[EMAIL PROTECTED] writes:
> 3) /etc is a kind-of old-fashioned place to put global config files.
> A slightly newer-fangled place is /usr/share/gnucash ...
>
> The reason for this is that /usr/share/... can be easily NFS
> mounted by a sysadmin managing hundreds of machines, while
> /etc cannot be (because boot info is in /etc).
Actually my understanding is that /usr/share is specifically *not* for
config files. In an ideal world, on a properly organized system, you
should be able to capture *all* of the state representing that
system's personality (hostname, net configuration, mail setup, etc.),
and nothing else, by just copying /etc. While few systems live up to
this, it's a good goal, and at least in Debian, any time a program
violates this rule, it's bug.
More particularly, according to the FSSTND/FHS *any file*, that might
need to be modified by the local system admin is supposed to be in
/etc, not /usr/share. /usr/share is only for dictionaries, manpages,
documentation, info pages, language translation files, etc. This
means (to me) that our config file(s) should go in /etc (or more
properly, in configure's --sysconfdir, which they do ATM as far as I
know).
What you want isn't provided by any of the current standards. It
seems like you want something like an /etc-share, but thinking about
it, I'm not sure how it could be defined in a meaningful manner
because what should go into /etc-share will vary per-program on a site
to site basis, depending on what the local admin's needs are for a
particular group of machines.
Further, if you really do have machines where it makes sense to NFS
mount /etc [1], I know that I've seen a way to tell an NFS server to
selectively show some files to a client, and not others. I can't seem
track down the pointer right now, but it was a trick where you could
have something like this on the server dir:
/etc/fstab#host1.somewhere.org#
/etc/fstab#host2.somewhere.org#
/etc/fstab#host3.somewhere.org#
and each client would only see the appropriate /etc/fstab for their
hostname. You could do this for whichever files in the shared volume
you needed to.
[1] On a properly segragated system, I would expect this to be
unlikely since most of the stuff in there should be things like
/etc/hostname, /etc/postifx/*, and /etc/init.d/network*, which will
all be machine specific.
Most of my knowledge of this stuff comes from Debian and there
(indirectly) from the FSSTND and now the newer FHS both of which
Debian aims to eventually comply with:
>From the FSSTND:
The directory /usr/share typically contains architecture-independent
files such as man-pages, timezone, terminfo information, etc.
..
One note: no program should ever reference anything in /usr/share. For
instance, a manual page program should never directly look in
/usr/share/man/man1/ls.1, but it should refer to /usr/man/man1/ls.1 at
all times. Anything in /usr/share will be "pointed to" by the use of
symlinks from other areas in the filesystem, such as /usr/man,
/usr/lib/<something>, etc.
>From the FHS (the newer sequel to the FSSTND) -- see particularly the
second paragraph here:
The /usr/share hierarchy is for all read-only architecture independent
data files. Much of this data originally lived in /usr (man, doc) or
/usr/lib (dict, terminfo, zoneinfo). This hierarchy is intended to be
shareable among all architecture platforms of a given OS; thus, for
example, a site with i386, Alpha, and PPC platforms might maintain a
single /usr/share directory that is centrally-mounted. Note, however,
that /usr/share is generally not intended to be shared by different OSes
or by different releases of the same OS.
Any program or package which contains or requires data that doesn't need
to be modified should store that data in /usr/share (or
/usr/local/share, if installed locally). It is recommended that a
subdirectory be used in /usr/share for this purpose.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
