Filesystem Hierarchy Standard (FHS) compliancy?

[James Ralston]

Okay, I've read the "Path config in inn.conf" thread from March of
1998.  (Thanks to all who provided pointers--IIRC, I was busy with
other things back then, so I probably didn't notice the discussion.)

First, let me clarify something I said:

> The "build on the target machine and just splatter everything into
> /usr/local" method of software deployment/administration is becoming
> more and more a thing of the past.

My "splatter everything into /usr/local" was not so much a criticism
of INN's default directory layout as it was a criticism of the
assumption that INN is being built on the machine on which it will
eventually run.  In the past, this was generally the case, but this is
changing.

Brandon Hume wrote:

> INN is the kind of application that dominates the entire machine
> [...]  Systems like Oracle and Sybase (major machine-dominating
> applications) do the same thing, which is not unreasonable, since at
> a philisophical level they do the same thing.

I disagree.  Having administered the mail infrastructure for a 60,000+
user institution, in serious deployments, INN is no more demanding
than a full-blown sendmail installation.  Each has a spool directory,
a directory for configuration files, log files, variable (stateful)
files, and auxiliary "helper" binaries.  Each requires careful
attention to the physical hardware being used in order to run properly
and provide realistic performance.  And each can live in harmony with
the rest of the OS, without "dominating the entire machine".

> Isn't the FHS primarily a Linux activity?

Mostly Linux and *BSD at the moment.  It might take a while, but I
think most of the traditional unix vendors (Sun, IBM, DEC) will
eventually adopt the FHS.  System administrators who are used to the
FHS will demand it.  (Witness Sun's inclusion of perl in Solaris 8.)

> I have big issues with third party software that throws itself in
> among the core OS

Not everyone shares your definition of "core OS".  Solaris does, but
most Linux vendors don't, as INN is included by default in most base
distributions.

Russ Allbery wrote:

> I personally detest the FHS for things like INN and find it
> constantly annoying that Red Hat insists on scattering INN to the
> winds all over the disk so that new INN users can't ever find
> anything and can't follow any of the standard instructions.

I find a certain irony in arguing against the FHS based on the
reasoning that "new users can't find anything".  This is one of the
exact problems that led to the creation of the FHS in first place!

The Linux and *BSD world is transitioning to the FHS.  Yes, this will
create some transient confusion among novice system administrators.
But in the end, this will make the world a Better Place (tm) for
novice system administrators, because they will be able to generalize
the knowledge they have learned from one package (config files etc in
/etc, variable data is in /var, etc.) and apply it to others.

You interpret installing INN as to conform with the FHS as "scattering
INN to the winds all over the disk".  I interpret it is "putting the
components of INN where they belong and where currently competent and
future system administrators will look for and expect them."

And on a practical note, I have zero sympathy for any Red Hat
administrator who doesn't know enough to run "rpm -ql inn", for
goodness sake.  RPM is the glue that holds Red Hat together; any
so-called Red Hat administrator who doesn't grasp even the basic
functionality of RPM (enumerating the files in an installed package,
to see what they are and where they are) is just going to create a
giant mess of his or her system.

> It's currently possible to configure INN to do that if you really
> want

No, it's not.  Trust me; if it *were* possible, I would've just done
it.  ;)  I use the existing configure options to get as close as I
can, but the result doesn't conform to the FHS by a long shot.

The problem is that there aren't enough directory options to twiddle.
The best example is /usr/local/bin.  As of INN 2.2.3, there's no way
to even set this directory; it's set to $(prefix)/bin, period.  If one
were to install according to the FHS, most of the programs here should
go into some combination of /usr/sbin and /usr/lib/inn.  Some of the
subdirectories under /usr/local/bin would go to /usr/lib/inn, but not
all--in particular, /usr/local/bin/filter would most appropriately be
/etc/inn/filter.

The /usr/local/bin issue is the most egregious problem with attempting
to install INN to conform to the FHS, but there are a few other
problems as well.

Forrest J. Cavalier III wrote:

> there is the problem of name and version collisions with things like
> rnews

Then the same problems exist for the current directory layout.

> I am asked do work on a number of INN systems, installed by
> different people, on various flavors of hardware.  FHS installations
> are the most difficult to work on.  I keep a notebook just so I know
> where to find the config files on each system.

If you had to keep a notebook to keep track of where the config files
were, then you weren't working with FHS-compliant systems, period.
The FHS is clear: configuration files go into /etc or a subdirectory
thereof.

Over the past decade, I have worked extensively on different unix
systems, including all mixes of FHS and non-FHS systems, and systems
that do and do not use package management.  (Of course, the FHS didn't
exist back in the early 90's, but we had the same issue with vendor
versus third-party software).  Today, I find FHS, package-managed
systems the easiest to work with.  Files are directories and where I
expect them.  I can use the package management tools to build and
distribute the software I need to deploy.  (And if I use those tools
intelligently--which I do--I can even simplify the maintenance and
upgrading of config files.)

Russ Allbery wrote:

> It's currently possible to configure INN to do that if you really
> want; I'm not personally inclined to make it any more the default
> (although if someone wanted to simplify it down to a single
> configure switch or something, patches would be gratefully accepted)

Well, as I said, it's not possible to configure INN 2.2.3 to install
in a manner conforming to the FHS.

I can patch INN so that it *is* possible to do this, by increasing the
number of directory locations which can be configured.  But to do this
in such a manner as to preserve INN's existing directory structure as
the default would require creating a significant number of new
directory prefixes (between 10 and 15, I'm guessing).  Based on the
discussion I saw in the March 1998 list archives, it would seem there
is a desire not to do this.

However, if INN's existing directory structure under /usr/local/news
could be rearranged, this task could be greatly simplified.  Perhaps
something like:

    /usr/local/news/bin/
    /usr/local/news/db/
    /usr/local/news/etc/
    /usr/local/news/etc/filter/
    /usr/local/news/lib/
    /usr/local/news/lib/control/
    /usr/local/news/lib/rnews.libexec/
    /usr/local/news/log/
    /usr/local/news/man/
    /usr/local/news/run/
    /usr/local/news/sbin/
    /usr/local/news/share/
    /usr/local/news/spool/
    /usr/local/news/tmp/

Do away with --with-lib-dir and distribute the files which currently
live there as follows:

    /usr/local/news/etc/innshellvars
    /usr/local/news/etc/innshellvars.pl
    /usr/local/news/etc/innshellvars.tcl
    /usr/local/news/lib/docheckgroups
    /usr/local/news/lib/innreport_inn.pm
    /usr/local/news/lib/libinn.*
    /usr/local/news/lib/libstorage.*

Under this scheme, one could make an INN installation fully comply
with the FHS just by redefining each of the above directories.  (Or,
for that matter, configure could provide a --with-fhs-conformity
option to set them all in one fell swoop.)

Thoughts?

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA