Potential improvement / replacement for clevis systemd unlocker

[jmarcelletti]

I had to make this for a couple of reasons, but I thought it may be of interest. If you want to review and see if this would make sense please let me know and we can work on a PR:

https://github.com/jmarcelletti/clevis-unlock

TLDR: Instead of using askpass, this will get involved and attempt to unlock any clevis based data (non root) drives. It does so without passing things around between FIFO's and has built-in retry. There's some settings in here that could be tweaked depending on the users environment, but I felt it worked better for us than the provided solution. I have not tested this on anything outside of ubuntu 16.04/18.04/20.04, but I see no reason it wouldn't work on RHEL/centos.

[XueSheng-GIT]

Thanks for providing this unlocker! I was trying to to unlock zfs disks (non-root) and failed with both clevis-initramfs and clevis-systemd on Debian buster. Your approach seems to work pretty fine for this case! But I had to uninstall clevis-initramfs because of ordering cycle errors during startup:

systemd[1]: sysinit.target: Found ordering cycle on cryptsetup.target/start
systemd[1]: sysinit.target: Found dependency on systemd-cryptsetup@scsi3\x2dpart1_crypt.service/start
systemd[1]: sysinit.target: Found dependency on cryptsetup-pre.target/start
systemd[1]: sysinit.target: Found dependency on clevis-unlock.service/start
systemd[1]: sysinit.target: Found dependency on basic.target/start
systemd[1]: sysinit.target: Found dependency on paths.target/start
systemd[1]: sysinit.target: Found dependency on clevis-luks-askpass.path/start
systemd[1]: sysinit.target: Found dependency on sysinit.target/start
systemd[1]: sysinit.target: Job cryptsetup.target/start deleted to break ordering cycle starting with sysinit.target/start

Does your approach replace clevis-systemd completely? Maybe I could have tried to uninstall this package instead of clevis-initramfs!?

[jmarcelletti]

Hello,

We experienced the same issues with the boot order looping on 16.04 and 18.04, however, it was just log noise in our experience, we did NOT have any real-world impact because of it.

In 20.04 the messages are gone.

My package does replace clevis-systemd completely, however, we leave it installed because it does not harm anything. I intend on submitting a patch to clevis-systemd that will make it retry talking to Tang forever. My package does not retry forever because it has no prompt (meaning if you needed to enter with a password mine would block if I made it last forever). At this time I think the right answer is to run both. Mine should have 99% of the situations and just work cleaner, but the other product allows a prompt to come up and a human to be involved. In our setup, we have over 20 Tang servers backed by various technologies (anycast, dns rr, proxy) to ensure that we can get a system online.

RE clevis-initramfs: We could not uninstall this because we also protect our root volumes, so if you aren't doing that I don't see a reason to have it.

[jmarcelletti]

I forgot I had shared this until I was randomly browing Clevis issues. I'll note while it was noise, it was annoying and you shouldn't have to uninstall their unlocker. I have updated the systemd service file to ours which works without the loop.