Posts

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).

Finally, the 14th revision of syslog-protocol is out. It now addresses all issues I am aware of, so this hopefully brings us very close to completion of this task. Chris already has announced he will call for WG last call, so let’s hope for the best. Of course, I expect some really bright and probably major-things-changing comments during last call. Let’s see how much must be redone then. On the other hand, we’ve had some real hard dicussions on the whole spec, especially in the last few month. So chances should be good the draft gets accepted without major revision need. But you never know…

The draft editor currently is very busy, as the cutoff date for draft submissions is next monday. Probably, it will take some days until the draft shows up. It’s available in my draft repository, so for those interested in it. This is draft-ietf-syslog-protocol-14.

Finally, we are finished with our new network monitoring tool. AliveMon monitors routers and server (well, everything with an IP stack ;)) and lets you know when they are in trouble. It can do ping based-checks but also the more reliable application specific checks. For example, it talks http to a web server. I was insistent on these app-specific probes because I’ve often seen situations where a simple ping probe told you “all well” where the web server was already died. As an extra bonus, it also supports UDP monitoring for game servers, which, as my frieds have told me, is a great feature (did I mention I am too old-fashioned to see the greatness in it… ;)).

OK, so it is a nice tool – but why the heck I am talking in my syslog blog about it? Well, as one of its alerting actions, it supports sending syslog messages. This is cool, as it allows you to integrate server availability monitoring into your central syslog backend.

AliveMon is part of the Windows product line, but it is free for monitoring a single server. This is thanks to my “game server friend” who insisted this might be a nice incident for his folks ;) Those with more than a single server are expected to pay a reasonable fee. As my fried said: “those with money for many servers my also want to fund development a little”. I guess this was said rightly ;)

Chris send a nice encouraging note and I have changed some of the IANA considerations to be more precise. Also, I have added text to allow for experimental (x-) PARAM-NAMEs in any SD-ID. I think this is a good idea and it will probably be helpful. And: if we don’t allow it, the community will do it anyhow. So why forcing them to become non-standard. Let’s see what the WG tells us.

I am just a bit concerend that Didier will not be able to provide his feedback right in time. But anyhow, as Chris told, there is a 2 week “Last Call” period in the WG, so that is probably another chance to get it in.

Let’s see how things progres…

Rainer