Date: Sun, 19 Mar 1995 12:12:33 -0800 From: "Jordan K. Hubbard" <jkh@freefall.cdrom.com> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: freebsd-hackers@FreeBSD.org (FreeBSD hackers) Subject: Re: cvs commit: src/gnu/usr.bin/man/catman catman.perl Message-ID: <20209.795643953@freefall.cdrom.com> In-Reply-To: Your message of "Sun, 19 Mar 95 19:36:49 %2B0100." <199503191836.TAA14270@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> I'm not sure if i like your idea entirely. Coming from a system where
> everything and all has been done with different entries in root's
> crontab, i like the /etc/{dai,week,month}ly approach much more. I
Ah, you perhaps misunderstand me. I didn't say that /etc/{daily,weekly,monthly}
should go AWAY, simply not _do_ anything by default!
Consider, many many many of the system lossages we've encountered have
come as a result of a misconfigured or overly aggressive _default_
daily/weekly/monthly file - the principle of least surprise being
violated rather extremely here! When I first install a FreeBSD system,
I don't want that sucker going behind my back and doing _anything_ by
default until/unless I so chose it! They way it is now, you install
the box and then the next day you get this mail out of the blue saying
that your system has done all sorts of strange and confusing things to
itself over the night! If I were a new new system administrator, I'd
be scared and annoyed! What did these strange FreeBSD folks set my
system up to do by default? Where do they explain it to me? Ack!
So I think the scripts should do nothing by default. No mail, no
security checks, zilch. If I want to turn this stuff _on_, of course,
then I'm also free to do so. As I suggested before, this could be
(and will be) front-ended so that the novice system adminstrator is
encouraged to add a few checks like this, but at least they'll KNOW
that they set it up this way.
And yes, I agree that the commands should be individual files so that
the implementation is fairly open. We need to establish an API,
however, so that the overall framework utility for all of this and the
individual tools can communicate somehow! I would assume that a
certain number of special environment variables will show themselves
to be necessities as we dive in and start writing a more comprehensive
system.
If perl weren't already so popular, I'd be making a case for a tcl daemon
that you could feed scripts to in order to check your system security and/or
report information back to a central administrative workstation! :-)
Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20209.795643953>