Forum OpenACS Development: Conforming with Linux Standands Base Project (was re: Reference Platform)

Continuing this thread on a sub-topic:

Would someone else (Tallil?) like to take responsibility for understanding LSB and watchdogging compliance for the Reference Platforms?

On first skim, the things I see non-compliant right now are:

  • I hack /var/spool/cron/crontabs; we should instead go to /etc, and we should instead instead go platform-independent by moving everything up to OpenACS.
  • I'm not sure if we're init-compliant - certainly, we shouldn't use a mix of init scripts, inittab, daemontools, and rc.local as we currently are.
  • LSB seems to require RPMs. uh....
  • something about localization

I think LSB is a Good Thing, but unless somebody hollers otherwise I think we should move towards it opportunistically. IMHO.

Why would a software project which runs on all *nix want to follow a single 'standard'. I think we should wait until the different *nix do things exactly the same way before considering following one of those. It would be better in my estimation to create a standard for OpenACS, one almost already exists. The only thing lacking is where to put config files and backup files.

I'm dumb, but I believe there is even several ways to setup Linux 'correctly'. Our standard may result in users having to follow our documentation to install things like postgresql, oracle (they already do), tcl, aolserver, etc. This will only increase confusion.

Hi,

I think what Joel has layed out on the last thread is good enough for me.  I believe the first priority is making the installation easier.  Following standards is nice.  I can't volunteer anymore time other that putting some opinion out on the forums.  If Joel has time to volunteer and it improves things, I think he should go for it.

It maybe also be just possible to have a big tar ball since the current layout given by Joel can be done like that.  Extract the tar ball on /web.  Then run a script that will restore the pg_dump file then run on non-root port on localhost.  Like 8080.  The current installation of both aolserver and postgres seems to be easy enough.  So we just make a reference system in a tar ball of openacs.  Its a reference not a production system.  John S tried to use vmware for this, which is also a great idea.

I don't think that LSB requires RPM, if it does, my boxes will never be LSB compliant, so it is irrelevant.
Joel, following up on LSB opportunistically sounds like a decent plan to me. The reason that I would recommend considering it is that some of the major Linux vendors are planning on moving towards it, namely Red Hat and Suse.

Unfortunately, I'm the wrong person to figure any of this stuff out since I'm not technical. If need be, though, I could go through all the technical documentation and compare what they recommend vs what we ultimately decide on the organization.

Tom, I figure a reference platform suggests a reference OS, which I would generally assume would be Linux since most people are using Linux in the community. If we decide on Linux, then we need to choose a distro. Debian is set up quite differently from RH and both are different than Gentoo. LSB seems to be about reaching some basic consensus among all the various distros.

A reference platform seems to be just a suggestion. I agree with Joel that if it's easy, we should do it, just to make it easier to fit within various distros.

talli

Perhaps the reference system should assume the LSB arrangement with contigencies for platform variations.

An install script (and documentation) could refer to a series of reference files adjusted for different platforms. New reference files could be created for different platforms as existing ones do not work. A document could help installers locate platform specific reference points (and report to OpenACS for doc updates). I'd be glad to help write the instructions --once the reference points are identified. =)

This info could tie in well with dynamically created platform-specific install and admin instructions.

The only thing I see different between Red Hat and debian right now is the details of the init scripts. Which brings me to a related point:

LSB gives rules for init scripts, but I'm not sure it requires them. The install in its current form documents full init scripts for postgresql, rc.local for qmail, and daemontools for aolserver instances. Daemontools is more powerful and more user-hostile than init scripts; doing per-instance init scripts the way we do per-instance service directories would take some re-working. Should I leave it as-is, should I screw up the moral stamina to re-figure out supervised qmail and document it, or should I try to roll qmail and aolserver back to init scripts? Oracle I'm not touching. I would prefer to leave it as-is.

qmail should NEVER be run from initscripts.

Please take the time to do it right, not mislead people on improper installations.

The qmail INSTALL doc says, "Add csh -cf '/var/qmail/rc &' to your boot scripts," which I interpreted as rc.local.  Is this acceptable to all, or should I document (well, copy other documents and simplify and test) supervised qmail as the only option in the install doc?  Does anyone think it's important to run postgresql supervised?  (Supervised means run via daemontools.)  Note that this may not comply with LSB, though that's my cursory opinion.

Actually for AOLserver instances, I now use init scripts which use daemontools commands. Why? Daemontools doesn't shut down during server shutdown or restart, and doesn't start up in an order that you can adjust. This could be important for AOLserver connecting to Oracle, because Oracle will not shut down if AOLserver is still connected. Actually Qmail, djbdns and other software also doesn't shut down nicely, so I just creates an init script that runs a bulk svc -d /service/* as the first script to run. You would need individual scripts only if you want a more specific order for these services.

Talli, good point about the reference platform. I had decided not to send my previous post, as it wasn't really helpful. Somehow it got sent anyway.

I think many people install qmail by following the guide called Life with qmail, and if you do, qmail will be supervised.

It would be awesome if someone were to figure out and document how to run PG and Oracle under Daemontools 😉

Daemontools are great IMHO because they are flexible, powerful and user-friendly not user-hostile! ... well maybe to set up. Then again, there's a cure for that as well; just use Debian and run "apt-get update; apt-get install daemontools-installer" ...

I run PG and (when I had it) Oracle under supervise. I also run OACS under supervise. Search the forums as this has been discussed many times.

As Tom pointed out, it isn't a problem to run supervise from an init script. Although you certainly don't need to.

I made a new aolserver-4.0b2 package for gentoo and have some discussion on its layout and the FHS/LSB. Might want to check out this post if you haven't already.

--Chris