Upgrading the OpenACS files

Chosing a Method to Upgrade your Files

OpenACS is distributed in many different ways: + +Upgrading the OpenACS files

Prev	Chapter�5.�Upgrading	Next

Upgrading the OpenACS files

Chosing a Method to Upgrade your Files

OpenACS is distributed in many different ways:

as a collection of files
as one big tarball
via CVS
via automatic download from within the APM (package manager)

Upgrades work by first changing the file system (via any @@ -9,8 +10,8 @@ using the last method, you can skip this page. This page describes whether or not you need to be upgrading using this page or not: - the section called “Upgrading an OpenACS 5.0.0 or greater installation” -

Methods of upgrading OpenACS files

Upgrading files for a site which is not in a CVS repository.�Unpack the tarball into a new directory and copy its + Section�, “Upgrading an OpenACS 5.0.0 or greater installation” +

Methods of upgrading OpenACS files

Upgrading files for a site which is not in a CVS repository.�Unpack the tarball into a new directory and copy its contents on top of your working directory. Or just 'install software', select remote repository, and upgrade your files from there.

[root root]# su - $OPENACS_SERVICE_NAME
@@ -31,7 +32,7 @@
         with the latest OpenACS version, without overriding your own
         local customizations. 
This diagram explains the basic idea. However, the
         labels are incorrect. Step 1(a) has been removed, and Step
-        1(b) should be labelled Step 1.
Figure�5.2.�Upgrading a local CVS repository
Step 0: Set up a working CVS checkout.�
To get your OpenACS code into your local CVS
+        1(b) should be labelled Step 1.
Figure�5.2.�Upgrading a local CVS repository
Step 0: Set up a working CVS checkout.�
To get your OpenACS code into your local CVS
                 repository, you will set up a working CVS checkout of
                 OpenACS. When you want to update your site, you'll
                 update the working CVS checkout, import those changes
@@ -66,10 +67,10 @@
 [$OPENACS_SERVICE_NAME aolserver]$ cvs up -Pd ChangeLog *.txt bin etc tcl www packages/*

Update a single package via cvs working checkout.�You can add or upgrade a single package at a time, if you already have a cvs working directory.
```
[root root]# su - $OPENACS_SERVICE_NAME
 [$OPENACS_SERVICE_NAME aolserver]$ cd /var/lib/aolserver/packages/openacs-5-1
 [$OPENACS_SERVICE_NAME openacs-5-1]$ cvs up -Pd packagename
```
In the next section, the import must be tailored to just this package.

Step 2: Merge New OpenACS code.�Now that you have a local copy of the new OpenACS code, you need to import it into your local CVS repository and resolve any conflicts that occur.

Import the new files into your cvs repository; where they match existing files, they will become the new version of the file.

[$OPENACS_SERVICE_NAME openacs-5-1]$  cd /var/lib/aolserver/openacs-5-1
-[$OPENACS_SERVICE_NAME openacs-5-1]$  cvs -d /var/lib/cvs import -m "upgrade to OpenACS 5.1" $OPENACS_SERVICE_NAME OpenACS openacs-5-1
+[$OPENACS_SERVICE_NAME openacs-5-1]$  cvs -d /var/lib/cvs import -m "upgrade to OpenACS 5.1" $OPENACS_SERVICE_NAME OpenACS openacs-5-1

Tip

If adding or upgrading a single package, run the cvs import from within the base directory of that package, and adjust the cvs command accordingly. In this example, we are adding the myfirstpackage package.

[root root]# su - $OPENACS_SERVICE_NAME
 [$OPENACS_SERVICE_NAME aolserver]$ cd /var/lib/aolserver/openacs-5-0/package/myfirstpackage
-[$OPENACS_SERVICE_NAME myfirstpackage]$ cvs -d /var/lib/cvs/ import -m "importing package" $OPENACS_SERVICE_NAME/packages/myfirstpackage OpenACS openacs-5-1

Create a new directory as temporary working space to +[$OPENACS_SERVICE_NAME myfirstpackage]$ cvs -d /var/lib/cvs/ import -m "importing package" $OPENACS_SERVICE_NAME/packages/myfirstpackage OpenACS openacs-5-1

Create a new directory as temporary working space to reconcile conflicts between the new files and your current work. The example uses the cvs keyword yesterday, making the assumption that you haven't checked in new code to @@ -86,7 +87,7 @@ (you may have to click Ctrl-space at the beginning of the file, and go to the end, and then try M-x sort-lines) and then, for each line that starts with a C, open that file and manually resolve the conflict by deleting the excess lines. When you're finished, or if there aren't any conflicts, save and exit.

Once you've fixed any conflicts, commit the new code to your local tree.

[$OPENACS_SERVICE_NAME tmp]$ cd $OPENACS_SERVICE_NAME-upgrade
-[$OPENACS_SERVICE_NAME $OPENACS_SERVICE_NAME-upgrade]$ cvs commit -m "Upgraded to 5.1"

Step 3: Upgrade your local staging site.�Update your working tree with the new files. The CVS flags ensure that new directories are created and pruned directories destroyed.

[$OPENACS_SERVICE_NAME $OPENACS_SERVICE_NAME-upgrade]$ cd /var/lib/aolserver/$OPENACS_SERVICE_NAME
+[$OPENACS_SERVICE_NAME $OPENACS_SERVICE_NAME-upgrade]$ cvs commit -m "Upgraded to 5.1"

Step 3: Upgrade your local staging site.�Update your working tree with the new files. The CVS flags ensure that new directories are created and pruned directories destroyed.

[$OPENACS_SERVICE_NAME $OPENACS_SERVICE_NAME-upgrade]$ cd /var/lib/aolserver/$OPENACS_SERVICE_NAME
 [$OPENACS_SERVICE_NAME $OPENACS_SERVICE_NAME]$ cvs up -Pd
 (CVS feedback)
 [$OPENACS_SERVICE_NAME $OPENACS_SERVICE_NAME]$ exit
@@ -95,12 +96,12 @@
       
[$OPENACS_SERVICE_NAME ~]$ cd /var/lib/aolserver/$OPENACS_SERVICE_NAME
 [$OPENACS_SERVICE_NAME $OPENACS_SERVICE_NAME]$ cvs up -Pd
 (CVS feedback)
-[$OPENACS_SERVICE_NAME $OPENACS_SERVICE_NAME]$

Upgrading a Production Site Safely

If you are upgrading a production OpenACS site which is on a private CVS tree, this process lets you do the upgrade without risking extended downtime or an unusable site:

Declare a freeze on new cvs updates - ie, you cannot run cvs update +[$OPENACS_SERVICE_NAME $OPENACS_SERVICE_NAME]$

Upgrading a Production Site Safely

If you are upgrading a production OpenACS site which is on a private CVS tree, this process lets you do the upgrade without risking extended downtime or an unusable site:

Declare a freeze on new cvs updates - ie, you cannot run cvs update on the production site
Make a manual backup of the production site in addition to the automated backups
Import the new code (for example, OpenACS 5.0.4, openacs-5-0-compat versions of - ETP, blogger, and other applications) into a "vendor branch" of the - $OPENACS_SERVICE_NAME CVS tree, as described in "Upgrading a local CVS repository", step 1, above. + ETP, blogger, and other applications) into a "vendor branch" of the + $OPENACS_SERVICE_NAME CVS tree, as described in "Upgrading a local CVS repository", step 1, above. As soon as we do this, any cvs update command on production might bring new code onto the production site, which would be bad.
Do step 2 above (merging conflicts in a $OPENACS_SERVICE_NAME-upgrade working tree).
Manually resolve any conflicts in the working upgrade tree @@ -109,5 +110,5 @@ have a new website called $OPENACS_SERVICE_NAME-upgrade.
Test the $OPENACS_SERVICE_NAME-upgrade site -
If $OPENACS_SERVICE_NAME-upgrade is fully functional, do the real upgrade.
1. Take down the $OPENACS_SERVICE_NAME site and put up a "down for maintenance" page.
2. Repeat the upgrade with the most recent database
3. Test the that the new site is functional. If so, change the upgraded site to respond to +
4. If $OPENACS_SERVICE_NAME-upgrade is fully functional, do the real upgrade.
  1. Take down the $OPENACS_SERVICE_NAME site and put up a "down for maintenance" page.
  2. Repeat the upgrade with the most recent database
  3. Test the that the new site is functional. If so, change the upgraded site to respond to yourserver.net requests. If not, bring the original production site back up and return to the merge.

Prev	Home	Next
Upgrading an OpenACS 5.0.0 or greater installation	Up	Upgrading Platform components

docs@openacs.org

View comments on this page at openacs.org