Erwan David wrote: > update-rc.d dovecot disable 2 > reboot, indeed dovecot is not started > telinit 3 > dovecot does not start (even if there is a Sxxdovecot in /etc/rc3.d) Hmm... It should start. I just tested this on a service locally and it starts for me. are you sure it isn't starting due to the presence of a new policy-rc.d script? :-) In any case... I wanted to add an additional comment. I have been thinking of doing something like this myself. I haven't done it yet but if I were implementing this then I think I would have the server contact a central machine elsewhere on the network to get the keys to decrypt and mount the encrypted partitions. I am not sure what the best mechanics would be to implement it. But I think as soon as networking came online I would have the remote server with the encrypted disks contact a different server that I controlled. Have it pull the keys for the partition from there. Then automatically mount the partitions. Then have it continue the boot process normally and start the daemons normally. That way the machine can be rebooted in an automated way without trouble. I would have them go through automatically. Then on a normal reboot the machine would mostly behave normally. But if the machine were stolen it wouldn't be able to get the keys and wouldn't be able to decrypt that disk. Lock the key server to the remote server's IP address. The machine could also block waiting for the external keys and allow you to acknowledge them if you wanted the extra security. After acknowledging them the machine would continue to boot normally. If the machine were stolen then the encrypted partition would not be unlocked automatically since it would then come from a different IP address. However knowing that IP address would give you a trail to the thief. Bob
Attachment:
signature.asc
Description: Digital signature