I would suggest people who need a syslogd to use syslogd. Specifically, rsyslog, which can also output to the journal using the 'omjournal' module, (besides the aforementioned normalization features). -- Mantas Mikulėnas <<a href="mailto:grawity@gmail.com">grawity@gmail.com</a>> <div class="gmail_quote">On Jun 1, 2014 8:26 AM, "Lennart Poettering" <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Wed, 28.05.14 22:30, Lubomir Rintel (<a href="mailto:lkundrak@v3.sk">lkundrak@v3.sk</a>) wrote: > This is fairly simple, yet useful with netconsole. Remote socket address is not > used to obtain hostname, it would be easy to fake it via UDP anyway, which is > probably not desirable. If clients wish, they should identify themselves via > identifier field in syslog packets. > > Disabled by default. Humm, I am really cool about this one... There are two problems: journald is highly priviliged because it must be able to read meta-data from /proc for all processes, and exposing such a process onto the network makes me feel very uncomfortable. So far our network-facing services either ran without any priviliges at all (such as systemd-journal-gatewayd), or with only the absolutely minimum they needed (such as timesyncd which only possesses CAP_SYS_TIME). But doing the same with journald is intensly hard since it needs all kinds of super powerful capabilities (such as CAP_SYS_PTRACE) for what it needs to do, because /proc is so weird in many ways.. I mean, I have recently changed the virtualization detection code, so that it can run with no capabilities at all, which should prepare us for changing networkd to run as normal user and only require the various CAP_NET_* caps, but no CAP_SYS_PTRACE or suchlike, which would make it quite a step up security-wise from NM and thelike. So, in many ways we are busy with limiting our attack surface and running things with fewer priviliges, but opening journald up to the internet would really be a step in the other direction here. The other big problem I see is that of normalization. syslog messages are very free-form, and there's very little general structure applied. As long as focus on only local messages (and that means glibc as sender), we can work around that this, as we know what format the client precisely chose. However, if we open this up to the Internet, then we suddenly have to deal with all kinds of formats, from all the router harwdare and whatnot that exists. Much of the complexity of rsyslog and suchlike stems from the fact that they try to normalize the myriad of formats. And I'm really not so keen on getting into that game... I'd be more open to this if this at least could be an independent little daemon (akin to systemd-journald-gatewayd) that runs at minimal priviliges. That would fix my major concern #1... Also, if we do this, then I'd prefer doing this for any number of udp sockets, not just one... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list <a href="mailto:systemd-devel@lists.freedesktop.org">systemd-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/systemd-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/systemd-devel</a> </blockquote></div>