IP address in log messages vs. a separate log file per IP

[John Gerth]

In the wake of moving over the last year from NT to Samba PDCs
(both for my own group and helping other people), I've had to chase
a number of annoying residual problems for which the samba debug
log messages proved invaluable.  However, they would've been much
more valuable several times if there had been an option to get
the IP address included in the bracketed message header, e.g.
    [2006/01/04 09:26:39, 1, 10.0.0.1] ....
in order to be able to see where the request was being generated.

For some time, I reasoned that the IP information wasn't always
necessarily available perhaps because a debug log message was
being generated many layers down, but after scratching around
for a while I found I could use a smb.conf directive, e.g.
       log file = /var/log/samba/%M_log.txt
or even sometimes
       log file = /var/log/samba/%m_%M_log.txt
to get a separate log file per IP and Netbios name thus it's clear
that the information about which IP a message is associated with
is there.

I have used the separate log file per IP method quite a few times,
so the question is why would I ask for a way to include the IP in
the message prefix?

Frankly, it's mostly a matter of convenience. Normally, we have
so few problems that a single log or syslog is sufficient, but I find that
when one has dozens or hundreds of clients that even fairly simple
problems (e.g. the client with a cryptic factory-default Netbios name)
require one to change the config and restart smbd to get the
disambiguation which comes with the individual files. Second,
explaining all this to others is very time-consuming and for
people with Apple Xserves, the individual files break all the
normal GUI tools forcing the novice admin into the commandline
(of course, some might consider that, on balance, a Good Thing).
Third, as both an audit and forensic tool, we have domains where
syslog messages are replicated centrally and so having the IP
would allow us to troubleshoot directly.

I realize that changing the format of log messages might be
both easy *and* difficult...easy in that the information is
available, difficult in that there may already be log parsing
tools that wouldn't tolerate such a change, but perhaps there's
a way to make a new behavior non-default so as to be backward compatible.