Month: July 2005

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

Did I say syslog-protocol is close to being finished? Well, yesterday evening, I started to integrate some intelligent comments into my draft (then at revision #14). Initially, I thought it was a quick job. Now (again arrived close to evening), I now know I underestimated things a little bit. If you need to double-check the documents, this is quite time-intensive. For example, I changed some field values, which lead to all examples become invalid and needed to be redone. Also, when at it, I noticed some other minor quirks (interesting, they are still there…). Nothing big, but it simply takes time. Anyhow, now it’s finished and I’ve send a really huge posting to the IETF discussion list. I hope people will actually look at it.

Anyhow, as Chris has announced on the list, we seem to be close to final call.

I have just released rsyslog 0.9.2, the first release of it supporting plain TCP syslog. This is really good news, as TCP syslog allows much more secure log transmittal. Not only that the sender has an indication of the message arrived or not. TCP enables also to use cryptography, for example with the help of stunnel or IPSec (IPSec, to the best of my knowledge, doesn’t play well with UDP).

So here we are with a syslogd capable of this. So have we arrived? Not really. The current TCP implementation support receiving messages, only. Not yet supported is sending them via TCP, so relaying is also not possible with rsyslog alone. Guess what’s the next major thing to be added. Anyhow, even the receiver-only implementation offers many goodies, for example we can now accept messages from Cisco PIX, syslog-ng or our Windows syslog product line. Especially with the later stunnel integration works well, so this buys us many things.

All in all, I am quite happy with today’s release. As said, the sending part will follow, but there are also some other things I need to look at, so it might take a few days longer…

Tags: syslog, network security

Benedikt’s idea strikes me: a graphical subsystem for syslog notifications under Linux: Xfce Diary: Desktop notification

Sounds so straigthforward – why didn’t it ever come up my mind (after all, we are doing it on Windows anyhow…). Of course, it’s nothing I can do immediately, but at least I will keep it on my “to look at list” ;)

Coincidently, I ran into a thread on syslog.org (see 6th post). As it looks, there are also some other folks who are not overly happy with the 1k restriction of syslog. BTW: did I mention that I, too, need more than 1k as soon as I need to deal with Windows Event Logs? Actually, I am doing a number of eventlog-to-syslog products and the event log is always very verbose. So it is often hard to get the message into 1k. This is the main reason why our Windows software products initally supported large size messages. As we now see, there are other good reasons, too :-)

back to our regular programming… ;) The IHE initiative uses syslog for auditing. Unfortunately, though, their framework specifies audit records way in access of syslogs’s normal 1024 byte message size. Some IHE messages can grow as large as 32K, few stay within the 1024 byte limit. The bad thing is that most Unix syslogds will truncate the message at 1024 bytes, effectively loosing audit data. Under Windows, it’s less of a problem, as most Windows syslog servers accept “oversize” messages.

So I thought I’ll cure this under Linux and include the capability for larger size messages in rsyslog. I fired up the development machine to get a first glimpse of what to do. Well, it figured out that all I need to do is change the MAXLINE #define – and that’s it. Isn’t that funny? I am now fiddling with the source for some month, have even applied some considerate changes … but never noticed this simple thing. Dumb me ;) Anyhow, I’ll change the default to 32K with the next version I will release, so the IHE folks will hopefully be happy…

Tags: syslog, IHE