Re: "CfPAN" library (was Re: Radmind vs CFengine)

[Christian Pearce]

I find it interesting that this topic came up.  I suggested something in 
passing like
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 :

http://www.cfengine.org/Workshop/pearce.pdf

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. 
 I
have beening doing this for over 3 years now.  I successfully installed my 
cfengine
code base in more that 10 different locations.  So I do think it is possible.  
Not
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 
the
same set of cfengine files with enough flexibilty that we can define site 
specifics
of how we do business.  Or we need to create a good plugin structure.  Either 
way it
should work.  Once this is in place we can build front ends onto of the data 
stores.

Having that we can use a templating engine to take all the configuration data 
about
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 
happen. 
dmtg.org is already getting a start on doing this.  Companies like Sun are 
trying to
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 (chip@trdlnk.com)
Subject: "CfPAN" library (was Re: Radmind vs CFengine)
Newsgroups: gnu.cfengine.help
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
9/Intel" setup.

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.

--
Christian Pearce
http://www.commnav.com



help-cfengine-owner@gnu.org said:
> 
> 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
> help-cfengine-owner@gnu.org.
> 
>