Systemd broke a use case that people were actively using, and cryptsetup comes with scripts to support.
There were complaints about this four years ago, you rejected a patch that would have resolved it, and it still has not been addressed. If you won't merge the patch that addresses this, can you explain what needs to be done to support the "use some administrator defined program to supply the password" use case that you will merge? Depending on the scope, I may be able to write the code. Is there any way this can be done with a wrapper so that people don't have to maintain two versions of their programs? On Wed, Oct 19, 2016 at 2:27 PM, Lennart Poettering <lenn...@poettering.net> wrote: > 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
