Yeah, a reflector does sound like a good idea. I'll run it on the local system - we are writing an embedded system that has to be well-encapsulated and we have no control over systems outside our own. Since our system is a daemon (in C) that runs on the local system, I can just have it do the listening itself. I could config syslog-ng to send its data to a listener on a port on the local machine and it would then do the broadcast out onto the local net. Did we ever establish that syslog-ng cannot do a broadcast? Sounds like it can not. And I agree with your statement about 'translators' - can't tell you how many times I've done that in the past decades that I have been writing code...it's beyond being countable. I want syslog-ng to be a black box so we can update it at will and not have to worry about embedding our own changes in it, ever. So I don't think I'll try to add anything to it. Many, many thanks for your responses. It is great to put a message into a list on Friday and have a workable suggestion by Sunday afternoon (US PDT). This world-wide collaboration is great, isn't it? [Jim] On 4/23/06 12:43 AM, "Alexander Clouter" <ac56@soas.ac.uk> wrote:
Hi,
Ahhh, legacy 'fun' :)
Jim Schuyler <sky@red7.com> [20060422 17:32:06 -0700]:
We are rewriting an existing bit of software and porting to Debian Linux. The old piece could use a UDP broadcast to send its logs, as well as specifying an IP address or a resolvable name. And they wrote custom code to do everything. Our approach is to use Debian packages for most things so we don't have to go write custom code. Vastly superior, but it means some of the things that were totally "exposed" before are now hidden. The problem is that our client requires that we exactly duplicate the previous capabilities - in this case that includes the broadcast.
If thats the case I would suggest you write a custom standalone reflector which takes regular unicast UDP packets, rewrites the destination and spits the packet back onto the wire.
This could be done with twenty lines of Perl script or C code. syslog-ng would not have to be changed and you could use anything. The reflector would sit on the legacy subnet, everything outside that system would be able to continue as it was before.
Also we do not have control over the "receiving" end. We cannot demand that it be syslog-ng. Any old syslog has to work.
In my experienceits best trying to write 'translators' to get legacy stuff to behave better rather than bogging down 'new' code to speak to the legacy stuff. The idea is that then you only write the translator one rather than 'n' times for each bit of 'new' software you want to speak to the legacy system.
I wish it were so. Thank you for your suggestions.
If you still plan on re-writing a chunk of syslog-ng then I still suggest you look at my patch. The reasoning is that you have to program syslog-ng to recongise the the address is a broadcast one, call a setsockopt() and then you can broadcast packets. Beej[1] comes to the rescue with that one ;)
My patch had to do that same, first identify if the address is a multicast one, and then set some socket options (abeitly for receiving).
Cheers
Alex
[1] http://beej.us/guide/bgnet/output/htmlsingle/bgnet.html#broadcast
[Jim]
On 4/22/06 9:28 AM, "Alexander Clouter" <ac56@soas.ac.uk> wrote:
Hi,
Jim Schuyler <sky@red7.com> [20060421 18:38:31 -0700]:
Although I have tried to convince my client that this isn¹t exactly the best idea, they want to configure syslog-ng to send logs by broadcast rather than to a specific address on their subnet.
Previously the configuration line we used for a specific remote syslog was:
destination grouplog { udp(192.168.1.14 port(514)); };
Can syslog-ng actually do udp broadcast, and if so, what would be the appropriate config line to cause this to happen?
(I have tried using 192.168.1.255 and 255.255.255.255 and neither seems to do it, although I might not be properly configured on the other end to receive broadcasts...the other end is Mac OSX and it does receive messages just fine if I configure 192.168.1.14, as above.)
If you look over the previous month or so worth of archive for this mailing list you will come across my multicast support patches. To send stuff to a multicast address you don't need to do anything special, but to receive it syslog-ng needs a light bit of patching.
For the sort of thing you are after, it really sounds like multicasting would suit you far better.
Cheers
Alex
[Jim Sky]
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html
Jim Schuyler <sky@red7.com> red 7 communications, inc. San Francisco, California USA PGP key ID: 0x93618262 Have a FIT! ... http://red7.com/fits.html
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html
Jim Schuyler <sky@red7.com> red 7 communications, inc. San Francisco, California USA PGP key ID: 0x93618262