Konstantin Ryabitsev (icon@xxxxxxxxxxxxxxxxx) said: > > Not sure I can parse this, but IIUC you are wondering whether logwatch > > is compatible with the journal. Not to my knowledge, no. But adding this > > should be fairly easy as the output of "journalctl" is a pixel-perfect > > copy of the original format, so where it works on /var/log/messages it > > should simply work on the output of journalctl and all should be good. > > > > Note however that with the capabilities of the journal it might be > > interesting to add journal support to logwatch that goes beyond mere > > compatibility. For example, tests such as "look for messages which are > > claimed to come from PID xyz but actually came from uvw" and suchlike > > would be really interesting to have. That information is not available > > in the /var/log/messages format however... > > So, in other words, all our existing log analysis tools have to be > modified if they are to be of any use in Fedora 18? Right, you'll have to port them to understand CEE from updated rsyslog. HTH, HAND. <- note: THIS IS A JOKE. MORE SERIOUSLY.... There are a lot of usage cases that people want from their logging. 1) Administrators want their plain-text logs that they know and love (or at least know and have gotten accustomed to) that they can use their normal unix tools and their homegrown custom shell/awk/perl/python/whatever scripts for parsing. (For the purposes of this discussion, consider logwatch one of those homegrown things, as it basically is that writ large.) 2) System management authors would love to have a mechanism where they can subscribe to particular alerts as they come in, without having to subscribe to all messages, or try and parse the unstructured text of syslog 3) Application developers might want to be able to express stuff they log in a more structured fashion rather than just: "(function:line) bad juju happened here in frobnitz" 4) Administrators want to be able to do things like 'show me everything sshd did/logged about', or 'show me what happened last Thursday, because I can never get the hang of them.' 5) Standards People want to have messages in the new CEE format, so they can use their new CEE tools on them and merge some of their homegrown tools. 6) Meanwhile, you've got the poor audit logger over there on the side doing its own thing, and there are users who Really Like those audit logs. And we've got a lot of technology going around. journald - that's technology. rsyslog - that's technology. libumberlog & ceelog - that's technology. What we've got to do is take the usage cases we have, and the technology we have, and get a coherent solution that covers them. And it's certainly not clear at this point what that solution would be. If people want CEE format logs, or plain text logs, maybe journald should grow those as output formats. Or maybe rsyslog should produce those formats. Maybe rsyslog should grow a journald plugin, so instead of duplicating some of journald's code for associating entries with pid/exec/etc., it can read the already annotated journal stream and add its own metadata & spit out whatever formats it wants. (Maybe it already does this!) Maybe rsyslog or journald should take over audit logging in some way. But the point is, there's a lot of work in this space going on on all sides (take ceelog, liumberlog, and journald - all relatively new bits of technology touching portions of this space). And at this point I'd say it's way too early to say that Fedora Shall Be XYZ, or to conversly say that Fedora Shall Not Be XYZ. A full plan for hitting all the usage cases we might want just isn't known. (Although it would be a lot easier to get there if y'all would stop shouting AT & PAST each other.) So no, you don't need to change anything for Fedora 18. rsyslog is there by default, journald is there too if you want to look at that. And until we actually have a Plan, rather than just Technology, I'm not sure why you'd say that Fedora will do XYZ in F-19 either. Well, you can probably say that Fedora 19 won't ship with sysklogd by default; that should be safe. Bill -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
