Re: End of hypocrisy ?
On 8/8/14, Jerry Stuckle <jstuckle@attglobal.net> wrote:
> On 8/7/2014 8:28 PM, AW wrote:
>> On Fri, 8 Aug 2014 09:03:56 +0900
>> Joel Rees <joel.rees@gmail.com> wrote:
>>
>> > You do understand the chicken-and-egg nature of what you're asking
>> for?
>> >
>> > You're needing to output logs to but up servers, but you have to boot
>> > a server as complex as anySQL server to get there.
>>
>> I wasn't going to continue on this thread -- and after playing with
>> the journalctl cli for much of the day -- I repent of my complaints
>> [mostly]
>> -- any remaining complaints are extremely minor. But I guess I should
>> answer a
>> direct question... perhaps a new thread should be started, this one is
>> getting
>> long in the tooth.
>>
>> Of course I understand the chicken-egg problem. However, once the system
>> is
>> running, there's no reason why the log data collected during the boot
>> process couldn't then parsed into a standardized db --- resulting in
>> standardized sql query capabilities. The boot log data should be
>> entirely
>> ASCII until a login prompt. This greatly assists troubleshooting of
>> failed
>> boots - undeniably. However, after booting, remove the ASCII boot log
>> data
>> from RAM via secure deletion process to increase security of the system as
>> a
>> whole...
>>
>> --Andrew
>>
>>
>
> I just wonder - why should I have to look in multiple paces for
> (possibly related) messages?
Seriously Jerry, your mind needs expanding!
> That is, some to a text file, some to a SQL file.
Of course! You just don't get it.
Whoever does the patch to systemd will I'm sure put some
options in to send just say every second log message to the
db, and the others to the journal - for load balancing or
whatever its needed for.
> I have nothing against SQL (I've been using it for over 25 years). But
Awesome! That means you can help out with the --output=sql
patch yes?
> I don't think it's a good solution to everything. Not everything is
Your thinking is questionable at best.
> relational (which is what SQL excels at). And not everything needs a
Except for the journal's binary blob support, it is relational,
and Postgres has support for all sorts of wierd types, I'm sure
it can handle binary blobs just fine!
> SQL engine when text files work just as well.
Definitely wrong about that.
Cheers
Zenaan
Reply to: