| Prev | Chapter�5.�Upgrading | Next |
|---|
OpenACS is distributed as a collection of files, available as one big tarball, via CVS, and via automatic download from within the APM. Upgrades work by first changing the file system (via any of the previous methods), and then using the APM to scan the file system, find upgrade scripts, and execute them. This section describes how to upgrade the file system. Starting with OpenACS 5.0, this section can generally be skipped because the OpenACS APM can directly download new files from the openacs.org repository.
Many OpenACS site developers operate their own CVS repository to keep track of changes from the release OpenACS code. This part describes how to import the latest OpenACS version into your own repository. If you are using CVS, you will unpack the OpenACS 5.1 tarball into a working directory and then import that directory into cvs. If you have changed files in the core packages, cvs will attempt to merge your changes. You may have to manually merge some conflicts. When that's finished, you can update your normal development checkout directory and the new files will appear. If you aren't using CVS, you can unpack the tarball on top of your existing tree, but any customizations you've made to the kernel or core packages will be erased.
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.
[root root]# su - $OPENACS_SERVICE_NAME +Upgrading the OpenACS files OpenACS is distributed as a collection of files, available as one big tarball, via CVS, and via automatic download from within the APM. Upgrades work by first changing the file system (via any of the previous methods), and then using the APM to scan the file system, find upgrade scripts, and execute them. This section describes how to upgrade the file system. Starting with OpenACS 5.0, this section can generally be skipped because the OpenACS APM can directly download new files from the openacs.org repository.
Many OpenACS site developers operate their own CVS repository to keep track of changes from the release OpenACS code. This part describes how to import the latest OpenACS version into your own repository. If you are using CVS, you will unpack the OpenACS 5.1 tarball into a working directory and then import that directory into cvs. If you have changed files in the core packages, cvs will attempt to merge your changes. You may have to manually merge some conflicts. When that's finished, you can update your normal development checkout directory and the new files will appear. If you aren't using CVS, you can unpack the tarball on top of your existing tree, but any customizations you've made to the kernel or core packages will be erased.
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.
[root root]# su - $OPENACS_SERVICE_NAME [$OPENACS_SERVICE_NAME aolserver]$ cd /var/lib/aolserver [$OPENACS_SERVICE_NAME web]$ tar xzf /tmp/openacs-5-1.tar.gz [$OPENACS_SERVICE_NAME web]$ cp -r openacs-5-1/* openacs-4 @@ -10,7 +10,7 @@ cp -r openacs-5-1/* openacs-4 exitUpgrading files for a site in a private CVS repository -
Step 1: Import new CVS code.�There are two common ways to get new OpenACS code into your local CVS repository - via tarball or with a working CVS checkout of OpenACS. Both methods work well for starting your local repository; the second method is better for incremental additions or upgrades.
(a): via tarball.�Download a current tarball and unpack the new files into a working directory.
[root root]# su - $OPENACS_SERVICE_NAME +
Step 1: Import new CVS code.�There are two common ways to get new OpenACS code into your local CVS repository - via tarball or with a working CVS checkout of OpenACS. Both methods work well for starting your local repository; the second method is better for incremental additions or upgrades.
(a): via tarball.�Download a current tarball and unpack the new files into a working directory.
[root root]# su - $OPENACS_SERVICE_NAME [$OPENACS_SERVICE_NAME aolserver]$ cd /tmp [$OPENACS_SERVICE_NAME tmp]$ tar xzf openacs-5-1.tar.gz [$OPENACS_SERVICE_NAME tmp]$ cd openacs-5-1(b): via cvs working checkout.�Create a CVS checkout from OpenACS. The first time you do this, you will need to create the checkout directory. We use one dedicated directory for each branch of OpenACS - if you are using OpenACS 5.0,x, you only need an OpenACS 5.0 branch. The openacs-5-1-compat tag identifies the latest released version of OpenACS 5.1 (ie, 5.1.3 or 5.1.4) and the latest compatible version of each package, including .LRN. Each minor release of OpenACS since 5.0 has this tagging structure. For example, OpenACS 5.1.x has openacs-5-1-compat. @@ -44,7 +44,7 @@
[$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]$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]$
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
