| |||||||||||||
The Journal - a proposed syslog replacementThe Journal - a proposed syslog replacementPosted Nov 20, 2011 6:51 UTC (Sun) by dlang (✭ supporter ✭, #313)In reply to: The Journal - a proposed syslog replacement by THe_ZiPMaN Parent article: The Journal - a proposed syslog replacement
one interesting issue with using a hash like this (both your proposal and the journal proposal) is that it will cause problems when logs get sent over the network.
the logs may end up arriving in a different order than you sent them for a number of reasons (UDP messages can pass each other on a network, you coudl send some logs to a relay box that fails before it re-sends them and the backup relay box sends newer logs on first, etc)
also if you are combining logs from many systems on one box, the you now have many different hash chains to track (and things get even more fun if you have more than one server sending with the same ID, something that happens in real life, even though it's a really bad idea)
(Log in to post comments)
The Journal - a proposed syslog replacement Posted Nov 20, 2011 14:04 UTC (Sun) by THe_ZiPMaN (subscriber, #27460) [Link]
No, that's not the case because you are mixing 2 different problems.
Syslog already allows for secure, autenticated and reliable network communications, particulary using the RELP protocol (rfc 3195), so ther's no need to add an overhead to that phase.
The hash is then added only when the message is saved on the disk, non before sending it over the network. It's scope is only to guarantee that the log has not been modified after being written, not to guarantee it's immutable during network paths.
The solution is not complete as a journal, but it's really really simple to add to existing daemons (rsyslog and syslog-ng), does not require any invasive operation on the syslog infrastructure, allows a complete backward compatibility and satisfy a big part of the problem addressed by journal in a simple.
|
|||||||||||||