Mark D Roth <[EMAIL PROTECTED]> writes: > I can easily imagine needing more granularity in NEWS and MAIL; for > example, to seperate out IMAP/POP connections from SMTP connections. My experience as a news administrator is that LOG_NEWS works pretty much exactly the way I want. A lot of news servers involve a huge spectrum of different programs, so a simple regex solution just wouldn't work. One could add a tag specifically for regex filtering, but the tag that I'd want to add is exactly what LOG_NEWS provides. Seperating reader logging from transit logging sounds like it might be reasonable on first glance, but it turns out that nearly all news server installations use automated tools that come with the news server to summarize logs into reports, and those tools expect everything in the same file. > AUTH is almost never used right, in my experience. Many things which > should log there use DAEMON instead, and many things which log to AUTH > really belong somewhere else. AUTH suffers primarily from a poor specification, IMO. Is it specifically for authentication events (logins, failed logins, password changes), is it for anything that may be authentication-related (TCP wrapper logs), or is it for the authentication subsystem (Kerberos kdc logs)? I think this could be solved with a clearer separation and clearer definitions. Or maybe a completely different approach.... There have been several times when I've really want to classify log messages along two orthogonal lines. One where I'm keeping all the messages related to a particular service together (all web logs, all remote login -- telnet, rlogin, ssh, etc. -- logs, all sendmail logs, all POP service logs), and another where I can see all log messages of a particular *type*. Like all rejected connection logs, whether internal to ssh, from TCP wrappers, from some daemon linked with libwrap, from tcpserver, etc. Or all user authentication events, whether from nnrpd or from telnetd. That makes an argument -- I don't know how strong of one -- for a third classification in addition to facility and priority. -- Russ Allbery ([EMAIL PROTECTED]) <URL:http://www.eyrie.org/~eagle/>
