Filesystem Hierarchy Standard (FHS) compliancy?
Todd Olson
tco2 at cornell.edu
Mon Aug 14 14:55:22 UTC 2000
Hi
On this discussion of where to put the bits of INN,
I'd opinion that I much prefer to wear a coat than to have fur.
Over the years I've experimented with various
different schemes and have finally settled on the "Modular"
"Each program in it's own single location" scheme
(eg INN is under $INN/ )
Basically I would stop using INN if I could not put it all under $INN/
Further, based on my (painful) experience if I inherited a site that uses
the FHS approach I'd probably convert it to a "Modular" scheme.
(That should make my biases clear)
Most of my reasons have already been mentioned by several different people
Anonymous Coward <barry at NetScum.dK>
Russ Allbery <rra at stanford.edu>
bkryger at exchange.edgix.com
Russell Vincent <russellv at uk.uu.net>
and perhaps others I have missed
but I think it important that they be collected together in one place:
Virtues of INN all in one location (eg $INN/ )
1) Easy relocation from Machine to Machine
If you have to move to a different machine, just pick up the disk(s)
and go. This makes it easy to work around hardware failure, or a
network compromise of your system, or even if you are upgrading your
hardware.
2) Easy rebuild of the underlying machine
Again if your machine was broken into, you can just pull off the INN disks
Erase the vendor supplied system, install it fresh, then slap the
INN disks back on. Since most of the time a break in does not diddle
an application like INN this gets you most of the way back into service.
It is also a nice way to upgrade your vendor supplied OS. You can
be pretty sure that the vendor did not stomp on you "application"
3) Ability to run multiple instances and multiple versions on one machine
I sometimes run multiple instances on one machine so that I can provide
different services to different people AND isolate those people from
each other!!!!!. I also use this ability to test new versions, and
sometimes to roll forward from one version to another version on the
same system. Even with the same version of software, being able
to play with builds with different compilers and compiler options
with out having to overwrite the standard location each time (as
something like FHS would see to require) is very useful.
I've been in situations where a a demo that *must* happen *tomorrow*
has two pieces, one that will not work unless a package is upgraded
and one that will break if that same package is upgraded. This can't
be handled with a "standard" intermixed location type install. One
must have a modular, each version in it's own place install. To simplify
paths for different accounts, symlinks to ~/bin are your friend
(think plan 9).
4) Scalability to many systems/platforms
I've attempted to administer a site with 13 different flavors of UNIX
In the end I found each package in it's own single place best. If some
systems are to get some things and not others, it is best not to intertwine
the packages too much.
5) Avoidance of side effects between INN and other packages
The Modular approach permits placing the App one (or more) of it's
own disk partitions. This means that when some other program fills
it's disk, it does not take down the App I'm responsible for. It
only takes one occurance of the beeper going off in the wee hours only
to find that it is not your app that cause the problem, but some other
app that shared the disk space, filled it, and caused your app to die
to learn the importance of this. If application installs are intertwined,
it is impossible to address this indirect interaction(DOS) by putting
things on their own file system.
ALSO, I hate it when an App (gnu emacs comes to mine) seem to think
that they can put a writable directory where ever they please. When
Apps are sharing as in FHS this is annoying because this prevents
you from mounting a */etc partition readonly, which you might
want to do for security reasons. Having Apps in their own file systems
means you don't get bit by these subtle side interactions.
ALSO, if I build INN to depend on perl 5.005_3 because that is what
my vendor suppled and then a vendor upgrade revs perl to 5.6, I could
be hosed. Yea, if I'm knownledgable I just rebuild INN, but if I'm
a junior admin, or the OS maintanence and the APP maintanence is
split between two groups, the parties involved might not know what to
do (especially if the knowledgable human is undergong surgury).
So, even if the vendor provides Perl, I build my own, so the vendor
upgrade can happen (say forced by security) and I can keep running
my production (now older version of Perl) and upgrade the INN, Perl
combo at my leasure.
6) Easier to add paranoid security
When a network App (like INN) is installed all in it's own place it
can be adorned with a chroot to put one more layer of separation
between different parts of the machine and avenues of break in.
An FHS style scheme would make this hard. (Not that I'd have to
do this with INN, but once with apache I had to run run 10 servers
that had to be presumed hostile to each other, on one machine,
so separate installs, separate binaries, separate chroots, in a modular
way worked .... FHS would not have worked.
7) Trying to learn what is and what is not part of INN
If some one teaches you how to swim by throwing you into deep water
then having INN installed in it's own location makes it easier to
figure out what is involved, than scattering it about the filesystem.
I don't think it is possible to address all of 1-6 with anything other than
a modular approach. And I have not yet encountered an issue that
is made worse by a modular install.
Regards,
Todd Olson
Cornell University
More information about the inn-workers
mailing list