The anti-systemd-brigade only seems to be a small minority of Debian devs (though they're very loud, and very persistent), so I'm not sure it would have much effect on the project as a whole.
If a fork would reduce the time spent arguing about the init system (which 99% of users don't care about), it could even prove beneficial for Debian.
[It seems unlikely the fork would attract the critical mass of devs/users to succeed on its own though.]
I'm not even "anti-systemd". I'm actually in the process of implementing systemd for the firmware of an embedded target in $dayjob because socket activation is actually a good idea and happened to work well when I played with it.
But a switch to a different init system shouldn't break your system so badly that it no longer boots. And yet that's what happens if you rely on keyscript to unlock your drives in /etc/crypttab.
You can still use a keyscript (I do), it just need to be done in a different way. Instead of putting the configuration in /etc/crypttab, which confuses systemd indeed, you can still use the kernel cryptopts variable. For example, in the grub configuration add something like:
Anf then in /etc/fstab use the /dev/mapper/<target> (sdc5_crypt in the example above) as the root device, as before.
Then you need to make sure the initramfs contains all the tools needed to support this (that was done automatically with /etc/crypttab, it's "manual" with the kernel option). To do this, add under /etc/initramfs-tools/hooks a script file to load what's needed in the initramfs: cryptsetup, passdev, the needed kernel module. You can roughly copy the existing /usr/share/initramfs-tools/hooks/cryptroot and simplify it.
I've seen other distro documenting the kernel approach instead of /etc/crypttab for the root filesystem. It may become the standard way in the future, and there's no reason it couldn't be fully automated. There's some coordination between several components so it may take a bit of time to converge to an accepted and supported way thought.
Thanks, I appreciate the hint, I should have noticed that a kernel parameter would be one way to do it (I'm familiar with writing initramfs-tools/hooks to make the existing keyscripts work).
The fact remains though that a wheezy dist-upgrade is going to ruin your day badly enough to spend some time digging up your iDRAC/whatever creds (admittedly, nobody is going to dist-upgrade their prod servers without testing first... or are they? :P)
During boot - before the rootfs is even mounted, what kinds of exposure are you thinking of that's worse than the shell scripts which already make up cryptmount labyrinth? Some sort of `() { :;};` response from the smartcard I'm querying? If I can control the smartcard response, wouldn't I also be able to crash a similarly badly-coded custom C program which does the same?
Only in the future it may use kdbus for some purposes (eg. uploading firmware blobs), but this will only affect internal interfaces.
On the other hand, systemd does not require the D-Bus daemon when you're launching systemctl it as root, the D-Bus daemon is only needed to route the call when used by unprivileged users. When used as root, systemctl connects to the PID1 socket directly and D-Bus is basically just a serialization protocol (and systemd does not depend on libdbus either).
To be fair, udev communicates with the kernel via netlink. All the userspace notifications are done via dbus. So dbus was already part of the equation whether people realize it or not.
You raise a good point. I hadn't considered a shell based init system where the shell scripts only run at startup and aren't available to run at any other time.
You mentioned smart cards... what system would handle when you connect a smart card after boot?
The trigger is the appearance of the volume. If the mounter actions crypttab properly it'll run the keyscript which challenges the smartcard or TPM or USB crypt token or some combination thereof, which in turn provides the response to cryptsetup.
By default nothing happens when you insert a smartcard; if the keyscript tries to run without the smartcard it will retry, timeout, and eventually fall back to askpass. If there's a LUKS keyslot with a backup passphrase which can be entered by a human operator at the tty, this also serves as a disaster-recovery mechanism so that you can afford to lose the LUKS keyslot associated with the token/smart card.
I'm sorry. I wasn't clear. I was asking about the work that gets you to the point where the volume appears. You don't necessarily have a device file for the volume, so something needs to be ready to handle that logic when the device is inserted, then when it has figured that out, you have to notify the automounter that it is time to go to work (or not), etc.
Now add logic so that all of this magically gets powered down all the time to conserve power (and then figure out what you do with the filesystem when that happens).
Now handle the case where you have a bad connection so it is constantly flapping as inserted & not.
Now handle the case where it gets ripped out with no warning.
Now handle the case where you have a smartcard and you are using it to provide the key to decrypt another smartcard...
I think I get your point, but for what it's worth the sysvinit cryptroot/crypttab setup has worked seamlessly for servers for years. Basically if keyscript fails (smart card not available or challenge material not available or TPM won't unseal) it falls back to ask pass on a TTY with the hopes that you can type something in.
I also do appreciate the systemd features for mobile and desktop devices.
But the sysvinit mechanisms aren't rendered completely irrelevant by systemd; the sheer stupid dumb luck of the the thing is actually deterministic and repeatable in my experience. systemd migrations have exposed hidden dependencies I hadn't previously had to worry about between services, which is good in one way, but not necessarily good in other ways (transient intermittent failures which never occurred under sysv).
Yes, it's unfair to blame systemd for poorly defined services - I do like the concept systemd is offering in that respect. But if I have servers in the rack which have smart cards in them that I know are always attached except for very rare events where a sysadmin will be dealing with things, I don't think there's harm in a 4-line shell script failing maybe once or twice in a server's lifetime if it means not having to maintain bespoke C programs for years and years
Racy code has issues with race conditions. Any error in setuid executables can be very dangerous, so they are strongly discouraged. However, once you've decided that you have to write a setuid program, there's no particular reason to not write it in a scripting language.
As a datapoint, the KDE folks think that using scripting languages for setuid executables is okay:
/usr/lib/kde4/libexec/fileshareset: setuid Perl script, ASCII text executable
> The anti-systemd-brigade only seems to be a small minority of Debian devs (though they're very loud, and very persistent)
The pro-systemd brigade only seems to be a small minority of Debian devs (though they're extremely loud, and trollishly persistent).
I've thought for a long time that they must have a place where they all hang out in secret and share links to discussions where they need a pro-systemd response / a handful of downvotes.
In this way they give the impression that their numbers are much larger (the reasoning here is that for any given post or discussion, if the number of "ambient" / "organic" critical comments or downvotes that it receives is a proxy for how critical the community at large is, so by sharing links they make it seem like there's a broad base of support for systemd).
This kind of thing seems to happen periodically, where a person / group of people railroads a decision using methods that are outside the "accepted" set of methods for OSS development, namely meritocratic discussions.
Who knows what their motivations are. It probably varies per person. Having "I designed and implemented a new init system and got all the major distributions to adopt it" on a resume is a huge demonstration of "impact", which is something that really pays off in a lot of companies / organizations.
Decoupling systemd is a feature desired by system administrators, who are responsible for installing and managing most debian and debian-based distros.
on the contrary, systemd is a feature desired by system administrators, who are responsible for installing and managing most debian and debian-based distros.
There's a whole lot of "I don't/do like it" and "It did/didn't work for me" but not a lot of explanation of why they do or don't like it, or what didn't work, and I'm interested in those details.
Is that because you think it's somehow technically inferior or because you you've learnt a whole bunch of skills and don't really want to have to replace them? I mean, would you like to see the init system change, period?
I have. I ran Arch for 3 years, up until 3 months after they implemented systemd. It made a KISS situation incredible complex. I switched back to Debian on my desktop after that. If Debian switches to systemd, I'll switch to Slackware, until SystemD has proven iteself to be stable and simple to administer. Not before.
I've installed systemd on Debian testing months ago and have not had a single problem. https://wiki.debian.org/systemd has some hints.
I think it's likely when Jessie is released you'll most likely find that stuff still works.
I saw that as a giant red warning flag as well. Why would I expect them to maintain a fork and ensure it has full sysv init support, if they don't even have the time to engage in the current process?
It's all a bit overdramatic anyway - there are heaps of Debian forks; they're called 'downstream distros'. Ubuntu is one.
> Why would I expect them to maintain a fork and ensure it has full sysv init support, if they don't even have the time to engage in the current process?
Probably because they (experienced Unix veterans) realized that it makes much more sense to test the demand of a fork (that's what they made the website for) than to continue any useless discussion about systemd. Some systemd proponents obviously have serious problems to make a sober discussion anyway (interestingly also in a prominent German forum).
Notice: "If SystemD will be substituting SystemV in Debian, we will fork the project and create a new distro: Pure Debian by Veteran Unix Admins. We hope this won't be necessary, but we are well prepared for it."
They are not eager to make a fork but I think they will actually do it if necesary.
Using the same argument, forking would seem like a horrible idea if there isn't active maintainers.
Until I saw that line, I was thinking: well quit talking about doing it, and just do it!
The idea of a non-systemd distribution in general is something I've been expecting to pop up for a while. And if the vocal people online represent a real desire not to switch, then one really should exist. Beyond that I'm rather uninterested in such a project one way or another.
The trouble here is that the bulk of the work is just maintaining a changeset to debian packages. They haven't even spun up dak and friends, so I'm assuming this is DOA for now. It seems like a lot of hot air to pressure debian, or at the least attract contributions that can maintain their fork. Is "fork" a scary word to any DD, considering debian is already the upstream distribution for other, more popular, derivatives?
Using the same argument, forking would seem like a horrible idea if there isn't active maintainers.