Forum OpenACS Improvement Proposals (TIPs): TIP #10 (Approved): Automation of Installation Process

I wanted to hear what people think about automating the installation process of all needed components of openacs/dotlrn (Postgres/Oracle, Aolserver, OpenACS/dotLRN, different supporting tools).

I was thinking about bash scripts that would cover all sections of the installation documentation:

This set of bash scripts could consist of i.e. one bash script for each section of the installation documentation and one additional bash script for a complete installation.

I have never worked with rpms before and only heard that they were not that easy to create.

Did anyone already work on something like that or put some thought into it? If I remember correctly this topic has been mentioned recently on the bboard. It was in connection with documentation and how time consuming it was to keep it updated.

Posted by Jade Rubick on
David, I think this is a great idea. This would address one of our biggest weaknesses, I think.
Posted by Frank N. on
This is something I have considered making in the past, but didn't work on in earnest as I'm not the world's greatest bash hacker. 😊

There are several reasons why we might need the flexibility of bash over a Linux dist format like RPMs or Debs, like being able to support different architectures (FreeBSD, OS X). We would need to pass a large number of parameters to the install process, which could be through a single, global and well commented config file. Then there are source modifications (OpenFTS doesn't even compile 'out-of-the-box' on FreeBSD), PG tuning (BLCKSZ, shared memory segment size, kernel limits, --enable-locale --enable-multibyte), format and location of startup scripts etc. Loads of fun! 😉

The current install docs are somewhat Linux centric, and a UNIX newcomer would face a few rough spots if trying to install OpenACS on, say, FreeBSD by following them. Personally I have adopted the habit of keeping a large file of shell command snippets around, for when I want to repeat a particular operation again, but a set of well tuned install scripts would certainly be welcome.

If someone champions the project and shows how it should be done, then I would like to help by modifying, testing and maintaining the FreeBSD/PG parts of the install system, if multiple architechtures will be supported. Note that an architecture may also be a Linux distro, like redhat or debian.

4: Re: TIP #10: Approved (response to 1)
Posted by Lars Pind on
Go for it! :)
> There are several reasons why we might need the flexibility of bash

If you are considering *BSD, etc. then the script should rather be plain sh, without bash' bells and whistles. Otherwise you'd end up with an install dependency of shells/bash...

I would, however, second the "don't make it sooo Linux (especially .rpm) centric".

BTW, what were the problems with OpenFTS when you tried it, Frank? It's been at least six month since I've installed it on one of my machines, and I can't really remember of any issues (other than you have tinker with Pg).

Posted by Frank N. on

I meant sh, not bash. ;)

From memory, then aolserver3.3ad13-oacs1-beta-src.tar.gz needs two tweaks to the source/makefiles to compile: One library not being named what the makefiles expect, and the removal of a pair of typedefs (u_int32_t, u_int8_t) in nssha1/nssha1.c, as the FreeBSD system include files already have those.

OpenFTS has the name for make ('make') hardwired into the makefiles in a few place, but expects it to be GNU make, which is called gmake on *BSD. Also I think the typedefs came up again, and I believe there was at least a third compile issue as well, which escapes me at the moment.

Other BSDisms needed to be taken into consideration are that all user/group modifications are done via the pw command, plus that . (dot) is not allowed as a username/group separator for chown/chmod. Here : (colon) is required.

There are probably more nitpicks, which I've forgotten about.

I will start on an sh script for a Unix/Oracle setup soon. If anyone wants to give me some hints on how to make it as adaptable as possible for other setups, especially Postgres/Linux, go ahead 😊

Janine told me that there is supposed to be an sh script for the Oracle install as it usually only installs through an X server. Does anyone have a link or already used an sh script for that?


Yeah, right you are about OpenFTS -- just tried to put it in on another box.  It also requires a small fix to to add "-I /usr/local/include/tcl8.3" which it does not add to INC path.

As for aolserver3.3... -- maybe when 5.0 comes out AOLServer 4 is always there...  It is not in the ports, though.  I'll try and see if latest beta compiles on FreeBSD out of the box -- that'l be an interesting test...

...and the answer is "it is completely hosed".
When I tried to install Oracle through the shell script instead of X, it never came close to working.
Peter Marklund has a postgres bash script I can email you.
Hey Joel,

could you send me Peter's bash script for Postgres? What would be the best documentation to base the scripts on? I heard that you've been working on some recently... What shell script did you use for your failed Oracle install? I heard that there are some hints in the Oracle installation docs. Could anyone point me to the exact spot?

Has anybody else experience with getting Oracle installed through a shell script?

If anyone else has a bash script for any part of the installation document, please send it to me (


I'm not sure what scripts Joel was refering to, but the scripts I use to auto-re-install OpenACS and .LRN can be checked out from CVS:

cvs -d checkout dotlrn-install


So are you proposing these installation scripts to be incorporated into OpenACS or what? From your tip description it seems that you're just asking for feedback about the goal.

On the Linux arena, AOLserver packages are being worked on, and there's a gentoo AOLserver package. PostgreSQL is packaged for all distributions. Perhaps this TIP should be reformulated to say that Peter's installation scripts (the OpenACS part) should be included in the main tar ball.


Hey Roberto,

I actually don't really mind that much about how we should do it, but I think that it should be integrated with the next release...

If I were a complete newbie and just wanted to *quickly* install everything and see how it is running, I would like to have one single button to push and everything would install automatically. This could maybe be accompanied with some kind of uninstall script.

I just installed a fresh RH8.0 server and spent around a day to get everything up and running. I followed the 4.6.3 installation docs and used some qmail daemontool stuff from HEAD, because qmail wouldn't work properly.

Next time I do all this, I would like to hit this magic button and everything would be set up the exact same way without having to worry about having skipped some lines from the docs.

If there is a better way than on huge sh script, I will go for that... But I would also like to be able to set up sites with a different character set than English, which requires unicode for PG. IMO this isn't covered by PG rpms... Frank also mentioned the flexibility aspect of an sh script in his post.


I do not personally understand anything about all the things you are writing about but, as Frank Nikolajsen wrote: "...I'm not the world's greatest bash hacker.", I just wanted to inform that there is a recently updated Advanced Bash-Scripting Guide online.
Sorry for disturbing, in case such a hint is too basic for you.
Hey Luigi,

no, the link is great... not too basic at all. Thanks.

Peter's scripts are already in the cvs tree.  They take a prepared machine with aolserver and database server already installed and put in everything necessary for a specific OpenACS service, leaving it a running, fully installed service.  They are not bulletproof yet, and so are mostly useful for developers working on Core who need to reinstall regularly.  I would like to add David's scripts when he feels they are ready - my understanding is that they automate the first part of the Install Guide, covering aolserver and the database.  The obvious next step is to go to a standard package - RPM, debian, FreeBSD port, etc.  The current barriers to that are 1) an OpenACS volunteer familiar with RPM/.deb/etc and 2) a binary package of AOLserver.
As this work is going in I think it's fair to say this was
in fact approved.