Tech Enthusiast. Nature Lover. Computer Geek. rsyslog lead developer.
Did you know? GPLv3 is out. And I am seriously considering it for my rsyslog project. Why? I do not like Tivo-ization nor do I like software patents. So, isn’t then moving to a license unfriendly to those a good idea? I think it is. But of course, there are a number of subtleties that I need to check.
I guess version 2.0.0, due soon, will be released under GPLv3.
Have you ever wondered why your logs do not contain anything from the syslog subsystem itself, except for maybe a message or two? Tina Bird has started an interesting new discussion on the loganalysis mailing list.
Of course, I couldn’t stand it and have added my 2cts. I’d like to reproduce it here in the blog, too:
> I have received a number of responses along these lines, obtained by
> grepping the source code or by running strings on the binary.
> These are far
> better than nothing, and I’m grateful for the help, but they miss an
> important piece of the picture. Especially in a piece of code
> as old and,
> uh, crufty as syslogd, there’s a high likelihood that many of
> the errors
> find themselves at the far ends of code paths that rarely (if
> ever) get
> executed, and therefore those errors never find themselves in
> the “outside”
> world, providing assistance (or confusion) to system administrators
> everywhere.
OK, I’ve once again done a real review of the sysklogd 1.14.1 source. I wanted to make sure I really tell the truth. The plain truth is that it is nearly impossible that anything goes wrong after syslogd is started. So you’ll observe a number of “config file invalid” messages, but only (hopefully;)) during initial setup. Once things run smoothly, you will see error message only when things go really wrong, e.g. when the hard disk dies. But then, in practice, will that ever occur? If the answer is yes, then you need to ask “will it be seen”? Of those systems where a hard disk failure is catastrophic, all of the logs are probably on that failed hard disk. Yes, exactly that disk our error message will be … ahem would be … written to ;) So you end up with just initialization and termination messages.
Is that the case because syslogd is such a perfect piece of software. Not really. The reason is that the stock implementation simply can not have any real problems once it runs: selector lines were either OK (and operating) or invalid (and disabled). And how about the network? Surely received packets are a trouble source. Formatting errors of all kind…
Let’s have a look at (informational RFC 3164):
##
4. Packet Format and Contents
The payload of any IP packet that has a UDP destination port of 514
MUST be treated as a syslog message.
##
Sweet – anything that is destined to 514 is a syslog message. No matter what the content is. Really? Am I kidding? Let’s read on:
##
Example 2
Use the BFG!
While this is a valid message, it has extraordinarily little useful
information.
##
Yeah… This is a valid message. This also: “HaHaHa”. So how will a parser need to complain when it processes the message. It doesn’t – and that’s why you won’t see many messages from sysklogd itself.
HOWEVER, things are improving. In rsyslogd, there are a lot more things that can go wrong. For example, IETF is standardizing the frame format if TLS is used. This provides a number of opportunities for emitting error messages. TCP itself gives ground to another set of messages. On the output side the same: rsyslog can do dynamic file names. That means files are created depending on incoming messages. Of course, things can go wrong here, providing another set of error messages.
I am talking about rsyslog, because I maintain this project. I think any other modern-day syslogd has a similar set of error messages. And these are possibly seen in practice. But now it is much more depending on how valid all parts of the system, including senders, work. With the majority of syslog-enabled applications still following the “I don’t need to obey any format” paradigm, the typical cause for error messages is not-existent for syslog servers.
I hope that clarifies. And there is even hope: syslogd’s will spit out more errors in the future ;) [and, yes, I have at least created a todo item to emit meaningful error identifiers together with them…]
Rainer
Hi all,
I’ve not posted anything for a looong while. I was (and I am) dissatisfied with the amount of traffic (or better non-traffic) that the blog showed. Anyhow, I think I am giving it a new try. Probably this blog will also morph into a rgerhards blog, not necessarily being on syslog only (which seem to be a too-boring topic for blobs). But I am still unsure if it makes sense to continue – drop me a note if you have an opinion.
Rainer
“The Clouds” is both an educational and fun project. It aims at providing a better understanding of nature as well as pure beauty. Here, find animations of the clouds encircling our planet Earth. Animations are based on weather satellite data. The project is still in its infancy, but already has a number of stunning images.
Follow links below to watch the animations:
I hope this project is useful. Feedback and suggestions are highly appreciated.
While I have not yet found time to create some useful background information, you may want to visit Wikipedia’s article on “atmospheric circulation”.
Copyright © 2007 Rainer Gerhards
Satellite Picture: Copyright © 2007 EUMETSAT
Last Update: 2007-08-11
Visit “The Clouds” Homepage (more animations and information)!
You probably know that earth has cloud bends like other planets in the solar system (most notabely Jupiter and Saturn). If you watch at weather forecasters, you’ve probably seen some of these clouds come and go to your area. However, local (even nationwide) forecasters typically only show you a small part of the visible earth and only a few days of data at most.
Watch the animation below: it shows earth’s cloud circulation during a full month (May 2007) and on a global scale. Note: you need to start the animation by clicking the “play” button in the player below – I’ve not auto-started it so that you are not distracted. Satellite data is taken from EUMETSAT, who thankfully makes images available free of charge to the general public.
Note: a full seven-month hires version is available on my German site!
Please accept YouTube cookies to play this video. By accepting you will be accessing content from YouTube, a service provided by an external third party.
If you accept this notice, your choice will be saved and the page will refresh.
What can be seen? You probably notice the big cloud bend along the equator. This is where sun shines very strong and a lot of clouds from due to evaporation. Winds in this area blow mostly easterly. These winds are called the “trade winds”, a name that stems back to sailors in former centuries. They used the route along the equator to sail from Europe to America. In higher latitudes, we see the belt of the westerly winds. These winds were used by the sailers to sail back from America to Europe. They do not blow as steady as the trade winds, but they are still quite reliable. In between these areas, there is the desert belt with only very little clouds and hence little rain. There is a third wind belt, the “polar easterlies”, from the pole down to around the 60 degree of latitude. That belt can unfortunately not very well be seen in the animation.
Before I created that animation, I know that there are some wind / cloud systems on earth. But I have to admit that I was quite surprised at how good these can be observed. From first view, it looks like the forces creating these systems are quite similar to those on other planets. Now that I have started this animation project, I have become somewhat addicted. First of all, I’ll try to cover at least a year’s worth of pictures and animation. One should probably be able to see seasonal effects. Secondly, I’ve begun to dig deeper on why these wind belts exists. I hopefully will be able to provide further information and animations once I have covered the basics.
I would deeply appreciate any feedback – be it questions, new ideas, corrections, suggestions – whatever. I have set up a forum are on my side. You may use this thread as a starting point.
There is also a high-resolution version of of earth’s cloud circulation available. That version offers considerable extra detail, but comes at the cost of a 25 MB download. If you have a fast Internet connection (or be patient), I highly recommend having a look at it.
You probably notice that the area of earth shown covers Europe, parts of Asia and Africa. That stems back to the data source: the satellite is used for weather forecasting in that area. If you know of similar (free to use) images for America, please let me know: I’d really love to create a similar animation. In fact, one should be able to see clouds moving all around earth if two different sets of images could be acquired.
Copyright © 2007 Rainer Gerhards
Satellite Pictures: Copyright © 2007 EUMETSAT, Animation: Rainer Gerhards
All other Pictures: Rainer Gerhards
Last Update: 2007-07-09
Hi folks,
long time no post, but now one is really due…
Let’s wrap up: The IETF is trying to standardize and evolve the syslog protocol. Syslog is in wide-spread use for system and network monitoring, both in small and large-scale environments. Though widely used, it has never been standardized and is inherently insecure. The IETF syslog working group is trying to change this. During the work, a proposal for a (TLS) secured syslog protocol has been developed, a real group effort. This proposal reflects what already is done in practice (just google for “syslog ssl” and you see what I mean…).
Now, Huawei (the authors of the standard document belong to them) claims an undisclosed patent on this work. This in turn has lead to a standstil of the standardization effort plus a search for alternate, less efficient and more complex solutions to the problem.
The full story can be obtained from the working group’s mailing list archive. It started with this message:
http://www.mail-archive.com/syslog%40lists.ietf.org/msg00593.html
The discussion can be followed by reading the top half posts on this page:
http://www.mail-archive.com/syslog%40lists.ietf.org/maillist.html
Two of my favourite rants in the discussion are these:
http://www.mail-archive.com/syslog%40lists.ietf.org/msg00657.html
http://www.mail-archive.com/syslog%40lists.ietf.org/msg00620.html
Isn’t that cool? It is a nice example of how useful that current software patent system really is.
Happy legalizing,
Rainer
Yesterday I have finished the 16th version of the syslog-protocol internet draft and sent it to the IETF for publishing. It now addresses (almost?) all issues that were brought up in Vancouver and thereafter. In the mean time, the IETF has still made no final decision on the future of the syslog-sec WG. As Chris says, it is likely to stay and the new charter to be accepted. I just wonder if we finish that work until spring…
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.
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 ;)
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
http://lists.adiscon.net/mailman/listinfo/rfc3195
I hope this is a useful tool for the community. Let’s see how it evolves.