[rsyslog] directing logs to a broadcast address fails
rgerhards at hq.adiscon.com
Thu Apr 30 11:16:46 CEST 2009
> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Tom Metro
> Sent: Thursday, April 30, 2009 12:45 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] directing logs to a broadcast address fails
> Rainer Gerhards wrote:
> >> I was hoping rsyslog had fixed this, but the bug is present in version
> >> 1.19.12, and worse, it appears not to log any error messages.
> > That's a *veeeery* old version ;)
> Yeah, I figured. I noticed Debian jumped from 1.x to 3.x between Etch
> and Lenny, and even the faster paced Ubuntu did likewise between 8.04
> and 8.10.
> >> What might be a good work around for this? Build a local
> >> backport of 3.18.1?
> > Why not install from source?
> Just the usual reasons...more maintenance work down the road. If I
> install from source, it'll pretty much stay frozen at that version until
> something breaks, I'm motivated by new features to upgrade, or I do an
> OS upgrade. Packaging makes installing security updates practical.
> I'll try doing the backport. As long as there aren't any
> interdependencies that can't be met (like reliance on a newer kernel or
> shared library), it should just be a matter of grabbing the newer
> package source and rebuilding. Then when the OS eventually gets
> upgraded, it'll automatically get updated too.
Ahhhh! I was thinking about backporting a patch. I am the rsyslog guy, you
know, the one not really interested in distros ;) I now got you. I think a
backport to the older distro should be fairly painless. You may run into
gnutls issues, if you do, let me know. They should be easy to address (at
least I hope so).
> > ...only very occasionally come across [broadcast being used] (but of
> > course it makes sense if you have multiple receivers or want to hide
> > where the receiver actually is).
> I'm using broadcast as a means of distributing relatively rare critical
> notifications to all machines with a desktop I use. Reliability isn't
> critical as there will be redundancy in multiple receivers, traditional
> local logging, and eventual log analysis and reporting (logwatch).
> I considered using an IM protocol for this, but that requires depending
> on a server. It's hard to beat the simplicity of a broadcast UDP packet,
> and using syslog, which was already involved to some extent, seemed
Makes sense to me...
> rsyslog mailing list
More information about the rsyslog