Author: Rainer Gerhards

I so often used ports 1514 and 10514 that I didn’t really notice that they are IANA-reserved. I today posted my syslog stunnel article at aplawrence, and the first comment told me so. Wow! Looks like I need to rethink which ports I used. I am also a bit tempted to try to register a port for syslog/tcp, but this sounds not very easy (especially given the fact that the syslog-sec IETF WG does not at all like plain tcp syslog.

Yesterday, I finally released rsyslog 0.9.4, the first version with full TCP support. I got some encouraging feedback from www.syslog.org. I hope that word now spreads and we get some more momentum for rsyslog. After all, it isn’t looking bad at all. We just need to keep in mind that the project is out since a few month (March this year I remember), so its not bad at all.

The next thing to do is writing a parser for syslog-protocol-14. I wanted to at least seriously begin this during the last call period, but I begin to feel I won’t be able to manage that. Well, we’ll see…

Wow… I took me the afternoon to create a syslog encryption tutorial. The initial version is now posted for review and comments, but I think it will need some further brush-up. Also, doing the tutorial I noticed that I needed to tweak rsyslog a little to make it behave well with stunnel. It’s done now, too. Looks like I am about releasing it early next week :)

I just got my syslog demo site online. It is available at demo.rsyslog.com. The intention is that anybody can send his syslog data and see how it ends up. Now I need to prep some documentation and announce it. Honestly, I am very interested to see if it will be used at all ;)

BTW: I did also notice that phpLogCon needs some “minor” changes. I will see if I can at least initiate something, but given the current ressource restrictions, this does not look well… what a shame ;)

I’ve now made a number of changes to rsyslog, resulting in full TCP capabilities. Hopefully, I can make a release announcment today.

With that done, rsyslog is finally on its way to a secure syslog replacement. One of the next steps is to look into using stunnel, a thing that must be easy to do … but also one that must be set up. The TCP support was a key to using things like stunnel, because UDP packets can not be secured in a way that makes sense (two tunnels would work – but who would like to have such a monster…).

Finally, it happens :) Chris announced workgroup last call this morning. I am very interested to see which additional feedback we may get until August, 5th (the deadline). The last call period unfortunately is a bit sub-optimal, with the 63rd IETF right in the middle of it. Hopefully this poses no problem to the overall advance of the draft.

I’ve just read a nice article on syslog:

http://www.enterprisenetworkingplanet.com/netos/article.php/3521481

It’s a good intro, though it again mentions syslog-ng as the only secure alternative. I guess we need to work a little on that (OK, rsyslog is not yet ready for prime time… but we are approaching;))

I’ve now released rsyslog 0.9.3, which fixes the nasty bug I described yesterday. Due to the bug, this release was urgent, but I am not 100% satisfied with it. I would have preferred to have a real functional tcp sender in it. Anyhow, maybe it is good that some folks might get their hands at the early implementation (if somebody cares…). The download can still be found at the monitorware-bound site, its time to get the new site up (who is eating up all the time…).

This sounds interesting and I probably should try to define a scenario for rsyslog, once it has complete TCP coverage.

iLAMP: Setting up a reverse SSH tunnel

C is know to “bite”. Today, it bit me ;) rsyslog, as I thought initially, did duplicate the TIMESTAMP and the fields after it when relaying data. Looking closer, I found that actually the timestamp was not correctly parsed. As such, all fields were invalid, not only when forwarding but also when storing data. What a shame… The cause, however, is even somewhat more shamefull – should I really tell? ;) Of course I do. One of my beloved ultry-optimal parsers had a small bug. I incremented a character pointer at the wrong place, makeing it point to the wrong location. It did not cause a buffer overflow or something like that, but it resulted in each message to be treated like one without a proper TIMESTAMP – leading to all the mess. Obviously, this is something that needs to be fixed and I already did this. I just need to package everything, so hopefully tomorrow we will see a new release. Oh, btw, did you wonder why I didn’t catch this bug earlier? Well, it appeared the first time in July… If you wonder why, you need to look at the code. I won’t tell all dirty little secrets here (but it’s well-documented in syslogd.c).