Wednesday, November 23, 2005

IETF syslog seems to be back on track

Long time no post ;) It has been busy days, with finaly a healthy discussion on the IETF syslog-sec mailing list. Still, there are (too) few participants, but it looks like the recent events got the group some momentum. The WG is now in danger of being shut down and that seems to drive activity. A new charter is being discussed. It looks like the rejection of previous work will lead to a really good alternative. It is still too early to be sure all will have a good outcome, but in my opinion it looks more promising than any time the past month - especially if you think about a spec becoming implemented.

Wednesday, November 09, 2005

syslog-protocol back to the WG

Sam Hartman (IETF Security Area Director) has rejected the syslog-protocol draft due to missing support in the last IETF meeting. I do not yet know which new non-concensus turned up. I fear it is an re-iteration of arguments already exchanged. I am very curios to have a look at the minutes. Anyhow, if it is yet another re-iteration, I seriously begin to doubt if that activity makes any sense at all... Maybe it is a much better idea just to create some simple TCP-based syslog format, talk to the other implementors... and do it ;)

Friday, October 21, 2005

rfc3195 mailing list...

I've talked with a lot of people about rfc3195 to lots the past days. I've a mixed feeling. Since spring, rfc 3195 is getting momentum. On the other side, the IETF syslog-sec WG is considering removing some parts from RFC 3195 (namely the COOKED profile). The adoption rate in practice is also very low...

Anyhow, the discussions indicated that a lot of folks seem to work on rfc 3195 (well, "a lot" in my terms...), but most of them somewhat isolated. I will now try to solve this issue with a new mailing list. Maybe we can even get some IHE folks onboard.

The list charter is as follows:

The rfc3195 list is targeted towards people interested in RFC 3195-based solutions. It is primarily aimed at implementors, protocol-designers and operators who would like to have insight into the protocol and the various implementations. It carries deeply technical content about protocol interpretations, interoperability of different RFC 3195-based solutions, and discussion about the future of RFC 3195. It also covers news and annoucements about RFC 3195-related projects and products. These items should not be marketingish but rather help inform the community of new arrivals and other important events.

Subscription information is available at

I hope this is a useful tool for the community. Let's see how it evolves.

Wednesday, October 19, 2005

rsyslog 1.11.1 released

Today, I have released rsyslog 1.11.1. It now supports BSD config file extension for hostname and program blocks. Initialy, it caught me by surprise that BSD has such considerable extensions. Actually, it looks like I picked the wrong starting point with sysklogd. BSD's syslogd is much more capable (e.g. it has IPv6!) and the code looks somewhat cleaner. Anyhow, now we are too far in the game to reconsider anything. Plus, there is not much code left from the orginal sysklogd. In lines of code, I think rsyslogd has roughly 2.5 times as much code then sysklogd (hopefully not only consisting of bugs ;)).

Today, I've also brought over some patches from sysklogd to those remaining code pieces in rsyslogd. The sysklogd team is *very* conservative with updating the package. In its CVS, there are a number of non-intrusive yet slightly important patches which have not yet made it into the source. The "current" version is now rougly 2 years old... Anyhow, I think I have finally build a considerably more capable and also reliable syslogd than what I started with. It's still a way to go, but I begin to like what I have done. :)

Friday, October 14, 2005

syslog-protocol into the next round...

I am a bit late in posting this. After "last call", syslog-protocol went to AD review. On September 19th, 2005, Sam Hartman has replied with a number of very good questions and suggestions. Obviously, that has pushed us a bit back, but it also has fingerpointed to some very important issues. While I am not happy that syslog-protocol will probably take much longer to complete, I am happy to get it as good as possible. Sam has also mentioned that he will have it reviewed by a number of operators, which is a big plus given the sparse feedback we had so far from that community.

In the mean time, I have looked at most issues on Sam's list and done some text changes. I am right now finalizing on Unicode security, the last thing with outstanding suggestions and feedback by the WG. Hopefully, I'll be able to find consensus some time next week.

Chris has called for a meeting at the next IETF (in November), and I hope to meet the October 24th draft submission deadline. Then, the meeting can hopefully reach decision. It's a shame I can't attend, but it is hardly justifiable for Adiscon to travel to Vancouver for an one hour slot...

An interesting fact is that Chris also has put re-consideration of RFC 3195 on the agenda. It is only very slowly getting implemented. My personal view is that it is too early to dump it, implementations are now beginning to be seen. I am most interested how this continues...

Wednesday, October 12, 2005

rsyslog 1.11.0 released - with RFC 3195

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

