Filesystem Hierarchy Standard (FHS) compliancy?

Sven Paulus sven at tin.org
Fri Aug 11 11:19:26 UTC 2000


In article <200008110104.WAA14691 at Den.BOFH.Halifax.NS.Ca> Brandon Hume <hume at Den.BOFH.Halifax.NS.Ca> wrote:
|> INN doesn't just 'splatter' all over /usr/local.  It packs itself quite neatly
|> into /usr/local/news with the default prefix.  I find this very useful because
|> INN is the kind of application that dominates the entire machine, and tends to
|> survive several iterations of the underlying hardware and OS.  

That's why it's even nicer to use "/news" as a starting point and do
symlinks from there to the real storage places :-)  But this is of course
only personal taste.

|> When I do my backups, I carefully preserve the one directory, not dozens
|> scattered all over the filesystem.

Speaking of backups, one thing which has annoyed me since 2.0 is out: Why
has the history to share a directory with active, active.times, newsgroups?
When I do backups I want to put everything which belongs together under one
common tree. Of course I want to do backups of my configuration, of the
active and the newsgroups file and of the binaries but _not_ of the large
history database. Usually it's not really useful to have a daily backup of
this multi-GB-file (if the machine really crashes hard and your history is
lost but your spool is still ok, you don't want to use an old history file
from some hours ago ...).

So, how about splitting pathdb in two different directories? One for the
"configuration db files" (like active, active.times, newsgroups), which
should _never_ be lost, and one for the large "database type db files".
These setting could even default to the same directory when you are using an
out-of-the-box configuration, but you should be able to split them without
patching the code (which you have to do now).

Sven




More information about the inn-workers mailing list