Initscript dependencies for mdadm raid, luks

[Havin_it]

Hi all,

I've configured a new home server with some mdadm RAID5 arrays, one of which also has luks encrypted partitions (with keyfiles) on top. On it I'll be running a bunch of services that must not start until these volumes are available. I have some experience with init dependencies, so I know about using rc_servicename_need="otherservice" in /etc/rc.conf, but I've not used mdadm or dmcrypt before, so I'm not certain I'm doing things right at that level.

I already have mdadm and dmcrypt in the boot runlevel, but the mdadm seems to already have a default dependency on dmcrypt, when I'd have thought they should be the other way round. Also, what does the mdraid initscript do? Should I use that too? Nothing seems to indicate this script's role. The arrays have so far come up reliably through autodetection anyway...

Essentially, what do I need to ensure 100% that the RAIDs are correctly started, and the luks volumes on top of them correctly mounted, before $otherservices will start?

Thanks in advance

Update: what I have learned so far is that the luks mappings can't be auto-mounted just by putting them in fstab. Nor does putting post_mount='mount /dev/mapper/my_mapping' for each one in /etc/conf.d/dmcrypt. Perhaps I need to actually add my own initscript to take care of this and have other stuff depend on that?

Correction: not *all* mappings get mounted from fstab. The swap volume (which is not luks, just randomised dm-crypt) on /dev/md0 does, but the two Ext4 ones that are on partitions of another array (/dev/md1p1 and /dev/md1p2) don't, even though all three have gotten mapped by dmcrypt at the same time. What's up with that?

[pgu]

[Havin_it]

Hi pgu, thanks for the reply.

No it's not the root partition, that's more grief than I need

So far there hasn't been any problem in practice with dmcrypt because the mdadm autodetection has worked OK (though I've taken the precaution of adding ARRAY definitions to mdadm.conf in case a new kernel decides to rename them). It would be more reassuring, though, to make certain that the arrays were correctly started before dmcrypt, and I'm not sure that my mdadm.conf really guarantees this.

Probably homebrew initscripts are the best way to go for both of us. While awaiting replies I've written one to mount the LUKS volumes, which other services that access the volumes can then depend on. It in turn depends on dmcrypt.

[pgu]

I'm not familiar with dmcrypt, but truecrypt would simply fail (and you could check the return code) when trying to map a faulty or non-truecrypted file system. Would that be possible with dmcrypt?

Alternatively you could add two file systems on your raid device, a small one which is not encrypted where you just keep a file with a simple signature in it. You can then check for the existence of the file and the signature, and if it's there you know you have managed to mount the raid and should be ready to start dmcrypt.

[pgu]