Hi! It's me again! I tried to take account of all your recent comments. So, here's what I'm thinking about the project acccording to them.
> Not all the VMs are running Fedora, there are also Debian-based and some > people use also Arch. Not to mention also Windows, but I think we can > not care about it for now ;) > But currently all the Linux VMs do have journald (hmm, not sure about > Arch?). You're absolutely right, currently all the Linux VMs do have journald (as a part of systemd). > Using full journald export format isn't a good idea, at least for those > reasons: > - many fields should be out of control for sending VMs - for example > hostname, timestamp, but probably more > - many fields are unnecessary (for example all __*), so lets keep the > attack surface as small as possible; even Lennart Poettering can't > write bug-free code ;) > - for the same reason, I'd filter out binary entries (replace > non-printable characters with dot, underscore or sth like this) - > even if journald itself handle them well, some log-viewing software > may not; even simple 'less' command throw a bunch of parsers on its > input... > If using this format, I'd use some simplified version - filter out > unneeded fields (most of them?) when sending, and synthesize those > required after receiving entry in LogVM. And of course reject entries > not conforming to this simplified specification. If we don't use the full version of journald export format, I can't see the point of using it at all. Don't get me wrong, I only suggested to use this format for full compatibility with journald (which we would receive in LogVM). I thought it would be very useful because of the already implemented log rotation, very handy search in journal entries and the security feature of journald (which lets us know when a journal entry has been tampered with). But if we want to change structure of journald entries and leave only the "necessary" fields, we should be ready to lose all the advantages of using journald for logs storage mentioned above. I also don't think that synthesised entries can make friend with journald, this approach prevents us from using all the cool features of journald, and at the same time makes us process the transmitted data twice. > To be honest, I think the "short" format (`journalctl --output short`), > with timestamp and hostname stripped off is enough. So, basically just > MESSAGE field from "export" format. Okay, we can use the "short" format in its pure form, if I understood you correctly. Let's take the output of this command, put it in some file and send it to LogVM via qrexec. In this case we don't even need a proxy-server on the ordinary VM's side. Of course, we would track which entries have alredy been sent, and the next time we would send only the newly generated ones (there should also be some sort of timer for establishing connections). On the side of LogVW we would use a simple proxy-server, which would be responsible for listening for connections from different VMs and receiving information from them. We can keep received logs from different VMs in different directories and rotate them independently (like delete older files, archive not very recent ones and don't touch very recent logs). In this case, we can only search logs as text files (grep), and we don't get the security features of journald (I'm talking about sequential hashing) So, based on your remarks, if I understood you right, here's what I suggest. Please let me know what you think about it. Love, Alisa. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/6e3ef416-5877-4a9a-a7b7-4cad579f3d2a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
