Filesystem Hierarchy Standard (FHS) compliancy?

[Russ Allbery]

James Ralston <qralston+ml.inn-workers at andrew.cmu.edu> writes:
> 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!

I understand that.  However, in my experience, it doesn't work.  I'm one
of the people who has to answer questions from those people when they
can't get INN to work, and I've seen that in practice Red Hat's layout
causes those people to be unable to find the files that they need to
configure INN.

> 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.

I'm sorry, but I disagree.  I have no intention of installing INN anywhere
other than /var/news on any server that I run.  I want the entire package
in one place so that I can add /var/news to my cdpath and easily get to
what I need to get to without bouncing all over the whole file system.

> 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."

We may have to agree to disagree on this, then.

> 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.

Binaries don't belong in /usr/lib according to the FHS; they go in
/usr/libexec.  Or have they changed it again?  (Another of my problems
with the FHS.)

Anyway, yes, you're right that the binaries aren't sorted into
administrative and user binaries, mostly because they're essentially all
administrative binaries.  If you put them all into /usr/sbin, you'd get
basically what FHS would demand.  /usr/lib or /usr/libexec would be the
wrong place; you can run the binaries directly any time you want and it's
often useful to do so.

> 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.

Yeah, I don't like where filter is either.  And authprogs and
rnews.libexec should be in lib; I agree with you there.  control should
probably also be a subdirectory of lib.  I'll look at making some changes
along those lines for 2.4.0.

>> 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.

I think you're drastically underestimating how hard it is to keep track of
where you're supposed to go next in the file system if you're very
familiar with INN but not familiar with the FHS.  For example, if I want
to edit my news config files, I just type "cd etc", and then to edit my
filters, I type "cd filter".  This is very convenient, and I don't need a
notebook to figure out where I am.

> 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.

I appreciate that, and I'd like to make it possible for INN to be easy for
you to use, but your opinion is not unanimous among those of us who have
worked extensively on different Unix systems for the past decade.

> 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.

I'd really rather not make configure take even *more* options, yes.  What
I'd rather see is something like --enable-fhs or something similar that
fixes all the paths to conform to FHS.

> 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/

My only real reluctance here is that I'd rather not make people add two
different paths to their PATH in order to find the INN programs they need
to run.  I'd prefer to combine sbin and bin by default.

> 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

No, these belong in lib.

>     /usr/local/news/lib/docheckgroups

This belongs in bin (or sbin).  I run this directly all the time.

>     /usr/local/news/lib/innreport_inn.pm
>     /usr/local/news/lib/libinn.*
>     /usr/local/news/lib/libstorage.*

Other than that, I do see your point, as much as I disagree with you about
the FHS.  :)  I'll take a look at making this easier to do in 2.4.0.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>