[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Strategy for "one-off" tasks
RE: Strategy for "one-off" tasks
Fri, 11 Jul 2003 13:55:04 -0400
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
Keeping audit results in a web page is also a good idea. Time to start
growing the "to do" list.
gedas USA, Inc.
RE: Strategy for "one-off" tasks, Ferguson, Steve, 2003/07/11
Re: Strategy for "one-off" tasks, David Masterson, 2003/07/11
RE: Strategy for "one-off" tasks,
Ferguson, Steve <=
RE: Strategy for "one-off" tasks, Ferguson, Steve, 2003/07/14
RE: Strategy for "one-off" tasks, Nielsen, Steve, 2003/07/14
RE: Strategy for "one-off" tasks, Wheeler, John, 2003/07/15