Forum OpenACS Development: moving the default SERVERHOME. Again.

Picking up where this thread left off. In 4.6.x, following from Ars Digita's lead, the recommended place to install services is /web/SERVICENAME. Heading towards RPM-land and other standard packages and LSB compliance, we can't do a root-level directory. From LSB, we need to be in /var. Apache goes to /var/www/html. How about using /var/www/SERVICENAME for our home? (with /var/www/SERVICENAME/etc, var/www/SERVICENAME/packages, and so forth)? I think the SERVICENAME user should still be home-dir'ed in /home/SERVICENAME, keeping those login-oriented files seperate from the web service files. Opinions?

Has anybody heard/is anybody working on an Aolserver 4 RPM or other binary package?

Collapse
Posted by Chris Johnson on
I have a few threads/postings on how I handled this for gentoo. I am interested in following this thread. I can definitely see the data for SERVICENAME being in /var/SERVICENAME or similar, as that is how dbs (postgres/mysql), apache (/var/www), etc. are handled. And I agree with having the *aolserver* user in /home/aolserver, not sure how to handle with multiple aolserver instances running (perhaps run them as service0, service1, etc. and each have its own /home dir. ( ? ) ).

Re: Reference Platforms and Supported Platforms
https://openacs.org/forums/message-view?message_id=85002

new aolserver-4.0 beta2 gentoo packages available
https://openacs.org/forums/message-view?message_id=84995

Installation documentation and file permissions
https://openacs.org/forums/message-view?message_id=33903

Hope some of that helps...

Collapse
Posted by Jade Rubick on
I'm not sure about the need to have multiple directories for Aolserver instances. After all, we're not using nsadmin as the user that owns the Aolserver instances any more, right? We're a separate user for each instance, and having them in the web group. That seems better, security-wise.

/var/www seems good to me. Especially if it's what Apache is using. That will also make it easier for Apache users to get used to Aolserver.

Collapse
Posted by Joel Aufrecht on
By Aolserver instance do you mean OpenACS instance? If you have, say, two services on one machine, then I envision:

/usr/local/aolserver with binaries, nothing service-specific, basically read-only

/home/service0 with ssh certs and emacs files and such for the people who connect to the machine to work or administer on service0
/var/www/service0 with all the files to make service0 work

then
/home/service1
/var/www/service1
etc.
the service0 user wouldn't be able to affect the service1 user.
Collapse
Posted by Chris Johnson on
I don't find anything I disagree with in Jade's and Joel's clarifications. The ideas can be summarized by the following:

/home/aolserver for aolserver (analog: /home/httpd for apache)
/home/serviceX for serviceX login/ssh files
/var/www/serviceX for serviceX data files (analogous to /var/www/htdocs for apache)

Sounds good!

Collapse
Posted by Lamar Owen on
Some good ideas here in this thread thus far.

For RPMs, if I were building them to full LSB compliance as if they would become OS standard, I would use a slightly different structure.  Understand that installing an RPM implies root access for the installer, which implies the users will have root's ear later.

/etc/openacs/$servicename for the tcl, certs, etc configuration. (or /etc/aolserver)
/usr/lib/aolserver for aolserver shared objects
/usr/bin/nsd or /usr/lib/aolserver/nsd (there is precedent for both)
/var/www/$servicename for web data (alternatively, /var/lib/aolserver/$servicename)

AOLserver RPM would use all of these; OpenACS RPM could be a relocatable RPM that installation would place into the right area (or a non-relocateable one that would put the ready-to-install template into, say, /usr/share/openacs, with an installer script that would create the instance directory, initial tcl configuration, and place the template into the /var/www area).

There may be good reason to use some other directories in addition to these.  Scripts to create additional instances  should be included, as should proper initscripts.  Editing inittab from an RPM scriptlet would not be a good thing, though.  If AOLserver gets its own supervisory capability ala daemontools, then that allows a more straightforward, standard, LSB-compliant initscript.  Daemontools probably never will meet LSB, so we can't count on it.

There is no reason to touch /home or /usr/local -- in fact, an LSB-compliant distribution cannot touch /usr/local in distribution packages.  If our packages got into a distribution, they would be changing these anyway.

These are distribution standard locations, learned the hard way maintaining a distribution-included RPM for four years.
Collapse
Posted by Jonathan Marsden on
Lamar wrote:
/etc/openacs/$servicename for the tcl, certs, etc configuration. (or /etc/aolserver)
/usr/lib/aolserver for aolserver shared objects
/usr/bin/nsd or /usr/lib/aolserver/nsd (there is precedent for both)
/var/www/$servicename for web data (alternatively, /var/lib/aolserver/$servicename)

Since we'd like the AOLserver RPM to work for people who want AOLserver but not OpenACS, I'd suggest /etc/aolserver rather than /etc/openacs. (My OpenACS 3.2.5 RPMs used /etc/nsd, but /etc/aolserver is easier for newcomers to remember).

Since some installations may want to run Apache and AOLserver on the same machine (bound to different ports or different IP addresses), re-using /var/www might lead to conflicts? So /var/lib/aolserver is preferable IMO. (And it is what my 3.2.5 RPMs used).

I'd opt for /usr/bin/nsd rather than /usr/lib/aolserver/nsd for the binary, but I don't have a solid reason for prefering one over the other (my older AOLserver RPMs used /usr/bin/nsd).

We're now starting to use OpenACS "for real" at my work, so that gives me hope that I might actually be able to find time to build a releaseable set of RPMs for AOLserver and OpenACS 4.6.3 sometime... but given the long delay, if someone else wants to do the work, feel free -- just let me know, please, so that we don't accidentally duplicate our efforts!

Jonathan