Hai all,
Today, we had a discussion about tools. My conclusion, for now is, there
are --somehow--, mistakes in the rfc.
We are implementing right now; some programmes that will generate, use and
relay syslog messages. As there was no RFC untile lately, we used the draf
rfc's and the implementation on (Free)BSD, Linux and the observed behaviour
on AIX and others as input. We did made some design changes on them. It
worked, both stand alone, as in togheter with other tools
It did work...
Until today,
The programmer, workin on the tools made some changes to his code, to
reflexd the lastest changes in de rfc. And it stoped working!
What is wrong?
Somewhere, between draft-06 and the curent rfc (I don't have other drafts on
hands), the definitions of the fields, mostly HOSTNAME and TAG are changed!
On paper, it's correct. But functionally there is a bug!
An example. A syslog line starts with PRI and TIMESTAMP. It use "P-T" to
denote that part. It's alright
Some typical lines looks below
P-T janitor /kernel: arp: unknown hardware address format (0x0800)
P-T janitor qpopper[8994]: Stats: albert_laptop
P-T janitor qpopper[8997]: Stats: albert_laptop 0 0 0 0 ...
P-T janitor qpopper[8998]: Stats: albert_laptop 0 0 0 0 ...
P-T janitor qpopper[8999]: Stats: albert_laptop 0 0 0 0 ...
P-T janitor su: albert to root on /dev/ttyp1
P-T janitor qpopper[9024]: Stats: melanie 0 0
To denote where the line is generated, the part after P-T, unto the ":"
should be used. I call that the "location"
This location is build from a HOSTNAME (janitor) a programname (qpopper,
/kernel, su) possible a pid (889?, 9024). In more advantage systems possible
a thread-nummer (-).
However, acording to the RFC only the HOSTNAME (janitor) and a TAG are part
of the "header"; the remaining is vree formated text. Any non-alfanumiric
character will terminate the TAG. So the TAG in the above lines are
_invallid_ (/kernel doesn't start correctly), qpopper, su, and qpopper
again. But *no* PID.
The RFC does advice tho place them in the CONTENT. So, it's is possible to
say that the above lines are according to the RFC.
But that is useless; when automatic tools has to interpret it!
Bassically, I'm very disapponted on the quality of the work we have delived.
And I'm sorry that I didn't see this "change of the draft" beforehand. I
too, did have a busy time, soo I wasn't able to study evry draft again and
again.
I concentrated on the parts taht where discussed on this list.
Somehow I have mist the discussion; Somehow we all did.
I do not believe, this change is intended. Probally, it is made to make the
text more clear. However, it doesn't describe a
GOOD protocol!
Beside's, a quick study on the implementation on BSD, suggest the HOSTPART
isn't filled in in the device. It's "madeup" by the syslogdeamon. But
possible that a bug in FreeBSD. I have to study in detail.
My quistion is: Can we still change the RFC (or replace it with a new one)
As we use RFC3164 as base, for the secure versions of syslog, we have the
sameprolem there ...
(and yes, I'm implementing... I'm working on a opensource version of
syslog-sign at the moment....
--ALbert
sent mail to [EMAIL PROTECTED], to address me personal.
sent mail to [EMAIL PROTECTED], to address me for businesses
