Re: Strategy for "one-off" tasks

[David Masterson]

>>>>> Ferguson, Steve writes:

> Here's an example of one thing I want to do:

> I have a software audit script.  It'll report all packages on the
> system from a particular vendor.  I only want to run this once, get
> the output, and send it off to the business types who have to
> reconcile it with invoices and budgeting.

> It's done maybe annually, if that often.  I only want it run when
> I'm sitting there, at the keyboard, actually looking at the output.
> So it's essentially a once-only manual task.

So you do it with (perhaps) a looping 'rsh' script?

> I have a lot of other simple one-offs, mostly around harvesting
> information about the systems, not actually changing configuration.
> I can write a script, then leverage the fact that I've got this nice
> trusted cfengine infrastructure to push it out and execute it,
> returning the results to a central location.

One-offs are probably best done as shell scripts.  You could have a
control script that knows about the list of one-offs and invokes the
right one(s) based upon a given argument.  CFEngine could then invoke
the control script either at predefined times or when kicked
appropriately from a remote (central) system.  You could kick it from
the central system by dropping a file (containing one or more
arguments) into a well-known location which cfengine could copy to all
(appropriate) systems which, in turn, would trigger the cfengine on
the remote systems to run the control script.

> Because I have various classes of systems (production, development,
> qa), they're not all configured the same.  cfengine deals with this
> nicely, but I can't just say "Every system has 'product X'
> installed, and I have 100 systems, thus I know exactly what's
> running where."  I need a live check that tells me what's out there.

After the first time, why?  Are you *not* controlling what gets
installed on the systems?

> Granted, any change to configuration should be defined in a
> convergent manner.  Just because a configuration setting may only be
> performed once, it doesn't mean I can't leave the check in there to
> check/correct/enforce it periodically.  I agree that those sorts of
> things should be persistently handled.

Ah.  So CFEngine could run the control script at regular intervals to
collect the information.  That information could then be diff'ed
against the last "well-defined" set of information and an alert could
be signaled to you when things have (significantly?) changed.

> I think the notion of defining some sort of special class, to be
> invoked with cfrun, is probably the best approach.

Or, if you setup the information collection format correctly so that
diff'ing makes sense, CFEngine could do it also at regular intervals
and only alert you if needed.  If you were doing this by-hand, you
might collect the information only when needed (which is potentially
relatively time-consuming) whereas CFEngine could run the information
collection as often as you like and keep an up-to-date report in a
well-known location (like a web-page) as well as alert you when things
change (which you could later refine to when things change
significantly). 

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA