Re: samba Unmatched Entries

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

The point is that if the information is somewhere, logwatch should use 
this "somewhere". Obviously, you can't get information that nowhere 
logged. Then documentation what to change make sense. However, we always 
found a somewhere to get all needed information, AFAIK.

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

Do you never look at your raw logfiles?

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

If I can split out data earlier, I do it. And it's much easier to handle 
the case when a service went crazy and filled your logs with garbage. I 
have this issue sometimes with squid and crazy windows machines.

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

I assume the trivial way to solve that would be to allow a
script =
option, that allows overiding the filter script name.

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

And is often so badly configured that it produces masses of bounces.

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

That's just because %m can't always be resolved. As far as I understand 
it, log.smbd and log.$ip should always be disjunct. But splitting per 
client is too much distribution IMHO.

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

Seems to be true.

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

I would say, log rotation should be better configured in the default 
configuration. (an example is the apache2 log rotate script), and max 
log size should be set to 0 then.

The smb.conf manpage calls all logging "debug logging", probably because 
in SAMBA, there is a macro call DEBUG_PRINT or the like, for all 
logging. So I don't see a problem with logging to /var/log/samba, and 
don't think they don't want to do general logging there.

Willi