[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cfengine config files location
From: |
Tim Nelson |
Subject: |
Re: cfengine config files location |
Date: |
Wed, 29 Sep 2004 10:56:08 +1000 (EST) |
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/
Message not available
- Message not available
- Message not available
- Re: cfengine config files location,
Tim Nelson <=
Message not available