(Attributions fixed.) On Fri Oct 22 08:43 1999 -0700, Roger Marquis wrote: > On Fri, 22 Oct 1999, Mark Roth wrote: > > Actually, I'm not sure that the facility is relevent. If you think > > about it, it's really just an arbitrary tag attached to each message > > in the current syslog scheme, and the categories are laid out in a > > completely useless manner. > > Facility isn't relevant? In what respect? If you mean as a tag in the > log file I'd agree. As a field in the protocol, however, it's > critical. I would never be able to manage the volume of log data our > sites generate without a separate file for each facility: I completely agree that having some method of filtering log data is required. I also run a busy log server, and I wouldn't want to sift through mountains of data to find the one thing I want. However, I think that the current facility mechanism is a really poor way of doing this filtering, for two reasons. First of all, it's not granular enough. LOG_DAEMON is a clear example of this. I don't see the value in throwing all daemon log data into one file unless multiple daemons have to do with each other. For example, cron and named don't really relate. Secondly, there's no clear standard over what each facility should be used for, so application developers each decide for themselves which one they should use. Even Weitse Venema, who has written some truly excellent security tools, made the dubious choice that the TCP wrapper library should log to LOG_MAIL by default. That's why I prefer to filter based on regexp. I can grab any message which has "connection refused from" in it and send it to the TCP wrapper logs, regardless of whether tcpd sent it to LOG_MAIL or sshd sent it to LOG_DAEMON. Or, I can simply check for "^sshd" to grab everything relating to sshd. In any event, I'm beginning to agree with many others here who think that metadata tags are the way to go. That would allow us to solve the problem of intelligent filtering in a much more elegant manner than simply matching a line of text based on a regular expression. > Why would you need 256 priorities when almost no applications use more > than 2 or 3 of the existing 8? Just as with facility names, I think application writers would be more careful with what priorities they send messages at if there was a clear standard guideline for making the decision. -- Mark D. Roth <[EMAIL PROTECTED]> http://www.feep.net/~roth/
