Forum OpenACS Q&A: Response to Enhancing the Installation Process: Automation.

Collapse
5: Response to Enhancing the Installation Process: Automation. (response to 1)
Posted by Lamar Owen on 08/30/00 05:43 PM
Did I hear my name? 😊

Working OpenACS RPM's that can meet the RPM criteria are going to be tough.  Doable, but tough.

Oh, getting an automated 5-minute install isn't the killer --- getting the automatic upgrade right is going to make for some sleepless nights.

First, there will need to be interaction between at least five RPM's:
postgresql
postgresql-server
aolserver
aolserver-nspostgres
openacs

(or sub openacs-postgres instead of aolserver-nspostgres).  This isn't difficult with RPM -- RPM knows about and can be taught package dependencies and installation order.

It becomes more difficult in the pre and post installation scriptlets. I call them scriptlets because you want to do the absolute minimum necessary here.  The more you do, the harder it is to debug, the more difficult it will be to get working right, and the less likely RedHat will ship it.

Debian's install scripts have far greater latitude here -- RPM's scriptlets are designed to do such mundane tasks as run ldconfig -- not parse and modify configuration files.

Now, default configs _can_ be placed.  But, currently, the ACS configuration is far too installation-specific -- there needs to be a single place for variable declarations for pageroot, etc -- while ad.tcl is a good template, there are _many_ variables defined that are terribly installation specific.

Now that I've given the pessimistic side, let's look a little closer at what we _can_ do:

We CAN separate a portion of the install out to utility scripts that can parse and mungle config files;

We CAN install the ACS to a central, nominally read-only 'holding cell' (such as /usr/share/openacs), that the utility installation script then pulls from and installs to the chosen webroot (but we CANNOT force a user into using /web as the webroot -- I lost count of how many places /web is hardcoded in the configs -- and RedHat most definitely won't ship a package requiring a new directory off the system root!);

We CAN make the upgrade of the 'holding cell' automatic -- but I don't think we should muck around with someone's live site during an automated upgrade;

We CAN use dirs under /etc for configuration, dirs under /var/lib for pageroots, dirs under /usr/share for shared data and master templates;

We CAN do all kinds of nonsense in scripts outside of the RPM scriptlets.

The current Debian package is a good starting point -- but for OpenACS RPM's to fly, a good set of AOLserver RPM's must fly.

I am ready, willing, and able to do any and all of these -- within my time constraints.  The last two months have been terrible -- the next two might not be so bad.

RedHat 7.0 is due Any Day Now (they just went public beta) -- RedHat 7.1 should theoretically be due sometime next March, if they stick to their typical six month schedule.  If we have the goal of solid RPM's by RedHat 7.1's freeze date (which likely will be mid to late January), then I believe, with some creative help, I can meet that goal.

There will be much to discuss and much to plan with these -- I know from hard experience that once you've released an RPM, you then have to upgrade from that RPM -- major changes to RPM structure become royal pains at that point.  So, the layout and installation procedure need to be worked out _first_ -- in fact, that doesn't need to be RPM-specific AT ALL -- the same scripts an RPM user would use to throw up an OpenACS site are just as usable for any OpenACS user.

But, I can already tell you, the current '/web'-centricity won't fly in the RPM world.  So, the installation procedure, layout, and scripts need to be applicable regardless of where OpenACS is installed -- use environment variables or global configuration files located in /etc/openacs to find everything.

Do it right, and I can even give you aolserver-chroot and openacs-chroot.

Then there's the upgrading issue.  Do we want to go there?  Just how upgradable is the exiting ACS installation?  No, a 'dump your data then reload it after loading a new datamodel' is not an upgrade path. Like the installation, the same scripts an RPM would use would be terrific for ANY ACS user -- not just an RPM user.  If you even want to use perl for those scripts, that's fine -- as perl is almast guaranteed to be installed on a working RedHat system

I'm currently at war over the PostgreSQL upgrade procedure -- or lack thereof -- there seems to almost be hostility towards the idea that a smooth upgrade is a pressing issue -- dump/restore has been done there so long that the foolishness of that approach is invisible to core developers.

I would hope to see a little more cooperation here for the needs of those who simply want to upgrade smoothly -- and a more flexible installation/upgrade situation means more ACS users, RPM or not.

And I'm willing to help out in this area as well.  Good solid installer/upgrader scripts central to the core ACS/OpenACS packages will make advocating the package much easier, both to RedHat, and to users of other packages.  Having specialized RPM install scripts won't help those who want to install OpenACS/AOLserver on a more secure OS (such as OpenBSD).  Let's try for the general case, then RPM's will be much easier and more robust.