On Mon, 16 May 2011 22:35:12 -0300, Henrique de Moraes Holschuh <h...@debian.org> wrote: > Then, 'stop' tries to close all managed crypto devices and aborts *with > an error* if it cannot. 'Start' tries to open all managed crypto > devices, and aborts *with an error* if it cannot. > > And 'restart' should not be supported, and return with the appropriate > error, or it could just be stop+start. You likely don't want to run > this on package upgrades. > > You'd still have to call 'stop' and abort the package removal in prerm > [when removing the package. You will have to diferentiate the various > reasons for why prerm is called] if it cannot close all crypto devices > it manages. And 'start' on postinst, of course.
I'm not totally sure why, but also don't like the idea calling these from the maintainer scripts. Especially (but I'm not sure on this) as it might ignore any non-crypttab-managed dm-crypt devices. Still, the IMHO best solution would be: - let any scripts fail with $? != 0 if the action they're expected to perform failed => this however does not comply with the crude Debian init-scripts policy AND - if cryptsetup is removed OR purged, give a big fat debconf-prio-low warning that devices a b c are still open, and cannot be closed using cryptsetup, if the user decides to continue. Then we've warned/instructed the interactive user and we've also secured any (clean[0]) script usage of the scripts within the cryptsetup package. > Well, I think it is not appropriate to even let the package get removed > in the first place if there are devices still open. This would make removal of the package impossible, if you e.g. use dm-crypt for the root-fs. Happy hacking, Chris. [0] Of course we cannot force any users to check the exit codes,.. but this is then really their fault. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/c980f1ea803695b21b3ed29ecc88f...@imap.dd24.net
