In short: it worked. But it was a long and not automated process.
As you may have seen in a couple of previous posts, there were problems. Most of them are inspired by acs-authentication, and there does not seem to be an easy way around it -- at least not to get the core up and running.
To sum it up, I had to do the following:
- As described in the docs, get updated OACS (tar ball from nightlies at old place worked just fine for me in the first test, but for the finishing move a fresh CVS checkout was used.
- Back up your database, back up the old filesystem tree (in my case all of what follows was done on a separate upgrade-test database).
- Manually run SQL upgrade scripts for:
- acs-kernel
- acs-service-contract
- Manually install data model for acs-authentication.
- Go to packages/acs-tcl/tcl and symlink content of packages/acs-authentication/tcl:
$ ln -sf ../../acs-authentication/tcl/*.* ./
- Create a "boot-strap" file as follows and put it under /www (I called it plug.tcl):
# quick-fixes for 4.6.3 - 5.0 migration
# do not mask out username in login box
apm_parameter_register "UsePasswordWidgetForUsername" \
"Should we hide what the user types in the username
field, the way we do with the password field? Set
this to 1 if you are us ing sensitive information
such as social security number for username." \
acs-kernel 0 number \
security 1 1
parameter::set_value -package_id [ad_acs_kernel_id] -parameter UsePasswordWidgetForUsername -value 0
# init acs-authentication
auth::package_install
I needed it to initialize acs-authentication, as well as to get kernel to stop complaining from out of acs-subsite/lib/login.tcl.
- Update authority_id for at least your site-wide admin user (you):
update users set authority_id = (
select authority_id
from auth_authorities
where enabled_p = 't'
) and user_id = your_user_id_here;
Note: I don't have any subsites on this instance, nor do I have any communities, etc. defined -- the above UPDATE may have to be different in your case. What you need to do is to get authority_id of your user to equal main-site authority_id.
- Start-up your server -- there should be no issues with it (in fact, mine started up even w/o all of the above -- it just was not very usable :))
- First of all, go to /plug.tcl -- this will fully initialize acs-authentication.
- Restart server.
- Go to /acs-admin/apm as instructed in the docs. You'll be redirected to login page, that will be all messed-up: acs-lang is not correctly installed at this moment.
- Log in. There should not be a problem with that.
- Follow the "Install packages" link.
- I have upgraded first kernel, subsite, service contract and installed authentication. For all (except of subsite) of the above I have deselected all of the data model upgrade sripts -- these were already loaded manually.
- Restart and upgrade whatever other remaining packages there are.
With several package upgrades there were issues, and I had to perform a few more manual operations to get it all right. Yet those were non-critical, since most of the core was successfully converted.
At some point I experienced a few issues with acs-lang (or possibly I thought I did) during the initial upgrade, but these did not re-occur.
No patches at this point -- can't really see what/how.
