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

[Chip Seraphine]

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.