On Wed, 19.10.16 11:20, Ryan Castellucci (ryan.castellucci+systemd-de...@gmail.com) wrote:
> What will it take to get keyscript support in systemd-cryptsetup fixed? > > This is a nasty regression for people who were using that functionality, > and it necessitating some pretty ugly workarounds. I understand from > previous threads that there's an aversion to restoring this without some > more generic key handling functionality. I disagree with this stance, it's > a case of "perfect is the enemy of good" - keyscripts work well enough, are > easy to work with, and seem as though they should be easy to implement (I > think I even saw a patch). > > Under older initscripts, I was able to write a very small shell script or > trivial statically compiled C program that does whatever custom > functionality I need to get a password for LUKS and dump it on STDOUT. I > don't want to have to rewrite my existing scripts or deal with anything > more complicated than this. > > I mainly use non-interactive keyscripts, so I've been able to re-implement > the automapping of my encrypted volumes by some ugly udev hackery, but I > have other stuff I've used in the past (for example, requiring a quorum of > admins to enter passwords) for which this doesn't work. It should be possibly to write a password agent that does what keyscripts do, without adding direct keyscript support to systemd-crpytsetup itself. systemd is not supposed to be this conglomerate of pieces glued together with scripts here and scripts there. That makes me very conservative in adding a concept such as "keyscripts" to our tools, natively. Sorry. It's not that we didn't have an API for that, there's just some glue missing to make it work for your use case, but it shouldn't be too hard to write. Sorry, Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
