Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

systemd's syslogd replacement supports JSON output

freedesktop.org

Post reply on HN
Print view View original

41–50 of 54 posts

Re: systemd's syslogd replacement supports JSON output

#41

Post by vertex-four »

FooBarWidget wrote: post #40
vertex-four wrote: post #37

Earlier quoted context omitted.

> However I want to argue that not all software should cater to everybody. The issue here is that the Linux kernel developers are starting to make decisions that assume systemd is being used. For example, the (proposed?) new cgroups API is being built with the idea that systemd will manage it, and anything else that wants to interact with it will go through systemd.

That isn't what I read at all. The cgroups maintainer wants a flat cgroups list so that the code is easier to maintain, but Lennart said he must have hierarchical tree so that systemd can take full control over at least a part of the tree. That's hardly "being built with the idea that systemd will manage it".

You've read wrong, unfortunately. http://lwn.net/Articles/557082/ describes that:

> Unprivileged access to the cgroup hierarchy will be strongly discouraged; the hope is to have a single, privileged process handling all of the cgroup management tasks. That process will, in turn, provide some sort of higher-level interface to the rest of the system.

and that:

> This hierarchy becomes private property of systemd. systemd will set it up. Systemd will maintain it. Systemd will rearrange it. Other software that wants to make use of cgroups can do so only through systemd's APIs.

That is, systemd will implement a manager on top of the new cgroups API, and all cgroups users will be assumed to go through systemd.

Re: systemd's syslogd replacement supports JSON output

#42

Post by benbataille »

fosap wrote: post #36
mordae wrote: post #21

Earlier quoted context omitted.

No, what happened was init scripts. Something completely alien to the original init tab concept. It was an extremely ugly hack that worked only because of extensive documentation and effort by much larger amount of people than systemd has now. Both systemd and journal are an actual solution. Try journalctl on your system, it actually makes sense! The silly thing even has bash completion of filtering criteria! And the…

something that was not necessary. Init scripts can be nice and clean [1]. And yes, I'm all for a init replacement. Something new, nice and clean. But I take the shell script hackery over a dbus dependency. But that's just my personal opinion. I have neither used it nor looked at the code, but [2] seems to be what I want. It's by the libdietc author, so i expect the code to be small, elegant and not maintained very we…

