[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cfengine config files location (fwd)
Re: cfengine config files location (fwd)
Wed, 29 Sep 2004 10:45:47 +1000 (EST)
Oops, I sent this yesterday, but accidentally didn't choose reply
to all. Chip replied to this; Chip, could you reforward your e-mail to
the list, and I'll include them in my reply to you.
---------- Forwarded message ----------
Date: Tue, 28 Sep 2004 09:41:31 +1000 (EST)
From: Tim Nelson <address@hidden>
To: Chip Seraphine <address@hidden>
Subject: Re: cfengine config files location
On Mon, 27 Sep 2004, Chip Seraphine wrote:
On Sunday 26 September 2004 19:18, Tim Nelson wrote:
On Sun, 26 Sep 2004, Hauke Fath wrote:
On Fri, 24 Sep 2004 13:14:55 +1000 (EST) Tim Nelson wrote:
/etc/cfengine/master: cfengine configuration files to be rolled out
Please consider sticking with the default of /var/cfengine. This is more
appropriate than /etc, since the directory is written to quite
Just to clear things up, I'm not suggesting that we change
/var/cfengine to anything else. I'm suggesting that we keep all of it
right where it is. It's just fine for everything it does.
The one thing we don't have is a standardised location for the
master cfengine files. For example, I use /var/cfengine/clients/inputs at
So we're talking about master files that will be copied into /var/cfengine
before being run?
That's exactly it. In fact, /var/cfengine/inputs :).
I think the common case is for such files to be on a server somewhere.
In that case, /etc might not be a good choice, since that is generally for
Better than /var/cfengine/clients, though :).
(Of course, NIS servers use /etc for master config files, but
that is because those *are* live local config files that are distrubted to
clients.) I personally have an /opt/cfengine directory on my server where
all the master files, SCCS (or RCS for the Open Source world :-) histories,
templates, etc all live. I'd be hesitant to put it under /etc if for no
other reason than it is large and wants its own disk.
Ok, so you don't like /etc, but I'm not sure that /opt is much better.
I'll cast around a bit more (see below).
Apologies for being Linux centric in the following example, but I
don't have access to the appropriate information for other systems. If
they differ from the Linux example below, perhaps someone could provide
some additional information.
From the Linux FHS:
/var contains variable data files. This includes spool directories and
files, administrative and logging data, and transient and temporary files.
The /etc hierarchy contains configuration files. A "configuration file" is
a local file used to control the operation of a program;
The word local, as I interpret it, makes me think this is a bad place for a
repository of server files.
it must be static
and cannot be an executable binary.
In the above, I admit to being unsure what "static" means.
I think they are saying /etc/mtab doesn't belong in /etc :-)
:). Agreed, too.
To summarise, I'd be saying that /var is logging, cache, and spool
things, whereas /etc is configuration.
None of which are server repositories than. Perhaps /usr/lib (or
lib) if you don't care for /opt?
Hmm. Not sure I like either of those. /usr/local is, according to
FHS, supposed to be empty on default installs. The way it gets used by systems
with package managers (or at least RPMs, anyway), is that files that aren't
part of an RPM are supposed to go there (ie. site-specific files). That way,
by backing up /etc and /usr/local and a list of packages, you should be able to
restore the machine to a working state (oh, and you may also need /home :) ).
As for /usr/lib, it just doesn't seem right somehow, although that's
how it's often done.
Also, You snipped an important bit from "man hier", under "/etc":
Site-wide configuration files may be placed here or in /usr/etc.
Nevertheless, programs should always look for these files in /etc and you may
have links for these files to /usr/etc.
:). OTOH, the FHS says:
Note that /usr/etc is still not allowed: programs in /usr should place
configuration files in /etc. ------------------
I think the FHS missed the point that the "man hier" page was making.
But casting around a bit more, and looking at the FHS:
/usr/share : Architecture-independent data
That sounds like it, doesn't it.
According to my searches, FHS doesn't mention the words "site" or
"global" in a context that appears like they have considered the kind of
problem we're studying, so I suspect that we're pretty much on our own here.
How would one of the following be:
/usr/share/etc/cfengine.d <-- my preferred option
So all the stuff currently in /var/cfengine pretty much belongs
there (input/output cache/logs and the like), but the master configuration
belongs in /etc.
I'd interpret the above to mean that the actual config files belong in /etc,
not the masters that the live configs are copied from.
Depends on how you want to look at it. The way I'm looking at it, the
ones in /var/cfengine/inputs are "cached" versions, rather than "local config",
because any changes you make locally will get overwritten from the masters on
the next run.
In addition, I personally am going to be generating most of the
"standard" master files from .pt (perl template) files, which interweave
cfengine config, documentation, and perl code which generates one of the other
two. I'd naturally love to include this in my proposed scheme :), but thought
it would cause too much uproar and trouble :). So my idea was:
- .pt files generate central cfengine config files (only on my
system; others could edit their own cfengine files however they
- Packages that know cfengine install their files in
/usr/share/etc/cfengine.d or wherever (hopefully with different
names than the ones being generated by my .pt files).
- cf.fileinclude.cfa gets regenerated by looking in
WebAlive Technologies Global
Level 1 Innovation Building, Digital Harbour
1010 LaTrobe Street
Docklands, Melbourne, Vic, 3008
Phone: +61 3 9934 0812
Fax: +61 3 9934 0899
|[Prev in Thread]
||[Next in Thread]|
- Re: cfengine config files location (fwd),
Tim Nelson <=