Forum OpenACS Development: Re: RFC: automated installer

Posted by Tom Jackson on

Unfortunately OpenACS relies on many packages which the OpenACS community cannot demand be maintained, and available in rpm, etc. format. To require this is to say no to an auto installer.

Even OpenACS doesn't have a standard which adequately addresses running multiple independent installations on the same machine.

You only install sendmail once, same with qmail, daemontools, and a bunch of other standard packages. It makes sense to have rpms for these singleton packages. However AOLserver and OpenACS and PostgreSQL are often installed in multiple locations on the same machine. Plus you have to address the possibility that a user might not have root access to their machine and might want to install OpenACS with their own privileges.

Even if rpm packages existed, you still need to maintain an installation document to explain how to do the install. Users still have to find and deal with the same issues. What is needed is a tool to combine installations of multiple independent software products.

Also, note that it isn't rocket science to install any individual package. Most of the time is spent figuring out what options to use to ./configure, how to do the post install configuration, etc. The problem is in glueing the packages togeather (plus finding the up-to-date packages is a pita). OpenACS installation itself couldn't be easier, and with 5.0 it seemed to get even easier.

It is possible something as simple as 'configure' and 'gmake' could work. Some AOLserver modules have gmake targets to create release version of the module, so it is obvious it can be used to perform any command line task, handle dependencies, etc.

Posted by Joel Aufrecht on
Agreeing with Tom: the majority of installation errors seem to be problems getting the required setup working.  Once you get to the "install OpenACS" page of the install guide, you are pretty much home free.  That's why I think we need to rely on the packaging systems, and do what we can on our side to require a stable platform.
I've been playing with a multitude of different solutions to the installation in multiple places problem and found one easy solution that would translate easily to an rpm package.

first create all the rpms for the supporting software. (tcl, tdom, nsd-*, aolserver) these packages would all have the appropiate dependancies with each other.

then create the openacs rpm package (again with the appropiate dependancies) This package will not create an installed instance of openacs but create what unix sys-admins refer to as a skeleton directory as well as supplying a bunch of installation-generation scripts.

these scripts would then be used to run the useradd command (or equiv) to create the openacs user, database, directory structure.

the admin would then modify the site specific .conf file and WHamm0! they have openacs installed.

to the admin this could be made extremely easy if we made all the packages avalible from a yum or apt4rpm repo.

this would be the overall view from the admin's perspective:

apt-get install openacs

this downloads all the dependancies, and installs them

acsinit testinstall
vi /srv/openacs/testinstall/etc/config.tcl
svc -u testinstall

where acsinit is the propigation script and it sets up the directory structure into /srv/openacs/<username>

any thoughts to this method?