Re: Rsyslog template
James Zuelow put forth on 1/26/2010 7:19 PM:
>
>> -----Original Message-----
>> From: Stan Hoeppner [mailto:stan@hardwarefreak.com]
>> Sent: Tuesday, 26 January, 2010 15:57
>> To: debian-user@lists.debian.org
>> Subject: Re: Rsyslog template
>>
>>
>> Seems they put their network management eggs in the SNMP
>> basket. Log into the
>> web interface of one of the units and look at the "Tools"
>> tab. You can assign a
>> unique name there on each access point. I don't know if that
>> will only show up
>> in SNMP data or if that name will also then be logged via
>> syslog. Either way,
>> I'd def plug a unique name in here on each AP and reboot it.
>>
>> Look at their network management utility, comes on a CD
>> bundled with the AP.
>> It's geared toward SNMP. Also, look at your manual. It's
>> where I found all
>> this info:
>> ftp://ftp.dlink.com/Wireless/dwl3200AP/Manual/dwl3200AP_Manual_104.zip
>>
>> If you can't get syslog to do what you want, and you don't
>> already have an SNMP
>> infrastructure/collector, now might be a good time to start
>> building one. SNMP
>> is the standard for network device monitoring, not
>> syslog--likely the reason
>> DLink put more effort into SNMP than syslog.
>>
>> --
>> Stan
>
> Thanks for the comments. They are very odd devices.
>
> I have distinct hostnames set up, although you can only see them via telnet/ssh, not via the web browser. (Also, as far as I can tell you can only save the config via the web interface -- so you have to use both to fully configure one of these things.) Even with the system name set up, they do not put that information into their syslog messages.
>
> I already get SNMP info from them using OpenNMS. I do not want to install a specialty management suite just for them. Especially as the units I've received have come with different firmware revisions, and I would need two versions of their management software. They have one version for firmware 2.40 and another for firmware 2.50. When I had trouble getting 2.40 units to accept the 2.50 firmware, dlink tech support strongly discouraged even attempting to flash the firmware.
>
> So I'm more interested in getting rsyslog to work around their syslog quirks than trying to set up a SNMP trap based system. I know that rsyslog can create different files and even folders based on hostnames. I don't need such a complex system, I just need to know what the default rsyslog template looks like so that I can modify it by adding an IP address field into the mix.
>
> Cheers,
>
> James
Hi James,
It looks like you need to use an rsyslog template such as:
$template TraditionalFormat,%timegenerated% %HOSTNAME% %syslogtag%%msg%\n
However, I can't figure out from the rsyslog docs how to change the default
template to that. On my Lenny system, the default template declaration is:
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
You might try just commenting out the original you have, and entering something
like:
$ActionFileDefaultTemplate TraditionalFormat,%timegenerated% %HOSTNAME%
%syslogtag%%msg%\n
I don't know if that will work, but that's the first thing I'd try. If you
don't have DNS hostname entries for the APs' IP addresses, then I'd replace
"%HOSTNAME%" above with "%FROMHOST-IP%" which should just log the remote IP address.
If that doesn't work you'll need to bone up on the rsyslog docs, specifically
the section on templates. It's a bit confusing to me. It's as if the
documentation is written for folks who already have years of experience with
syslog and assumptions are made about the readers prior knowledge. For
instance, it tells you how to declare templates, but for the life of me I can't
figure out how you actually use them once you've declared them. The docs also
fail to state how declaring a new template affects the ActionFileDefaultTemplate.
IMHO the rsyslog documentation leaves much to be desired. In addition, I was
less than a fan of rsyslog after upgrading to Lenny and finding that rsyslog has
a virtual memory footprint of over 30MB(!) compared to only a few hundred
kilobytes for the old sysklogd. Rsyslog is a $deity d@mn memory hog, and
there's no good reason for that. Any syslogd should be miserly on resources.
The good news is that rsyslog is *optional* for Lenny. You have two other
choices for a syslog daemon. I upgraded from etch, and ran with the old
syslkogd for a while before replacing it with rsyslogd, which had to be done
manually. The *only* reason I did so was that the Lenny release notes almost
demanded that I install rsyslogd, as if sysklogd would break under Lenny, which
isn't the case. Apparently one of the Debian team has/had a stiffy for rsyslog
and they prodded us into using it. In my limited experience with it so far, I
see no advantage over the old syslogd.
So one option might be reverting back to syslkogd and work from there. There is
a current and supported sysklogd for Lenny. I'm not sure, but the default
configuration of sysklogd might do almost exactly what you want. You might also
want to look into syslog-ng although I have no experience with it.
Package: sysklogd
State: not installed
Version: 1.5-5
Priority: extra
Section: admin
Maintainer: Martin Schulze <joey@debian.org>
Uncompressed Size: 217k
Depends: libc6 (>= 2.7-1), klogd | linux-kernel-log-daemon
Conflicts: syslogd
Replaces: syslogd
Provides: syslogd, system-log-daemon
Description: System Logging Daemon
This package implements the system log daemon, which is an enhanced version of
the standard Berkeley utility program. It is
responsible for providing logging of messages received from programs and
facilities on the local host as well as from remote hosts.
Package: syslog-ng
State: not installed
Version: 2.0.9-4.1
Priority: extra
Section: admin
Maintainer: SZALAY Attila <sasa@debian.org>
Uncompressed Size: 434k
Depends: libc6 (>= 2.7-1), libevtlog0 (>= 0.2.3), libglib2.0-0 (>= 2.16.0),
lsb-base (>= 3.0-6)
Recommends: logrotate
Conflicts: linux-kernel-log-daemon, system-log-daemon
Provides: linux-kernel-log-daemon, system-log-daemon
Description: Next generation logging daemon
Syslog-ng tries to fill the gaps original syslogd's were lacking:
* powerful configurability
* filtering based on message content
* portability
* better network forwarding
--
Stan
Reply to: