Forum OpenACS Development: Re: RFC: automated installer

10: Re: RFC: automated installer (response to 1)

Posted by Janine Ohmer on 02/06/04 04:44 PM

Just getting back to this...

The reason Sloan wants to build and contribute an automated installer is to make it easier for a new user with no technical background to download and install dotLRN. The long list of "stuff" that has to be downloaded from here, there and everywhere and installed is thought to be scaring away potential adopters, who don't have much time to spend on this and feel they lack the skills to get through the manual installation.

The question about using Tcl vs Bourne shell boils down to this: Is tclsh going to be installed on all systems by default? All of the different flavors of UNIX I have access to already have it, but that's no guarantee. I don't know how to find out, without trying each one, whether all the major distros include tclsh in a default install and will continue to do so - any sugestions?

I completely agree that the script should stop on error. I haven't done much shell scripting lately but it seems like it ought to be possible to trap errors somehow; on Solaris in particular many installers still use Bourne shell, AFAIK. Is there some reason why this can't be done?

My gut feeling is that it would be better to have one script (or set of scripts) that takes the user all the way to installing OpenACS, as Tom describes above, rather than having one set to do the external package installs and another (the tclwebtest-based script) to do the setup. However, this would mean there would be some duplication between my script and the exisiting one. Can someone familiar with the existing script comment on how widely used it is, who is supporting it, and what the future plans for it are? If no-one is really championing it then it's probably not such a big deal to make it potentially obsolete.

12: Re: RFC: automated installer (response to 10)

Posted by Joel Aufrecht on 02/06/04 04:59 PM

We are using and improving the OpenACS install script continuously. Any replacement should offer at least the same functionality (create a new openacs site from scratch, tear down and rebuild an existing site). The only direction forward that really makes any sense to me is to pick one or more distros and create and commit to maintain packages for them. Those packages should specify their dependencies and then re-implement the stuff in the script in the native language of that particular installer platform.

In this scenario, we still need a fairly generic script to serve as the reference across different implementations. Note that the current install script is in fact a bash script, not a tclwebtest script. Tclwebtest is required for a single call, and for some advanced features such as doing a link test after installation.

So the most useful approach would be to pick an existing distribution platform that already has all of the dependencies, and make an OpenACS package on top of that. Out of RPM, debian, bsd ports, fink, etc, which one is closest? What scripting languages do they use? Which is most useful to the broadest range of existing and immediate potential users?

The better solution, tongue in cheek, is to start charging $10,000 for installation services. Then we'd be recognizably enterprise-class.

13: Re: RFC: automated installer (response to 10)

Posted by Jeff Davis on 02/06/04 06:42 PM

I think it's easier to write a portable Tcl installer than a sh based one (it's easy to end up using flags not supported everywhere or depend on commands that don't exist in some OS's). For a Tcl based install we could do it with a tclkit and there are tclkit binaries for pretty much any platform I think people are interested in.

Otoh, you can definitely exit on errors with a shell script

set -e

does that and you can use the trap command to catch the error (although I think that is a bash-ism and you cant trap ERR with vanilla sh).

I would like to see packages for .debs, .rpms, and ebuilds and any of the half dozen other package managers people use.

I suspect the best way to get there would be to have a place in CVS where we keep the source for building with the various package tools (for example there are a set of ebuilds to install all the aolserver stuff + openfts and writing an openacs ebuild would be pretty easy). Maybe we should create an openacs-4/etc/installers/DISTRO directory and under that have the source for generating the various packages/build scripts. If we get them working well then I imagine they will get pulled into more standard distributions.

Another alternative would be to try harder to become the maintainers of aolserver and openacs on various standard distributions. The problem seems to be that the people maintaining aolserver for the various distributions where it is present are not really very good at keeping up to date. I don't know how hard it would be to get commit on gentoo and debian for example, and I don't follow fedora at all.

Anyway, there are a lot of options; I think getting things into standard distributions is important but I don't know how it will happen until some people here get commit to maintain the necessary packages.

14: Re: RFC: automated installer (response to 10)

Posted by John Sequeira on 02/06/04 09:21 PM

Janine,

If Sloan's need is to demonstrate .LRN to those with limited technical background, why not skip any installation and use a VMWare image or .LRN LiveCD like the one Malte is working on?

There would be hugely less amount of work to maintain it (no need to select tcl vs. bash, deb vs rpm vs etc, no need to track or resolve openacs/tcl/aolserver/tdom version conflicts), and also way less work/time to install and try it out.

Also, fwiw I was planning on including a .LRN install on my next Oasis release.

16: OpenACS Live CD (response to 14)

Posted by Malte Sussdorff on 02/08/04 01:04 PM

Live CD, i knew I forgot to post something....

http://www.sussdorff.de/oacs5dot2v2.iso

This is the OpenACS Knoppix run out of the box, should not use 512MB of RAM (but might), .LRN 2.0 enabled, Jabber running demo live CD.

We have to work a little bit more on it, but are keen to collect feedback and if you want to get your custom made CD don't hesitate to contact Björn Kiesbye (the author), or myself.

17: Re: OpenACS Live CD (response to 16)

Posted by Malte Sussdorff on 02/08/04 01:06 PM

You might have to right click and say "save to disk" to download the file and not view it in the browser. Any idea how I could teach my AOLserver to offer this file type as "download only" ?