Hey, On 17/05/2011 Christoph Anton Mitterer wrote: > 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. > > > 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.
I disagree with Henrique here. Christoph is right: It's a bad idea do start/stop the cryptdisks initscript from debian maintainer scripts. This is for several reasons: - cryptsetup is not the only userspace tool which manages dm-crypt devices. Low-level tools like dmsetup, udev, hal; commandline tools like cryptmount and gui applications like gnome-mount etc. might unlock/lock encrypted devices as well. - the cryptdisks initscript only manages dm-crypt devices which are listed in the crypttab. Therefore otherwise unlocked devices are ignored. - for most setups, the solution that Henrique suggested, would mean that cryptsetup fails to be removed/purged. usualle the unlocked dm-crypt devices are mounted if the system is running, maybe even as root filesystem. > 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 Sorry Christoph, but this is simply not an option. > 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. At the moment I consider this as the best solution. Greetings, jonas
signature.asc
Description: Digital signature
