Author: Rainer Gerhards

Long time, no post. But now I am really excited. Finally, I have managed to get RFC 3195 functionality into rsyslog. The 1.11.0 release contains just the listener (aka “server ;)), and the code definitely can be improved. But, after all, this is a big step for rsyslog. Esepcially, if you consider that the original project goals called for immediate implementation of RFC 3195. Even the name – rsyslog – stems back to RFC 3195 (reliable syslog!). Well, it turned out that other needs were in much more in demand, and so RFC 3195 was postponed and postponed…

Still, we do not have the initiator (sender) and not the greatest code. But at least we can now see if there is growing demand. I expect so, but only slowly. I will see that I can integrate the initiator shortly, but I will first have a look into multithread-enabling rsyslogd. That would facilitate some of the RFC 3195 (synchronous) requirements and it probably is also needed to implement openssl with sufficiently performance (and thus low to no message loss).

But for now, I am happy with where I am arrived ;)

Finally, I have been able to do some major feature editons. Now the development branch somewhat gets off. See the change log for rsyslog 1.10.0 to see what I mean ;)

I have to admit that creating this release was more effort than I initially estimated. While I was right that the base design allowed neat integration of the new filtering, a lot of infrastructure (counted strings, parser, …) had to be added. Of course, these additions will help in the future, too. But as I said… it took much longer than expected. I ended up adding 1,000 lines of code and also modifying others. So roughly about 1/6th to 1/7th of the project needed to be changed to make this feature a reality…

It is finally done: rsyslog 1.0.0 is released. This is the first (officially ;)) stable branch. I’ve taken some weeks of close-to-no modifications to make sure as many bugs as posisble have been found and removed. I am very positive this release is really stable. I also hope that the availability of a stable release will help grow acceptance of rsyslog. All in all, we are now scoring within the top 5,000 projects on freshmeat.net (by popularity), which I think is not bad for such a new project in the logging area. I also already got some helping hands (more soon), so this is also an excellent sign.

Now that 1.0.0 is out, I will begin new feature enhancements – which will bring even more usefulness tp rsyslog.

I have finally begun preparations for the rsyslog 1.0 stable release. I’ve checked all bug trackers, done some minor doc updates and other such things. Made some very minor changes. As I heared no bad feedback after the 0.9.8 release (now two days ago), I do not accept any more troubles. So I think I am basically set to release by the end of the week or monday.

I have now branched off a stable branch in CVS and think I won’t need to modify it. Now I can turn back to new features. I will start by implementing a core counted-string library, which will hopefully enhance the security ones it is used all over rsyslog. To be honest, that will probably take quite some while. And there is also another reasoning for the library: to support syslog-protocol, I must also support strings with embedded characters, which makes it impossible to use with the standard library routines. So it is nice to even get some more security out of a thing that I need to do anyhow…

After some silence, I have released rsyslog 0.9.8 today. I was on vacation the last two weeks and used this time to see how 0.9.7 worked in the field. No bad news, but some user activity. So the problems with the new make procedure seem to be solved. I still had some minor changes, which I didn’t like to apply before going on vacation (I had email with me, but… ;)). So I released these few changes today as 0.9.8. I think they won’t break anything. If that assumption is right, we will have a final 1.0 within the next days :).

I have just announced phpLogCon on freshmeat and also announced it yesterday on icewalkers. I hope that this tool will evolve and bring even more attention to syslog. I know its a long way to go, and database performance is probably an issue, but if we don’t start to solve problems … they will always persist ;)

I am very interested to see how this tool will be accepted in a few months time.

You can also read in my adisconblog on some background with phpLogcon.

Rsyslog 0.9.6 caused some grief. The new build system wasn’t that easy and the “improved doc” wasn’t consistent with the previous one. Finally, I discovered this morning that MySQL support was crippled due to a bug in the make system. Might it be that I shouldn’t have watched NASA TV during the release period ;) Anyhow, I now have released rsyslog 0.9.7 after a round of good testing. I hope that will really resolve all the issues. Now I just need to go back and release another version later this week, because I wanted to do some other minor enhancements…

A totally off-topic posting: NASA’s STS-114 mission is finally succesfully completed with the safe landing of orbiter Discovery at Edwards air force base. This was a historic mission, not only because it is the first mission after the shuttles were grounded. It als had the first in-orbit repair of a shuttle.

All in all, I would like to express a big CONGRATS to NASA! Not that I think writing this here makes a big difference – but I’ll do it anyhow ;)

Isn’t standardization a lovely thing. This morning, I thought I had a new rsyslog release ready. Then I did what was intended to be a quick test on FreeBSD. Guess what – nothing worked at all ;) The reason was that I made the makefile more user-friendly, enabling easier feature selection. For this, I needed to use make file conditionals. As it turned out, they are different between the standard make in Linux and that in FreeBSD. I guess I could have found a make tool for FreeBSD without these incompatibilites – but after all, I want to make it run as easy as possible, which means with as few prerequisites as possible.

I now have split the makefile into a common file and os-specific files in newly created os (or distro) subdirectories. I do not like this approach really much – but as far as I can see currently, it probably is the best. Eventually some Linux wizards will tell me a solution (or I will have a really bright idea), but for the time being, I will have to live with that.

Chris has this morning requested that -syslog-protocol (and the related -transport-udp) be published by the IETF. That’s good news, nothing came up during WG last call. Now eventually the AD come up with something. As I’ve never been through this process, it is quite interesting to me how things progress from now on…