help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: John Sechrest
Subject: Re: "CfPAN" library (was Re: Radmind vs CFengine)
Date: Wed, 07 Apr 2004 06:52:58 -0700



I think that this direction of moving to plugins or to some means
of sharing code for cfengine is vital. 



"Christian Pearce" <pearcec@commnav.com> writes:

 % 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.
 % > 
 % >
 % 
 % 
 % _______________________________________________
 % Help-cfengine mailing list
 % Help-cfengine@gnu.org
 % http://mail.gnu.org/mailman/listinfo/help-cfengine

-----
John Sechrest          .         Helping people use
                        .           computers and the Internet
                          .            more effectively
                             .                      
                                 .       Internet: sechrest@peak.org
                                      .   
                                              . http://www.peak.org/~sechrest




reply via email to

[Prev in Thread] Current Thread [Next in Thread]