Remote hosts logging as loopback, not hostname
Hello, Knowing next t'nothing about openssl, stunnel, and syslog-ng, i've gotten a central loghost going with one remote client. Poking into MySQL is via: INSERT INTO logs (host, facility, priority ... VALUES ( '$HOST','$FACILITY','$PRIORITY'... )etc. with all the $MACROS you'd expect. However. The messages from the remote host always seem to appear as 127.0.0.1! My question is: is it because of something i am or am not doing in syslog? I am not logging remote messages to any local logs, something that only dawned on me after i had it all running. Instead, I am doing this: # Sending to the MySQL table log { source(s_all); destination(d_mysql); }; # ... as well as remote client messages log { source(stunnel); destination(d_mysql); }; which, i realize, may inspire laughing. or not. It seemed like a good idea at the time, as the idea was to have every individual hosts' logs be 'personal,' and the database be the amalgam. I am starting to suspect stunnel, however, as well: source stunnel { tcp(ip(127.0.0.1) <<=== ! port(514) max-connections(10) ); }; is THAT why remote messages are being stamped with a $HOST of the loopback address? Is it a combination of both factors, neither, something else entirely...? I'm prepared to go bug the stunnel list too, if necessary :D. Thanks! Robert -- Rob Munsch Solutions For Progress IT
Rob, This is covered in the faq - it's even called something like "using stunnel, all hosts are logged as localhost". Use this: options{ keep_hostname(yes); }; -- Nate Campi
That's what i thought, and did from the start... No joy. Sorry. i should have been more explicit about that. just to be safe, i'd enabled keep_hostname on client and server. No effect. After that, i fiddled with various permutations of chain_hostnames on and off on client and/or server; since the $HOST macro expands to name of the originating host, as explicitly stated in the reference manual. nothing. aargh... then, since it was very late on Friday, i went home :). is there anything i could be doing with stunnel to mangle this process..? I have syslog dumping the remote messages to a plaintext file, and there too hosts show as loopback. Did this to see if maybe i was just screwing up the MySQL side of things; don't seem to be. So here's what the client, randomaccess, logs/dumps to a text file: randomaccess auth info info 26 2006-03-13T15:52:15-0500 su(pam_unix) su(pam_unix)[9942]: session opened for user root by (uid=500) now here's the funny part. here's a sample line, on the server, of what's coming over. Isis is the server, randomaccess is the remote client, they both are using the same template... but this same line on isis looks like: 127.0.0.1 user notice notice 0d 2006-03-13T15:52:55-0500 randomaccess randomaccess auth info info 26 2006-03-13T15:52:15-0500 su(pam_unix) su(pam_unix)[9942]: session opened for user root by (uid=500) How is the info getting scrambled around? Both files are using identical template statements, which is template("$HOST $FACILITY $PRIORITY $LEVEL $TAG $ISODATE $PROGRAM $MSG\n") and on the client it seems pretty clear. by the time we hit the server, however, it seems to think loopback is the host... and randomaccess is the program...? in addition, the entirety of this info - host thru isodate - becomes the $MSG. Very odd. How am i accomplishing this feat? Nathan Campi wrote:
Rob,
This is covered in the faq - it's even called something like "using stunnel, all hosts are logged as localhost". Use this:
options{ keep_hostname(yes); }; -- Nate Campi _______________________________________________ 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
-- Rob Munsch Solutions For Progress IT
oh SON of a SWITCH. So of course, i should not be stuffing clients' info into the same template twice. Doesn't seem to like that. I assumed they'd have to match, for some reason. Removing the template() line from the client has allowed the info to appear as one would expect. Templates on client and server processes it twice and it doesn't like it a little bit. may i humbly suggest that a note about template() being advisably *server-only* in such an environment might be in order. of course, that may be obvious to most people without having to be told; i can't tell. this would be the second "note to, for and by idiots" addition on nate's faq to come from my addled brain. i'm going to go get some coffee. Rob Munsch wrote:
a lot of pointless detailed crap
Nathan Campi wrote:
Rob,
This is covered in the faq - it's even called something like "using stunnel, all hosts are logged as localhost". Use this:
options{ keep_hostname(yes); }; -- Nate Campi _______________________________________________ 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
-- Rob Munsch Solutions For Progress IT
On Mon, 2006-03-13 at 17:26 -0500, Rob Munsch wrote:
oh SON of a SWITCH.
So of course, i should not be stuffing clients' info into the same template twice. Doesn't seem to like that. I assumed they'd have to match, for some reason.
Removing the template() line from the client has allowed the info to appear as one would expect. Templates on client and server processes it twice and it doesn't like it a little bit.
may i humbly suggest that a note about template() being advisably *server-only* in such an environment might be in order. of course, that may be obvious to most people without having to be told; i can't tell. this would be the second "note to, for and by idiots" addition on nate's faq to come from my addled brain.
i'm going to go get some coffee.
Oh I see, you were changing the on-wire format using a template(), although this might be useful for custom receivers it causes problems for a 'normal' syslog daemon (like syslog-ng is behaving when it is a server) I'll add a note to the documentation. This is what I added, is that making it clear? <row> <entry>template()</entry> <entry>string</entry> <entry> a format conforming to the default logfile format. </entry> <entry> Specifies a template which defines the logformat to be used in this destination. Macros are described in <xref linkend="macros">this section</xref>. Please note that for network destinations it might not be appropriate to change the template as it changes the on-wire format of the syslog protocol which might not be tolerated by stock syslog receivers (like syslogd or syslog-ng itself). For network destinations make sure the receiver can cope with the custom format that you define. </entry> </row> -- Bazsi
yah, that should red-flag it nicely. thanks! Balazs Scheidler wrote:
On Mon, 2006-03-13 at 17:26 -0500, Rob Munsch wrote:
oh SON of a SWITCH.
So of course, i should not be stuffing clients' info into the same template twice. Doesn't seem to like that. I assumed they'd have to match, for some reason.
Removing the template() line from the client has allowed the info to appear as one would expect. Templates on client and server processes it twice and it doesn't like it a little bit.
may i humbly suggest that a note about template() being advisably *server-only* in such an environment might be in order. of course, that may be obvious to most people without having to be told; i can't tell. this would be the second "note to, for and by idiots" addition on nate's faq to come from my addled brain.
i'm going to go get some coffee.
Oh I see, you were changing the on-wire format using a template(), although this might be useful for custom receivers it causes problems for a 'normal' syslog daemon (like syslog-ng is behaving when it is a server) I'll add a note to the documentation. This is what I added, is that making it clear?
<row> <entry>template()</entry> <entry>string</entry> <entry> a format conforming to the default logfile format. </entry> <entry> Specifies a template which defines the logformat to be used in this destination. Macros are described in <xref linkend="macros">this section</xref>. Please note that for network destinations it might not be appropriate to change the template as it changes the on-wire format of the syslog protocol which might not be tolerated by stock syslog receivers (like syslogd or syslog-ng itself). For network destinations make sure the receiver can cope with the custom format that you define. </entry> </row>
-- Rob Munsch Solutions For Progress IT
participants (3)
-
Balazs Scheidler
-
Nathan Campi
-
Rob Munsch