rsyslog work log 10

Past day’s rsyslog work log:
2008-04-30
– added server-side TLS capability for plain tcp server
– added $InputTCPServerStreamDriverMode config directive
2008-05-02
– fixed a bug in imklog which lead to startup problems (including
segfault) on some platforms under some circumsances. Thanks to
Vieri for reporting this bug and helping to troubleshoot it.

rsyslog work log 11

Hi all,

again, I have been quite busy the past days. A lot was rsyslog related, but phpLogCon also kept me busy. I am still working on TLS support with some occasional bug-hunting in between.

TLS support grew too a much larger project than it initially looked. In short, it caused a more or less complete rewrite of the base networking classes. Quite complex work, even though it doesn’t involve lots of code (I am always surprised how few code changes actually happen). I am going slowly but steadly through it and hope that we will have an even better abstraction of the networking classes when I am done. In the long term, it will probably also affect gssapi (in a positive way) which could finally lead to a fully generic, driver-based and highly flexible networking model. Well worth the wait, I’d say… ;)

So here is the past day’s rsyslog work log:
2008-04-21
– worked on netstrm abstraction (server side)
2008-04-22
– got socket abstraction to work for server part
– fixed newly introduced memory leaks
– released 3.16.0
– -c option no longer must be the first option – thanks to varmjofekoj
for the patch
2008-04-25
– added missing copyright statements (thanks to Michael Biebl for noticing)
– added select() driver for GnuTls
– made gtls server driver work in plain tcp mode
2008-04-28
– added $DefaultNetstreamDriver config directive
– added $ActionSendStreamDriverMode config directive
2008-04-29
– worked on klogd problem on gentoo
– moved netstrms, netstrm and nssel into a single loadble module
because they belong together
– fixed “loadbale module leak”
– fixed problem with module unload sequence

finally… phpLogCon v2

Finally, we have released phpLogCon 2.1.0, the first official beta version of the v2 branch. PhpLogCon has been completely rewritten from scratch. It now offers a state-of-the art modern user interface and also is able to work with log files and not just databases. For example, it can be used to view a remote server’s log files over the web (proper authentication settings highly recommended). It will evolve to a very capable search, reporting and analysis frontend for syslog data.

Let me stress the point that it can work with log files directly. For example, we have set it up on one of our mail relays so that we can review mail logs without the need to login onto that machine. Obviously, this functionality should only be available to authenticated users, but then it is quite useful. I would appreciate to learn about any more thought of how this tool can be put to good use.


Download
:

We are currently setting up the infrastructure (mailing list et al) for phpLogCon. I’ll do one more announcement here when this is completed. In the meantime, I suggest subscribing to freshmeat’s announcements, which we maintain in a timely way. You can do so at:

http://freshmeat.net/projects/phplogcon/

work log

Past day’s rsyslog work log:
2008-04-18
– abstracted a driver level for netstream
– converted netstrm into generic netstrm and the nsd_pctp driver
– prepared everything so that I finally can begin to implement
TLS sender part (in plain tcp output)
– bugfix: a recent change effectively disabled error messages
– implemented a first working version of a TLS-enabled plain TCP
sender (but, of course, the implementation is insecure as it is)
2008-04-21
– primarily phpLogCon design

A good blog post on syslog reliability

I found a good blog post describing the problems that go along with reliable logging. It also offers most of the options to resolve them:

http://mschuette.name/wp/2008/03/31/thoughts-on-reliable-syslog/

The author missed one thing: a buffer must not necessarily exist only in main memory. When the in-core buffer runs out of space, you may also use a disk-based buffer, which offers much more capacity. Of course, even the largest disk-based buffer may be exhausted at some point, where one needs to resort to other strategies. But a disk-based buffer is an excellent solution for temporary (but lengthy) receiver outages.

Rsyslog has implemented everything mentioned in the paper, plus more. You can directly apply the knowledge you got from this paper to rsyslog. And then, you can dig down into the dirty details:

http://www.rsyslog.com/doc-queues.html

rsyslog work log 12

Yesterday’s rsyslog work log:
2008-04-17
– some cleanup
– created a global data object
– moved “family” variable to global data pool
– moved “bDropMalPTRMsgs” variable to global data pool
– moved “option_DisallowWarning” variable to global data pool
– moved “DisableDNS” variable to global data pool
– moved host/domain-name related variables to global data pool
– moved “glblModPath” variable inside global data pool (but
still as a variable, not part of glbl object)
– added the ability to specify an error log function for the
runtime
– removed dependency of core runtime on dirty.h
– imported tcp module from librelp as basis for new stream class
we got permission to include the tcp module from librelp
copyright holders
– done some forward-compatibility work on librelp
– brought netstrm to a (hopefully) somewhat usable state
– partly rewritten and improved omfwd
– some (small) cleanup of omgssapi
– optimized omfwed, now loads TCP code only if this is actually necessary

