[syslog-ng] Trouble with switches and syslog-ng

[Balazs Scheidler]

On Thu, 2007-04-05 at 08:29 -0400, Jean-Michel Philippon-Nadeau wrote:
> Balazs Scheidler wrote:
> > On Wed, 2007-04-04 at 11:01 -0400, Jean-Michel Philippon-Nadeau wrote:
> >> Good day everyone,
> >>
> >> 	We use syslog-ng to store and organize the logs of our machines 
> >> (~3900). For every host we have, syslog-ng creates a folder with the 
> >> hostname or the ip address (if it couldn't determine the hostname) of 
> >> the machine and then stores the logs.
> >>
> >> 	We also have 5 switches that can report logs with standard syslog 
> >> capabilities (udp on port 514). The problem is that syslog-ng doesn't 
> >> create the folder for these switches and doesn't store their logs. I 
> >> made sure there was no network problems by using tcpdump - the packets 
> >> correctly made it to the central syslog-ng host. Yes, of course, I made 
> >> sure udp(); was in my source declaration.
> >>
> >> 	Does anyone know how I can make sure syslog-ng receives the logs?
> > 
> > the message sent by the switch might not be in a format that syslog-ng
> > accepts and this way the message gets to the wrong destination.
> > 
> > can you paste a single log message as received by the syslog-ng host?
> > ie. a message you captured using tcpdump.
> > 
> 
> Here is a login failure from ssh to the switch received by tcpdump -A 
> -vv to a specific interface, a specific hos (a switch) and on UDP port 514.
> 
> 08:10:15.767285 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto 
> 17, length: 88) 192.168.175.2.syslog > 192.168.175.1.syslog: UDP, length 60
> 
> E..X.. at .@.[@.............D..Login failed for user adminccs through ssh 
> (192.168.10
> 

hmm. this line does not include a log header (no pri, no header, no
host, nothing)

syslog-ng will probably think (but I'd have to check) that "Login" is
the hostname, and depending on your keep_hostname() setting, it either
replaces Login with the host that sent the UDP frame, or leaves Login
alone, and thinks that it is a hostname (and thus stores messages in a
subdirectory named "Login").

the solution is to 
1) file a bug report to the vendor to fix their syslog message format
2) try to tune the bad_hostname() option to indicate that "Login" is a
bad hostname.



-- 
Bazsi