Re: samba Unmatched Entries

Willi Mann wrote:
> I guess on most distributions, syslog does not get successful logins, so 
> the filter author had to use the debug logfiles.

That should be just a matter of tweaking the log level for syslog.

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've quickly searched the syslog logfiles on one of my servers, but 
> there are no messages from samba in Debian default config. All messages 
> are in /var/log/samba/*.

That seems correct. I just checked the package supplied smb.conf on an 
Ubuntu system:

# If you want Samba to only log through syslog then set the following
# parameter to 'yes'.
;   syslog only = no

# We want Samba to log a minimum amount of information to syslog. Everything
# should go to /var/log/samba/log.{smbd,nmbd} instead. If you want to log
# through syslog you should set the following parameter to something higher.
    syslog = 0


This makes it clear that informational messages won't get sent to syslog 
by default, but it is a bit vague when it comes to error/critical 
messages, which perhaps are still being directed to syslog.


> AFAIK the samba filter was written long before the 3.0 release, so it 
> was written for the messages samba typically wrote out in 2.2...

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?

"log level" is absent from the above config, and the man page says:

   The default will be the log level specified on the command line or
   level zero if none was specified.

I don't see any logging related options in the init script, so it would 
seem that on Ubuntu samba is configured to use debug logs, but not log 
any debug information.

Whether "log level = 0" and "syslog = 0" means it is logging the same 
level of detail to both places, I can't say for sure, because as soon as 
I started actively using samba on the box in question I reconfigured the 
logging to follow the non-default settings I use elsewhere. I do see 
early debug logs showing only these lines:

[2007/06/02 14:16:23, 0] smbd/server.c:main(847)
   smbd version 3.0.24 started.
   Copyright Andrew Tridgell and the Samba Team 1992-2006
[2007/06/03 08:04:11, 1] smbd/server.c:open_sockets_smbd(408)
   Reloading services after SIGHUP

and nothing in the corresponding syslog daemon log, so that suggests 
there are at least some differences between the two log channels even 
when at the same log level.

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.

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.

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

  -Tom

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