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 <graw...@gmail.com> On Jun 1, 2014 8:26 AM, "Lennart Poettering" <lenn...@poettering.net> wrote: > On Wed, 28.05.14 22:30, Lubomir Rintel (lkund...@v3.sk) 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 > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel >
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
