On Tue, Feb 2, 2010 at 7:43 AM, Clayton Dukes <cdukes@gmail.com> wrote:
Also, After looking at the documentation for 2.0, I see an option for: spoof_source
I'm a bit confused here since I've always just used keep_hostname and it seems to provide the correct source. What does spoof_source provide that keep_hostname doesn't?
Doesn't keep_hostname replace the header with the original source before forwarding it to the central syslog-ng server?
On Tue, Feb 2, 2010 at 9:29 AM, Clayton Dukes <cdukes@gmail.com> wrote:
Hey guys, I have a customer that is running v2.09 (with security patches). We need them to forward logs to our syslog-ng server but need to keep the original device as the source name.
I'm assuming this is what they need: keep_hostname(yes); chain_hostnames(no);
Can anyone confirm that v2.09 supports this? Is there anything else needed to accomplish this in v2.09?
-- ______________________________________________________________
Clayton Dukes ______________________________________________________________
-- ______________________________________________________________
Clayton Dukes
Hey Clayton, Yep, syslog-ng 2.0 supports keep_hostname(). As a simple explanation, keep_hostname(yes) simply preserves whatever is in the second column of an incoming message. By the sounds of it, your client should be using it throughout any syslog-ng relays or hops and you should be using it on your receiving end. When keep_hostname(no) is used, syslog-ng sets the host column to be whatever IP it received the message from. Also keep in mind that keep_hostname() (along with other formerly global options) can be used in a source {} definition starting with syslog-ng 3.x , so if you have multiple clients relaying stuff to you on several different ports, you may have more flexibility by using versions 3.x. Using spoof source, syslog-ng will re-write a UDP packets source address prior to forwarding it on to its next destination, so the endpoint syslog box *thinks* it got it from someone else (since UDP is connectionless, this is possible). It doesn't sound like you need this feature in your scenario. -- Lance Laursen Demonware Systems Engineer