Hi, Time to reply to my own email.... Alexander Clouter <ac56@soas.ac.uk> [20061019 10:25:38 +0100]:
[snipped]
What I am planning on doing is having something like the following in my syslog-ng.conf file which is fantastic as to add logging groups I just add extra udp() lines to s_multicastGeneric and nothing else is needed. At the moment I would need separate source/destination/log entries per multicast group address, which is upsetting and results in a hideous configuration file.
==================== source s_multicastGeneric { ## squid # access udp(ip(239.194.251.0) port(514)); # cache udp(ip(239.194.251.32) port(514)); };
destination df_multicastGeneric { file("/var/log/syslog-ng/mulitcastGeneric/$DESTIP/$R_YEAR$R_MONTH$R_DAY.log"); };
log { source(s_multicastGeneric); destination(df_multicastGeneric); flags(final); }; ====================
[snipped]
As I said, I'm working on a patch at my end and will post it here once done, but its unlikely to be pretty... :)
well I said it was going to be nasty, the patch has been attached for peer review. It really does things in probably a manner that is going to make Balazs break down into tears. The patch enables you to do the above so that you can have a group of machines all logging to the same multicast address and all their messages appear in the same logfile. To add new *groups* of machines you simply add the single extra multicast udp() line to s_multicastGeneric you want to listen out for. This is as opposed to maintaining a collection of source address IP's to filter under which can become un-managable if your groups become large in the number of hosts they contain. The only other way I thought I could implement the patch, that I could think of, was to make my admendments in log_source_group_queue() however[1] I thought it would be more efficient to put it in the macros.c file so that the conversion of the binary address into something human readable would only occur if $DESTIP[2] is evaluated. Anyway, it "Works for Me(tm)" and something like this in syslog-ng would be very helpful. Obviously we are in the release candidate stage so I don't expect it for version 2.0 :) I look forward to the feedback, flames, onslaught... Cheers Alex [1] also I could not find out how to get to the original socket that had been read from easily [2] I chose not to bother with $HOST_TO (look up the PTR record for the destination multicast group) as I though it would be best to get this looked at first and I can live without $HOST_TO 'support'