BTW, one issue from my examples below, I think is relevant to -protocol.
In current implementations, syslog servers probably always add the originator's IP or hostname because they don't want to trust the host providing this in the message. This brings up the question of what should be done by relay in -protocol. It seems to me it would be nice to provide a standard way for relay to include the IP, FQDN or both of the originator of the message. Maybe it can be placed in the standard structured content parameter. The original packet has the IP, but the server receiving relayed message, won't have access to it. The message manipulation by relay sucks, but I think we should not lose any information in relay. This information can be useful for cases when a host, for example, thinks that it has a certain FQDN, while in fact, its IP resolves to something else. We have to distinguish between the first relay and subsequent relay for this to work, right? Maybe if information is already in the structured content, then relay should not update it and the originator will recommended no to use that parameter. What do you think? Anton. > -----Original Message----- > From: Anton Okmianski [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 10, 2004 5:04 PM > To: 'Harrington, David'; 'Rainer Gerhards'; 'Andrew Ross'; > '[EMAIL PROTECTED]' > Subject: RE: -international: trailer > > > David: > > > > I am really struggling with that restriction not to > > standardize syslog > > > storage in IETF. It diminishes the value of the syslog > protocol as > > > people can't write a standard syslog parser. > > > > I'm not sure I understand why you feel this. Assuming you are > > parsing what was sent on the wire, that should be standard > > (to the degree that we standardize it). > > Well, I am parsing a log file. If I am parsing a syslog log > file, regardless of what we send, it does not match what is > stored unless it is standardized. The state of the art today > is very sad and for no good reason. Consider two examples. > First, I send a well formed message: > > <183>Oct 11 22:14:15 aokmians3-w2k su: Simple message 8 > > On Solaris, I have in the log file: > > Oct 11 22:14:15 aokmians3-w2k aokmians3-w2k su: Simple message 8 > > On Linux -- same (only I assume hostname was not resolvable): > > Oct 11 22:14:15 161.44.64.125 aokmians3-w2k su: Simple message 8 > > Why duplicate hostname or IP was added if it was a > well-formed message? > > Then consider platform implementation variations. For > example, Solaris logs TLI endpoint identifier (IP + port) for > forwarded messages if FQDN can't be resolved: > > Example of what's logged on server A: > > Jun 20 11:26:57 bacdev1-cmts-1.cisco.com 715: My message > > Same messages relayed to host B as stored: > > Jun 20 11:26:57 [10.86.149.160.134.68] 715: My message > > Great! And guess what the 10.86.149.160 is? The IP of the > relay A, not of message originator > "bacdev1-cmts-1.cisco.com"! For one, this loses the identity > of message originator (which could be addressed in > -protocol), but it is also a new log format to parse (TLIs). > Solaris has also a features where it can add other stuff to > the stored message like message id. Example: > > Sep 29 21:41:18 cathy ufs: [ID 845546 kern.notice] alloc /: > file system full > > I agree the -protocol and -transport are definitely higher > priorities and -storage is a separate topic. But without some > agreed upon storage format, writing a portable log parser is > a challenge. In the above example, Sun had to invent a > proprietary mechanism to store severity and facility in the > message, for example. Whichever is the appropriate way to > solve this, I don't think anyone benefits from the existing > state of the art, which will definitely continue if nothing > is done about it. > > Thanks, > Anton. >
