On Thu, Dec 22, 2016 at 11:58 AM, Anton Aylward
On 12/22/2016 11:29 AM, Carlos E. R. wrote:
On 2016-12-22 15:19, Anton Aylward wrote:
On 12/22/2016 09:07 AM, Carlos E. R. wrote:
Is it reliable? Can we trust the journal to work and not loose anything in, say, two years time, even after upgrades?
You've descended into the stage of a ridiculous argument, Carlos.
I don't think so. A binary store is prone to breakage, it has happened. If you think that way, I'll think then that you are a zealot that negates any possible problem.
It is a reasonable question. Will I be able to read it in 2 years time, in any machine
I say again: You've descended into the stage of a ridiculous argument, Carlos
I 100% disagree, and reading logs is part of my professional day job. (Never journald yet professionally. Always Windows event logs or linux text logs to date.). With syslog logs, there are lots of tools. I use X-Ways and Splunk in particular to read logs off of computers that have been compromised. -> X-Ways is my main day-to-day tool. It has zero support of journald binary logs. I would have to export the log files and run them through journalctl then add the text logs back into my exam. -> Splunk can also natively parse Windows binary event logs from the last 15 or so years. When I just googled for Splunk and systemd I found this comment: "Now that Splunk is running and has a place to live, we need to feed data to it. To do this, I setup another service, which uses the journalctl tool to export the journal to a text file. This is required as Splunk can’t read the native JournalD binary format" From: http://blogs.splunk.com/2015/04/30/integrating-splunk-with-docker-coreos-and... So for this professional centralized logging and analysis tool, I have to use text files as the stepping stone. That obviously works okay for day 1 centralizing of logs. But, what if I'm doing an examination of a server 5 years after the fact. (I really do things like that on occasion.) I haven't seen a spec for the journald binary format. I haven't seen a commitment that journalctl from 2020 will have backward compatibility to read 2016 journald logs. I'm not saying those don't exist, but without that commitment at a minimum systemd loses much of its value for me as an incident response responder. And unfortunately I'm not normally part of the planning process for this. I get called in when the incident is identified, not years earlier when the logging system is established. I interpret Carlos's question to relate to that commitment. It is a very important question. I truly hope the commitment has been made, but to claim it is unimportant is simply wrong. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org