I just finished installing OpenACS on my webserver, and the main page stated:  Thank you for using our software. Please write to us at the OpenACS bboard to let us know of your experience with installing and using OpenACS.

OK. Here is my experience. First, let me start by thanking everyone who put this whole thing together, because the installation went much better than I had hoped. It has clearly come a long way from when I tried the installation at around version 3.2.

The installation documentation is excellent. I started with a blank system, compiled and installed postgres, aolserver, and openacs without any problems thanks to the great examples.

The only problem that I am still having is the daemontools. I followed the instructions carefully, and the daemontools are running, but I cannot get them to run the website for me. As of this moment, the only way that I can actually run the site is to copy the text out of the run file located at /home/username/web/sitename and then paste it into a command window and run it from the commmand prompt.

Even with this minor issue that I hopefully will get resolved soon, I just can't say enough good about the excellence of the installation experience and the great product that you have put out.

I have always used inittab, but on my new server decided to try out daemontools.

I have it all working, and it does the trick - but it's a bit obscure, has zip documentation and appears to me to be an abandoned project (the files in the archive are dated Jul 13  2001).

Given these issues, I wonder if we should be promoting it as the method of choice for running OpenACS.

It can't be that hard for us to roll our own perl (say) program to replicate what daemontools does but specifically for OpenACS.

Any comments?

Noone says you must run daemontools, but it is way more reliable than the evil inittab, and I doubt you could write the equivalant program in perl. http://jongriffin.com/static/aol-supervise

Just from a security point of view I wouldn't try and inittab is a lot more evil.

I haven't seen the absolute latest doc, but I believe it shows both ways. And, it really isn't very difficult, it is like anything new. Ever tried to configure the most popular web server in the world (apache). If you can figure that out, daemontools is a breeze.

Garn,

I couldn't get the supplied script to work with daemontools either. However the following, slightly edited one does the trick for me:

#!/bin/sh

exec su -l nsadmin -c "/usr/local/aolserver/bin/nsd -it /usr/local/aolserver/birdnotes.tcl"

I agree that daemontools is the way to go. All you have to do is read a little of what DJB has written and all the stuff he writes makes a lot of sense.

I really appreciate all of the tips you have given for setting up my run file. I will try them today.

I should write up my latest experiments with using daemontools with OpenACS. Things missing from daemontools are the problems of starting and stopping services in some kind of order. Using the /service directory in the default situation works for things like qmail, but not for web services that use a database. I'm doing another install this week, so I can spend time to fine tune my startup scripts. Essentially, I am using the init.d scripts to start and stop things in the correct order, but the scripts use the svc commands. I use the down file to keep services from starting on their own:

# cd /service/myservice
# touch down

With Oracle OpenACS, it is critical to make changes to the Oracle start/stop scripts. Oracle should be brought up after most everything else (especially sshd), but before the webservers. To shut down, the web services need to go first, then Oracle then sshd. This prevents the problem of Oracle deciding not to stop after net access is terminated.

Janine,

Just out of curiosity, what makes you want to run away from djb (or his software)?

Based on my practical (non-religous) experience with daemontools, qmail, tinydns, and dnscache I've found each of them a huge success.

/Ola

Recently I forgot the option how to restart a service with svc:

develop:~ # svc
develop:~ # svc -h
develop:~ # cvs --help
Usage: cvs [cvs-options] command [command-options-and-arguments]
  where cvs-options are -q, -n, etc.
...
develop:~ # svc --help
develop:~ # man svc
No manual entry for svc
develop:~ # svc -whereisthedamnhelptext
svc: illegal option -- w
svc options: u up, d down, o once, x exit, p pause, c continue, h hup, a alarm, i interrupt, t term, k kill

Just my personal experience - might be wrongly installed. It's great software, but it has unnecessary annoyances, IMHO.

I do think that calling inittab "evil" is a bit much. It's inconvenient in some situations, but it works just fine.

The daemontools package uses inittab to start up svscanboot, so it seems DJB doesn't consider it too evil.

Janine makes some valid points about about DJB: he doesn't mind sharing his arrogant opinions with the world, he puts his software in strange locations, etc. All true. However noone here seems to complain that AOLserver, PostgreSQL, Oracle and OpenACS are all similarly strange. If you compare different flavors of unix, they do not adhear to exact standards on the way the os starts up and how they start services, the result is that every software that is installed using standard locations and practices have to use different locations and practices depending on the unix flavor.

The Postgres team seems to believe that they can make incompatable changes without changing the Major version, forcing developers to go back and constantly revise their software to conform.

OpenACS tcl code doesn't conform to any standard either, even though a tcl style manual existed before ArsDigita wrote the 3.x series.

The lack of man pages for the daemontools package could be frustrating. However the README file contains a link to the online documentation.

As arrogant as DJB may be, he is definitely selfless in sharing his software. He doesn't promote it, sell it, or make any money off of it. But he still makes it available to everyone, he maintains and improves it. He even offered $500 for anyone who could find a security related bug caused by his qmail software. To date the money is unclaimed.

He is also fighting the U.S. Commerce Department on a legal issue where he established that 'source code is speech' and the Department's export regulations amounted to censorship. He won in the District Court, but the Government is appealing. He case is being handled by the Free Software Foundation.

Janine makes some valid points about about DJB: he doesn't mind sharing his arrogant opinions with the world, he puts his software in strange locations, etc. All true. However noone here seems to complain that AOLserver, PostgreSQL, Oracle and OpenACS are all similarly strange.

That's because Mike does everything except those things!

(couldn't help but drive my truck through that opening!)

_Janine makes some valid points about about DJB: he doesn't mind sharing his arrogant opinions with the world, he puts his software in strange locations, etc. All true. However noone here seems to complain that AOLserver, PostgreSQL, Oracle and OpenACS are all similarly strange. If you compare different flavors of unix, they do not adhear to exact standards on the way the os starts up and how they start services, the result is that every software that is installed using standard locations and practices have to use different locations and practices depending on the unix flavor_

Yes, he does install the software in what is considered strange locations, but it is the same across ALL platforms.  He had to pick "strange" locations (ie: broke frrom the various standards out there) so that this software was in one location.  But if you goto Solaris, Irix, Linux, *BSD you can always find (or should unless the installer changes it) /command, /package, /service, /var/qmail.

Now if that is good or bad is up to debate (I don't like it but I apperciate the effort).

You can also find the latest docs of DJB's code at:

http://cr.yp.to

That's because Mike does everything except those things!

Don is correct, of course. :)

Seriously, though, there is a difference. All of those things are easy to install wherever you want them to go. They do default to non-standard places, but we have created our own standards for them. The difficulty with DJB software, or so I understand, is that it pretty much has to go where he puts it. I don't know if this is a limitation of the install or if it's just because it's too much of a pain to follow the installation instructions otherwise.

Anyway, I believe in "live and let live" for most things, and I'm certainly not trying to convince anyone else not to use DJB software. I just think it should be presented as an option among options, and not the One True Way.