Hacker News new | past | comments | ask | show | jobs | submit login
Unlocking LUKS2 Volumes with TPM2, FIDO2, PKCS#11 Security HW on Systemd 248 (0pointer.net)
148 points by uggedal 45 days ago | hide | past | favorite | 99 comments

Unrelated to unlocking devices...but LUKS is a really nice piece of software for linux. You throw any block device(real or otherwise) to it, and you get a /dev/mapper/<name> volume that transparently encrypts anything written to it.

Other than encrypting my local workstations, you can also use it on VMs from linode/digitalocean/aws/gcp/etc. If you store all your sensitive data beneath /home for example, you can boot the instance, use OOB console to access it, decrypt and mount /home, then SSH and it's business as usual. This gives you (some) protection against a malicious actor at your provider snooping your volumes.

edit: typo

At risk of being pedantic, technically it's device-mapper/dm-crypt that's doing the heavy lifting here... but I guess LUKS has become the popular name for the whole pile due to its visibility.

At the risk of being offtopic, this is exactly the type of pedantry that keeps me coming back here.

To be even more pedantic: There's also a qemu block layer device that is compatible with LUKS and works in userspace (https://www.linux-kvm.org/images/8/8c/01x03-Daniel_Berrange-... - page 13).

And the cryptsetup tools / kernel has recently added support for Windows Bitlocker encryption as an alternative to LUKS, obviously only really appropriate if you deal with Windows images or need interop with Windows.

I’ve found out that my VPS hoster mounts disk of my VM when I power it off and writes some config changes (which broke network because their scripts were buggy). That creeped me out, so I decided to encrypt my disks. So encryption is useful even for better stability in uncontrolled environments.

> VPS hoster

> so I decided to encrypt my disks

Where is the data encrypted? Local or remote? If its done remotely, whoever owns the hardware and has root on the host OS has your private key. Even with rented servers, where you are root, the KVM is king.

It is encrypted remotely using LUKS, but I have to enter password manually when machine is booting (via web VNC). Of course I understand that determined attacker from hoster side could sniff that password, but, as I said, that's more about preventing automatic scripts to mount my disks rather than trying to hide something.

You can even setup SSH to the bootloader to unlock LUKS if it reboots.

Yup, earlyssh - I found it a massive pain to set up, but it works.

Interesting, I've never heard of earlyssh as an option--I've used dropbear-initramfs for this in the past.

Same here, I have been using dropbear-initramfs since forever. I am now looking into Mandos[1] though, as doing it manually with Dropbear becomes a massive pain when managing several bare-metal servers.

[1] https://www.recompile.se/mandos

Thanks for the link; I hadn't heard of Mandos.

Another solution in the same space is Clevis[1]; last time I was researching this problem, I came across it via Red Hat's docs[2].

[1]: https://github.com/latchset/clevis

[2]: https://access.redhat.com/documentation/en-us/red_hat_enterp...

I think dropbear is what sits under earlyssh. I'll look into dropbear-initramfs, if it's easier to work with than earlyssh that is a big plus in my book.

edit: early-ssh is hosted at https://github.com/gheja/early-ssh . Not to knock early-ssh by saying it's difficult to work with too - it's a great piece of software which has made my life a lot easier.

If you like early-ssh, I would like to suggest checking out better-initramfs. No dependency on systemd, easy to modify and build. I think it can do everything early-ssh can do. I use it to boot a variety of LUKS encrypted btrfs machines.

Disclosure: I'm a contributor.


Nice! Starred, will definitely keep that in mind, thanks a lot.

Same, that's what I use, and it was super easy to do.

Also you can auto-decrypt LUKS when your main machine is booted https://blog.haschek.at/2020/the-encrypted-homelab.html

Note that this trashes your disk I/O performance; AWS offers Customer Managed Keys as an alternative where you use their platform's encryption but with your own keys: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncry...

Google compute platform even offers user-provided keys at instance startup; they persist in RAM only for the lifetime of the instance and you can provide an rsa-encrypted symmetric key to GCP if you don't trust the box responsible for calling the GCP API.

Combined with AMD-based (SEV) confidential computing and shielded vm you can get close to what on-premises hardware offers.

