RE: Strategy for "one-off" tasks

[Ferguson, Steve]

David Masterson wrote:

> Ferguson, Steve writes:
> 
> > 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?

Certainly possible, but when I have this cool public-key-backed secure
method of distributing and executing commands, I'd rather use it.  Sure, I
could substitute ssh for rsh, given that we've disabled rsh (and I do plan
to have cfengine handle key management for host-based ssh trust), cfengine
has a lot to offer in ease of gathering the output and error handling that I
no longer have to 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?

We have a large group, and essentially this audit mechanism has been defined
as "the way".  That way nobody has to manually remember to update a list
somewhere when installing software.  Even if we did manually update a list,
this audit is going to be more accurate because it reflects a point-in-time
snapshot of reality.  No manual intervention by the technical staff = good.
:-)  Let the bean-counters and managers spend their time manually reviewing
the data and reconciling it against their reports. :-)
 
> > 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 hadn't really considered this, but I like the idea of keeping the audits
for historical purposes and applying diffs.  The audits are not terribly CPU
intensive, so running them weekly would be negligible.  See, that's why I
asked for everyone's input. :-)

In fact, I could arrange to have the results automatically shoved into an
RCS or CVS repository when they change, so storage is more efficient and I
can easily pull up diffs based on different points in time.  Hmmm... the
wheels are turning.
 
> 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). 

Keeping audit results in a web page is also a good idea.  Time to start
growing the "to do" list.

Steve
--
Steve Ferguson
gedas USA, Inc.
Steve.Ferguson@gedas.com
http://www.gedasusa.com