On Wed, Jul 18, 2007 at 03:31:54PM -0400, Greg A. Woods wrote:
> 
> 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. 

I am well aware of your experience - you should not assume everyone
else is a neophyte.  Having used logadm I can tell you that just
reading the man page you have missed some important facilities.

> 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.
> 

Yes, but is it kimberlite which may contain a diamond or a chunk of
slate?  This is what I was getting at - you are says "oo look, here is
a rock", I am telling you you have missed some important information
because you have only looked at the man page.

> 
> 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".

Oh dear, then I suppose you are going to argue what exactly
constitutes a system log?  Why should newsyslog only deal with
syslogd?  Isn't that against the unix philosophy?  I think it should
be a tool that can, generically, manage logs - the right tool for the
right job instead of reinventing the wheel every time something else
needs to have logs managed.

> 
> Anything over and above that is not, and never was, its job.
>

So, a syslog log is a totally different and separate thing from a
squid log, apache log, sendmail log, <inser foo here> log?  No.  We
need a tool that can flexibly handle rotating any log.

> Today the benefits of data compression, even that of historical log
> data, are highly over-rated.
> 

I am glad to see that someone lives in a world where there are vast
vistas of disk to keep a reasonable depth of highly repetitive data.
Some places don't have this luxury and their management have an
expectation that reports can be generated on the data for a reasonable
time period.

> 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 have done is say "here is this round thing, it's not like
that syslog round thing".  I have yet to see where you demonstrate
that using newsyslog is any less safe & secure, just saying so does
not make it fact.

> 
> 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.
> 

Or squid or apache or.... that's the problem there are a lot more
things generating log files apart from syslogd - all the logs should be
managed in a centralised consistent manner.

> 
> 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. 

Who said anything about this not being the case?  The solaris
logadm.conf is precisely that - you can edit the file manually.
I may have missed it but I didn't see any mention of a suggested
format for the newsyslog changes - I don't think it progressed that
far.

-- 
Brett Lymn