Forum OpenACS Q&A: Re: Instant gratification OpenACS installation documentation needed

Ok, I'll weigh in in this.  First, a quick-install guide would be nice.  However, is it really an issue since the toolkit requires significant customization anyway?  This is not an easy toolkit.

Joel Wrote: "- Assume that people have PG installed already, or tell them how to do so with an RPM or a Debian package

What is the most official PostGreSQL RPM?  Does it meet our needs?  If not, can we use it and do some post-install steps in another RPM?  Or fork the RPM?  Or get our needs met in the official RPM?"

Ok, the 'most official PostgreSQL RPM' is the one that came with your distribution.  If its version isn't high enough, the generic postgresql.org set that I maintain is always available.  If you tell me what unique needs you may have, I can easily get that in the 'Official' set I maintain, given a good reason for the need.  One thing I won't do is create a database in the post install script.  Can't, due to where my RPM code gets used (OS installs can't do this; my RPM is the base for RPMs that have to live in the OS install/upgrade environment).  All you have to do to get the initial database is, as root,

/sbin/service postgresql start

which isn't very hard.

I think OpenACS currently needs to be able to call sendmail (or a lookalike wrapper) to send outgoing mail.  Port 25 is for incoming mail.  Should the RPM require one of several compliant mail packages (which ones) or just not care about mail?

Red Hat ships both sendmail and postfix, and allows switching using the 'alternatives' system.  Using ns_sendmail and the standard MTA port will work virtually anywhere, including a stock  Red Hat install that doesn't accept port 25 connections from anywhere but localhost.  On Red Hat, you can have the RPM Require: smtpdaemon, and that will get any RPM-installable MTA that provides smtpdaemon (the Red Hat packages provide this for both sendmail and postfix).  It is probably reasonable to assume that the person this quick install is targeted to will be running one of these two. Do we want to fork another process for sendmail?


- Ignore daemontools, backups, local cvs tree, and all the other elements of a production installation.

The current documentation has all of this as optional.  Has anybody run the documentation and skipped the optional steps?  How intrusive is it?  Does it work?

I found the cvs and daemontools portions distracting, and I'm not a newbie.

This argues for a distinct quick-install guide.  Maybe we should have the quick-install with RPMs and the full install with source?

A 'README.quick-install' file is sufficient.  However, that statement almost makes it sound like a from-RPM install wouldn't be a 'full' install.  That is fallacious, IMO.

won't work.  So we should identify what things people want to see when they evaluate the product, and make sure those work.  And we should try to keep the quick guide compliant with the Reference platform so that it's easy to move to production or to incrementally add production-quality features like source control.

JMHO, but I think there's too much in the install documents.  I personally think we should address CVS issues, daemontools issues, backups, etc as separate documents. Tell them how to install it; then tell them how to set up CVS, or whatever.  And the documentation needs to address the why as well as the howto.  Rather than, 'type in this arcane command' explain what is going to happen and why they want to type in the arcane command.  That is, to me, the hurdle with the present docs.  Lots of HOW is presented; little WHY is presented.  Why should I care about cvs?  (we should tell them).  Why do I need foo when I have bar? (we should tell them why, or tell them how to make it work with bar.)

But, in reality, OpenACS itself isn't a hard install. Getting all the AOLserver pieces is the hard part.