rsyslog work log 13

Yesterday’s rsyslog work log:
2008-04-16
– more or less finished im3195, but need changes in liblogging
to complete this work – does not compile yet
– moved files to runtime library part
– some cleanup
– provided ability to initialize the runtime
– some more cleanup; reduced dependencies, moved non-runtime
files to its own directory except for some whom’s status
is unclear
– completed im3195 including some documentation
– changes due to restructuring in 3.17.2 have big bug potential;
beta 3.15.x has almost no bug potential; thus I initiated a
shift of devel -> beta -> v3-stable; devel will restart at 3.19.0
– prevented segfault during runtime library init phase

rsyslog work log 14

Yesterday’s rsyslog work log:
2008-04-15
– added imklog doc
– begin LGPL change for a select set of files (core runtime)
– merged in bsd-port and klogd changes
– released 3.17.1
– worked on rsyslog runtime library
– worked a bit on phplogCon
– worked on liblogging 0.7.0
– begun re-integrating rfc3195 in rsyslog

on the rsyslog runtime

I had a conversation on the new runtime design for rsyslog. I think it had a quite some good technical information (and brief), so I reproduce it here:

> The new design is:
> rsyslog core (GPL)
> rsyslog runtime (LGPL)
> modules (whatever)

Yes, actually I intended to say that ;)

>
> what is the interface between
> rsyslog core/syslog-ng runtime? Pipe/linked
> runtime module? Pipe/linked
>
The runtime always needs to be linked. A few cases:

rsyslog runtime –> always linked
syslog-ng/whatever runtime… linked
runtime module -> linked

BUT the interesting case is:

rsyslog plugin -> linked or pipe
syslog-ng/whatever -> linked or pipe

In these cases, it depends on build parameters (all of this of course
not yet implemented). I would anticipate these combinations to be found
in practice:

rsyslog plugin -> linked [pipe for new functionality on old engine]
syslog-ng/whatever -> pipe

So with rsyslog plugin, that would just a fallback if you need it for
some reason (e.g. run a v3 engine with a v4 plugin WITHOUT the need to
backport it [requires a v3 and v4 runtime to be present on the system,
though].

For non-rsyslog syslogd’s I expect that pipe is always used, because I
do not think they’ll change their environment to adopt to the runtime.

rsyslog will provide wrappers for either interface. They will come as
separate binaries. There will be an input and output plugin to allow any
process (not necessarily rsyslog technology) to utilize a standard unix
pipe interface for producing and consuming messages.

Library modules will never use the pipe interface – it’s too slow and
too loosely coupled.

linking offers much greater performance and is lossless.
pipe is comparatively slow and may lose some messages.

Pipe is obviously a much easier and thus universal interface than the
plugin interface.

rsyslog work log 15

Past day’s rsyslog work log:
2008-04-10
– bugfix: omsnmp had a too-small sized buffer for hostname+port. This
could not lead to a segfault, as snprintf() was used, but could cause
some trouble with extensively long hostnames.
– removed dependency on MAXHOSTNAMELEN as much as it made sense.
GNU/Hurd does not define it (because it has no limit), and we have taken
care for cases where it is undefined now. However, some very few places
remain where IMHO it currently is not worth fixing the code. If it is
not defined, we have used a generous value of 1K, which is above IETF
RFC’s on hostname length at all. The memory consumption is no issue, as
there are only a handful of this buffers allocated *per run* — that’s
also the main reason why we consider it not worth to be fixed any further.
– worked on tls support (as part of libsci)
– thought about modularization
2008-04-11
– wrapped up modularization problem –> suggested rsyslog-runtime
– some cleanup
– enhanced legacy syslog parser to handle slightly malformed messages
(with a space in front of the timestamp) – at least HP procurve is
known to do that and I won’t outrule that others also do it. The
change looks quite unintrusive and so we added it to the parser.
2008-04-12
– implemented high precision timestamps for the kernel log. Thanks to
Michael Biebl for pointing out that the kernel log did not have them.
2008-04-14
– provided ability to discard non-kernel messages if they are present
in the kernel log (seems to happen on BSD)
– cleanup of imklog
– implemented $KLogInternalMsgFacility config directive
– implemented $KLogPermitNonKernelFacility config directive