On Thu, Aug 07, 2014 at 10:01:41AM -0400, Steve Litt wrote: > On Thu, 7 Aug 2014 08:31:02 -0400 > AW <debian.list.tracker@1024bits.com> wrote: > > > On Thu, 7 Aug 2014 00:38:16 -0400 > > Steve Litt <slitt@troubleshooters.com> wrote: > > > > > Software As A Service, with Web 2.0 > > ... > > > suggest a Google-hosted service > > > > Actually this is precisely the opposite of my suggestion. Using an > > externally stored database as I have listed would remove the need for > > an external provider, such as Google, for things like 'analytics'... > > and using a standards based sql package would allow extreme detail to > > be stored with very little effort. Once there exists a database of > > the information, there is no reason to store that database on the > > host. Although there is no reason why it couldn't remain there as > > well. The advantage of remote log storing and querying would remain > > even for a small 2 or 3 host home network. If this was a common > > GNU/Linux package, open source routers, like buffalo, could include > > the ability to collect log information from hosts and email a local > > client if a host log indicates compromise --- thus perhaps > > preventing, and/or early detection of, problems like the Bitcoin > > mining botnet running on poorly configured but also open source NAS > > boxes, like Synology. > > > > Seriously, if all logging is going to be dumped into a central binary > > -- it would be much more useful to dump the data into something that > > is logically searchable and can be scripted easily from bash using > > very simple: > > > > pgsql -c "select $foo" > > > > statements. Systemd does this as is [almost]... but the command set > > to query the data is definitely not standard, nor easily > > discoverable. An sql query-able database makes much more sense. And > > it could be sqlite rather than postgresql. > > > > --Andrew > > Oh geez, I'm sorry, I thought your post was flippant sarcasm, so I did > what I thought was extending it. OK, you really do mean the log should > go into Postgres. > > I don't necessarily disagree, but I very strongly believe its first > step should be to go to a text file with one line per event, or perhaps > some sublines. If that text file were designed correctly, perhaps with > field separators, it would be trivial to write a C or Python program to > input it into Postgres. I just want to make sure that I can read that > log on any Linux, BSD, or even (ugh) Mac and Windows. You see, though, this isn't the design goal of the journal. The journal is designed to be resistant against corruption (hashes are used to preserve message integrity), quick to access (there is an index so you don't have to spool through the whole file looking for the event that happened at 10:00, say) and well defined (times, for example, are defined as µsec since the epoch, not some lets-defined-another-parser text string). Consider it to be another database format. You wouldn't necessarily try to cat a MySQL or PostgreSQL datastore; you'd use the appropriate tools to select all from it. In a similar vein, you'd use journalctl to select all the entries from the journal file and you'd expect it to do much of the hard work such as telling you if a line has been altered (either tampered or simply corrupted), adjusting the timestamps for time zones and so on. "cat"ing the journal doesn't have to lose information, either. Journalctl can export as JSON or a serialised "export" format (plain-text). > > SteveT > > Steve Litt * http://www.troubleshooters.com/ > Troubleshooting Training * Human Performance > > > -- > To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org > Archive: [🔎] 20140807100141.4abad88c@mydesq2.domain.cxm">https://lists.debian.org/[🔎] 20140807100141.4abad88c@mydesq2.domain.cxm >
Attachment:
signature.asc
Description: Digital signature