Re: samba Unmatched Entries

> I view logwatch's primary job as a system for monitoring for abnormal 
> conditions. It should be able to do that with minimal impact on the 
> system being monitored. But when it comes to informational reports (like 
> successful logins), 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.

> OK, that explains the volume of unmatched entries, but if so, why aren't 
> others complaining about this? Is it because the typical user is using 
> debug logs, but has the log level set to a low value?

Yes, probably.

> Samba seems to be yet another service that falls into the group of 
> services that potentially log to syslog or their own native format, 
> raising complications for the service filter.

I think this less an issue. A bigger problem is no program lists all 
possible log messages (it would suffice if it would at least do for the 
low levels), The only chance is to go to the source. And it would be 
good if the "headers" would be syslog compatible.

> In my opinion, logging for purposes of error monitoring (as is done by 
> logwatch) should go to syslog. This lessens the need to filter out 
> extraneous debug messages, and syslog logs are usually already set up to 
> be rotated and archived in a way appropriate for the level of security 
> monitoring desired on a system. In contrast, samba debug logs are by 
> default set to be truncated when they reach a specified size - throwing 
> away historical data.

I'd agree here if syslog (sysklogd, as it's still used per default at 
least on debian) was a little bit more flexible, so the samba 
maintainers could, without any potential naming conflict, make samba log 
to its own file, or at least a logfile group "fileserver". I'm not a 
friend of the "all in one" logging, as for example, I can't see anything 
in common between an VPN server and an CIFS fileserver.

BTW, on Debian sarge, the default debian config rotates a samba logfile 
named log.smbd. Unfortunately, per default there's one logfile per IP 
instead of the log.smbd logfile. I have not verified if this is fixed on 
etch.

> So I'd recommend we retarget the samba filter to work on syslog format 
> messages. The only thing I'd want to confirm before doing that is to 
> insure that error messages actually get written to syslog in the default 
> configuration of "syslog = 0". (I guess sifting though the samba source 
> will answer this. Anyone know an easy way to provoke samba to produce an 
> error? The kind of error you'd want logwatch to be able to catch, like 
> say an authentication failure? That should be easy enough to provoke.)

Please not if that requires any changes to other configuration files. 
And I would like to continue to get reports about successful logins from 
logwatch, because my servers serve such a small amount of users that I 
can by this way find anomalies.

Willi