Wednesday, September 21, 2005

rsyslog 1.10.0 released

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

Tuesday, September 13, 2005

Finally... rsyslog 1.0.0 available!

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

Wednesday, September 07, 2005

coming close to rsyslog 1.0

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 \0 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...

Monday, September 05, 2005

rsyslog 0.9.8 released

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

Tuesday, August 16, 2005

phpLogCon being made public...

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.

Monday, August 15, 2005

rsyslog 0.9.7 released

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

Tuesday, August 09, 2005

Not syslog, space...

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

make syntax differences...

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.

Monday, August 08, 2005

-syslog-prottocol advancing...

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

Thursday, August 04, 2005

rsyslogd prooves to be flexible...

A lot of small development today... For the first time in history (hehe), rsyslog prooves that it is really flexible. We can emulate syslog-ng database writing, so that php-syslog-ng can be used together with it. See the history forum post on using rsyslog with php-syslog-ng. ;)

IHE and syslog

I am abusing this blog a little as my lab notebook. I had an interesting discussion on IHE and syslog. The issue with that is that IHE defines log records of up to 32K, while syslog only allows records of up to 1k - at least in current standards. Thankfully, many syslog implementation to not take this limit as fixed and ignore the standard in that regard. Also, the upcoming new standard allows for larger messages, so this...

While writing the text, I found blogger to be a bit unhandy for this use. So I moved that over to a paper on our web sites. There it is now, entitled "IHE and syslog message size".

I keep the text in here as a reference.

Reliable syslog logging...

Some things iterate from time to time. So this summer's syslog reliability discussion has surfaced ;) While it for sure is an iteration, it might be slightly different this time. A lot of work has been done on the "reliability front" and much more experience is in the field (and also I have some additional experience and testing done with rsyslog).

Wednesday, August 03, 2005

New syslog to MySQL Tutorial...

Yesterday, I have written a syslog to MySQL tutorial . It describes everything one needs to know to put syslog data into MySQL. Actually, I hope that the description will attract some more people to rsyslog. Let's see how things evolve...

Monday, August 01, 2005

rsyslog 0.9.5 released

Actually, I didn't plan to release a new version of rsyslog today, but it somehow evolved. So I have released rsyslog 0.9.5. It fixes the "semicolon bug" and it also supports multiple rsyslogd instances on a single machine. I needed to support this for our demo system, but it might also be helpful for some secure configurations (I need to think a little bit more about this, but it "smells" like there is a point in this...).

Demo machine enhanced...

I've finally modified rsyslog so that it can run in multiple instances. With that, I could now set up the syslog demo machine so that it runs two instances of rsyslogd. One instance is the "real" rsyslogd, which listens locally. The other instance is the demo rsyslogd, which reads data from the network and shuffles it to the database. As the database was very silent, I were now able to add some rules to forward some events from the real rsyslogd to the demo one. I do this mostly with postfix messages. For demo purposes, I've set up a fake postfix. Whoever sends mail to it, gets a bounce back. But the good thing is that postfix has something to do and as such messages will be added to the (demo) system log. I am sure spammers will pick up the mail address from web pages like this one, so I will have a healthy flow of log messages shortly ;)

Thursday, July 28, 2005

Finally ... new rsyslog site up!

Finally, I managed to get the new rsyslog site up and running. It turned out to be more work than initially expected. Special thanks go to Timm Herget, who did some of the initial preparation and of course to Andre Lorbach, who made the whole system appear. I just added the content and fumbled a little bit with the config settings ;)

The new site now allows user postings and easier updates. I hope it will be a valuable resource for the (hopefully growing) rsyslog community.

Besides rsyslog, the site also is intended to provide reference for add-ons like phpLogCon.

Tuesday, July 26, 2005

Port number for syslog/tcp...

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.

rsyslog 0.9.4 out

Yesterday, I finally released rsyslog 0.9.4, the first version with full TCP support. I got some encouraging feedback from 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...

Friday, July 22, 2005

Syslog Encryption Tutorial...

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

Thursday, July 21, 2005

Syslog Demo Site...

I just got my syslog demo site online. It is available at 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 ;)

Rsyslog is becoming mature...

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

Wednesday, July 20, 2005

sylog-protocol finally in last call

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.

Nice Article on syslog

I've just read a nice article on syslog:

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

Tuesday, July 19, 2005

rsyslog 0.9.3 out

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

Monday, July 18, 2005

iLAMP: Setting up a reverse SSH tunnel

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

A small C bug...

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

Tuesday, July 12, 2005

