Re: cfengine config files location

[Tim Nelson]

On Tue, 28 Sep 2004, Chip Seraphine wrote:

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

	Ouch, yes.  I would've gotten /var/lib/<database>, but probably 
missed some other stuff.

[snipped stuff I agree with :)]

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

        Hmm.  I know I have
/var/cfengine/clients/inputs (cfengine config)
/var/cfengine/clients/local (files I want to copy out to each machine)

	So, I think we have two separate issues we need to sort out here; 
neither of these are currently defined.

> >         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;
> cfengine does enough ivory-towering  as it is.

        Is this opinion because of the copying out of binaries?

> That being said, it is still a pretty reasonable approach.

        :).  I like being called reasonable :).

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

	Hmm.  Now I'm considering the same thing myself.  So now our 
preferred choices are:

/usr/share/etc/cfengine.d
/usr/etc/cfengine.d

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

	Yes!  Sorry, I'm not sure I've made myself entirely clear -- this 
is *only* to be set up on the (Gold Master|Policy Server|Central 
Everything server).  Many files from it may be copied out by cfengine (to 
eg. /var/cfengine/inputs), but it itself is only put in the one place.

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

	:).  But that's not what I want it for.  I want it so that 
software installed on the cfengine server can dump configs somewhere.

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

	I could propose that all configs be generated using a combo of 
Perl, Squeak, and ML (and then I could learn Squeak and ML :) ).

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

	Actually, I could avoid this by double-prefixing: my files would 
be whatever.local.cfa and the ones from the package would be whatever.cfa.

> > -       cf.fileinclude.cfa gets regenerated by looking in
> >         /usr/share/etc/cfengine.d
>
> You sure you want to  keep both prefix and suffix?

        No!  But I hadn't managed to kick the habit yet :).

	Just to come back to something we were discussing before, what 
about a central location for particular files that people want to copy 
out?  It could be quite useful for packages to be able to put files in to 
be copied out (for example, a mysql/postgresql shared secret ("password") 
for a database that needs to be accessed from various places).  These 
machines might like to have a directory that they know is already allowed 
in cfservd.conf (or whatever we call that).  So maybe the following are 
possibilities:
/usr/share/cfengine/files (and maybe config in /usr/share/cfengine/etc.d
        or something).
??? Ideas anyone?  I don't think this kind of thing is supported by the 
FHS; do we need a new /sitewide folder?  :).  Should this be suggested to 
FHS?

        So, the questions I'm putting out generally now are:

1.      /usr/share/etc/cfengine.d vs. /usr/etc/cfengine.d vs. something
        else?
2.      Location for stuff we want to copy out from a master location (see
        comments below)?

        And the question I'm putting to Mark is:
1.      Can we post something like this as a separate package on the
        cfengine site, once we get it sorted out a bit more?

        :)

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