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

Collapse
5: Re: Instant gratification OpenACS installation documentation needed (response to 1)
Posted by Joel Aufrecht on 06/13/03 07:56 PM
One of the key problems with the OpenACS project (and all open-source, I guess) is the amount of work that goes into side-projects and never comes back to the mainstream.  So if at all possible I'd like to see how we can focus and improve core documentation to meet these additional needs, instead of addressing them with a side document.  If it is a side-document, it should still be in the core doc package, possibly as a "quick install guide".

Let's look at where we stand now vs where we should be:

- Assume people have Linux installed already

Current core docs do - Redhat install is in an appendix.

- Just care about PostgreSQL

Is the current Oracle stuff intrusive?  I know it can be skipped over, but is the sight of it intimidating to people who are skimming?  Should we further isolate the PG and Oracle installs?

- 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?

- If possible, use an RPM or Debian package for AOLserver

Are we still blocked from making AOLserver 4 official due to that crashing/file corruption bug?  I know somebody's working on/has an Aolserver RPM - any reasons not to adopt that in the RPM install?

- Provide a tar-ball which includes the whole service tree, including run scripts, AOLserver config file, etc.

All of this is already in HEAD, if not 4.6.3.

- Only one OpenACS instance, if people want more instances, they can use the existing 'advanced' documentation.

That's what the current install does.

- Assume people have an MTA running on port 25, and don't worry about incoming mail

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?

- 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?

"The whole point is to cater to people who don't care about a production environment, they just want to try it out, to see if it fits their needs."

I agree that the lack of this is a major barrier to OpenACS adoption.

"It must not leave any room for people to want to skip any step. All the steps must be absolutely necessary."
This argues for a distinct quick-install guide.  Maybe we should have the quick-install with RPMs and the full install with source?

"And it must be fool-proof."
:)  The more we cut out to make the install less risky, the more will break when people try to go to production or to use more features.  For example, if we don't worry about the MTA then someone will install the quick version to test out the mail features, which 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.