Forum OpenACS Q&A: Upgrading from OpenACS 4.5 to 4.6

Collapse
Posted by Jade Rubick on
Quick question:

My understanding of what I need to do is:

1. Down the webserver
2. Update the code from OpenACS 4.5 to 4.6
2b. If there are any conflicts in the code, resolve them.
3. Boot up the webserver
4. Go to the APM, and go to install packages, and it should automagically do all the datamodel changes.
5. Restart the server
6. Thank everyone for making such a slick package manager.

My questions:

1. Is that right?
2. I'm confused at how to do step 2. I have my cvs repository at /cvsweb, and my code in /web/safe4all-dev    This seems like a perfect thing for CVS, but I seem to have forgotten how to do this. The last time I did this was a year ago, when I was ungrading ACS 3.4.9 to 3.4.10, and there was some documentation on how to do this.. Can't find it now.

Sorry to be asking for help all the time. I try to answer any questions I can help out with. 😊

Collapse
Posted by Jade Rubick on
So far as I can tell so far:

https://openacs.org/4/checkout

Describes how to download the code using CVS

http://www.piskorski.com/docs/cvs-conventions.html

Describes some clues as to how to do the upgrade. I'm going to see if I can figure it out (hopefully without screwing up my cvs repository :)

Collapse
Posted by Jade Rubick on
the cvsbook describes how to track third party sources very well.

Here's what I did:

  • cd /tmp
  • cvs -z3 -d :pserver:anonymous@openacs.org:/cvsroot co openacs-4
  • cvs -d /cvsroot -q import -m "Import of OpenACS 4.6" safe4all OpenACS openacs-4-6
    Here's the message I got after I finished
    12 conflicts created by this import.
    Use the following command to help the merge:
    
            cvs -d /cvsroot/ checkout -jOpenACS:yesterday -jOpenACS safe4all
    
    
  • However, when I try this:
    cvs -d /cvsroot/ checkout -jOpenACS:yesterday -jOpenACS safe4all
    cvs checkout: existing repository /cvsroot//openacs-4 does not match /cvsroot//safe4all
    cvs checkout: ignoring module safe4all
    
I think I'm missing something. Any clues?
Collapse
Posted by Jade Rubick on
Looks like I had to...

cd /web/safe4all-dev/
and then do the conflict report.

Collapse
Posted by Don Baccus on
Important first step:

Back up your live database.

Just so you won't be hosed if you run into an upgrade script problem.

You also have to visit the install packages page to see the upgrades options.  I think.

Collapse
Posted by Joel Aufrecht on
My work-in-progress upgrade guide:

http://aufrecht.org/openacs-4.6-quick-guide/ch03s02.html

It includes these steps (in more detail):

  1. Make a Backup.
  2. Drop the OpenFTS Engine
  3. Build and install the new OpenFTS driver
  4. Stop the server and upgrade the files.
  5. Install new database commands required for OpenFTS 0.3.2.
  6. Upgrade the kernel
  7. Upgrade other packages
  8. Install the new OpenFTS Engine.
  9. Outstanding problems:
        there are somewhere between one and an infinite number of problems with static pages/search, including two or three bugs that are supposed to be fixed in 4.6.1.  After spending many hours working on it in a repeatedly rebuilt dev environment, I gave up and pulled search offline for now.

  10. Instructions for rollback of database and files if necessary

Feedback would be much appreciated.  This is eventually bound for the official docs, I think.

Collapse
7: APM spits at me! (response to 6)
Posted by Jade Rubick on
Joel, that is some great documenation. Great work!

I've updated the source code, and merged it via cvs. I then brought up aolserver, and went to the APM page, and tried to install the kernel updates. Before I even got that far:

Package Installation

    Your Workspace : ACS System Wide Administration : ACS Package Manager : Package Installation

Please wait while the installer loads ........

  HTTP/1.0 200 OK Server: AOLserver/3.3.1+ad13 Content-Type: text/html; charset=iso-8859-1 MIME-Version: 1.0 Date: Sun, 16 Feb 2003 04:22:53 GMT Content-Length: 2694 Connection: close

Request Error

Invalid file type "message_catalog"
    while executing
"error "Invalid file type \"$type\"""
    (procedure "apm_read_package_info_file" line 152)
    invoked from within
"apm_read_package_info_file $spec_file"
    ("foreach" body line 2)
    invoked from within
"foreach spec_file $all_spec_files {
    array set version [apm_read_package_info_file $spec_file]
    set version_name $version(name)
    set package_..."
    ("uplevel" body line 37)
    invoked from within
