items in LIBDIR (related to FHS patch)

James Ralston qralston+ml.inn-workers at
Tue Apr 24 19:59:30 UTC 2001

On 20 Apr 2001, Russ Allbery wrote:

> Oh, this reminds me.  Make sure that anything that's installed in
> /usr/bin is *not* owned by news.  Anything that's on root's path
> should be installed owned by root, since otherwise it's too easy for
> the news user to break into root.  This will require some fiddling
> with the installation rules, unfortunately.


Would it be acceptable to install all programs in PATHBIN as user
root, regardless of whether --eable-fhs-dirs was provided?  This
shouldn't affect anything in a non-FHS install anyway, because in a
non-FHS install, nothing in /usr/bin is editable or configurable at

> > /usr/share/doc/news/
> /usr/share/doc/inn, surely?

Yes; see my follow-up to Marco.

> > /usr/share/man/man/
> I assume you mean /usr/share/man?

Yes.  (Actually, I meant "/usr/share/man/man*/*", but I decided to
remove globs from the list, and I didn't clean up this line properly.)

> Other than that, this seems fine, although I agree with Marco that
> as many binaries as are reasonable to move should probably live in
> /usr/lib somewhere instead of in /usr/bin.
> And I don't know the rules for /usr/bin vs. /usr/sbin.

In short, they're a big pain.  To paraphrase the FHS:


	Anything that is meant to be executed directly by regular


	Anything that is meant to be executed directly by non-regular
	users (the superuser, system administrators, other system-type
	accounts, etc.).


	Object files, libraries, and internal binaries that are not
	intended to be executed directly by users or shell scripts.

The most important distinction for a program is whether it should be
executed directly.  If it's not--that is, nothing is going to expect
the program to be in anyone's PATH--then it belongs somewhere in

If, however, the program is intended to be executed directly, then it
needs to be in /usr/bin or /usr/sbin.  If the program is useless is
intended for system administrators only, then it should go in
/usr/sbin.  Otherwise, if regular users can use the program, it should
go in /usr/bin.

Unfortunately, INN probably needs all 3 of /usr/bin, /usr/sbin, and

An example for /usr/lib/news/bin is parsecontrol.  This program is
invoked exclusively by the control programs.  There's no reason this
program should be in /usr/bin or /usr/bin; it belongs in

An example for /usr/sbin is makehistory.  This program is never
invoked automatically by any subsystem of INN; it is intended to be
run manually by the news administator, or by a script of some sort
written specifically to automate its invocation.  It doesn't belong in
/usr/lib/news/bin because it's manually invoked, but since it's
useless for regular users it doesn't belong in /usr/bin.

An example for /usr/bin is convdate.  In the past, I've found convdate
useful enough that I've ripped it out of INN and put it in my own
~/bin directory.  This program is always manually invoked (so far as I
can tell), and it's perfectly useful for regular users.  It belongs in

The way I'm thinking of solving this issue is to fork BINDIR into
three directories: BINDIR, SBINDIR, and LIBBINDIR.  In a non-FHS
build, they'd all have the same value (/usr/local/news/bin by
default).  In an FHS build, they'd be set to /usr/bin, /usr/sbin, and
/usr/lib/news/bin, respectively.

I'm certainly open to suggestions, though.

BTW, I notice that TODO has this entry:

  * Add a separate utils directory for things like convdate, shlock,
    shrinkfile, and the like.  Some of the scripts may possibly want
    to go into that directory too.

This sounds to me like you want the non-FHS equivalent of /usr/bin:
you want a directory to place tools that INN uses, but which aren't
specifically tied to INN, and might be usable by others.  Is that
correct?  Perhaps we can kill two birds with one stone here...

> > I think that's a good idea, but if the library name is changed, it
> > should be changed regardless of whether --enable-fhs-dirs is
> > supplied.
> The directory name should be changed everywhere, and should be
> libinnstorage or libinnstore or something like that.  Feel free to
> make this change.

Ok, the new name will be libinnstorage.

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

More information about the inn-workers mailing list