| |||||||||||||
The Journal - a proposed syslog replacementThe Journal - a proposed syslog replacementPosted Nov 19, 2011 7:05 UTC (Sat) by alankila (subscriber, #47141)In reply to: The Journal - a proposed syslog replacement by gmaxwell Parent article: The Journal - a proposed syslog replacement
On the contrary, I think there's a significant degree of thought spent on especially forensic issues. Reading the blog post indicates that today, any tool can fake any PID for syslog, apparently, because syslog spends no effort validating the client-given PID value. There's apparently linux-specific way to find out the true PID of process connecting to the syslog facility, and systemd is using it.
Undocumented binary data doesn't mean it's somehow fundamentally unreadable. You just compile the library and use it to read the crap. And it's open source. Sheesh.
(Log in to post comments)
The Journal - a proposed syslog replacement Posted Nov 19, 2011 7:27 UTC (Sat) by gmaxwell (subscriber, #30048) [Link]
It makes me sad that you appear to have not completely read my message.
I explicitly point out that you can use tools to read the logs, and that this works pretty well e.g. for varnish.
But your life will be very painful if you are trying to piece together data from hundreds of machines, and backups across long spans of time, with different and incompatible versions of the file format.
If the developers are not very careful about versioning you may find yourself unable to read data from backups, or worse getting silently corrupted or truncated results. This is a risk which is heightened by using binary logs. It's orthogonal to the PID smarts— which seems like a great idea even without the replace everything proposed.
The Journal - a proposed syslog replacement Posted Nov 19, 2011 9:38 UTC (Sat) by alankila (subscriber, #47141) [Link]
Well, it is a well-understood worry at least.
Log files have a long life, potentially in order of decades, so that sets the level of backwards compatibility required. It is huge, and indicates that whatever the merits of not documenting the format, it will become set in stone anyway unless log conversion tools are provided which can perform the conversion and afterwards validate that every bit of the information is old version was preserved and correctly converted (which might be same as checking the hash value of the log entries).
Nevertheless, even if archived logs become unreadable, old versions of this software do not just vanish into the ether but remain runnable, at the limit through emulation of x86 instruction set and old linux kernel versions. So some solution will always exist.
Regardless, I'd say that the reasonable requirement is that every generated journald log file must remain readable forever, or a chain of provably non-lossy converters must be provided that can upgrade from the earliest version.
The Journal - a proposed syslog replacement Posted Nov 19, 2011 16:59 UTC (Sat) by backslash (subscriber, #32022) [Link] Nevertheless, even if archived logs become unreadable, old versions of this software do not just vanish into the ether but remain runnable, at the limit through emulation of x86 instruction set and old linux kernel versions. So some solution will always exist. This is all open source and not binary only apple or windows.... Just recompile!!
The Journal - a proposed syslog replacement Posted Nov 19, 2011 18:28 UTC (Sat) by alankila (subscriber, #47141) [Link]
Obviously you have not tried to recompile old software. There tends to be a significant porting effort because changes in build system (autotools, I hate you) and compiler code purity requirements may cause code to not compile anymore, or might segfault despite compiling. Additionally, any dependencies to libraries make things that much worse, because not only must that software compile but the old versions of the libraries must compile also.
Emulation at binary level through technique such as virtualization may therefore be far easier to achieve.
|
|||||||||||||