[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cfengine config files location
From: |
Chip Seraphine |
Subject: |
Re: cfengine config files location |
Date: |
Wed, 29 Sep 2004 10:23:32 -0500 |
User-agent: |
KMail/1.5.4 |
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
- Re: cfengine config files location, (continued)
Re: cfengine config files location, Hauke Fath, 2004/09/26
Message not available
Message not available
- Message not available
- Re: cfengine config files location,
Chip Seraphine <=