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

Hi All,

I think we need a document that takes the path of least resistance to getting an OpenACS service installed and running for people who are interested in checking out what this beast is all about and can do for them.

A non-exhaustive of areas where it should differ from the current documentation is:

- Assume people have Linux installed already

- Just care about PostgreSQL

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

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

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

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

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

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

Maybe we can even have versions specific to select Linux distros such as Red Hat, Debian, and Suse, in addition to the one that tells you how to manually download and compile PG and AOLserver, to make it even simpler for people with the most common distros.

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.

It must not leave any room for people to want to skip any step. All the steps must be absolutely necessary.

And it must be fool-proof.

Do people agree that's a good idea?

Anyone interested in doing it?

/Lars

I can supply a (RedHat-ish) tarball.
I've been wanting to do something like this, too.

I'd like to see something like lifewithqmail.org for OpenACS so folks can just cut and paste from the docs to get a working installation. I even registered lifewithopenacs.org a while back, but frankly, I don't see how I'll have time this year to do anything with it.

I'd recommend using a stock Red Hat distro and things don't have to be installed from rpms if the steps to download, compile, and configure the components are clear, concise, and correct. I'd recommend running it out of inittab instead of daemontools to simplify things.

We could add a section on advanced topics (like at lifewithqmail.org) where things like daemontools, .LRN, etc. could be discussed.

I think we have to be careful how we do this.

I like the idea, but perhaps this should be the official way, and the official docs would then continue to describe how to improve your installation to make it a production level server, with backups, etc..

Otherwise, we're going to get a million questions on the differences between the different documents.

I think this is a really good idea, however. This is probably one of the largest barriers to entry for OpenACS.

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.

Yesterday I installed OpenACS into the 'template1' database. I was hoping to use this for development, and create a new database just by using createdb as the user who will own the db.

It seems with a binary build on a popular OS, and a copy of what is in /usr/local/pgsql and /usr/local/aolserver, you would pretty much have a quick install OpenACS.

I hope this is the case, because I want to develop an app and quickly trash everything to load my packages up again for testing.

I like the idea of a prebuilt binary including aolserver and postgres. So you would do something like
tar xjzf /tmp/openacs-eval.tar.bz2
mv /tmp/openacs-eval/aolserver /usr/local
mv /tmp/openacs-eval/pgsql /usr/local
mkdir /web
mv /tmp/openacs-eval/service0 /web
./tmp/openacs-eval/run
And the run script could start postgres and aolserver. What's the minimum amount of user creation and permissions needed for this, and can we stuff it into a script and have it work reliably? Can we stuff all of that into a script? Are there other packages that do something similar (agata reporting tool comes with an optional version that includes php and php-gtk)? Should we put stuff into the standard versions or put it all within one directory like /usr/local/openacs-eval (ie, /usr/local/openacs-eval/pgsql) and all under one user openacs-eval? Unfortunately it looks like the lower-risk we make this, the more we guarantee that it doesn't look like the recommended configuration.
I really like this idea. God, it would make things so much easier!

Then we could just pay attention to the install scripts, and making sure they work well, rather than on the details of how to get everything set up.

If we did this well, then the production-level instructions could just expand upon this easy install.

I can help with testing, but I don't really have the time right now to help with setting this up.

This would rock!

On gentoo, a typical install currently goes like this:

    emerge postgresql
    emerge aolserver
    emerge nscache
    emerge nssha1
    emerge nspostgres
    emerge nsxml
    emerge openfts
      (download and install openacs code/sql setup)

When I'm done making it (soon), I will release an ebuild for openacs itself that depends on the above and optionally utilizes imagemagick, daemontools etc. if they are installed:

    emerge openacs

Lastly, what about having a nice non-manual db setup script?

    psql < openacs-setup.sql

A 9-line install doc for Gentoo! I will be happy to contribute the Gentoo install doc very soon...

Tom: I highly recommend the use of a template database for quick new openacs setups.  However, if there is any possibility you might want to use that postgres install for something else other than openacs I recommend installing your template database into a new database such as aolserver-template and using
command line "createdb mynewdb -T aolserver-template" or
psql line "create database mynewdb with template aolserver-template"

