The problem with systemd's NTP and DHCP and whatnot is that they use their own systemd-specific APIs. Not using the APIs means that you don't talk to those components. And the thing is, if you're on a systemd-based system (which you can generally assume* to be the case now), you can 100% depend on those components absolutely definitely existing, regardless whatever else is(n't) installed.
(* Unless your users are using Slackware (hi there :D), Devuan or something like that.)
So of course things are beginning to depend on those services' APIs.
Which are exposed via D-Bus. ("Desktop"-Bus. On servers. Facepalm, Inc.)
Now, I do understand that when you use systemd-nspawn or LXC or Docker or whatever else you can generally assume that these components will interoperate and that's why they were implemented. That's the theory.
Their DNS "client" implementation was a tour the force of NIH wrongs, including screamers like not implementing security functionality that had been commonplace in other implementations for a decade or more.
Damn it, they have a web server in there for the sole reason of displaying a QR code for the initial log signing key. A signing system that apparently Poettering's brother came up with as a doctorate thesis, with systemd-journald being the only implementation (that i know of).
BTW, these days you find dbus inside the initramfs. Because systemd need it to be present during bootstrap. After systemd-pid1 is up, it will kill the initramfs version and fire up the one from the HDD instead.
There are times i wonder if the Fedora maintainers grit their teeth and play along with Poettering and crew because they have the same paymasters.
> Their DNS "client" implementation was a tour the force of NIH wrongs, including screamers like not implementing security functionality that had been commonplace in other implementations for a decade or more.
:(
> Damn it, they have a web server in there for the sole reason of displaying a QR code for the initial log signing key. A signing system that apparently Poettering's brother came up with as a doctorate thesis, with systemd-journald being the only implementation (that i know of).
Okay, that I didn't know.
Actually let me read that backwards...
> log signing key
What on earth? Is the log encrypted?
> QR code
How are QR codes relevant to encryption?
> web server
Why do I need a WEB SERVER to display a QR code?! Uh... I can get displaying a QR code on the screen, sure. But... I get the impression you mean the QR code is served over a web server?
Oh. For headless boxes. But... why display a QR code, again? Why not just serve the log signing key itself? QR codes aren't encryption (just a good week's worth of reading on error-correction).
> BTW, these days you find dbus inside the initramfs. Because systemd need it to be present during bootstrap. After systemd-pid1 is up, it will kill the initramfs version and fire up the one from the HDD instead.
Mmm. Because all of its APIs are delivered as D-Bus (desktop-bus) services. I totally get that, but... aghhh. Why not even ZeroMQ :(
> There are times i wonder if the Fedora maintainers grit their teeth and play along with Poettering and crew because they have the same paymasters.
Unless things have changed, Linus Torvalds uses Fedora. He's had a lot to say about things.
I would be very very surprised if there wasn't a noteworthy bunch of mental-pitchfork-wielders.
My limited understanding of the whole thing is that journald use a chain of signatures to verify journal integrity.
Meaning that the first key is used to sign a new key that signs the journal entry and the next key that sign yet another key and entry etc etc etc. And that by having the initial key handy one can at any time walk through the journal to verify that it has not been tampered with.
The whole QR thing it there to allow a would be admin to quickly transfer the initial key to their smartphone or similar by scanning the code.
As for Torvalds being a Fedora user, my impression is that his usage needs are fairly modest these days. He spends most days reading emails via gmail, and approve commits to the kernel code housed on the kernel.org servers.
I see, interesting. For what it's worth that's pretty cool. I never even thought of the idea of a verifiable system boot log...
It's almost sad systemd has some good points. Heh.
I vaguely recall a video that noted where Torvalds was at nowadays; he seems to mostly be in administration/management now, as opposed to low-level hacking. Must be an interesting position to be in.
The problem with systemd's NTP and DHCP and whatnot is that they use their own systemd-specific APIs. Not using the APIs means that you don't talk to those components. And the thing is, if you're on a systemd-based system (which you can generally assume* to be the case now), you can 100% depend on those components absolutely definitely existing, regardless whatever else is(n't) installed.
(* Unless your users are using Slackware (hi there :D), Devuan or something like that.)
So of course things are beginning to depend on those services' APIs.
Which are exposed via D-Bus. ("Desktop"-Bus. On servers. Facepalm, Inc.)
Now, I do understand that when you use systemd-nspawn or LXC or Docker or whatever else you can generally assume that these components will interoperate and that's why they were implemented. That's the theory.
In practice, things... don't work out so well. This was on here a couple days ago: https://thehftguy.com/2016/11/01/docker-in-production-an-his...