Nothing can truly replace hardware you own (except maybe fast fully homomorphic encryption eventually) but if you can trust the firmware that Intel/AMD, HP, Dell, or Supermicro ships in a box then the cloud is 99% as good at this point.

If you don't trust Google, even this doesn't help you. They run enough code in and near your VM, they could find a way to steal data out if it if they wanted.

If you do trust Google, this is of no benefit. They encrypt your disk at rest anyway with their own keys if you don't provide yours.

The only reason to use any of the above tech is to change the legal burden of who has to provide data if a court order is made. If you provide the keys then the court has to come to you to provide data on demand.

That's actually a pretty compelling use case. Instead of the US Government being able to routinely compel Apple, Google, FB, Amazon, etc to to hand over data they just say "we don't have the keys". The fact that any of these entities could find a way to get the data if they wanted (yes, even Apple, even with E2E could have an insider attack where a rogue spy employee implanted some code in the OS to intercept data)

Allowing the service providers to say "we don't have it", makes widespread government attack less scalable, because instead of focusing on one entity, suddenly they've got to chase down thousands of individuals and compel them. And the individuals usually have a lot less to lose if they don't obey than a tech company with billions on the line.

> If you don't trust Google, even this doesn't help you. They run enough code in and near your VM, they could find a way to steal data out if it if they wanted.

Exactly, but so can Intel/AMD/Dell/HP/$HW_VENDOR. That's why we have libreboot and friends trying to disable ME and other firmware blobs.

You could airgap your hardware in a SCIF and shred it when you're done with it but as stuxnet and other attacks have shown if you want to do useful network computing you can't be totally secure.

Hey all, as it was mentioned in the article, a significant remaining issue is being able to protect your initramfs and your cmdline options during boot while still keeping the convenience of auto-unlock. Current distribution implementations DO NOT, EVEN WITH SECUREBOOT ON, verify the integrity of the initramfs, which can be repacked to include malicious code that will execute during boot, potentially intercepting your LUKS key.

There have been a number of attempts to solve this problem, but the most complete appear to be Mortar (a project I head) and safeboot.dev

I highly recommend taking a look at either of these projects if you want be able to improve both your convenience through auto unlocking, and security through broadened scope of audit.



As someone that leaned pretty hard into using a Yubikey 5 for GPG/SSH keys over the past year, I am looking forward to giving this a try on my Fedora workstations. If you are interested in a fantastic walk through of using a Yubikey with your GPG/SSH keys check out https://github.com/drduh/YubiKey-Guide

I am also really looking forward to the YubiKey Bio getting released too.

If you just want ssh it's even easier to use u2f/fido now since it's built into openssh.

I didn't know that. Thanks! I'll check it out.

FIDO-based SSH requires support from the server, because it's a new authentication method. So this is great in an environment where you control the servers, and some day it'll be pretty great for almost everybody, but today e.g. you can't use FIDO for GitHub. Whereas the older methods did not have this dependency.

On the other hand, one really nice thing is that FIDO lets you force employees to actually use organisation mandated security if that's appropriate. There's no way to force the remote SSH client not to store that RSA private key unencrypted, for example, even if it is company policy to use a 16 character passphrase; but if you issue every employee a Yubikey (picking one famous brand) the FIDO authentication step can insist that a genuine Yubikey was used, that the Yubikey says a PIN was entered and user presence confirmed. The OpenSSH design passes the digitally signed assurance from the Yubikey to the remote server for assessment, so you can't just comment out a few lines of SSH client code to bypass it.

Should you actually do that? Probably not, but it's an option you didn't have before. Certainly if your key people already swear they obey a policy requiring this there's no harm in enforcing it, is there?

> There's no way to force the remote SSH client not to store that RSA private key unencrypted

