Re: cfengine config files location

[Chip Seraphine]

Heh.  I was *wondering* why Tim took the discussion off-list :-)

Resending to the list... 


--

On Monday 27 September 2004 18:41, Tim Nelson wrote:

> > In that case, /etc might not be a good choice, since that is generally 
> > for local configuration.
> 
>       Better than /var/cfengine/clients, though :).

Indubitably.
 
> > 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).

I agree /opt isn't a good choice.  It's 100% proper on Solaris, not so much on 
Linux.  Besides, I have some fundamental moral objections to a Linux package 
manager putting stuff in /opt, since as an admin I want to reserve that for 
NFS mounts, large applications, etc.

> > 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. 

Agreed.  On Linux, I personally use it for non-packaged software that does not 
get its own directory.... a big app (say, Sybase) might go in /opt/sybase but 
a small install that consists of a handful of files (e.g. your typical 
binary-manpage-config set) I just splay across /usr/local/
{bin,sbin,share,etc,lib}.

>  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 :) ).

Good luck getting the machine restorable without /var/lib....

>       As for /usr/lib, it just doesn't seem right somehow, although 
> that's how it's often done.

Agreed.  Solaris in particular puts random crap all over /usr/lib.  It's a 
very reasonable place for non-executable files that are more or less 
read-not-written.    That being said, on Linux (which has and uses a 
libexec) /usr/lib is primarily for (gasp!) *libraries*, which makes it an odd 
place to drop authoritative master configs.

>       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.
> ------------------

I ignored the hier page because it hasn't been updated in mellenia; I figured 
the newer FHS stuff superceded it.
 
Hmm.  That *is* interesting.  And even relevant.  That being said, I've never 
used /usr/etc for *anything*.


> ------------------
> /usr/share : Architecture-independent data
> ------------------
> 
>       That sounds like it, doesn't it.

Except that the binaries are generally copied out along  with the configs by 
update.conf.  That, and a lot of cfengine folk probably have decidedly 
non-arch-independent cf files and (especially) modules...

>       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?

Not really.  I dislike forcing the arch-independent angle on the admin.  That 
being said, it is still a pretty reasonable approach.

If I ran the circus I would probably deposit the configs (inputs) into /usr/
etc (sounds like that is exactly what  that dir is for) and executables in /
usr/lib.  In both cases I would make a subdir called cfengine or cfengine.d.

But I don't really like that too much either, so take that as a very lukewarm 
recommendation.


> 
> >>    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.

I can see that.  Disagree, but I can see that.  In a client/server scenario, 
you are either making the copies in the client's /etc irrelevant or  adding 
an extra layer of copying.

Or are you envisioning the package as just being for the policy server?

>       In addition, I personally am going to be generating most of the 
> "standard" master files from .pt (perl template) files, 

Ah!  The dark secret comes to light!  You autogenerate your confs, which makes 
an extra layer of  'repositoryness' reasonable in your case.

> 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 :).  

Probably wise.  Autogenerating cfengine confs is still a bit controversial and 
not-standardized.

> 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).

Cool.

> -     cf.fileinclude.cfa gets regenerated by looking in
>       /usr/share/etc/cfengine.d

You sure you want to  keep both prefix and suffix?

>       :)

Indeed.

-- 

Chip Seraphine
Unix Administrator
TradeLink, LLC
312-264-2048
chip@trdlnk.com