Red Hat Bugzilla – Bug 175837
allow forwarding to localhost ports other than 514
Last modified: 2008-11-29 08:58:19 EST
Description of problem:
On Thursday 15 December 2005 03:31, Tony Griffiths <firstname.lastname@example.org> wrote:
[we have] a centralised logger that captures information from all computers and
applications that have the appropriate logging levels enabled. Various
utilities to examine this log information in both realtime and via batch
trolling have been written.
But what about system daemons, et al?
This has been problematic since there are numerous system daemons and
subsystems that affect the performance of the computing cluster and
applications but their logging information typically gets lost in the
syslog message file(s). It would be possible to troll these files later
but merging that information into the other log in proper time sequence
would be difficult. Even a 'live' tail -f on the /var/log/messages file
would probably not provide good enough timing to keep log entries in
strict monotonicly increasing time order! To solve this problem, I've
created a patch to the redirection code in syslogd that allows UDP
messages to be sent to a port OTHER-THAN syslog (514). This patch tries
not to break the circular redirection logic but does allow redirection
to a "local" IP address as long as the destination port# is not the one
that syslogd itself is listening on. With this patch, we can setup
rules in /etc/syslog.conf to capture *important* system information and
have it sent to our logger daemon for incorporation into the application
logfile(s) in proper time order. Of course if our daemon is not up or
is unreachable, the UDP packets simply drop in the bit-bucket as they
should. The format allowed by the patch is-
# redirect some msgs to a remote host
with the absence of the ":port" indicating that the variable LogPort
(defaults to 514 but can be overridden by -p switch) is used. This is
traditional syslog redirection! I've attached the patch files. The
remote-port patch to syslogd.c assumes that the three prior patch files
have been applied.
Hopefully you can incorporate this patch into the standard RedHat SRPM
Created attachment 122292 [details]
Patch submitted by Tony Griffiths of Agile TV
(Reassigning to current package owner.)
Given the alternatives now available for this use-case, and the date at which this request has been made, is this still relevant?
If it is, I'll need to contact upstream and ask if they want to accept the patch, because I won't ship it in Fedora if it's not going to end up upstream.
No response from customer