But there is a way to remotely attest that the private key has been generated on device (either through TPM attestation or https://developers.yubico.com/PGP/Attestation.html ).

Not to mention that the admin could just generate private keys on the token and give employees that.

I was unaware of these options, thank you.

> Unlocking with FIDO2 security tokens (well, at least with those which implement the hmac-secret extension, most do). i.e. your YubiKeys (series 5 and above), or Nitrokey FIDO2 and such.

FYI, Nitrokey runs Solo FIDO2 implementation [1], which is also used by Signet HC and OnlyKey. So all these FIDO2 keys will work with LUKS2.

And if any maker of keys is reading, please reach out if you're implementing U2F but want to upgrade to the full FIDO2, including the hmac-secret extension.

[1] https://github.com/solokeys/solo

Does the yubikey "security key" series (the ones that only do u2f/fido2) support the necessary extension?

Edited to update: Nope :(

My Security Key 2 reports lacking this extension.

This is what the comment said before I updated it, in case it's important context for replies:

I believe that they do implement hmac-secret yes. For what it's worth this is the same feature (for the same reason) you need to enroll FIDO authenticators to unlock a Windows system, so if you use one to do that today, it definitely ought to work with this too.

I intend to spend the next few minutes playing with code to check I'm correct about this, but I might get distracted, so either there will be an edit saying I was right, saying I was wrong, or no edit because I watched Youtube.

Now I feel terrible, because I think this was incorrect due to an embarrassing error and yet it has 5 upvotes which suggests several HN readers thought it was helpful :(

During another activity I was talking to somebody about this test, and when I visualised it in my head I realised that even though I was talking about testing my "Security Key 2" I had actually tested a much simpler/cheaper Feitian based U2F authenticator I own because it was in my pocket and I just instinctively use the one I'm carrying for FIDO authentication.

Unsurprisingly this cheaper device doesn't do hmac-secret.

However I have now fetched my actual genuine Yubico Security 2 and re-tested that, and it does have hmac-secret despite Yubico's own site seeming to suggest otherwise.

The chances anybody is reading this for any reason other than to point out I was wrong are small, but just in case this is found by somebody's later Google search here it is.

Here's some example output from Yubico's example app (the secrets here are random and worthless)

New credential created, with the HmacSecret extension. Authenticate with salt: b'21cef9e80517c7527ddaea4229ea36c675c539da7f98ecf3878dfc026caf4a6d'

The chart at the top of shaicoleman's link indicates that the security key series doesn't support it. I also just tested the hmac_secret.py sample from the python fido2 library and it didn't work with a yubikey security key nfc.

It seems like it's only available on the Yubikey 5 Series


Thanks. That's too bad.

If LUKS could store a piece of random public data in the LUKS header then LUKS keys could be derived by signing that public data.

For example, ssh-agent can sign arbitrary data via its wire protocol. Lots of USB security keys expose their functionality via ssh-agent.


Does LUKS / cryptsetup provide hooks for deriving a key from a blob of plaintext stored on the disk?

[edit] There’s the UUID — sign it with your ssh-agent and use the hexdigest as a LUKS key. It sounds so simple it must already exist?

I am confused at which stage this is happening.

Is this after the bootloader, after initramfs but now systemd-cryptsetup is loaded and unlock the first disk?

AFAIK when I do my first disk unlock, at that point does systemd units get loaded including systemd-mounting.

Those mounts can already already mount/unlock encrypted secondary disks, based on the keyfiles stored on the now decrypted disk. So what exactly in this case is the advantage of any of this?

EDIT: Also, is there any discussions over ftpm support? Last I checked TPM2 was ok, but ftpm (which most intel/AMD now using) are a bit flaky in regards to support.

Quoting the man page:

At early boot and when the system manager configuration reloaded, /etc/crypttab is translated systemd-cryptsetup@.service units by systemd-cryptsetup-generator(8).

So this should run during mkinitcpios systemd hook, I think (i.e.during "initramfs times").

EDIT: Also as a service it can also run later one if you e.g. plug in a LUKS encrypted hard drive I think. I haven't tried it out.

Initramfs I believe. `systemd-cryptenrol` would probably just be a binary like any other and wrap `cryptsetup` which is on your initramfs.

here's what I had to do on Arch to enable unlocking the root volume with TPM2: https://github.com/systemd/systemd/pull/17741#issuecomment-7...

it'll need some work from the distros so the whole process is a bit more straightforward.

fTPM on my Ryzen 3600 worked.

Good. No mention of contactless, but for PKCS#11 it should be automatic since it's responsibility of the reader via pcsc/ccid. Not so for FIDO2 or previous incarnations last I checked.

I tolerate systemd as I want to use a popular distro for desktop use, but given the project's dismal security record (and attitude!) I can't trust systemd explicitly handling cryptographic secrets. No thank you; there are better options available https://wiki.archlinux.org/index.php/YubiKey#Full_disk_encry...

Is systemd's encryption a replacement for existing software like LUKS or just a wrapper around it?

By my understanding, systemd is just handling the unlocking process and merely provides LUKS with your password/token communication. LUKS is the part that actually needs to be secure beyond systemd just not emailing your password to the gubment/north korea/4chan. LUKS unlocks its key store with the info you provide it which is used to decrypt the drive.

It enables you to use a token that is portable and removable, which TPM2 chips are not. This has an advantage that it can be carried and secured separately, even if the device has to go into insecure storage like a hotel safe. You need to trust your FIDO2/PKCS11 device to be secure, though.

Clevis, on the other hand, allows to bind the key to a specific machine, preventing the storage itself from being yanked out (where it is still possible) - and you need to trust TPM2, which many do not.

It's all about trade-offs and trust.

Superior might be a stretch, but it the ability to use PKCS11 and FIDO2 tokens look to be differentiating features.

This means systemd needs to live on an unencrypted volume though, right? Seems like a bit of a weakness given how much systemd can actually do.

I went with LUKS1 which grub can unlock.

You always need something to live outside of your main disk encryption.

Now you have the choice to use grub for this or linux itself.

In either case both can be modified to do arbitrary things and corrupt later stages.

To prevent this you use secure boot, and if you want to do it right a custom platform key.

So now you either pack the Linux kernel initramfs etc into a single blob and sign it or do something similar with grub.

In both cases you should have a similar secure system.

But in my experience GRUB's functionalities in this area are not very nice to use and lead to slow boot.

On the other hand directly booting the signed linux blob without a bootloader is fast and smooth, but exposes what is in you initramfs, which normally doesn't matter.

If you're concerned about an evil maid attack then you can authenticate bootloader, initramfs and kernel via secure boot.

systemd-boot measures the bootloader, initramfs, kernel and kernel-params state into the PCR registers of your TPM. SecureBoot state is also measured.

You can configure through systemd-enroll to configure the TPM to only unlock the cryptokey if those measurements are consistent.

If somebody changes your systemd binary in the initramfs; this causes the TPM PCR register to change; and will cause the system to not be able to decrypt the stage-2 rootfs

Do you have a good tutorial for all these processes? This is something I thought would be awesome for a while, but there are a lot of moving parts. I also thought all the hardware was not yet support to do all of this.

Chances are theres an EFI partition thats still unencrypted, too! This is where secureboot/tboot has its chance to shine.

Indeed. LUKS key on tpm2 with secure boot with /boot on encrypted seems anything but easy to setup. I also complicate things by making everything apart from efi on zfs.

What's the problem though? systemd is included in quite a few initramfs so nothing inherently has changed here.

Does this allow for having a fido2 pin on the yubikey and entering it at boot time?

I am wondering if there's a way to have some kind of unattended boot process along with an encrypted disk, as long as there's a tpm chip in the host.

It is possible if a bit convoluted [1, 2]. When I looked into it last year it seemed the good guides were focused on Clevis & Tang with a separate server (i.e. your PC at home on your network would boot but if away from the Tang server the PC would fall back to password). In a quick look it seems they may simply support TPM2 now although I haven't looked into how/if this is different to the article.

[1]: This is older with TPM1.2, but is the 'autoboot' similar to Windows BitLocker, https://ranzbak.nl/tpmluks/ [2]: https://blog.dowhile0.org/2017/10/18/automatic-luks-volumes-... [3]: https://redhat.slides.com/pladd/securing-automated-decryptio...

this is exactly the feature that's now possible with systemd too

Interesting, I wonder if if you can do PIV or Fido2 unlocking without systemd also?

Seems like some more feature creep from systemd.

I don't really understand this feature creep argument against systemd. I mean, this is not like this is a feature included in PID1, it is a new binary so a separate feature (and I am pretty sure that you can choose to not compile it too if you don't want, like almost any other systemd feature with the exception of systemd itself and journald).

Also, the way I understand systemd nowadays is it isn't an init system, it is an API for Linux systems that abstracts low level features in kernel in a consistent way (either using unit files or systemd C interface). It has an init system because it needs control from early boot so it can offer a nice interface for services. Ditto for dbus, mount system, timers, logging, etc. You can use as much or as little as you want, but if you choose not too you need to invent your own way (that was what most distros used to do before systemd).

Also, integration between those subsystems (say, init systemd and cron) was basically writing glue code, while in systemd world they're meant to be integrated (unit files of any type can depend of each other, so you can have a service that depends on a timer, a disk mount and a udev event, for example).

So yeah, you may not like the way that systemd does things, but at least use valid arguments like the fact that things are more opaque (but this is understandable, this is an abstraction layer), or that the declarative approach of systemd makes some things harder (true enough, but you can always fallback to use scripts and you still have all the power of systemd dependency system).

> I don't really understand this feature creep argument against systemd.

> Also, the way I understand systemd nowadays is it isn't an init system, it is an API for Linux systems that abstracts low level features in kernel in a consistent way (either using unit files or systemd C interface).

Starting as an init system and becoming a general API that abstracts low level kernel features seems like feature creep.

> You can use as much or as little as you want, but if you choose not too you need to invent your own way

Correct. The problem arises when you try using tools not provided by systemd in conjunction with systemd and systemd actively makes that hard. The accepted solution to that problem in the systemd world is to rewrite more tools the way systemd sees fit with the side effect of extinguishing every other approach and dragging linux further away from its BSD/Illumos cousins. This is again a form of feature creep.

Don't get me wrong. I think the tooling available 15 years ago mostly sucked and there was definitely a need for something new. I just don't believe cleaning a mess with a giant monolith is the way to go.

> Starting as an init system and becoming a general API that abstracts low level kernel features seems like feature creep.

I think the initial presentation of systemd as a faster init system hurt it more than helped, because people started to think that systemd "was just an init system". And it never was really, even early on there were blog posts showing how powerful was its declarative approach. But it seems that the only blog post people remember is the "faster init" one (that even this one did more emphasis on the fact that systemd did dependencies the right way them the fact that it was fast).

> every other approach and dragging linux further away from its BSD/Illumos cousins

The way I think about systemd is that it make it closer to the approach of BSD and other *nix systems does. Portability is never something easy, specially when you're doing complicated things like power or network management. A good example is that all the different BSDs have difference between on how you manage networks, and the way it was on Linux before systemd was that *every* distro reinvented their own network management system (and each one was slightly broken in some fun way).

So what systemd does? They standardized everything. Now if your distro uses systemd-networkd, you can finally write a service that depends on a specific network topology that is portable across multiple Linux distros.

BSD don't need something like systemd because they're already tightly integrated, because the kernel and user space is both developed by the same team. Each part of a Linux user space used to be developed by different people, and it was the work of the distro to integrate everything. Now systemd provides a good foundation for many things in user space, and most distros stopped to ship their own solutions except for package management and some other integration bits that they need for their specific purposes.

So if you say to me that systemd is feature creep, it is as much feature creep them the whole FreeBSD or OpenBSD. And this just doesn't make sense.

> I don't really understand this feature creep argument against systemd. I mean, this is not like this is a feature included in PID1, it is a new binary so a separate feature (and I am pretty sure that you can choose to not compile it too if you don't want, like almost any other systemd feature with the exception of systemd itself and journald).

AFAIK systemd and the different components has so many internal dependencies on each other than not much works if you try to pull things apart. You can remove systemd completely, yes, but try to only have systemd as an init system and nothing works!

Unless you give me a more concrete example, I don't really think this is true.

For example, right now neither my desktop nor my notebook uses `systemd-networkd` and it works fine. Actually, since I use NixOS even basic things like `hostnamectl` or `timedatectl` are "disabled" (they work in read-only mode since those configs are managed by NixOS). But I do use `systemd-bootd` (so I can get boot information from the early UEFI until user space, try doing the same thing with GRUB+sysVinit).

The only two components that I know it can't be disabled in systemd is the init part and journalctl (because all the other parts of systemd depends on it).

Systemd is a horrific abomination at this point it just never ends...

The "horrific abomination" turned a process of trial and error and custom shell scripts full of low-level, platform-specific commands into a single, consistent interface. I don't see the downside?

For me, the difference is simple. Systemd is great when it works. But, part of the value of the Unix philosophy is resiliency in the face of errors.

When my void Linux / alpine Linux systems have internal failures, I can troubleshoot and solve them because the system is composed of minimal abstractions tied together - I can feasibly deduce the root of the problem, and fix it, even if half the OS is missing.

With systemd, it's one big mess. Problems are far more opaque, and the pieces are far more interdependent: it's easier to wipe and start over, thereby treating the os as a black box, than to dig in and find the problem.

I avoid systemd systems wherever I need to do anything with the os itself that isn't extremely ordinary.

Are you sure it's not just familiarity with old tools? Systemd works pretty hard to put logs in one place (journald) - even ones from service start-ups. And any dbus interaction can be traced by listening to the system bus. Is that a mess compared to the old bunch of separate log files and errors lost if they don't activate their logging interface early enough?

I'm not talking about reading logs. (Which, by the way, is a lot easier to do in a dead system when they're text and not binary. It's hard to mess up cat, grep, and notepad.)

I'm talking about being able to rule out causes because the primary components of the system are independent of each other.

> is a lot easier to do in a dead system when they're text and not binary

The binary format doesn't matter for browsing logs. Replace `cat /your/custom/service/file.log | grep ...` with `journalctl -u service | grep ...` (or just `-a` for everything)

I'd actually argue it's easier not to mess up with journal with simple tools, because you don't have to special-case `service`, `service.1`, `service.2.gz` files.

For a dead system with it's main disk mounted on a living one, on which the service is not registered, is it that easy?

I've never tried.

I like service files, but the rest not so much.

journalctl -D /mnt/othersystemroot/var/log/journal <...>

I tinker on my gentoo box and OpenRC is more than capable of everything it needs to do. I don't understand why people's linux fill up with "trial and error custom shell scripts".

Can someone explain why non-systemd systems are claimed to be full of broken shell scripts? I've yet to experience that.

It's not that your system fills up with them from your side. It's that the old approach of not-very-synchronised shell scripts is very fragile and sometimes arrived to via trial and error. And many services carry their own custom implementation of those.

For example mysqld_safe is there pretty much to handle things that systemd can do, but initd can't. Some other services have custom wait-logic to make sure dependencies are ready, which is covered by service readiness notification in systemd (see just yesterday https://news.ycombinator.com/item?id=25845143). Many services do custom pidfile handling (see the fun implementation in openssh init file - your pidfile path better not have `=` in it) just because initd has no idea of services.

Basically every service I've seen which has more than a single line in start and stop functions in broken is at least one subtle way. (and close to every single status function - no, existence of the pidfile and that pid running an undefined process is not the same as service functioning) Systemd provides 99% of what those init scripts try to achieve as simple configuration and if something's missing you can still fall back to executing a script instead.

It is a straw man that people use to try to try to make systemd seem like a solution, the only issue is that the problem never actually existed, just like people who try to argue that "x is dying or not attracting enough new users" in order to try to present a change they want to make as some how "solving" the problem of users leaving (e.g. "we should switch development to github"). When you look at the numbers and look at the existing systems, the stories are a complete fabrication to try to prop up a fallacious argument or process, tool, or project that is usually worse than what is really out there, not what its proponents claim is out there.

for me the downside is mostly when I am forced as user to everything the 'systemd --user' way. All I have are mpd, dbus, pulseaudio, mako which I can easily run from my sway/config (the script that starts sway or xinitrc whatever) and I do not need systemd and journalctl and all the tooling that I'm then also buying into. This is IMO an annoyance where I think systemd is creeping in too much.

From a developer pov I'm optimistic. systemd seems to be positioning itself as a isolation technology. It gives me a simple and effective way to ship security controls that the user themselves would not be able to do with this granularity (well normally) and it's part of the package / installer (e.g. by default hardened because why bother the user?). And the process for me as dev is really simple too (see below).

It gives me additional options rather than just hope everyone will use firejail and apparmor (even on a debian sid apparmor userspace is too permissive or not properly maintained - firejail is better but rare).

some simple things that can be dumped into a systemd.service file (source https://www.redhat.com/sysadmin/mastering-systemd) to ensure hardening isolation/hardening is always shipped with the package.

  RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 AF_NETLINK
  SystemCallFilter=sendmsg recvfrom sendto getpid prctl brk socket read stat openat rt_sigaction fstat bind close connect getsockname setpriority capset getpriority lseek mmap mprotect munmap access execve getuid capget arch_prctl gettid

As an elitist user, sure firejail is great - but I would not install firejail on my 72 yro aunt Debian laptop (because many reasons :))

>All I have are mpd, dbus, pulseaudio, mako which I can easily run from my sway/config

The thing is, you want service management here. Sway is not a service manager and won't handle monitoring of the processes, socket activation, logging, etc.

> platform-specific commands into a single, consistent interface

Consistent interface that only works on one platform and uses all the platform specific commands imaginable to do things that have no reason to be platform specific. And it doesn't even play well with other parts of that same platform.

>to do things that have no reason to be platform specific.

If you ever try to port systemd code to non-Linux platforms you will see that this is not true. There are lots of things in Linux that have no real analog on other platforms, and it seems strange to fault a project for taking advantage of those. (BSD is the same way when you get into that too)

Systemd is here to stay at this point. It's not ideal(I much preferred sysV, and then preferred upstart...and so on), but it's what we have. It's also improved greatly from the initial state we received it in.

What specifically irks you about it? When I'm honest with myself, I realize my biggest objection to systemd was "change". I was comfortable with something, it changed, and I resisted it. Once debian finally gave out and switched to systemd, I saw the writing on the wall and drank the kool-aid. I haven't had any regrets.

Not to derail, but I've mostly gotten to just living with it.

I feel like it was mostly a missed opportunity to do things better; the declarative unit stuff is both over and underspecified, and for anything nontrivial, I always end up with sidecar scripts, anyway, which makes the whole thing just a game of useless boilerplate.

And then it started attempting to assimilate other daemons...

Like I said, it is what it is. But what it is is a barely competent make-work replacement for something that wasn't the worst problem in early-startup, anyway.

Yeah this is my exact sentiment. It took a lot easy things and made them require more boilerplate overhead. I'm sure its great for some use cases, but I've never encountered them. I actually like the idea of having a more consistent way to administrate the system, and for some thing systemd does great. But it also involved a lot of real head-scratcher decisions. (What problem was binary log files trying to solve?)

And screw unit files. Is there a helper utility to write and place the unit files for me? That would make me actually shutup about systemd.

Journald stores a lot of metadata and it is difficult to effectively store metadata without having some kind of structured format. (And before someone says it, storing JSON on disk or trying to split the metadata across files would probably be much worse than binary logs)

I am honestly surprised we haven't seen a good GUI pop up around systemd yet that allows for simple service creation and configuration like that.

I concur. Here, read my take on systemd:


Whew, thank goodness for "View > Page Style > No Page Style" as that is some geocities-esque CSS on that page

If others were similarly curious, the "/index.html" isn't pedantry, just navigating to "/" is a separate welcome page that shortly thereafter redirects to the freedesktop.org site

> "View > Page Style > No Page Style"

Just turn on reader-mode in your browser. Or prefix the url with `about:reader?url=`.

> that shortly thereafter redirects to the freedesktop.org site

Specifically, it redirects to the systemd documentation part of the freedesktop.org site. There's also a bunch of other documentation redirects for the stuff I use. That's what index.html describes.

Try finding the documentation online to write a systemd service. Google finds tons of useless results and good luck remembering the freedesktop.org URL for systemd documentation (or even knowing that it's the _freedesktop.org_ link that is authoritive), or try navigating their landing page. It's a f#$%ing nightmare!

Just go here instead. https://systemd.software/service. Super short and easier to remember and easier to discover than `man service` oh wait I mean `man systemd` wait no I actually mean `man systemd.service` because `man systemctl`. Wait where do I even put the .service file???

>Try finding the documentation online to write a systemd service. Google finds tons of useless results [...]

The correct page is literally the first result on ddg and google for `man systemd.service`, or even just `systemd.service`. Same for all the other `systemd.*`

This isn't even new; I've been searching `man systemd.service` and `man systemd.socket` for years to reach those same pages.

You have to know that you're looking for `systemd.service` in the first place.

If you search for `man service` you get linked to SysV init scripts [0] and are led astray if you don't know that sysv init scripts aren't systemd.

If you search for `man systemd` you get linked to a huge man page [1] which isn't approachable to a novice. There isn't an `EXAMPLE` section like there are on other man pages and searching for `example` doesn't reveal any commands to run. It doesn't describe where you can find an example service (unless you magically know that a "system unit" is a service and there's even a gotcha to that: it doesn't have a `files` section to describe where files are at (contrast with `man ssh_config` or `man nginx`) and it is absolutely not clear that the directory is hidden behind an obscure `pkg-config` invokation. Good luck discovering other services you can learn from by reading their service files!

If you managed to do `man systemctl` [2] you reach equally poor documentation. Again, no `files` section and this time not even a mention of `pkg-config`. There's a ton of mentions of environment variables (why does the _system_ need environment variables???). It describes how to "list" units but doesn't describe that it _won't_ list your user units (or, won't list the system units if you do --user). It doesn't describe how to _create_ a unit. It doesn't clearly walk you through the steps (again, there are no examples) so it's up to you to figure it out and hope you don't fuck up your system.

If you search for "just" `systemd`, you arrive at systemd.io [3]. Again, this site is not approachable to a novice! There's just lots and lots of reading. A _lot_ of reading. There's a few "examples" scattered everywhere in the form of an example command to run and a description of what it does. But _nowhere_ is there a single example with everything tied together into a single Hello World style solution.

[0] https://linux.die.net/man/8/service

[1] https://man7.org/linux/man-pages/man1/systemd.1.html

[2] https://man7.org/linux/man-pages/man1/systemctl.1.html

[3] https://systemd.io/

>You have to know that you're looking for `systemd.service` in the first place.

Yeah, because that's the thing you want help with.

No shit `man service` and `man systemd` aren't going to give you help for systemd services that easily.

Also, apparently you assume the user is simultaneously stupid enough to not put "systemd" and "service" in the same search query, but is meant to know to visit `https://systemd.software/service` even though it too contains both those words.

> Yeah, because that's the thing you want help with.

No it isn't. I, as a power user and only as a novice system administrator, want to "run a program at startup".

It's not clear to me that it's `systemd` that manages that. It's not clear to me that it's specifically `systemd.service` that I need to find help with.

> No shit `man service` and `man systemd` aren't going to give you help for systemd services that easily.

But... why???

> Also, apparently you assume the user is simultaneously stupid enough to not put "systemd" and "service" in the same search query

Yes, I do assume that because it describes me. I'm sorry you think I'm stupid though. Get off your high horse and start thinking of people with different experiences than yours.

> but is meant to know to visit `https://systemd.software/service` even though it too contains both those words.

Searching Google for `systemd service` puts a link to freedesktop.org with a very un-memorable URL. I didn't even understand that "freedesktop.org" is the authoritive site until a few weeks into learning systemd. I definitely won't remember to type in "freedesktop.org/software/" before trying to find systemd documentation. And I don't want to have to use Google as a relay every time I want to read the documentation for systemd.

So I made a site that does it for me.

Can't get there using Chrome (v.69) on a Chromebook: "systemd.software uses an unsupported protocol. ERR_SSL_VERSION_OR_CIPHER_MISMATCH"

I see absolutely no use for this what so ever. I wish systemd would just concentrate on being an init system rather than being a Swiss army knife! GRUB and cryptsetup handles unlocking just fine!

Not sure, why you're being downvoted. Perhaps it's the tone and lack of enthusiasm for all things systemd.

In the matter, I agree. I'd think unlocking of the filesystem ought to be happening in the boot-loader (either GRUB or ROM resident). Systemd will only be able to do so, if the root fs (typically holding /etc with plenty of stuff worth protecting) is unencrypted. It seems to me this feature was added to systemd just because they can.

Grub is basically a second OS. People who say 'systemd is large and should just do one thing' and then say 'this can be solved with GRUB' blow my mind.

Sorry, didn't mean to promote grub, which sure has its own issues.

If the boot-loader is meant to decrypt the root fs however, it won't be trivial and GRUB might be the best bet. At least it isn't listening on network ports ...

Applications are open for YC Summer 2021

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact