Forum OpenACS Q&A: inittab and daemontools in Intsall Documentation

Is inittab documentation going to be removed from the install documentation in favor of daemontools? Currently inittab setup is included in the OpenACS 4.6 Documentation however, I could not find it in Joel's OpenACS 4.6.2 Install Guide. This was discussed in this post, however, it seems no conclusion was reached. If possible, I would like to see the instructions for inittab stay in the documentation.

Collapse
Posted by Tom Jackson on

If it hasn't been removed, it sure is hard to find. This is a mistake to remove working instructions from the install doc. Inittab is convenient because it is already installed on most every system.

Collapse
Posted by Joel Aufrecht on
It's still there; I just moved it to an appendix and added a link. Keepalive is documented in the Install OpenACS 4.6.2 chapter:
Assuming AOLserver started cleanly in the previous step, we'll 
set it up so that it's always running, and automatically restarts 
whenever it dies or is stopped. This step is strongly recommended, 
even for development sites, because it makes install and maintenance 
much simpler.

The Reference Platform uses Daemontools to control AOLserver. 
A simpler method, using init, is here

My reasoning was that 1) we should only document one approach in the main flow of the documentation, 2) the community seems pretty evenly split on which to use, 3) daemontools is more functional (appropriate for other programs, finer control). If it's too hard to find, please tell me how better to link it or place it. If there is demand to swap them so that inittab is in the main flow and daemontools is the alternate method, I can do that too.

Collapse
Posted by Lamar Owen on
IMHO, the 'Reference Platform' should use the simplest approach.  As this is admitted to being inttab, it would seem the 'Reference Platform' should utilize that approach.

While inittab isn't nearly as flexible as daemontools, it is one less complication for an installation that is already complicated.  Joel, you've done an excellent job documenting things; I'm just of the opinion that someone new to OpenACS is going to be overwhelmed with all the extras involved in installation of daemontools.  To go a step further, an initscript setup might be the best newbie approach, even though that is the least desireable from a reliability standpoint.

Once a body gets better at it, they may very well decide to use the more powerful daemontools approach; but is that approach best for a novice?

I personally don't care what the docs say, for my purposes.  But as RPM maintainer for PostgreSQL, I get newbies' questions all the time -- some can't figure out why a major upgrade of PostgreSQL can't be automatic, for instance.  The simpler the docs: the simpler the Reference Platform -- the fewer 'newbie error' questions we'll get.  YMMV.
Collapse
Posted by Peter Marklund on
I err on the side of agreeing with Lamar here (i.e. keeping the inittab approach around). My own experience is that at ArsDigita I never had any problems doing OpenACS development with inittab, you carefully edit one text file, then issue a command (something like init q), then use the restart-aolserver perl script and you are off.

Working with supervise at Collaboraid on the other hand I have had *tremendeous* difficulties and frustrations. It turns out the approach is extremely sensitive to the permission in your source tree and when there is a failure it is a silent one that is hard to diagnose. If Lars hadn't been there to help me out I think I would have abandoned the approach altogether.

Therefore, I'm not sure I would recommend supervise to a beginner on a development box, unless there are some really fool proof instructions around for how to set it up. AFAIK we don't currently have those.

Collapse
Posted by Bruno Mattarollo on

I tend to agree with Lamar and Peter. We are using inittab on our production servers and we had zero problems with it so far. It's simple, convenient and when you don't need a lot of flexibility, it's the easiest solution to implement.

Just my two cents

Collapse
Posted by Oscar Bonilla on
I've used both the inittab and daemontools approaches, and I like daemontools better. I ported the restart-aolserver perl script from inittab style to daemontools style. Maybe that would be useful (the script is at the bottom).

The permission problem Peter talks about does not depend on how AOLServer was started (inittab or daemontool) but on the user as which it's running. My guess is that at ArsDigita they ran AOLServer as root (bad!) and at Collaboraid they ran it as a regular user. I'm only guessing here since ArsDigita had documentation on how to run it on a chroot environment (which I did once, but it was more painful than useful). One last thing, "init q" requires root priviledges, restarts init (unnecessary), and is also used for changing run-levels. If you setuid root init you're asking for trouble. On the other hand, "svc" does only one thing (restarts services) and even though it requires root priviledges it isn't as dangerous or prone to misuse as init. If you use the restart-aolserver script setuid root you limit the damage a regular user can do.

Daemontools is *very* simple to install and it comes as a package in most Operating Systems, in fact, it *works* in all operating systems. Inittab is a System V specific feature which is not available in the BSD's. I think the more generic approach is the daemontools approach.

Anyway, after all the blurb, here's the script:

---- cut here ----
#!/usr/bin/suidperl -Tw

use POSIX qw(strftime);

$LOGFILE = "/var/log/restart-aolserver.log";

$ENV{'PATH'} = "";

if ($#ARGV < 0) {
        print "usage: restart-aolserver <service_name>\n";
        exit(1);
}

if ( ! -d "/service/web-$ARGV[0]" ) {
        print "$ARGV[0]: service does not exist\n";
        exit(1);
}

$user = (getpwuid($<))[0];
$timestamp = strftime "%Y-%m-%d %H:%M:%S", localtime;

open(LOG, ">>$LOGFILE") || die "Could not open LogFile";
print LOG $timestamp, "\t", $user, " restarted ", $ARGV[0], "\n";
close(LOG);

print "restarting $ARGV[0]...";
system ("/usr/local/bin/svc", "-t", "/service/web-$ARGV[0]");
print "done.\n";
---- cut here ----

Regards.

Collapse
Posted by mark dalrymple on
My guess is that at ArsDigita they ran AOLServer as root (bad!)

I'm not sure how you reached that conclusion. AOLserver 3.x takes a user and group parameter, which is uses to release priviliges after it acquires port 80. aD ran these servers as the 'nsadmin' user. AOLserver 2.x had a "User=whatever" parameter in the config file that it used to downgrade itself from root after binding to port 80. We also ran the 2.x AOLservers as the 'nsadmin' user.

I'm only guessing here since ArsDigita had documentation on how to run it on a chroot environment

chrooted environment doesn't necessarily imply running the server as root. The thought was that shared sites on a machine would be chrooted, so that if one instance got hacked (whether due to aD or customer fault), the other instances would be somewhat safe. It was more CYA than anything. Inside of the chroot jail the AOLserver ran as nsadmin. I don't recall how widespread we actually chrooted customers (if at all)

(which I did once, but it was more painful than useful)

amen to that brotha! The Solaris truss command became my best friend in figuring it out.

Collapse
Posted by Andrew Piskorski on
And running AOLserver as unix user "nsadmin", the same user that owned the AOLserver binaries, wasn't exactly ideal either. But it's easy and simple, and of course much better than running as root. (But really, I've never heard of anybody leaving AOLserver running as root. The -u switch is so easy, everyone uses it.)
Collapse
Posted by Bruno Mattarollo on

Well, actually nsd won't run as root...

[23/Apr/2003:18:17:27][1580.16384][-main-] Fatal: nsmain: server will not run as root; must specify '-u username' parameter
:-) My 2 cents,

Collapse
Posted by Tom Jackson on

However, you can currently set the primary group of a user to 'root', and then AOLserver will run with the group set to 'root'. Are there any problems with this? I have a patch for AOLserver that disallows this, and also allows only valid groups the user is in, but I have yet to submit it.

Good point Bruno, I'd forgotten that!  :)
Collapse
Posted by Raul Rodriguez on

Joel, Thank you for your response. When I was reading through your install documentation I missed your link as I was used to seeing both methods on the same page as in the OpenACS4.6 Documentation. The link that you provide addressed my question/request.