Author: Rainer Gerhards

Rainer Gerhards ist Hauptautor dieser Seite und schreibt die meisten Artikel. Weitere Informationen über Rainer Gerhards können hier über das Hauptmenü abgerufen werden. Die Biografie findet sich z.B. hier.
Posted on

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.

Posted on

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

Posted on

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

Posted on

More on syslog message size…

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

Posted on

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

Posted on

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

Posted on

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

Posted on

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

Posted on

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 syslog.cc 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 rsyslog.com (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 syslog.cc, you’ll see that I had the same concerns initially, too. But it really doesn’t matter for that site…