Forum OpenACS Q&A: Re: Upload large files on Aolserver - Is moving to Naviserver the only way?
Upgraded! It has been quite straightforward thanks to the new scripts.
OpenAcs installer, during database configuration, probably makes use of unavailable syntax for postgresql 8.x, because failed the first time. Could be a configuration-specific problem tough, as I had to mess around with the conf in the past. Anyway, as I was already towards the idea of upgrading to postgres 9.x and to a supported distro, I switched my Debian repos from squeeze to wheezy and upgraded the distribution so I could installe postgres 9.1 .
actually, the new syntax of the postgres files works fine on pg 8.0, but recursive queries need 8.4. So, the first step should be to upgrade older instances (see http://openacs.org/xowiki/Postgres_9). New postgres versions might complain about upgrades containing the old syntax, therefore, one should upgrade with the old pg-version to be on the safe side.
To summarize, two kind of errors might show up:
- old pg version does not accept new SQL (argument passing need 8.0, recursive queries need 8.4)
- new pg version does not accept old SQL (backslash escaping in plain strings)
sudo is not really needed for the installation, it's convenient later... anyhow, added theses dependencies for debian and redhat to the script
Note that Debian doesn't install sudo by default, so install-oacs.sh should probably have it into requirements to run smooth on Debian.
I then made some tweakings to conform the installation to the 'Debian way' and feel more comfortable:
- moved root of the server to /var/lib/naviserver
- linked config.tcl into /etc/naviserver/conf.d/
keeping the server out of the "standard debian paths" has as well advantages. sooner or later we should have a debian naviserver package, that might conflict with your adapted installation.
what is this? ownership + permissions?
- created a sh script to store variables as user, group and port for the instance as was for the repo installation
Is there a reason for not using/adapting the provided upstart scripts?
- modified configurations so they matched instance name, db etc...
- copied /etc/init.d/aolserver4 to /etc/init.d/naviserver startup script and modified so it starts and stops naviserver properly, one instance for each configuration found in /etc/naviserver/conf.d/
here i am as well confused: for a new installations, this should not be necessary. for an upgrade (keeping old data), the dump/restore is missing.
- updated the code of the instance to oacs-5-8 branch by cvs
- created a db for the instance
- pointed browser to the instance and installed as usual
I can testify that memory consumption DROPPED. After two simultaneous uploads of 400MB each, the system occupies less than 100MB in resident memory, as stated by top, and inflates and shrinks under need. Before it was constantly increasing every time we tried to upload big files.
Since you are using though the script a local version of tcl, I'll send you a patch and short instructions how to use different mallocs...
all the best
Standard server root for packaged openacs in debian-like systems is /usr/share/openacs, which felt weird to me... I haven't really respected the debian convention, just put myself in a more familiar situation.
Another thing Debian did in the package and I replicated was the shell script. user and group are the ones the server is executed by. My replication was quite blind in this regard, just wanted to stick to the old package's style. Of course it is not necessary.
Debian doesn't install upstart by default, but sysvinit. Honestly tough, this is not the reason why I prepared the init.d script, I am just more used to it and wanted to feel at home...
In the end, as the data in previous site was not much, I decided to go for a clean install rather than upgrade. As I wanted to name the instance in a different way than oacs-HEAD, after openacs was installed I created another database for the instance and modified the configs of the new instance accordingly.
Thanks a lot for patch and hints!
Maybe we should provide command line switches to ease adaptation, but having a common set of parameters helps communication in forums, especially fro beginners.
Redhat went from sysvinit (fedora < 9) over upstart (fedora 9-14) to systemd (fedora > 14; currently 19). optionally spitting out sysvinit scripts should be no rocket science...