:: Re: [DNG] ..forensics on systemd or…
トップ ページ
このメッセージを削除
このメッセージに返信
著者: Clarke Sideroad
日付:  
To: dng
題目: Re: [DNG] ..forensics on systemd or journald logs, was: rc.local removed from Debian 9, rly?
On 2017-11-22 09:46 AM, Arnt Gulbrandsen wrote:
> Aldemir Akpinar writes:
>> No, I've actually asked an honest question.
>
> In that case you'll get my honest answer. I've implemented several
> file/network formats vaguely like that journal format, one of them has
> likely been used by millions of people.
>
> In each case, the team decided to use a header/packet format, because
> that made both writing and reading simple. In the case of the network
> format we additionally included a magic number to catch version skew,
> and did it using binary because that made for the simplest reading
> code. Reading a 16-byte header using read(2) is simpler than reading a
> textual header.
>
> I don't remember anyone on either of the teams suggesting that using
> text had advantages for developers or users. Generally we just chose
> what was easier to ship reliably and parse/generate with simple code.
>
> In one case we used binary because even though the data were readable
> text, they weren't editable (the actual format had non-trivial
> restrictions). I don't remember the details, but for some reason we
> worried that people would hand-edit files and cause problems deep
> inside the reading program.
>
> I find it totally plausible that the systemd people would design the
> format for similar concerns and end up a format where a fixed-size
> header includes a tag type and length, then a variable-sized packets
> mostly containing log lines, and then another header. That kind of
> thing is so easy to read and write using
> https://linux.die.net/man/2/read and its companion functions.
>

It is all a trade-off, making choices in implementation, and choice IS a
good thing to have (Insert thumbs up to Devuan here), I don't think
anybody is disputing that.

This sub-thread mentions forensics, which to me means analysis of a
system, a snapshot in time or worst case after complete failure.

Due to the nature of things one is always going to be faced with binary
files somewhere in the analysis that may or may not be easily
decode-able or even recoverable.

There is no question in my mind that a broken plain text file is far
easier to traverse and sort out, which is really what the finger
pointing game going on here is all about.

Choice is good, having "no choice" forced upon you is bad, end of story.

Clarke