Re: cfengine config files location (fwd)

[Tim Nelson]

	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 <architect@webalive.biz>
To: Chip Seraphine <chip@trdlnk.com>
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
> > > frequently.
> >
> >         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
> > the moment.
>
> 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.

        Exactly.

> In that case, /etc might not be a good choice, since that is generally for 
> local configuration.

        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.

        Agreed.

> > 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 
> /usr/local/
> 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
/usr/share/cfengine/etc

        Other ideas?

> >         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
        like).
-       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
        /usr/share/etc/cfengine.d

        :)

--
Tim Nelson
Server Administrator
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
E-mail: tim.nelson@webalive.biz
http://www.webalive.biz/