Bazsi's Home Automation blog

I have finished IPv6 support for syslog-ng, I'm wondering how this will improve the number of people actually using the new syslog-ng 1.9.x tree. In the implementation I've created separate udp6() and tcp6() source and destination drivers, because this was somewhat easier to implement. I'm expecting some portability trouble, but otherwise the implementation is nice and simple. Some smaller fixes went in recently as well, like: avoid chown/chmod files that do not exist as it clobbered error reporting, added close-on-exec flag to file descriptors to avoid child processes to inherit tcp/udp connection fds, fixed an off-by-one in flush_lines calculation, a possible memory leak, and a fix for non-existing filter references in the internal() message path Apart from IPv6 support these are mainly bugfixes and I'm confident we can have a 2.0.0 real soon now.

I received an email last week asking about IPv6 support in syslog-ng. The question also referred to an IPv6 application page where most of the system logging applications were listed red showing that they lack IPv6 support. I started hacking on it but I thought I would ask you how important you think adding IPv6 support to syslog-ng is? My idea was to add tcp6() and udp6() source and destination drivers, however a lot of applications seem to do IPv6 support with a single listener, e.g. open an AF_INET6 socket and assume that the system shares IPv4 and IPv6 sockets. Which of the two approaches is preferable? The first gives more control the latter seems to be a bit easier to use, it works out of the box.

Just a quick one this time, I have released syslog-ng 1.9.10 available at the usual places . The release contains mainly bugfixes and an implementation of the previously missing netmask() filter and support for bad_hostname() and check_hostname() options.

As I have written in my previous post there was a timezone related problem triggered by one of the unit test programs of syslog-ng. Apart from a minor issue in the testprogram itself, it turned out that there's a timezone conversion problem at the reception of messages. Syslog-ng 1.9.x has support for messages that use the ISO 6501 timestamp. As an example the current local time here right now in ISO 6501 is: 2006-04-09T22:43:24+02:00. The important part is that it includes an explicit timezone offset. This offset is processed by syslog-ng and it can convert timezones when necessary. I spent about half a day to fix timezone conversion, I even used a pen and a sheet of paper to do some calculations. All I can say that there's an important building block missing from the POSIX time handling functions, which would have made my job as an application developer way easier: one that converts a broken down time representation to a UNIX time_t value, where the time to be converted is N...

... but at the end I didn't. I prepared the NEWS file, changed version number etc, but the end it turned out that one of my unit test program which tests macro expansions failed. I still have not looked into the issue, hopefully it is only the test program, time related macros seem to use a bad timezone offset. Again I seem to have made a timezone related bug :( Although timezones and time related functions seem to be simple at first, it proved to be a problematic area, it already had a lot of bugs and again here is this one. Not to mention the problem that different platforms have different set of variables/functions to cover the issue. For instance "timezone" is a global variable on Linux and a function on BSD. Linux has a "tm_gmtoff" member in "struct tm", BSD doesn't. OK, I quit whining now :) Hopefully I'm going to have some free time to look into this bug in the nearfuture. I also have two other issues on my radar for syslog-ng 1.9.10, fi...

I have hacked on our SSH gateway today to add publickey authentication support. By the way I may not have explained this before, so a short introduction is due: Zorp is an application layer gateway with support for 21 protocols, among them an SSH gateway capable of looking into the encrypted SSH stream and restricting the protocol to a subset that you really want to allow to your users. (e.g. you can forbid TCP port forwarding while still allowing terminal access). The problem with publickey authentication is that the signature covers the so called SSH session_id which is a unique value derived during key exchange. My proxy implements a man-in-the-middle, so the client proxy and proxy server connections have a different session id, thus simply replaying the authentication packets of the client will not work since the SSH session ids do not match. The solution is that we are going to replace user keys transparently when crossing the firewall, which means that private keys need to be st...

I have finally tracked down the issue I was writing about in my previous blog post . It turned out to be a problem with OpenSSL on Linux 2.6 and NPTL. The default implementation of CRYPTO_thread_id() assumes that getpid() returns a unique value for each thread, however with NPTL each thread has the same pid and only their tid (thread id) value differ. This made OpenSSL to hash its thread-specific error state to the same memory area, thus possibly overwriting memory concurrently freed in another thread. This caused a heap corruption which in turn caused crashes every now and then, of course showing a backtrace completely unrelated to the original problem. The funny part is that I had a suspicion (see the yesterday's post) about this error state allocation I just have not seen the obvious reason: I had the impression that getpid() returns a different value for threads just like it did with LinuxThreads. Knowing the exact reason makes the whole issue trivial :). I have posted thi...

I have spent the last three days debugging an ugly crash in the upcoming Zorp 3.1. First I had some problems with the core files produced with Linux 2.6.12, as the register values proved to be invalid, thus the backtrace was even more unusable than it is usual with heap corruptions. I could get access to the original register values as Zorp dumps part of its stack when a fatal signal is encountered. Using that information I could locate the stack frame of the signal handler and luckily Linux passes a "struct sigcontext" to each signal handler as parameter which contains register information. But nevertheless it made analyzing the core files difficult. After a post to the gdb mailing list it turned out to be a kernel problem rather than a gdb problem and with the help of my collegue Krisztián Kovács (of Netfilter ct_sync fame) we could solve the problem by backporting a fix from 2.6.15, so core files are now ok. The problem however seems to be difficult, I have already studi...

I have started to prepare syslog-ng 1.6.10 for release, the tarball has already been uploaded to the website, but I still have not sent an announcement to the mailing lists. So if you read this here, you might download a still unannounced version :) Nothing really important in the release, a cleanup in the documentation with several fixes and a migration to DocBook/XML from the SGML favour and a new tunable called time_sleep(). The latter was worked out together with John Morrissey who did some profiling and found that on hosts with a lot of syslog connections syslog-ng might become a bottleneck. The option does nothing but sleep() a defined amount of time which makes syslog-ng to process incoming messages in batches, this way decreasing the number of poll() loop iterations which was listed high (about 67%) in the profiles generated by John. Setting time_sleep() to about 50ms decreased the CPU load by 80% which is quite significant I'd say. As Rusty Russell would say I have just re...

I have considered starting my own blog for some time now and have finally started doing something for it. I first tried to set up blosxom but as I did not want to spend too much time customizing it I finally gave up and tried to find a nice blogger website which does everything for me. This is blogger.com, I like what I see so far. Ops, I should have started by introducing myself: my name is Balázs Scheidler, I live in Budapest, Hungary and I started this blog because I would have some things to publish about some free software projects I am involved in and it is trendy to have a blog anyway :). Back to my projects, I am the author of syslog-ng that you might know as an alternative system logging package for UNIX based systems. And also Zorp, an application layer gateway. You can find out more about these at http://www.balabit.com/ . I also contribute patches to a couple of others (whenever I encounter something I don't like or which simply bugs me) and I sometimes poke into kernel...