"uplevel {
          ad_page_contract {

    Select, dependency check, install and enable packages.

    @author Bryan Quinn (mailto:bquinn@arsdigita.com)
    @c..."
    (procedure "code::tcl::/web/safe4all-dev/safe4all/packages/acs-admin/www..." line 2)
    invoked from within
"code::tcl::$__adp_stub"
    invoked from within
"if { [file exists $__adp_stub.tcl] } {

      # ensure that data source preparation procedure exists and is up-to-date
      adp_init tcl $__adp_stub
..."
    ("uplevel" body line 3)
    invoked from within
"uplevel {

    if { [file exists $__adp_stub.tcl] } {

      # ensure that data source preparation procedure exists and is up-to-date
      adp_init t..."
    (procedure "adp_prepare" line 2)
    invoked from within
"adp_prepare "
    (procedure "template::adp_parse" line 30)
    invoked from within
"template::adp_parse [file root [ad_conn file]] {}"
    (procedure "adp_parse_ad_conn_file" line 7)
    invoked from within
"$handler"
    ("uplevel" body line 2)
    invoked from within
"uplevel $code"
    invoked from within
"ad_try {
        $handler
      } ad_script_abort val {
        # do nothing
      }"
    invoked from within
"rp_serve_concrete_file [ad_conn file]"
    (procedure "rp_serve_abstract_file" line 60)
    invoked from within
"rp_serve_abstract_file "$root/$path""
    ("uplevel" body line 2)
    invoked from within
"uplevel $code"
    invoked from within
"ad_try {
        rp_serve_abstract_file "$root/$path"
        set tcl_url2file([ad_conn url]) [ad_conn file]
        set tcl_url2path_info([ad_conn url]) [ad_conn path_inf..."

Collapse
Posted by Jade Rubick on
Thanks for the advice, Don. I backed up the database, but I made the (huge) mistake of not tagging my cvs repository at the state it was at before I imported the new vendor tags. I'm not sure if it's going to be possible to easily go back to where I was at.

By the way, I want to correct my comment above about cd /web/safe4all-dev/ and then doing the conflict report. That appears to be the wrong way to go about it. You're supposed to create it in another directory.

Any idea of how to get around the error I'm having? Isn't the message_catalog related to internationalization? (I don't know why I thought that). It seems strange that the APM would barf on something like this. I thought it was supposed to handle the upgrades more smoothly. I suppose I could have screwed something up, but I was pretty careful...

Help? 😊

Collapse
Posted by Joel Aufrecht on
You can recover your cvs tree to a pre-upgrade state by dae as well as by tag.  Suppose everything worked on 31 Dec 2002 and then on 1 Jan 2003 you imported a bunch of new stuff.  To reset:
cvs up -D 01/31/2002

To be aggressive (clearing out directories, etc)
cvs up -APCd -D 01/31/2002

Collapse
Posted by Peter Marklund on
Jade,
I am definetely to blame for that last "message_catalog" filetype error message that you are getting, sorry about that!

However, you should only be experiencing this error when upgrading to 4.7 not 4.6 (4.6 should be clean of any I18N traces). Are you sure you are on 4.6? Could you do

find -iname '*.info'|xargs grep -l message_catalog| xargs cvs status -v

to see the cvs status of the info files that contain message catalogs.

If you are indeed upgrading to 4.7 the workaround is to execute:

insert into apm_package_file_types(file_type_key, pretty_name) values(''message_catalog'', ''Message Catalog'');

Hope that helps!

Peter

Collapse
Posted by Jade Rubick on
Thanks for the reply, Peter!! I didn't intend to download 4.7... It's not final, right? If I did upgrade to 4.7, would I be able to upgrade again later, to the real 4.7?

[joeuser@safe4all safe4all]$ find -iname '*.info'|xargs grep -l message_catalog| xargs cvs status -v
===================================================================
File: acs-kernel.info  Status: Up-to-date

  Working revision:    1.1.1.2 Sun Feb 16 17:10:17 2003
  Repository revision: 1.1.1.2 /cvsroot/safe4all/safe4all/packages/acs-kernel/acs-kernel.info,v
  Sticky Tag:          (none)
  Sticky Date:        2003.02.16.17.13.38
  Sticky Options:      (none)

  Existing Tags:
        openacs-4-6                    (revision: 1.1.1.2)
        openacs-4-5                    (revision: 1.1.1.1)
        OpenACS                        (branch: 1.1.1)

===================================================================
File: acs-lang.info    Status: Up-to-date

  Working revision:    1.1.1.2 Sun Feb 16 17:10:17 2003
  Repository revision: 1.1.1.2 /cvsroot/safe4all/safe4all/packages/acs-lang/acs-lang.info,v
  Sticky Tag:          (none)
  Sticky Date:        2003.02.16.17.13.38
  Sticky Options:      (none)

  Existing Tags:
        openacs-4-6                    (revision: 1.1.1.2)
        openacs-4-5                    (revision: 1.1.1.1)
        OpenACS                        (branch: 1.1.1)

Collapse
Posted by Peter Marklund on
Jade,
so you are indeed on cvs head - good to know. cvs head is far less reliable than 4.6 (4.7 won't be released until maybe this summer). However, if you want I18N you should go with cvs head. For encouragement, I am using cvs head on my homepage, and we also obviously use it for the dotlrn translation server.

If you do go with cvs head now you will be able to upgrade to 4.7 later as we are taking upgrade scripts very seriously. When/if you find glitches (like you just did) we will fix them.

I committed an attempt to fix the broken APM upgrade UI by making it not error out on unrecognized file types (instead log a warning) and by supplying an upgrade script to acs-kernel that adds the message_catalog filetype (new version of acs-kernel is 4.7.2d).

However for this to work the message_catalog file type must be added before the APM attempts to insert the new catalog files (because of referential integrity). This requires the acs-kernel package to be upgraded before any other packages that have message catalog files are upgraded or installed. A safe way to achieve this would be to set the required version of acs-kernel of all packages that have message catalog files to be 4.7.2d. This may not be necessary, maybe acs-kernel gets installed first anyway, I don't know.

/Peter