Thanks for the tip, Bazsi.... A new niggling comments, I'm afraid... check_hostname has been available since July 2002, but the only reference to it in the tar.gz is in the Changelog. There's no corresponding reference in the documentation trees, nor the FAQ. The same is true of bad_hostname of course, but that only been available recently. The code loop which performs the check_hostname check seems to contain a redundant colon check... We have: while ( ..... && *src != ':' ... ) { if ( .... || *src == ':' || ... ) {{_hostname The if clause is never true since the while test precludes it.... In effect the check_hostname option is performing hostname matches /^[A-Za-z0-9-_@:/]+$/ I can see why the "/" is needed to guard against declaring a chained-hostname as bad, but I can't quite see the logic behind the '@' inclusion. Could someone explain, please? Since my initial configuration errored on my Enterasys routers, ( effectively because the "hostname" field terminated in a "," instead of ":" or "[" ) the check_hostname() option obviously defaults to "no". Given how few good hostnames don't match /^[A-Za-z0-9-_@:/]+$/, it might be worthwhile making check_hostname() default to 'yes', or at least heavily recommending enabling the check in the FAQ. I'm guessing the check_hostname() option is a global only.. Under really odd circs, I guess some people might want it as a per-source option as well? so that a global yes can be overridden on some sources. Given that 1.5.25 now has a bad_hostname() option, how's about future releases having a good_hostname() option so that check_hostname(yes) === good_hostname( "^[A-Za-z0-9-_@:/]+$"). A hostname match then only succeeds if it passes both the good_hostname() and bad_hostname() checks, and moving the character set match for check_hostname() out to the configuration file would allow for more accurate site-specific hostname checking. Ted ............ check_hostname code loop in src/log.c /* It's a regular ol' message. */ else { /* If we haven't already found the original hostname, look for it now. */ char hostname_buf[256]; int dst; oldsrc = src; oldleft = left; dst = 0; while (left && *src != ' ' && *src != ':' && *src != '[' && dst < sizeof(hostname_buf) - 1) { if (lm->flags & LF_CHECK_HOSTNAME && !((*src >= 'A' && *src <= 'Z') || (*src >= 'a' && *src <= 'z') || (*src >= '0' && *src <= '9') || *src == '-' || *src == '_' || *src == '.' || *src == ':' || *src == '@' || *src == '/')) { break; } hostname_buf[dst++] = *src; src++; left--; } ............... =================================================================== On Thu, Jan 23, 2003 at 11:21:24AM +0000, Ted_Rule@flextech.co.uk wrote:

Having finally bitten the bullet and installed syslog-ng ( libol-0.3.6 / syslog-ng-1.5.24 ), I've only come across one problem... syslog messages from our Enterasys

Routers

are being corrupted. All Unix and Cisco messages appear Ok. [snip]

I note the version 1.5.25 has a bad_hostname() option. Is it possible that this may be used to alleviate this issue, or is some other workround needed? I'm guessing "keep_hostname(no)" might fix it, but would that potentially lead to other problems? Is there a summary of the algorithm which syslog-ng uses to determine whether the message contains a hostname?

There are two ways to overcome your problem: 1) check_hostname() is a global option that disallows '%' in hostnames, turn it on in your global options() section 2) use bad_hostname() -- ================================================================= ************************************************************************************************ This E-mail message, including any attachments, is intended only for the person or entity to which it is addressed, and may contain confidential information. If you are not the intended recipient, any review, retransmission, disclosure, copying, modification or other use of this E-mail message or attachments is strictly forbidden. If you have received this E-mail message in error, please contact the author and delete the message and any attachments from your computer. You are also advised that the views and opinions expressed in this E-mail message and any attachments are the author's own, and may not reflect the views and opinions of FLEXTECH Television Limited. ************************************************************************************************