--pgp-sign-Multipart_Wed_Jul_18_15:31:49_2007-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Wed, 18 Jul 2007 11:02:19 +0930, Brett Lymn wrote:
Subject: Re: newsyslog and script execution instead of sending signal to process
> 
> On Tue, Jul 17, 2007 at 02:26:32PM -0400, Greg A. Woods wrote:
> > 
> > Note too that it's poor design and total lack of integration into the
> > overal system pretty much mandates that it have both the pre and post
> > command hooks that it has.
> 
> I'm sorry - I don't believe that you are competent to comment on the
> implementation of logadm at all.  You have just looked at the man
> pages, you have no experience with running it.

Anyone with any decent amount of experience managing unix systems, and
I've got a whole hell of a lot more than many people do, can see from
its manual page alone what its inherent design limitations are.  If it
looks and smells like a rock, talks and walks like a rock, feels like a
rock, and hurts like a rock, then it's either a rock or a very near
relative of a rock, and we all know what rocks are like.


> newsyslog is meant to manage logs

No, not really.  newsyslog is meant only to keep syslog files (and other
similar system log files) from growing to fill all available disk space,
or more concisely to "maintain system log files to manageable sizes".
It happens to do so in a way that does not necessarily result in the
immediate deletion of historical information and at the same time it
provides enough flexibility to meet the varying needs of any site for
retention of historical information and for the varying demands and
requirements of most kinds of log files.

Anything over and above that is not, and never was, its job.  Even its
ability to compress historical information is more a concession to the
limitations of disks in the day when that feature was first implemented.
Today the benefits of data compression, even that of historical log
data, are highly over-rated.

As I've explained ad nauseam in another post, it is quite trivial to
design and implement additional programs which provide further abilities
to fully "manage" log files, and to do so in a more safe and secure
manner than could ever be done by extending or enhancing newsyslog.


> What you are suggesting is filling up the crontab with bunches of
> little scripts all watching directories waiting for Stuff To Turn Up.
> Or are you suggesting you roll all that up into one script?  and have
> a config file?

I didn't really suggest anything in so much detail.  _all_ of that is
left as an exercise to the reader -- the more imagination they have,
perhaps the better their result.  :-)  In this case if the person doing
the design can fully understand and explain why syslogd doesn't create
the files it writes to then perhaps they're qualified to come up with
something half-way decent.

This is unix -- there's more than one way to skin a cat.  Sometimes
you'll get scratched, sometimes you won't, and sometimes you'll lose
more skin than the cat.

Personally I like using config files to gather similar or related
information about objects or tools, and I'm quite happy with the
relatively free-style "table" form used by many unix tools.  I hate
having too many config files though, especially if more than one of them
contains highly similar or related information, and especially if
there's no easy and obvious way to form tight logical relationships
between the related items.  For example I don't necessarily like having
to edit two or more files just to describe one more object.

-- 
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>

--pgp-sign-Multipart_Wed_Jul_18_15:31:49_2007-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: cqWITMGjZkVJylVfaRmvmhv3IciRMjD0

iQA/AwUBRp5qpmZ9cbd4v/R/EQK8jgCdHWc0U5HGUZruZeW0bZkw0ZhtdYYAoJpb
mGNbTvceuVLvcLzREvrb2GEz
=3yMU
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Wed_Jul_18_15:31:49_2007-1--