On Sunday, 12 March 2017 22:20:33 UTC+3, Jean-Philippe Ouellet wrote: > > Please feel free to ask any questions you may have! >
Hi again! Since last time I've learned some materials related to LogVM task. Now I want to use your offer about asking questions that I have. :) I discovered that the majority of required functionality had already been implemented as a part of journald (which is a part of systemd project). Journald saves all the logs it knows about (such as kernel messages generated with printk(), userspace messages generated with syslog(3), userspace entries using the native API, coredumps via /proc/proc/sys/kernel/core_pattern and more; I took it from here: [1]). It also takes care of security (undetected manipulation is impossible because of because of each entry cryptographically verifying all previous ones) and journal files rotation for more efficient disk usage. At the same time it provides tools for comfortably viewing logs and even searching them. Because of the fact that all our VMs are working on Fedora, we can use all this features for our profit. (All of this sounds like journald advertisement. xD) Journald developers advise not to change journal files because of basic principles of journald implementation. They describe its on-disk format and note that it is "not what you want to use as base of your project". I think that we can parse journal export format (reasoning for why this is necessary below) to delete meta-information, but I'm afraid journald won't work with our modified file later. So this way an attempt to write some tool for processing such files is similar to reinventing the wheel (or reimplementing journald). My idea for the project is the following. Among other functionality, journald contains functions for sending and receiving journal messages over the network. For our goals we need its systemd-journal-remote [2] and systemd-journal-upload [3]. For transmiting entries journald uses the special format [4]. The problem is those tools only support transmitting logs in HTTP/HTTPS over TCP/IP, while we only support VMs communicating via qrexec. I think a simple proxy-server (maybe, even a self-written one) would solve the problem. Journald on VMs would send its logs to the proxy (that works on the same VM in the background) and it, in its turn, would open qrexec connection to pass them to LogVM. LogVM here would be a usual VM working on Fedora. There would also be a proxy-server working on LogVM in the background. It would receive data via qrexec and simulates for journald on LogVM the situation like it was received through TCP/IP. So this way can be suitable for collecting logs from other VMs. For better understanding the process I attach the scheme of the described process [5]. Hope it will be useful. Please, let me know what do you think about this idea. Is it suitable for this project? Can I write а proposal based on it? Best wishes, Alisa. [1] https://goo.gl/BaCCko [2] https://www.freedesktop.org/software/systemd/man/systemd-journal-remote.html [3] https://www.freedesktop.org/software/systemd/man/systemd-journal-upload.html [4] https://www.freedesktop.org/wiki/Software/systemd/export/ [5] https://goo.gl/8euAAM -- 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/c2472d6f-b26d-4642-8e4f-a11fea924717%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
