Forum OpenACS Development: Wizard Installation of OpenACS

Posted by Tom Jackson on 10/31/02 06:14 PM

I'm going through the painful process of exact documentation of how to install OpenACS. The interesting thing is that it seems everytime I install this stuff some new version is available, and it seems prudent to use th latest stuff. Wizards seem to be great for a single, well supported application, but OpenACS requires parts from lots of places.

One nice thing is that you can install everything via a command line interface. It seems like 'documentation' that was actually an installation script would be more useful than the list of 'do-this', 'edit-that' style doc.

What I would like the install script to do is the following:

Query a central url to get up-to-date software lists + install options.
Ask a series of questions used to write configuration scripts.
download, compile and install support software.
download, compile and install AOLserver + modules.
download and install OpenACS.
Record decisions made so that the installation can be repeated at a later date or on a separate machine.
Of course the final record should be easily edited by human wizards to produce slight variances.

I'm sure others have proposed similar convenience scripts, I just want to revive the discussion.

2: Re: Wizard Installation of OpenACS (response to 1)

Posted by Jorge Garcia on 10/31/02 06:29 PM

Yes, yes, yes, yes, yes, yes, yes, yes, yees, yeees, yeeeeesss!!!

(Quoted from 'When Harry met Sally') http://movies.yahoo.com/shop?d=hv&cf=info&id=1800134855

:))

3: Re: Wizard Installation of OpenACS (response to 1)

Posted by Mat Kovach on 11/01/02 02:55 AM

Part of that is being taken care of currently in the source distribution for AOLserver for OpenACS at http://uptime.openacs.org/aolserver-openacs. I'm currently reworking the script to include downloading OpenACS and creating and instance.

Currently I'm testing the latest version of AOLserver (the addition of tcl8.4 has some nice speed improvements).

I need to continue testing through. I was actually hoping to make a beta version available for OpenACS 4.7.

My current plan is:

o Basic install questions (db name, database type, base installation directory, use daemontools, inetd, or init scripts).
o Download AOLserver, required modules, optional modules)
o Display list of available OpenACS modules, select which to install.
o Download and install modules, create instance.tcl, instance directory, log direcoty.
o Fire up nsd -ft instance.tcl of package installation.

The basic framework is in my original code (on uptime) but
I'm open to ideas.

4: Re: Wizard Installation of OpenACS (response to 1)

Posted by Simon at TCB on 11/01/02 09:29 AM

Jon and I were also thinking of looking into a more automated installation process, i.e. par-installer, par-doc.

The problem really (as my feeling is most installation stuff can be done manually) is how to create an installer that doesn't itself make installation more complex.

We've been looking at CherryPy (www.cherrypy.org) as a possible solution. This essentially generates a python executable with the entire webserver and content included, as is as distributabel as python.

This might make a nice, self-contained, downloadable installation server that appears part web service, par automated tool...

It seems to me that virtually all of OpenACS (from PG upwards) is a candidate for automatic install.

5: Re: Re: Wizard Installation of OpenACS (response to 4)

Posted by Mat Kovach on 11/01/02 01:39 PM

It should be easy to convert my current shell scripts into TCL and use tclkit to distribute it OR use something like freewrap to create a installation executable.

Of course, almost every OS has /bin/sh (and some sort of
package management) and creating a wrapping around each
individual package management system would be trivial but very time consuming.

Right now I have the frame work for an installation that as about 10 questions and after compiliing your choices comes up with and OpenACS installation page. It would be easy to create pre-compiled packages that work with it (checks would have to be added to make sure libxml, postgres or Oracle is installed, etc) and distribute it that way.

6: Re: Wizard Installation of OpenACS (response to 1)

Posted by Tom Jackson on 11/01/02 06:03 PM

Basically I am thinking of a series of independent steps. You run one program to start off the process. This program gets an updated set of questions from some public url. The overall scope of what needs to be installed is determined by this step. For instance, if you already have daemontools installed, you should be able to skip that installation step. This initial program would write the answers down for later re-use or re-distribution, and use the answers as input to the next step.

The second step would be to query the public url for specific knowledge on each sub-installation step. This would probably include an additional series of questions specific to each piece of software that needs installation. Again, these answers would be saved into a re-useable re-distributable file. Certain of these questions would probably need flagging as private and/or instance dependent so that partial re-use could be possible.

The third step would acquire the necessary software, archive it, run installation and configuration scripts, record and archive the output of all this process, and maybe test installation and record the results. It should also be possible to step through the installation one command at a time.

Whatever this wizard turns out to be, it should be easy for someone to add new parts, or re-use the wizard on their own private url. The only real requirements here should be that the software should be able to be installed via a series of shell commands, and the software is accessible to the wizard via a public or private url. It might be convenient to have some type of interactive tool that could record your steps, and allow you to explain each step as you proceed. The hardest part will be the writing of configuration files, because this is usually not done via a command line, however this is also the hardest part to document correctly.

7: Re: Wizard Installation of OpenACS (response to 1)

Posted by Joel Aufrecht on 11/05/02 05:49 AM

I was just posting my new installation document when I saw this thread. I want to point out a few issues with a wizard.

First, it ought to be cross-platform. This will probably be a maintenance burden
Second, installing different versions of things is very high-risk. There has to be a well-defined screening process with regression testing or else things are going to break a lot.
The wizard should be integrated with a recovery process - point it at a database/file system backup and it puts that system back together. Perhaps we need a standard definition of a backup.

8: Re: Wizard Installation of OpenACS (response to 1)

Posted by Venugopal Maddukuri on 11/05/02 06:35 AM

Well this discussion seems to lead naturally to the Question of distribution and installation. Something that every Linux (GNU/..) addresses. I like apt the best.

Why not start a OpenACS subproject to handle this issue.
There has been a lot of talk but few people are willing to currently commit time to a full-fledged activity with goals.

There are many wonderful ideas for the implementation:
for example Ben's idea - MIST [ http://openacs.org/forums/message-view?message_id=52454 ]
has been postponed to be taken up after 4.6-test...

Probably what is required is a few sample implementations which could then be tossed up for discussion/testing/adoption...

cherio
venu

9: Re: Wizard Installation of OpenACS (response to 1)

Posted by Tom Jackson on 11/05/02 06:54 PM

Actually Ben's MIST idea would take over about the time what I am proposing finishes off. Maybe my subject is a little off. The chunks I want handled are things leading up to the installation of OpenACS, but it also might run again after OpenACS install to finish up.

Another main point of the wizard is to document the installation process. It can be used by a human wizard to build and test the installation scripts. It should also bundle the software used, and the configuration options selected, so identical installations can be performed.