Archive for May, 2009
I’ve updated the syslog-ng OSE roadmap on the syslog-ng webpage to include information about the upcoming syslog-ng version:
Also, I’d like to bring the changed release/support policy to your attention, that you can read at the same location above. I’d like to introduce stable track and feature track releases, the first being supported for a long time, whereas feature track releases are only supported until the next feature/stable release is published. When a sufficient number of features were published via feature track releases, the last one becomes stable and the cycle continues. Note that feature releases are NOT development snapshots, they are releases just like the major versions previously, the only difference is that instead of a large feature list like with syslog-ng 3.0, only a smaller set of changes are included.
This makes it possible to publish features more often, always concentrating on a few of them at a time, instead of doing development for a long time and come out with a feature packed release. I hope to increase the pace of syslog-ng development with this change and also to cause less problem for users who prefer stability over features. Please read the details on the roadmap page.
I’ve also opened the syslog-ng 3.1 repository and pushed it to our git server. Right now there are no differences (except for the version number) between 3.0 and 3.1, I’m planning to integrate Marton’s message tagging and patterndb changes as soon as possible (his git tree is here). Hopefully the 3.1 cycle will be quite short as most of the things on the roadmap are already implemented, although scattered around in various public and private trees.
With the opening of the 3.1 branch, I’m also obsoleting 2.0 (in the new support model two stable track versions are supported at any given time and we have 2.0, 2.1 and 3.0 right now), but that’ll go in a separate post/announcement.
After a long time and a lot of accumulated bugfixes, I’ve pressed the “release” button and syslog-ng OSE 3.0.2 was published on our website. The first official version to feature binary packages for Linux and BSD platforms. Since there was a long time between 3.0.1 and 3.0.2 the changelog is quite large, however most of it are bugfixes, only some minor enhancements here and there.
Hopefully I didn’t miss any important bugs and problems. It must be much better stability/functionality wise than 3.0.1 was.
The diffstat since 3.0.1:
150 files changed, 4332 insertions(+), 3000 deletions(-)
You can also check the patches in our git repository.
If you are using the 3.0 branch you are really recommended to check out this release. If you are using anything earlier than 3.0 you are also recommended upgrade, syslog-ng 3.0 is revolutionary to previous versions in many ways, especially if you want to do more to your logs than merely store them in a plain text file.
I’ve uploaded my OSDC 2009 presentation slides to
http://people.balabit.hu/bazsi/slides/osdc-2009-syslog-ng-3.0.odp Which has an example for processing iptables logs with db-parser() and putting the results in a customized SQL table.
I’m going to give a talk on syslog-ng on the upcoming Nordic Nagios Meet 2009. I expect the event to be great fun, just like last year. If you are in the Nordic region and use Nagios, rrdtools or syslog-ng, I recommend to pay a visit as you can meet the primary authors and some active contributors to these projects.
If you are there and have anything to ask/talk about syslog-ng, just feel free to approach me, I’m probably going to wear a badge, so you can recognize me
I’ve spent the last week in the nice city of Nuremberg where Open Source Data Center Conference took place, organized by Netways AG. I really liked the talks about Puppet, DRBD and the description of the booking.com infrastructure which runs MySQL.
Although I really enjoyed the conference I also had some free time to improve the automatic test program for syslog-ng, which now also covers TLS encrypted source and SQL destinations. I’ve also implemented a small script to collect coverage data of the testcases, thus right now I know that about 63% of syslog-ng is covered by automatic tests. (initially it was 55% but there were some low hanging fruits). I expect to raise this number easily to around 80%, then it’ll probably become much more difficult to increase it further as the rest is error processing paths, and unless I come up with something to inject errors from the testcases those are difficult to test.
Of course having a test suite is not a replacement for real-life, field testing, but nevertheless it makes it much easier to do releases as it ensures that no important functionality is broken completely.
Based on this test infrastructure I’m going to release 3.0.2, after which I’ll probably change the way I manage releases for syslog-ng, but I’ll talk about that in a forthcoming post.