Forum .LRN Q&A: Re: Upgrade OpenACS Debian 3.1 32 bits

Collapse
Posted by Érico Guimarães on
Dear Gustaf,

Let me put first this way:I don't want to work with legacy but make it work in a brand new VMware DebianAMD64 bits.If only I could make my legacy work into dotlrn2.5, openacs into i have installed in this new debian AMD64bit thru apt-get tool I would be very happy. Is it possible? I have been looking for migration steps but as we took to long to decide on upgrading I failed to find a step by step. I tried even to make the new dotlrn work with SGBD restored but did not work.

Collapse
Posted by Gustaf Neumann on
A fresh install of dotlrn 2.5 based on the debian packages is supposed to work as indicated on the wiki page. With the fresh install, you get at least the compiled binaries (aolserver, postgres driver, xotcl, libthread, ...) and a working version, but my guess is that you want to migrate the data from your existing dotlrn site.
correct?

You should be able to run the various upgrade scripts on your existing database and use the resulting database with the debian binaries.

Have you read through the dotlrn upgrade guidelines?
http://www.openacs.org/forums/message-view?message_id=243862

Collapse
Posted by Érico Guimarães on
Sure. I succeeded in installing and configuring dotlrn 2.5, aolserver, xotcl and so on Debian AMD64 Virtual Box. What I did afterwards is copying /var/lib/aolserver/myappl/.../content_repositories, backed up old data of Postgresql 8.1 restored both the appl and the SGBD into the new AMD 64 Debian.

The psql command ran smoothly into the AMD64 bits POSTGRESQL 8.4. But the legacy application did not work, as you could see in the post before

I will take my time, drink some wine as winter is coming and trying to upgrade as per instructions on the guidelines you kindly have sent me.

Anyway, I apologize in taking your precious time and to long to answer as I was travelling and soon you might hear from me about the progress I hope I make in upgrading, if you could be kind enough to read it.

Regards.

Collapse
Posted by Gustaf Neumann on
Érico,

it's not clear to me, what the "legacy application" exactly is (own package and modifications of dotlrn, or just the existing data). Anyhow, the way to upgrade your installation to dotlrn 2.5 and to move then this data into a debian installation should be something in the lines of:

