Re: Need 'UncommentAndSetValue' or some such

[Luke Kanies]

On Thu, 27 Oct 2005, Brendan Strejcek wrote:

> It would certainly be nice to be able to manage objects representing
> things like users, cron jobs, and packages. These are common concepts
> shared by most operating systems. However, I am not sure it is worth
> abstracting everything in that way. For example, earlier today I needed
> to configure dvips's default paper size to letter rather than a4. This
> was the editfiles stanza that I used:
>
>     editfiles:
>         { /etc/texmf/dvips/config.ps
>             DeleteLinesMatching "^@\+ %%PaperSize: Letter$"
>             DeleteLinesMatching "^@ letterSize 8.5in 11in$"
>             # Since we are using prepend, the second one is listed first
>             PrependIfNoSuchLine "@+ %%PaperSize: Letter"
>             PrependIfNoSuchLine "@ letterSize 8.5in 11in"
>         }
>
> Sure, that would have been nicer if it was something like:
>
>     tetex-bin.defaultpapersize = letter
>
> (such as one might do with a system like lcfg) but that requires lots of
> uninteresting and hard to maintain translation code.

I agree completely, object-style management does not always make sense,
which is why I allowed for a simplistic editfiles system.  I actually think
objects + simple templates would probably be sufficient for everyone, but
the problem with editfiles, and this will always be a problem with this type
of system, is that it hides the intent of the action behind the format.

Even in your snippet, which is relatively straightforward code, it is by no
means obvious what the heck you are doing.  I don't know PostScript, so I
have to assume that '^' is the comment character in PostScript, and I also
have to assume that when you say that A4 is the default, you mean that it's
the program's default, not that it's specified in the configuration by
default (since you don't perform any operations involving this format).

The intent of this operation -- "use letter" -- would fail if someone had
explicitly specified any value at all, and anyone coming behind you would
have to rely entirely on comments to discern what the heck you are doing.
(You do comment your code, don't you?)

> I think there is probably a happy medium between low-level editfiles
> operations and high-level constructs like what you are suggesting, at
> least for managing Unix machines.

I'm not so sure, at least in the long term.

> > I'm guessing that 90% of all cfengine code out there is devoted to
> > host grouping, file actions (files, tidy, etc.), shellcommands, and
> > triggering processes based on changes. Throw in modules, and you're
> > asymptotic.
>
> Well, I just whipped up a quick perl analysis (see below for the
> possibly buggy code) of my cfengine policy files, based on line counts,
> and this is what I get:
>
>     editfiles       1133
>     shellcommands    614
>     control          436
>     classes          417
>     copy             335
>     comment          333
>     files            301
>     import           285
>     links            258
>     disable          161
>     alerts            93
>     processes         91
>     strategies        21
>     tidy              17
>     disks             15
>     groups            14
>     grant              6
>     ignore             3
>
> I rarely write long lines, so I think that is probably good data. I did
> not actually expect to see that so much of it was editfiles, but it is
> interesting to know. This manages various parts of about 200 machines,
> maybe 10 different OSs.

It would be interesting to compile results from everyone.  Here are mine,
with some caveats:

comment          459
control          281
copy             155
editfiles        116
files            102
processes         98
groups            48
shellcommands     35
import            28
strategies        27
disable           24
tidy              23
ignore            19
classes            7
links              4

I counted up my editfiles code, and there are a total of 15 elements in
there (that is, 15 discrete actions).  However, 4 of those elements create
cron jobs, 6 of them manage /etc/inetd.conf, and all but one or two of the
rest manage individual lines in files like /etc/netmasks and /etc/networks,
which could easily be managed through objects.

I wonder what the "element" count for your editfiles work would be.  For
instance, in your example, you use 7 lines to perform a single action, which
I would call one element.

Given both my and youyr stats, though, I would appear to be filling up on
crow right now, even though I still feel hungry.  I have not yet converted
my entire configuration to Puppet yet, and Puppet does not support any kind
of editfiles or templating yet, so we will see to what extent I cannot do
in Puppet what I did in cfengine.

-- 
Never interrupt your enemy when he is making a mistake.
                    --Napolean Bonaparte
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com