From owner-freebsd-hackers  Sun Mar 19 12:12:35 1995
Return-Path: hackers-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA20219 for hackers-outgoing; Sun, 19 Mar 1995 12:12:35 -0800
Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA20210; Sun, 19 Mar 1995 12:12:34 -0800
X-Authentication-Warning: freefall.cdrom.com: Host LOCALHOST didn't use HELO protocol
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 
In-reply-to: Your message of "Sun, 19 Mar 95 19:36:49 +0100."
             <199503191836.TAA14270@uriah.heep.sax.de> 
Date: Sun, 19 Mar 1995 12:12:33 -0800
Message-ID: <20209.795643953@freefall.cdrom.com>
From: "Jordan K. Hubbard" <jkh@freefall.cdrom.com>
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

> 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