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