Cool re: documentation.
I'm almost certain that /web and even djb's /service are either strangely left out of mention in FHS or are no-no's. I sympathize with the unix-admin unfriendliness of crufting up the root dir; but I really don't mind /web and /service because I'm not running a large multihosting facility :)
Agreed that using /usr/local does not go against the FHS. For my gentoo ebuild I am trying to mimic the apache installation for the following reasons:
1) Easy to understand coming from an apache background (on gentoo)
2) Each service gets its own user (* more on this below)
3) Each user gets its own dir that is in /home (this is the most debatable and least important part). This could just as easily be /usr/local/. But /usr/local/somefoo does not connotate that the activities originating in somefoo package should correspond with all processes (`ps aux`) owned by somefoo quite as well as does /home/somefoo to me. Potato Potahto ;) It's a matter of taste: I'm not a fan of a nobody user. Compare with
ps -A |grep qmail
1503 ? 00:00:00 qmail-send
1538 ? 00:00:00 qmail-lspawn
1539 ? 00:00:00 qmail-rspawn
1540 ? 00:00:00 qmail-clean
In my ebuild script, just changing ${AOLSERVER_HOMEDIR} to /usr/local/aolserver will get one back to the 'traditional' install location :)
Just for further reading:
An interesting user/perms model is what EROS-OS (extremely reliable OS) is building into the OS and what djb achieves sort of by accident in his many-small-moving-parts implementation of qmail: i.e. each process should have access to only objects that are explicitly given to it (in EROS-OS this is a Capability). The way unix roughly mimics a true capabilities-based system is by running each process as a unique user rather than give a process capabilities to resources. Then the user, e.g. qmail-send, qmail-clean, aolserver, apache, can only access the files he owns (and that is roughly equivalent to initiating a process as a more priveleged user in a capabilities-based system but only handing it a few file and resource capabilities).
I also gravitate to what someone mentioned when proposing using /home/aolserver-<version> as directory/user: the idea is that the system allows side-by-side installation *and* instantiation of aolserver.