If you want any user with createdb privileges to be able to use this template then you must set datistemplate = true in pg_database, otherwise, I interpret the docs as saying that only super-users can use a regular db as a template.

Thanks David! I should have known that something so useful would be supported directly.

After reading Joel's post I had the thought that if we are going to work on a "Document" to create a basic install, then the document should really just be about creating a mobile tarball and installation script. What is needed to add to Joel's script is the correct users/groups for the installation. This could be packages into a single script, that might check a few things to make sure nothing is being overwritten.

Once this document is created, any of the guru's here should be able to create their newist install according to the doc and tar it up and provide it back to the community.

Eveyone here probably hates the amount of wasted time to install correctly all the junk we need. This is only compounded when there isn't a way to provide this work directly back to everyone else.

In other words, if the installation was done in big phases:

  • Get the basic software (compiled)/installed.
  • Test the basic install
  • cvs/autostart production install.

    Someone could just do phase one, one way being a binary install which would be useable by most everyone.

  • Hello,

    I am new to the community and have been setting up OpenACS on Slackware for a couple days, and have been tinkering with various parts of the OpenACS system for a couple of weeks. This forum has been a God-send -- thank you all for sharing your knowledge and experience.

    I agree very much that new OpenACS users would benefit from an easier point-of-entry.

    The current installation documents are quite good, and I have been able to dig into the documentation for supporting packages where I have had trouble. In fact, I would say that the install docs, as they stand, are _much_better_ than usual for this kind of system. I have experienced very little of the extended frustrations that I have had on other occasions. The explanations are clear and give enough "big picture" information to help me understand where I'm going, and where to get answers when I need further information.

    But still, the point-of-entry is too high for most people. My point of reference is Zope, which I have played with a bit, on both Windows and Linux. Under both operating systems, there is very little to do -- just install the system using the standard package-installation approach for that OS, and that's _it_. You end up with a working installation of the software in about 15 minutes, and you can begin to play with it. This is quite a contrast from the 15 hours or so that I have been working at getting OpenACS up and going -- though I'll grant that I'm doing everything, including OpenSSL and building PostgreSQL with Tcl and Python, and Qmail and Daemontools. I'll also say that, from what I've seen so far, OpenACS is much more of a production-level set of tools, and so one should expect more work to do. And too, I'm still learning UN*X, having come from a Windows world, so that's probably slowed me down some.

    All of the kinds of things that you have been talking about would be useful to the new user.

    (1) A clear document to describe how to make a "basic play/test/development installation" from the available software packages.

    (2) A document to describe how to upgrade a basic installation to a production installation. One of the reasons that I am doing everything I can now is, I don't have the experience to know how difficult it would be to add these things in later, and so I'm doing it now. If there were a document that described the paths to upgrade, though, I would have more confidence doing a simple installation now. (Some of the discussion on this thread suggests to me that, in fact, the "full install" is a good idea because the upgrade path is not straightforward.)

    (3) Pre-compiled binaries for a variety of systems. This would significantly speed up the installation process and lower the bar for new users. Most of this software compiles very easily (though I've had a little trouble today getting nsopenssl to recognize that I built openssl with threads ... but I'll get through that; and I could probably come back to that later on). But the time involved in doing all of the compiling is not trivial. I previously built a simple but dynamic, working Zope site from scratch in less time than I have spent waiting for gcc to run, which includes the time I spent reading "The Zope Book."
        (A side note: I spent/wasted a lot of time trying to set things up under Windows, only to discover that I needed MSVC++ to build AOLserver -- it wouldn't build with DJGPP, at least on my system (WinXP Pro). I was unable to find a binary of AOLserver for Windows, either on the the Sourceforge site or on the EmpoweringMinds site. Has an AOLserver binary for Windows been posted publically?)
        (A second side note: Even though the installation docs are fine, there seems a dearth of books on AOLserver and OpenACS. When I go to Borders and see the piles of PHP and MySQL and Apache books, it's a little disconcerting to have chosen Tcl/PostgreSQL/AOLserver. I know what I'm after, and I've taken the time to study the differences; so I feel confident I've made the right choice. But I like books -- and I think it would give many people more confidence if they could see O'Reilly publications -- or any printed books at all -- on AOLserver and OpenACS. I was glad to see, though, a book on PostgreSQL. It would be very encouraging to new users to see links on the OpenACS site to "The OpenACS Book" or whatever its title will be.)

    (4) Full binary installation packages for a number of OSes would be extremely useful. I am currently working with Slackware, so if I get to the point where everything is working satisfactorily I would be interested in working on a Slackware package. I realize that shared libraries make this process non-trivial. But others have succeeded with equally complex software. It is something to work toward. RedHat, Debian, OpenBSD, and Windows should have pre-compiled binaries among their offerings. A Windows install-package would not be significantly bigger than that of other large software packages, and would make it possible for a lot more people to install "play" versions OpenACS on their Windows laptops and workstations.

    (5) Someone mentioned documentation that begins where installation leaves off, to help those new to the system to get familiar with it and how to make use of it to build dynamic site and community services. This would be outstanding. Though I have not yet reached the "congratulations" screen, I suppose I'll be there in the next couple of hours of work. I know I would benefit from and appreciate some general guidance at that point.
        If easy-to-install packages were available, then a lot more people would get to the point of being able to make use of such documents, And, such documents would themselves be one of the better advertisements for OpenACS versus PHP & friends.

    Those are some thoughts from the perspective of a beginner. I am also willing to contribute in whatever way I can to a documentation effort.

    Shawn Harrison

    Shawn, good points. On your issue of "test/development" vs. "full/production" installation, I think it's not quite as bad as you fear. As far as I can think of just now, version control related install mistakes are the only "shortcuts" that are particularly likely to come back to bite you later. Therefore, here are my suggestions for some simple rules of thumb:

    The very minute you start customizing any OpenACS files, you must at least know and record exactly what OpenACS version you installed and where you got it from. Hopefully, just keeping the original tarball around should answer that question for you, as long as the OpenACS version (and corresponding CVS tag!) is properly documented in the tarball. Doing a cvs import (onto a vendor branch) of the sources is an ideal way to do this, but can be skipped at this point if you wish. As long as you know what you started with.

    Once you've both modified any OpenACS files (which at least currently basically means, "for all Production sites") and want to now upgrade OpenACS, you have to put everything under CVS.

    (As an aside: This really shouldn't be a problem, because frankly, if you're creating a production site using the toolkit then you're a programmer, and if you're a programmer you or at least one member of your team needs a firm grasp of CVS.)

    So, now that you want to upgrade, either you cvs imported OpenACS right when you started, or you waited till now. If you waited till now, what you do is go back to your original tarball, cvs import that, create your CVS checkout of just the stock stuff from the tarball, then copy all your non-CVS stuff on top of that checkout. Then commit all your changes. Now you're at the same place as if you cvs imported way back when you first started using OpenACS. It's a bit easier to do that CVS stuff at the beginning rather than after the fact, but it's doable either way.

    I think ignoring the above rules of thumb are the only ways you're really likely to shoot yourself in the foot by postponing "Production ready" infrastructure work till later. E.g., if you don't know what version you installed, customized and then upgraded various pieces without any version control - that sort of thing will definitely cause you extra work.

    Oh, one more way - custom data model changes. That can be kind of like CVS snafus except worse. But people aren't likely to get into that at all unless they already have a pretty good idea of what they're doing.

    But stuff like using pre-compiled binaries vs. compiling your own, using inittab rather than daemontools, etc., none of that is going to cause you extra work later, even if you decide you later want to switch. In fact, it may well save you time, and you may be happy with it for years.

    Oh, and we probably have somewhere in big bold letters: "If you are new to OpenACS, do not try to do any of this on Windows. It can be run on Windows, and if you are an OpenACS expert, go right ahead, but 95% of OpenACS users use Linux not Windows, so if you're a beginner you should use Linux too."

    So that's three so far: Things to be careful about when thinking about taking a shortcut: Version control, Linux vs. Windows (Windows is not a shortcut - unless you're talking John Sequeira's OpenACS on Linux in VMware on Windows thing), and less commonly, data model modifications.

    Great to see the interest. Now we just need to make a decision on which path to pursue, and who does what by when.

    Just a clarification on one little point:

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

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

    ...

    One difference, though: Currently you have to copy the files from .../packages/acs-core-docs/files/... to where they need to go.

    What I figured was that you'd get a tarball, which is rooted one level up from normally, and which contains everything, like this:

    service0/etc/run
    service0/packages/...
    service0/...

    Everything already in their desired place and in the desired layout. No copying around of files.

    Of course, if that distribution tar-ball would also include PG and AOLserver, or whatever else is needed to make it even easier to install, so much the better.

    /Lars

    One addition to things discussed in this thread would probably be the demo cd, which Frank Nikolajsen has been doing. It would contain a working oacs installation with some common applications and everything needed for that to work (e.g. a linux system, postgresql, aolserver, etc). I don't know the status of his work at the moment, though.
    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.
    Lamar,

    Thanks a  bunch for your comments, they're very useful.

    Yes, AOLserver and all its modules is a very central piece of the problem.

    And I agree that CVS and Daemontools in the current docs are distracting, and a simple approach which tells you how to do the others as add-ons would be better.

    I do want to comment on your first paragraph, though:

    "However, is it really an issue since the toolkit requires significant customization anyway?  This is not an easy toolkit."

    This is precisely what I'm trying very hard to change. I want to make OpenACS instantly useful for real-world problems out of the box. Obvious application areas are the groupware space, personal blog+photos+whatnot site, and cms.

    Sure, you can customize to an incredible degree, which is definitely the strength of this toolkit, but I don't think many people will ever see the light unless they get some gratification in a very short time. They'll just decide that OpenACS sucks, turn away, and never come back. "It's a dead project. A Mozilla."

    In other words, OpenACS is still going to be a toolkit, but it should also do things that we believe a lot of people will want to do, with no coding, and with very simple installation.

    Which is why I started this thread.

    /Lars

    Obviously Lars this fits in with your OpenACS in a box project, and for the record it is all a fantastic vision.

    I have been meaning to roll a Macos X package of aolserver to link with the apple available postgresql package, with a gui interface, so the install process would look like this:

    * download & double click install the postgres package from apple.com
    * download & double click install the oacs/aolserver bundle
    * run the oacs gui admin which would take you through this wizard:

    -> enter short site name (used to create database and /web/site-name tree)
    -> enter ip address and url to listen on
    -> do you want this service to start at boot time Y/N?

    subsequently the gui would take you to  a page with a list of your sites - each having start/stop/edit/delete buttons, and a "new site" button which would run the wizard again using a fresh oacs tree and a new database.

    hands up who thinks that would be great for macos x users (like a lot of uni professors)?

    Mark, hand is up high in the air and I'll be more than willing to do testing.
    Andrew,

    Thanks for your response and for giving me those suggestions and guidance. All of what you said was very helpful. Last night I got to the "Congratulations!" screen, 😊 and then stayed up too late looking around the out-of-the-box site package. Feeling the freedom to let some things be not-quite-resolved -- such as putting AOLserver in daemontools and getting qmail and nsopenssl fully working -- was helpful to me, so that I didn't get bogged down but pressed ahead.

    Since CVS is an important element of a production site, and since you can shoot yourself in the foot, as you say, by not including it, I would suggest that having the "quick install" use CVS should be the default, installing CVS on the system if it's not already there. Since the other things can all be added later, it would be simpler (less daunting) for the new folks not to have to wade through those things in the initial install document.

    Speaking of the out-of-the-box package, it is really very impressive. Lars mentioned that, currently, many people might not get to that point and turn away before seeing it. That, when it happens, is really unfortunate, because what you get out-of-the-box is so much more than what you get with other, similar packages -- more professional, more "industrial strength," and more transparent. Having such a powerful system as this be so transparent in its architecture is almost unnerving, as compared for instance with Zope which (in my experience) seems to obfuscate the simple. If people would have the opportunity to see what OpenACS is all about, I think it would really take off in its popularity. There are a lot of people willing to spend an hour to find out, but not ten hours. If a couple of journalists were to spend that hour and have good results, no doubt some buzz would begin to build.

    More thoughts from a beginner,

    Shawn Harrison

    I was looking into doing something similar for FreeBSD, so that you could do just:

    portinstal www/openacs

    and be almost done with...  Unfortunately, so far it only fetches allrequired stuff, but does not build anything but AOLServer and PostgreSQl (and that is only because there is dependency info in port Makefile)...

    Sorry to go a bit off topic, but since it was asked:
    There are Windows binaries of AOLserver 4.0 beta 8 available at http://empoweringminds.mle.ie/openacs/4/  Starting from my distribution and documentation is a *much* easier way to install OpenACS on Windows than starting from the AOLserver sources.  I haven't been publicizing the beta build's existence because I don't really have time to support it, but once AOLserver 4.0 is final, the Windows binaries and installer will be available on SourceForge.

    Native Win32 PostgreSQL is due with 7.4 - it has been held up but might be out at the end of the summer.  I'm hoping it will have a nice installer like the one for pgAdmin II.  So with a little more time and work, Windows will be a first class platform for OpenACS, but as Andy suggested, we should probably put up a warning in the meantime.

    Ask and ye shall receive. Here's an attempt to create a quick-guide that "leverages" the existing documentation and doesn't create new material that can get out of sync. This is what it looks like - the links won't work until I get HEAD documentation posted somewhere. Also haven't added tDOM to the docs yet.

    This page describes a minimal installation of OpenACS with PostGreSQL (not Oracle). It will produce a working OpenACS installation in under an hour. It excludes source control, full text search, ssl, managed services (daemontools), DocBook, and email.

    For Red Hat 9

    1. Install PostGreSQL 7.3.2 from RPM. Select Menu > System Settings > Add/Remove Applications and select Database Server.

    2. On the PostGreSQL page, do the Using the Red Hat RPM bullet point and step 6

    3. On the Aolserver page, do steps 1 , 2 , and 3

    4. In the section called “Set up the file system for an OpenACS Service” on the OpenACS page, do steps 1 , 2 , 3 , and 4 .

    5. In the section called “Prepare PostgreSQL for an OpenACS Service” , do steps 1 , 2 , and 5 .

    6. In the section called “Configure an AOLserver Service for OpenACS” , do 1

    7. Browse to http://localhost:8000 . If you see something like

      then proceed with Using the OpenACS Installer . If not, look at 2 for troubleshooting information.

    The current barriers to a quicker guide are lack of an AOLserver RPM and lack of an OpenACS RPM.

    Oh, and dummy-of-the-week award to me, please for whining for openacs.org permissions that I already had. Current HEAD docs are now available in their entirety . Most notably, the new index page replaced the page under /doc/; tDOM instructions, and a backup/recovery page that is still very much in flux.

    I was looking into doing something similar for FreeBSD, so that you could do just:

    portinstal www/openacs

    and be almost done with...


    I've done some work to try to make this happen. It's got a ways to go though.
    if it's the 'instant gratification' you're after why not just skip the documentation-bit and go directly for the 'out-of-the-box' experience?

    opengroupware does this for instance [1] by providing bootable CDs of a preconfigured installation based on Knoppix [2]

    in case you haven't heard of knoppix, it's truly amazing: a bootable linux on CD with really good automatic hardware detection, i've used it dozens of times at clients and they were all amazed that linux would run 'just like that' on THEIR computers...

    just a thought.

    [1] http://www.opengroupware.org/en/knoppix/index.html
    [2] http://www.knopper.net/knoppix/index-en.html

    oh, and i would just LOVE it, if OpenACS became part of the FreeBSD ports collection!