That's again a myth. There is no dbus dependency. You can use dbus to do activation but you don't have to. Now, there is a dependency on libdbus which just means systemd is using the dbus serialisation format for its ipc (which, I repeat, don't have to happen over dbus).

Re: systemd's syslogd replacement supports JSON output

#43

Post by spc476 »

asveikau wrote: post #38
spc476 wrote: post #35

Earlier quoted context omitted.

Unix domain sockets are the way to pass open file descriptors between processes, though (why? I don't know, it just is). I think that because of that, the mechanism was extended to also pass along the PID, UID and GID. I did use the open file descriptor with SO_PEERCRED options to implement a Linux-only daemon to open privileged sockets on behalf of a process: https://github.com/spc476/ipacld (something I'm surprised…

I think the easier way is to create the socket with high privileges, then drop down to lower privilege.

But why have the keys to the entire kingdom when all you need is a single key to a single room?

The daemon I wrote is very small, so there isn't much code to audit. The client that calls the daemon doesn't need to be root at all. The daemon can also make a lot of different checks (right UID, right GID, right executable image, etc.) before passing the privileged port back to the client.

Edit: fixing the last sentence.

Re: systemd's syslogd replacement supports JSON output

#44

Post by FooBarWidget »

spc476 wrote: post #43
asveikau wrote: post #38

Earlier quoted context omitted.

I think the easier way is to create the socket with high privileges, then drop down to lower privilege.

But why have the keys to the entire kingdom when all you need is a single key to a single room? The daemon I wrote is very small, so there isn't much code to audit. The client that calls the daemon doesn't need to be root at all. The daemon can also make a lot of different checks (right UID, right GID, right executable image, etc.) before passing the privileged port back to the client. Edit: fixing the last sentence.

A lot of stuff is built on the "worse is better" philosophy. Introducing a daemon like yours will complicate the OS a little bit more. So instead, OS developers outsource the complexity to the apps, and only implement a quick hack to make this possible. In practice, the running-as-root-then-drop-privilege pattern works well enough so nobody bothered making a more complex, but potentially more secure, solution.

Re: systemd's syslogd replacement supports JSON output

#45

Post by teho »

vertex-four wrote: post #41
FooBarWidget wrote: post #40

Earlier quoted context omitted.

That isn't what I read at all. The cgroups maintainer wants a flat cgroups list so that the code is easier to maintain, but Lennart said he must have hierarchical tree so that systemd can take full control over at least a part of the tree. That's hardly "being built with the idea that systemd will manage it".

You've read wrong, unfortunately. http://lwn.net/Articles/557082/ describes that: > Unprivileged access to the cgroup hierarchy will be strongly discouraged; the hope is to have a single, privileged process handling all of the cgroup management tasks. That process will, in turn, provide some sort of higher-level interface to the rest of the system. and that: > This hierarchy becomes private property of systemd. syste…

systemd manages cgroups on systemd based system. The systems that do not use systemd can implement their own cgroup managers. The kernel makes no assumptions on what manager you use on userspace. Other managers could also reimplement the systemd dbus API for managing the cgroups.

Re: systemd's syslogd replacement supports JSON output

#46

Post by teho »

Tobu wrote: post #33
zanny wrote: post #25

Earlier quoted context omitted.

Ubuntu just started using logind in 13.04, but haven't adopted the rest of systemd. Some parts (journal, systemd core, udev) can't be detached, but a lot of the peripheral software outside the init -> maintain services -> log events process are optional.

Ubuntu is splitting logind from systemd with no help from the systemd maintainers, because some gnome projects have started requiring logind. That effort is spent undoing Lennart's work swallowing most of the consolekit code base into systemd. The systemd maintainers won't accept patches that make logind a separate project again.

systemd-logind doesn't use code from consolekit. It has been written from scratch. ConsoleKit itself has been unmaintained for a long time.

Re: systemd's syslogd replacement supports JSON output

#47

Post by teho »

static_typed wrote: post #32

The way this is going, Linux will end up as a single process operating system, that will do everything at web scale. All outputs in glorious binary format. Funny, the crowd got distracted over Gnone3, Unity or Mir, or the latest worry of the day, yet never saw the big threat in their camp. Linux isn't done until the text processor won't run.

systemd is hardly monolithic as it is build of over 80 binaries. A normal system with systemd runs at least four processes: systemd (PID1), systemd-udev, systemd-journald and systemd-logind. There's various smaller services that are run on startup and other occasions. Then there are many configration utilities like timedatectl (systemd-timedated), hostnamectl (systemd-hostnamed) and localectl (systemd-localed).

Re: systemd's syslogd replacement supports JSON output

#48

Post by teho »

Tobu wrote: post #9
FooBarWidget wrote: post #6

Earlier quoted context omitted.

A quick look into systemd reveals that it's comprised of multiple components. For example the journal service is a separate daemon. What part of this does not align with your vision? EDIT: looks like the "monolithic" myth has already been busted: http://0pointer.de/blog/projects/the-biggest-myths.html I would say the distinction between systemd and older systems is that systemd follows the "better is better" mantra o…

It's monolithic because you can't pick and choose the components. You have to use all of systemd, or none of it. You can't replace bits of it, or use just parts of it.

>You can't replace bits of it, or use just parts of it.

You can replace pretty much everything. You need only systemd, systemd-udev and systemd-journald. Virtually everything else is optional. It also allows you to use syslog with journald. It allows you use use crond instead of the timer units. You could use ConsoleKit instead of systemd-logind as session manager... and so on and so forth.

Re: systemd's syslogd replacement supports JSON output

#49

Post by asveikau »

spc476 wrote: post #43
asveikau wrote: post #38

Earlier quoted context omitted.

I think the easier way is to create the socket with high privileges, then drop down to lower privilege.

But why have the keys to the entire kingdom when all you need is a single key to a single room? The daemon I wrote is very small, so there isn't much code to audit. The client that calls the daemon doesn't need to be root at all. The daemon can also make a lot of different checks (right UID, right GID, right executable image, etc.) before passing the privileged port back to the client. Edit: fixing the last sentence.

Well, you could probably set up a sudoers file that allowed launching your daemon but blocked everything else. A hacky solution, but it does not involve giving up all the keys.

I seem to recall reading ages ago how Hurd was going to solve issues like this, and make privileges into something else, tweakable by restarting some user mode process. But I guess there may be something to the other reply about "worse is better" - workable with some hacks is better than ideological purity and non working. (Not to say your daemon doesn't work, I am angling more towards a kernel that doesn't have that arbitrary low-port check.)

Re: systemd's syslogd replacement supports JSON output

#50

Post by vertex-four »

teho wrote: post #45
vertex-four wrote: post #41

Earlier quoted context omitted.

You've read wrong, unfortunately. http://lwn.net/Articles/557082/ describes that: > Unprivileged access to the cgroup hierarchy will be strongly discouraged; the hope is to have a single, privileged process handling all of the cgroup management tasks. That process will, in turn, provide some sort of higher-level interface to the rest of the system. and that: > This hierarchy becomes private property of systemd. syste…

systemd manages cgroups on systemd based system. The systems that do not use systemd can implement their own cgroup managers. The kernel makes no assumptions on what manager you use on userspace. Other managers could also reimplement the systemd dbus API for managing the cgroups.

> The systems that do not use systemd can implement their own cgroup managers. [...] Other managers could also reimplement the systemd dbus API for managing the cgroups.

True, except that the systemd developers are in charge of defining this API and have no reason to consult with other cgroups manager developers when defining it. This is, to make an analogy, equivalent to allowing Microsoft to unilaterally define all web standards from now on. The competitors are always going to be playing catch-up, and there's going to be tons of edge cases where the competitors don't quite work the same.

Post reply on HN