a) make a backup of your installation (primarily in the file-system SOMEPLACE/{packages,www.content-repository-content-files}/* and make a dump of the existing pg database)

b) get dotlrn-2.5.0.tar.gz (or via CVS), unpack it and start the new sources with your config-file (and your database).

c) Now, the installation should be sufficiently alive to run the upgrade scripts in your installation. Browse to http://YOURSERVER/acs-admin/apm/. On this page, you will find "install packages". If you click there, OpenACS/Dotlrn compares the installed versions in your your old database and compares it with the versions currently running to determine, what upgrade (migration) scripts should run. As a precaution, i would recommend to run first the upgrade scripts from openacs, restart the server, and run the upgrade scripts from dotlrn.

d) if everything goes well, you have upgraded your installation from dotlrn 2.1.3 to dotlrn 2.5 and you can move your data to the debian installation (32 ot 64 bit) to get the new binaries without the need of compilation. Dump the database, load it into the database of the debian installation (take care about the database name), move over the content-repository files from your existing installation, update the start script to use the right database, and in theory, you are done and can run dotlrn 2.5.* with your old data from there-

This should be the rough guidelines, not taking into account some additional packages outside dotlrn which might be in you installation.

Hope, this helps....

-gustf neumann

Collapse
Posted by Érico Guimarães on
Legacy means in this context two services, separate in Servers: one with Debian 3.1 32 bit (know it is too old!!😟) with a modified dotlrn2.1 (basically on the theme) and its content-repository if possible; and another Server with Debian 6.0 32 bit running Postgresql 8.1, which I actually backed and pg_restored in a PostgreSQL 8.4.9 Debian AMD 64 bit environment test, where the application dotlrn dwells too. I saw no mistakes during data restoration.

I did two tests: one over the brand-new apt-get installed dotlrn and its dependencies environment, where I could reach admin front page, register myself and log in successfully.

The command ps -es reads as follows:

www-data  9894     1  0 15:00 ?        00:00:00 /usr/sbin/aolserver4-nsd -u www-data -g www-data -b 127.0.0.1:80 -s main -t /etc/aolserver4/aolserver4.tcl
www-data  9906     1  2 15:01 ?        00:00:19 /usr/sbin/aolserver4-nsd -u www-data -g www-data -b 0.0.0.0:8000 -s dotlrn -t /etc/aolserver4/conf.d/dotlrn.tcl
postgres  9918  8929  0 15:01 ?        00:00:01 postgres: www-data dotlrn [local] idle                                                                                      
.......                                                       
www-data 10079     1  0 15:04 ?        00:00:01 /usr/sbin/aolserver4-nsd -u www-data -g www-data -b 0.0.0.0:8080 -s dotlrn -t /etc/aolserver4/conf.d/coptec.tcl
postgres 10084  8929  0 15:04 ?        00:00:00 postgres: 
....                                    
As you can see, I downloaded and installed dotlrn 2.5 and I can run it on X.X.X.X:8000/dotlrn successfully, with Zen theme. Ok?

Well, the second test I did was based on the link http://www.openacs.org/forums/message-view?message_id=243862 You have sent me before. In short, I copyed dotlrn.tcl to coptec.tcl, changed de database name for my old dotlrn application unico and port to 8080; everything on the new Debian AMD 64 bit server. From command line, I ran:

root@coptecvirtual:/usr/share/dotlrn# /usr/sbin/aolserver4-nsd -u www-data -g www-data -b 0.0.0.0:8080 -s dotlrn -t /etc/aolserver4/conf.d/coptec.tcl &

And ps -ef command reads as follows:

www-data 10079     1  0 15:04 ?        00:00:01 /usr/sbin/aolserver4-nsd -u www-data -g www-data -b 0.0.0.0:8080 -s dotlrn -t /etc/aolserver4/conf.d/coptec.tcl
postgres 10084  8929  0 15:04 ?        00:00:00 postgres: www-data unico [local] idle 
I even managed to access host remotely, in order to access this new server Debian AMD64bit machine from my Ubuntu Desktop (actually this Debian 64bit resides virtually on my Desktop😊)

However,when I type on my browser http://X.X.X.X:8080/dotlrn this mistake, the following screen appears:

Request Error
Server startup failed: Error during bootstrapping

    Database operation "0or1row" failed
    (exception ERROR, "ERRO:  permissão negada para relação apm_package_versions
    ")

        while executing
    "ns_pg_bind 0or1row nsdb0 {
          select 1 from apm_package_versions
          where package_key = :package_key
          and installed_p = 't'
        }"
        ("uplevel" body line 1)
        invoked from within
    "uplevel $ulevel [list ns_pg_bind $type $db $sql]"
        ("postgresql" arm line 2)
        invoked from within
    "switch $driverkey {
                    oracle {
                        return [uplevel $ulevel [list ns_ora $type $db $sql] $args]
                    }
           ..."
        invoked from within
    "db_exec 0or1row $db $full_name $sql"
        invoked from within
    "set selection [db_exec 0or1row $db $full_name $sql]"
        ("uplevel" body line 2)
        invoked from within
    "uplevel 1 $code_block "
        invoked from within
    "db_with_handle -dbn $dbn db {
                set selection [db_exec 0or1row $db $full_name $sql]
            }"
        (procedure "db_string" line 27)
        invoked from within
    "db_string apm_package_installed_p {} -default 0"
        (procedure "apm_package_installed_p_not_cached" line 2)
        invoked from within
    "apm_package_installed_p_not_cached $package_key"
        (procedure "apm_package_installed_p" line 5)
        invoked from within
    "apm_package_installed_p acs-kernel"
        (procedure "ad_verify_install" line 8)
        invoked from within
    "ad_verify_install"
...
, which prevents me from reaching http://X.X.X.X:8080/acs-admin/apm/ (actually if i put on scratch acs-admin/apm after 8080, the same page appears) to start de upgrade process, as per instructions on that link mentioned aforesaid. I think there is something I am still missing....

Bests Regards.

Collapse
Posted by Gustaf Neumann on
if google translate serves me well the error message seems to indicate that the user connecting to the database has insufficient rights. Can it be that you connected from your old application with a different pg user to the database?
Collapse
Posted by Érico Guimarães on
Gustaf,

Good afternoon. Please find below the steps taken:
1) Installed and Configured only one server Debian64AMD bit ;
2) I "apt-got" openacs, Postgresql 8.4, aolserver4, dotlrn25 from that repository successfully;
3) I backed up both old appl dotlrn 2.1 debian 3.1 SERVER and database debian 6.0 Postgres 8.1 sERVER and restored both on DebianAMD64 bit. That is, I had TWO SERVERS for may dotlrn env;
4) First I tried to make old appl and restored database into this DebianAMD64, all localhost, both appl and database. Lots of mistakes as I said before;
5) I followed your instructions sent before, including the URL http://www.openacs.org/forums/message-view?message_id=243862. In short, I configured dotlrn2.5 and managed to run on port 8000 successfully. Then, I copied dotlrn.tcl, renamed to coptec.tcl and changed port, database rights and etc. This time I have assigned dotlrn2.5, as per previous instructions, to the restored database. I succeeded in connecting to the restored database and produced a 184k warn and error with 9724 lines, named coptec.log. I would post it here but it is too long. If there is a way to post it or if you would be kind enough as to give me a e-mail address so that it can be delivered to you at you earliest convenience, I would be very grateful.
Best Regards

Collapse
Posted by Gustaf Neumann on
Dear Érico,

addressing the migration problem via forum has a better multiplicator than individual mails, and more eyes can spot different problems. Normally, there is no need to send/show the full error.log since later errors are typically consequences of earlier errors. Find in your error.log the place where the server starts and search for the first "Error:". Post this with a context of about 20 lines here....

all the best
-gustaf neumann