Erwan David wrote: > Bob Proulx a écrit : > >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? :-) > > Coming back after some testing and interrupts... > > No, there is no policy-rc.d script, so it's not the reason. I use a > wheezy, with sysv-init if it makes a difference All I can say is that when I change runlevels it works for me. The start scripts (/etc/rc3.d/S* for runlevel 3 example) all are invoked and daemons launched there are started. I tested this on a pristine installation. If it doesn't work for you then there is something about your system that is different from a pristine installation. Something local. You will need to debug it. Check /etc/inittab and verify that the runlevels are still defined there. > >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. > > I have no central machine on "the network". I want to encrypt > because the machine is hosted, thus I do not physically control it. > And that would leave some problem of booting the key_bearing > machine. This is still some dreamy brainstorming... This would mean that you would need two machines and those should be at different geographical locations. The further apart the better. That way if thieves stole one machine they would not get both of them. Individually each would be useless. The only information on the key_bearing machine would be the keys. As such those would not need to be on an encrypted disk. I wouldn't have that one need to be encrypted. Although you could and also have a way to manually enter the keys so that you could manually bring them up. Then if either machine were stolen you would be able to change the keys on the other machine. They keys are for boot time and not runtime and so compromise of the keys would not compromise the runtime of the system. You would just need to change the keys before the machine booted next. Of course you would need two machines. But for some of us there is always a spare machine somewhere on the net that could be used for this task and so that isn't a hardship. :-) Bob
Attachment:
signature.asc
Description: Digital signature