Re: samba Unmatched Entries

Willi Mann wrote:
>> I think it's fair game for the service 
>> filter author to document configuration changes needed in order to 
>> obtain the data for informational reports.
> 
> I think logwatch should never require changing configuration values. It 
> should work with the default configurations of most distributions.

Even for reporting on optional information? I don't think that's 
realistic in general. It just happens that in this case the service in 
question logs adequate detail to its debug logs to produce the desired 
informational reports. With other services, it may be necessary to 
increase the logging detail level to get what you want.

But again, if the primary task of logwatch is reporting on error 
conditions, then you shouldn't need to change configurations to attain 
basic functionality.


>> In my opinion, logging for purposes of error monitoring (as is done by 
>> logwatch) should go to syslog.
> 
> I'd agree here if syslog...was a little bit more flexible, so the samba 
> maintainers could, without any potential naming conflict, make samba log 
> to its own file...

I share your dislike of multi-service logs, as used by syslog. Syslog-ng 
is one alternative, though obviously it doesn't come stock with any of 
the common distributions.

However, most of the log monitoring tools, logwatch included, seem to be 
designed for working with combined logs. Some (logcheck) even go so far 
as to take all your separate logs and blend them together before 
analyzing them.

Once I considered that, it hardly seemed worth the bother of setting up 
Syslog-ng (which I've used on systems years ago, but don't bother with now).

If your log files are small enough to manage them easily, and the 
services are adequately identified in each log line so you can split the 
data out later, and the only time you actually need to look at the logs 
is when your log monitoring tool flags a problem, then I don't see too 
much of a negative in having combined logs.

One related issue is how best to handle multiple instances of the same 
service that might be used for different purposes, but still logs 
through syslog. For example, I use dovecot as both an IMAP server and a 
local delivery agent (LDA). Two rather separate functions. Normally 
they'd both log to syslog, and presumably the logwatch dovecot filter 
would report on both (in actuality, the current filter doesn't handle 
LDA messages, and I'll probably create a separate filter for LDA).

Having the different instances log through different channels seems like 
the logical thing to do, though that tends not to work well with 
logwatch, as that usually implies two different log formats, and even if 
you solve that, unless you want the data from both instances blended 
together in one report, logwatch doesn't have an easy way to handle it. 
(In theory, you'd symlink the service filter script to some other name, 
and then create a matching service config file and log group config file.)

Another example of this is Postfix. It's quite common with modern spam 
filtering setups to be running multiple distinct instances that each 
have specialized tasks. One might be used for the public-facing 
front-end (accepting mail and feeding it to a spam filter). Another 
might be for local deliveries and forwarding inbound mail to machines 
within the LAN. Another might be for relaying mail from client machines 
on the LAN. Ideally each of these should have separate logs and separate 
reporting in logwatch. That's probably quite tricky to pull off if 
they're all logging to syslog.


> BTW, on Debian sarge, the default debian config rotates a samba logfile 
> named log.smbd. 

I couldn't remember if that logrotate config file came with a Debian 
package, as I customized mine a long time ago, but looking at my RCS 
logs for that file, I do see it started out as a package supplied file. 
I don't seem to have kept the Etch version, but the Sarge version 
rotated both /var/log/samba/log.smbd and /var/log/samba/log.nmbd. (It 
was also a buggy script in that it rotated each file separately and 
unnecessarily restarted both daemons each time.)


> Unfortunately, per default there's one logfile per IP 
> instead of the log.smbd logfile.

There should be both. The ones with machine names or IP addresses are 
the client-specific debug logs.

Rotating the client logs was one of the things I fixed in my logrotate 
config file. But I think you'll find that the package smb.conf still 
contains a "max log size" directive, which I believe applies to all of 
the debug logs, not just the client logs. That means there is really two 
potentially competing log management/rotation schemes in effect.

The package maintainer probably figured he'd treat log.smbd and log.nmbd 
like regular logs, and rotate them normally, while letting samba treat 
the client logs as debug logs and truncate them.

If you look at the Samba documentation, all of these logs are really 
meant for debugging purposes, not general logging. It's quite arguable 
that the default configuration of the Debian package has the logging set 
up improperly. Perhaps I'll open a ticket on this...

  -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/