[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "CfPAN" library (was Re: Radmind vs CFengine)
Re: "CfPAN" library (was Re: Radmind vs CFengine)
Wed, 7 Apr 2004 13:14:49 GMT
I find it interesting that this topic came up. I suggested something in
this close to 3 years ago at the first LISA Cfengine Workship in '01.
See this link for more on what I am talking about :
I think we can do something like this and avoid localizations. You need to use
another scripting langauge to handle this problem. I call it Dynamic Cfengine.
have beening doing this for over 3 years now. I successfully installed my
code base in more that 10 different locations. So I do think it is possible.
trivially. But the benefits of having a community plug and chug infrastructure
makes me drool.
Essentially we need to define a base architecture that allows everyone to use
same set of cfengine files with enough flexibilty that we can define site
of how we do business. Or we need to create a good plugin structure. Either
should work. Once this is in place we can build front ends onto of the data
Having that we can use a templating engine to take all the configuration data
our machines and site then translate that in to cfengine files dynamically.
That challenge becomes building a community with a set of standards and good
practices that everyone can agree on. Which is what I would like to see
dmtg.org is already getting a start on doing this. Companies like Sun are
do it with N1. But were is the Open Source community for this?
I will leave my post at this. If anyone is interested please follow up. I have
resources to do this and I believe my company is willing to back me.
From: Chip Seraphine (address@hidden)
Subject: "CfPAN" library (was Re: Radmind vs CFengine)
Date: 2004-01-12 10:50:03 PST
I'm not talking about granularity, I'm talking about localization. For
example, your files probably contains a lot of things that are peculiar to
your environment. For instance, telnet might be universally banned on
Solaris machines at your site, you you might have a line that disables the
service in tcpwrappers or inetd.conf that responds to the 'any' or the
'sunos' class. That wouldn't be appropriate for sharing; you would need to
change that to a 'telnet_verboten' class and set that up in your groups file.
It's the same generalization problem that everybody has, really. Kinda like
how C coders try to define all constants in their header files so that 'magic
numbers' do not appear in the actual code. So called "properly written" code
would already have the telnet_verboten class used, thus abstracting the
decision to another file (cf.groups?).
However, we also have another type of localization issue that does *not* have
an easy analogue in C: The syntax of cfengine itself seems to encourage
intermingling of data and procedure. For instance, suppose my services files
are, by company policy, supposed to have all local services placed in
alphabetical order at the bottom of the file. Writing the code to enforce
this in cfengine without using "local assumptions" would be difficult.
Instead, I would probably just append the lines in a known order, or do a
"LocateLine" to the local service that precedes mine in the alphabet and then
insert. Both of these are hard to abstract out to the general case. Not
impossible, but much more difficult than a Perl routine (for instance).
I think cfengine config files are intended to be authoritative documentation
for the site, not just programs. Which means you are, in a sense, uploading
your site-specific documentation. With care this can be done in a way that
is useful, of course. I am just saying that it is a little less "natural"
than sharing code in traditional programming languages, which are designed
for reuse and library-fication from the ground up.
I think the real win of a cfengine library is in the 'how do you do that'
category. I'm sure somebody else has written a snippet that progressively
calls tidy with ever more aggressive deletion criteria until the free-space
threshold gets below a certain point; why should I have to reinvent the
wheel? Cutting and pasteing various snippets into my own config is entirely
reasonable, but I would hesitate to use someone elses entire "Maintain RedHat
On Monday 12 January 2004 11:18, Holger Schurig wrote:
> > As an example: If I was writing a perl utility to edit a config file, I
> > would expend a lot of work seperating my data from the machinery. In
> > cfengine, the cfagent *is* the machinery, and in a very real sense the
> > cfagent.conf *is* the data. So you end up with actual lines and words
> > mixed in with your procedure, so that your script becomes very localized.
> Are you sure? I split my setup in little independent files:
> aliases.conf groups.conf services.conf
> apt.conf inputrc.conf site.conf
> bashrc.conf issue.conf stopdaemons.conf
> bootmsgs.conf less.conf strategies.conf
> cd.conf mc.conf syslog.conf
> cfagent.conf motd.conf sysrq.conf
> cfservd.conf mountpoints.conf tcptimestamps.conf
> control.conf movehome.conf tcpwrapper.conf
> ctrlaltdel.conf moveopt.conf tidy.conf
> CVS/ network.conf timezone.conf
> .cvsignore nfs.conf update.conf
> devpts.conf path.conf xterm.conf
> dircolors.conf prompt.conf
> disable.conf rclocal.conf
> I could easily share some of them.
> You are not allowed to post to this mailing list, and your message has
> been automatically rejected. If you think that your messages are
> being rejected in error, contact the mailing list owner at
- Re: "CfPAN" library (was Re: Radmind vs CFengine),
Christian Pearce <=