[syslog-ng]syslog-ng documentation and some minor niggles

[Ted_Rule@flextech.co.uk]

Many thanks to Stephen Frost and Balazs for the useful information
and suggestions regarding PIX syslogging.

Having had a slightly deeper read of the latest src tree, I'd like to just
make a few suggestions and comments.


Several of the options available have Default Settings
in their relevant subsection of the HTML tree within:

/usr/src/syslog-ng/syslog-ng-1.5.19/doc/sgml/syslog-ng.html

However, several options don't have defaults listed therein. Perhaps the next
round of documentation
updates could double check that all defaults are fully listed in the html pages.

The Main HTML Doc Pages at

     http://www.balabit.hu/static/syslog-ng/reference/book1.html

contain no reference to recent dns_cache options - even though this option
appears to have
been available for about 18 months. As I think several others have mentioned on
the list, it would
seem reasonable for a more up to date copy of the html pages to be glued up onto
 the website.

The syslog-ng man pages explicitly state that destinations are closed and
re-opened
on SIGHUP, as per dear-old syslogd's behaviour. There have been references on
the mailing list
and the FAQs to the corresponding close / re-open of sources, but no explicit
statement
in the docs. Could I request that an explicit statement of source file
descriptor open/close behaviour on SIGHUP
be added to the docs/FAQ, please.

Others on the list have noted that closing /dev/log on HUP causes certain
programs grief - notably sendmail
which requires a further HUP to itself to properly heal the broken syslog file
descriptor. If syslog-ng does
indeed close descriptors on HUP, can we please have an option to explicitly keep
 certain descriptors
open on HUP. ( The docs suggest this may already be possible for TCP sockets,
and Unix SOCK_STREAM
sockets, but not Unix SOCK_DGRAM sockets ). See ensuing paragraphs for why I'd
like the option to
be available on Unix SOCK_DGRAM.

In all the syslog-ng docs, Linux platforms are documented as having a default
log listener socket of
/dev/log SOCK_STREAM. However, the most recent RedHat sysklogd RPMs open
/dev/log in
SOCK_DGRAM mode. I believe this was done as part of a security patch to avoid a
potential DoS attack
against the stream socket. To the best of my recollection, this behaviour
changed about a year ago.

This seems to bring RedHat - at least - in line with other BSD variants. glibc
openlog() call on RedHat opens
SOCK_DGRAM first, falling back to SOCK_STREAM if that fails. Hence RedHat's
glibc still supports
either socket type, and hence syslog-ng's documented Linux defaults still work.
  Likewise, Perl's
Syslog.pm module calls SOCK_DGRAM first falling back to SOCK_STREAM.

Sometime during the change from kernel 2.0 to 2.2 I believe, the Unix DGRAM
socket type behaviour
was adjusted to blocking ( this assumption purely based on the perceived
behaviour of sysklogd ).
Thus it should be impossible to drop a message across a Unix DGRAM socket , as
compared with
the ease of such a message being dropped across an UDP DGRAM socket when the
system is really
busy. Hence the change from SOCK_STREAM to SOCK_DGRAM within sysklogd should not
 make
the system more prone to dropping locally logged messages, as might have been
the case with
earlier kernels?

Given all of the above, is it reasonable to change the preferred documented
socket type from STREAM
to DGRAM on /dev/log for syslog-ng on Linux?

"logger-ng" -  I believe others may also have asked for this - does such a thing
 exist? to allow one
to create test messages and the like over TCP etc etc etc.

Sys::Syslog-NG.pm ?? does such a thing exist to support Perl Syslogging over TCP
 and suchlike?



Ted Rule,
Flextech Television









***************************************************************************************************

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.

***************************************************************************************************