Forum OpenACS Development: Re: Automated Install, Configuration, and Test

Collapse
19: Re: Automated Install, Configuration, and Test (response to 1)
Posted by Peter Marklund on 09/05/03 09:21 AM
Dave,
your scripts sound interesting. We checked in the OpenACS and .LRN setup scripts yesterday, see

http://cvs.openacs.org/cvs/openacs-4/etc/install/

The scripts underwent some changes by Joel yesterday and we will debug them today. Maybe you could check in your package to /contrib?

Concerning the install.xml file I think we should remove the install=* instruction and instead make sure the dependencies in the dotlrn info file are up-to-date.

Collapse
20: Re: Automated Install, Configuration, and Test (response to 19)
Posted by Joel Aufrecht on 09/05/03 12:49 PM
Automatic install script is complete and checked in. It checks out and installs an OpenACS (and optionally dotLRN) OpenACS server on a machine that already has a database, aolserver, and daemontools. The configuration file lets you change the server name, run without daemontools, use dotLRN, and control the paths. To get it, 
cvs -z3 -d :pserver:anonymous@openacs.org:/cvsroot co  -d install openacs-4/etc/install
sh install/install.sh
By default this will create a user called service0 and an openacs server called service0 in /var/lib/aolserver/, and start and install the site at http://localhost:8000.

There are probably lots of bugs and I left many TODOs in the code (which is Peter's work and my butchery), but I know enough other people are interested that I thought it better to get this out and get help and feedback on the method than to wait while we get around to polishing.

Known bugs: ignores command-line-specified config file; creates an orphan daemontools process.

Collapse
22: Re: Automated Install, Configuration, and Test (response to 20)
Posted by Randy O'Meara on 09/06/03 04:00 AM
Joel: A comment and a possible fix for the supervise orphan.

As I was looking at (and using) tclwebtest over the past few weeks, I came across a warning that tclwebtest doesn't work on non-port-80 connections. Don't know if that's still true or not.

The deamontools orphan is probably caused by moving the service directory before forcing supervise to totally relenquish control. I analyzed this same issue when I tested and modified the older version of the automatic .lrn install scripts. I solved the issue I identified as follows (copied from another forum article). Note that my setup uses supervise and multilog to manage the error log also. Just disregard the log stuff if that's not the case in your setup.

  • remove the service's symlink from /service (svscan no longer restarts supervise)
  • svc -xd /home/servers/service0/log ('log' supervise exits and service stops)
  • svc -xd /home/servers/service0 ('aolserver' supervise exits and service stops)
  • recreate the service's symlink in /service (svscan retarts supervise processes)
  • 'svscan' should now automagically restart everything
Randy