syslog-protocol-14 is out!

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.

New syslog client - AliveMon

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

Monday, July 11, 2005

syslog-protocol getting even closer to RFC...

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


Thursday, July 07, 2005

On to the next round...

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.

Wednesday, July 06, 2005

A new syslog/tcp receiver

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: ,

Tuesday, July 05, 2005

A GUI syslog...

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" ;)

Monday, July 04, 2005

More on syslog message size...

Coincidently, I ran into a thread on (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 :-)

syslog, IHE and message sizes...

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: ,

Temple 1 and NASA TV

The main NASA TV Internet media servers are overrun by visitors. The secondary NASA TV sites listed on are still available and have complete coverage. Their quality has been reduced, but it is still a very interesting view if you do not have access to other NASA TV sources (if you have, it's probably better to head for the TV set...).

Temple-1, not syslog...

I am mirroring the first Temple-1 foto NASA released. I've tried to browse the main NASA site for early picutures, but it took me around half an hour to actually be able to download one of it. So I thought I share it with all of you. Photo credit, of course, is NASA.

But you may ask - how does this relate to syslog? Well - not at all ;-). I just couldn't stand it. I am right now watching NASA TV and as it looks the Deep Impact mission was a huge success. The impactor seems to have it exactly where it should.

This is the Temple-1 main nucleus as the impactor saw it during its approach:

Tags: ,

Thursday, June 30, 2005

How to say it complicated...

Well.. this is not directly syslog related. But it is too cool... We are doing a manual for a new product (yes, closed Windows source this time...) and the initial version had a real nice sentence in it. How about this:

If this option is checked, application starts trace route as the trace route window is opened. It means that as you select traceroute for some host and the traceroute window opens up, you do not need to click TraceRoute button to initiate the trace route operation.

All understood? I think we've now replaced it with something like "click here to start traceroute" ;-)

To go to Cocos Islands or to not to go...

The good news is: I talked to the web folks and will get my own virtual server for things around rsyslog, liblogging and the other open source tools I created.

Question now: how does this releate to Cocos Islands? Well, we were in search for a good domain name. All good names (syslog.somewhat) were of course taken. But I have set up as an aid for my IETF activities. Sounds like a good fit... well, as long as you do not think about the country, whom's domain this is. In fact, it's Cocos Islands, with a population of less than 700. Do I really trust their NIC to be stable? The marketing folks want to make you beliefe .cc is a real top level domain. But it is a country-code top level domain (cc is the ISO code for Cocos Islands). So it all depends on what the country and its population decides to do to it. I even barely remember that one other such country were flooded by the oceans because of global warming. The country now no longer exists (really!). I remember there was some discussion that its domain needed to be disabled, because the country no longer exists (sounds like a valid argument...). Unfortunately I do not remember which country it was nor what happened to the domain.

Anyhow, should we take the risk and use a domain rooted on Cocos Islands? Being paranoid, I doubt. So we stayed away from using that domain. The site will now come up under (not yet operational), which might not be as cool but is more likely to stick around for some time.

By the way: if you visit, you'll see that I had the same concerns initially, too. But it really doesn't matter for that site...

Wednesday, June 29, 2005

syslog in German Wikipedia

Today I took of some time to translate the English Wikipedia syslog entry to German. Now the German Wikipedia covers this important topic, too ;)

BTW: it was nice to see that some other folks have enhanced my original syslog text in Wikipedia :-) The wiki idea seems to work on some esoteric topics, too.

Tuesday, June 28, 2005

rsyslog 0.9.1 done...

After receiving Dennis' "does not compile under FreeBSD" report for rsyslogd 0.9.0 yesterday, I today used my FreeBSD environment to get rid of these things as well as some other FreeBSD annouyances. So I could finally release rsyslog 0.9.1, bringing us a littel bit further. Next is probably support for message size above 1k, the IHE folks need that...

New syslog-protocol draft published

We are now in it's 13th round. I've just done some minor changes to syslog-protocol and published it as a new new internet draft. Hopefully, syslog-protocol-13 will finally find acceptance. The good thing is that I had only very few comments on the last draft, and it looks like we are really nearing completion. Let's hope for the best and see what the next days will bring...
Hehe, I am really a lazy guy. After some month (ummm, years) I begin to try blogging again. Now I am back at blogspot, it's some what easier to keep track. Let's see how far I will come.

simplifying rsyslog JSON generation

With RESTful APIs, like for example ElasticSearch, you need to generate JSON strings. Rsyslog will soon do this in a very easy to use way. ...