Re: Activating second crypted (or other raid) device
On Sun, May 05, 2019 at 05:41:38PM -0400, trondd wrote: | It's really not that big of a deal to call 'fsck' and 'mount' yourself in | rc.local. It's not, but it would be nice if this could be done automatically somehow, for services that start at boot (e.g. httpd) that need data on other softraid crypto devices. Doing an `rcctl restart httpd` in /etc/rc.local right after the fsck and mount seems a bit silly. | Unless you have system data on /srv (which would be it's own inconsistency | with a standard system) needed during rc. How about a huge /var/www or /var/ that's not on your primary softraid crypto device? | In fstab, I set the RAID partition to noauto and disable automatic fsck. | Then in rc.local call 'bioctl blah && fsck UUID.partition && mount /srv' | | I use a password so it's interative for me and I see if anything goes | wrong. Log a message with 'logger' or send an email or whatever if | something fails for your situation. Then you're done dealing with this. I use the -p option to bioctl in a hotplugd(8) attach script to automatically mount partitions on hot-plugged (USB) disks that use softraid crypto. Having a way to do this for extra disks at boot is something I've briefly looked at in the past but didn't find a nice solution for. Maybe Matthew finds something interesting :) Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: Activating second crypted (or other raid) device
trondd writes: > On Sun, May 5, 2019 3:57 pm, cho...@jtan.com wrote: > > My goals are: > > > > * /etc/rc already handles fsck of plaintext devices mentioned in > > /etc/fstab. > > * /etc/rc already handles mount of plaintext devices mentioned in > > /etc/fstab. > > * I would like to activate an encrypted/RAIDed device before /etc/rc > > performs > > either of those (so that code somebody else has written can do them > > for me). > > * /etc/rc.local is called too late. > > > > It's really not that big of a deal to call 'fsck' and 'mount' yourself in > rc.local. Sorry I guess I wasn't clear. I know I can use /etc/rc.local to do the post-bioctl steps but that's boring; if I only wanted to get the partition mounted I wouldn't have emailed. The idea here is to also fool around with the system for shits and giggles to see if any new knowledge falls out. It's my personal laptop, I know the risks and I can pick up the pieces if it all falls apart. I would like to to find way to fit my custom system into the same subsystems and process that already exist to bring a standard system up. I couldn't see anything in /etc/rc which would do this which is why I customised mine but I would like to know if I've missed something in there or if there's something elsewhere I don't know about that would activate softraid volumes based on some configuration file. If not then I also want to gauge thoughts on adding the ability bring up softraid devices declaratively (and at the correct boot stage) similar to how other devices are configured using eg. fstab, ttys, hostname.*. Cheers, Matthew
Re: Activating second crypted (or other raid) device
On Sun, May 5, 2019 3:57 pm, cho...@jtan.com wrote: > Thomas Frohwein writes: >> On Sun, May 05, 2019 at 08:57:55PM +0300, cho...@jtan.com wrote: >> [...] >> > Currently after every upgrade I patch /etc/rc to run /etc/rc.blockdev >> > (containing bioctl -cC -p /etc/sd0.key -l sd0a softraid0) before the >> > additional filesystems are checked or mounted. >> >> > The problem with rc.local is that it's not executed until after fsck and > mount have parsed /etc/fstab (or /etc/fstab has been parsed for them; > whatever). If they do this before sd3 exists they at worst abort and at > best don't perform their desired function on the previously-encrypted > block device (ie. the plaintext block device is not scanned and mounted > automagically and my computer boots without a /srv). > > > My goals are: > > * /etc/rc already handles fsck of plaintext devices mentioned in > /etc/fstab. > * /etc/rc already handles mount of plaintext devices mentioned in > /etc/fstab. > * I would like to activate an encrypted/RAIDed device before /etc/rc > performs > either of those (so that code somebody else has written can do them > for me). > * /etc/rc.local is called too late. > It's really not that big of a deal to call 'fsck' and 'mount' yourself in rc.local. Unless you have system data on /srv (which would be it's own inconsistency with a standard system) needed during rc. In fstab, I set the RAID partition to noauto and disable automatic fsck. Then in rc.local call 'bioctl blah && fsck UUID.partition && mount /srv' I use a password so it's interative for me and I see if anything goes wrong. Log a message with 'logger' or send an email or whatever if something fails for your situation. Then you're done dealing with this.
Re: Activating second crypted (or other raid) device
Thomas Frohwein writes: > On Sun, May 05, 2019 at 08:57:55PM +0300, cho...@jtan.com wrote: > [...] > > Currently after every upgrade I patch /etc/rc to run /etc/rc.blockdev > > (containing bioctl -cC -p /etc/sd0.key -l sd0a softraid0) before the > > additional filesystems are checked or mounted. > > The order of sdX may change if e.g. a USB drive is plugged in during boot. You > know you _can_ use the device UUID which AFAIK should be much more robust than > using sdX. I used the following line at some point in an rc.local: > > bioctl -c C -l b3914b7ba0818788.a softraid0 I was unaware I could supply UUIDs to bioctl. Thanks. I'm know of the danger of USB (and SD, etc.) insanity wrt device node names. I simply make sure to never turn my laptop on with weird shit plugged in to it. Seems like a safe bet. > > Before I resign myself to patching /etc/rc in perpetuity, is there a > > better or more canonical way to activate a second encrypted disc using a > > key file in /etc before filesystems defined in /etc/fstab are checked or > > mounted (it becomes /srv)? > > That would be rc.local. From rc(8): > > Normally, rc.local contains commands and daemons that are not part of > the stock installation. The problem with rc.local is that it's not executed until after fsck and mount have parsed /etc/fstab (or /etc/fstab has been parsed for them; whatever). If they do this before sd3 exists they at worst abort and at best don't perform their desired function on the previously-encrypted block device (ie. the plaintext block device is not scanned and mounted automagically and my computer boots without a /srv). > > The patch I use is below. Ignore the date; I've been using this since > > around 6.2 at least. I feel rather silly saying that you're welcome to > > use this tiny patch if it's useful, but there it is and you are. > > I empathize with your drive to get hands-on with the code to find a solution > to > a problem and the desire to share it, but the solution you are proposing > should > be discouraged. You are proposing a trivial 1-line patch to a file that isn't > meant to be patched; ignoring the man page that contains a valid place for > local customizations. I completely understand why such a non-standard patch is capital-W-Wrong. Developers and manglers believing otherwise are the bane of my existance which is why I'm in NO wise suggesting this should be immediately incorporated (perhaps I should have made that clearer in the previous email - if you don't know how OpenBSD boots from init to rc to getty then this patch is Not For You; it was included mainly so that those who understood it would be able to skip my waffle and zoom in on the actual question). My goals are: * /etc/rc already handles fsck of plaintext devices mentioned in /etc/fstab. * /etc/rc already handles mount of plaintext devices mentioned in /etc/fstab. * I would like to activate an encrypted/RAIDed device before /etc/rc performs either of those (so that code somebody else has written can do them for me). * /etc/rc.local is called too late. Currently I achieve these goals with a simple (for me) patch on a single machine's /etc/rc. I would love to hear of a better way or, if there isn't one, try to come up with one that everybody can be happy with. > For yourself, the closer you stay to the default install especially in regards > to infrastructure like rc(8), the less likely you will run into bugs that are > not reproducible by others. I have no problem with deviating from the standard. I know what I'm getting myself into and I know how to forge the pieces back together again :) I should probably come clean and point out that, having read /install.sub and /etc/rc et al. inside, outwards and sideways, I'm pretty sure that no such mechanism to mount RAID volumes prior to fstab-parsing exists but if I'm wrong then please tell me. Alternatively if there's any other interest than mine in creating one then I have opinions and am happy to do the legwork, I only need a bit of a leg up to make sure I remain within OpenBSD's coding guidelines etc.. Cheers, 'm not you're average noob, Matthew
Re: Activating second crypted (or other raid) device
On Sun, May 05, 2019 at 08:57:55PM +0300, cho...@jtan.com wrote: [...] > Currently after every upgrade I patch /etc/rc to run /etc/rc.blockdev > (containing bioctl -cC -p /etc/sd0.key -l sd0a softraid0) before the > additional filesystems are checked or mounted. The order of sdX may change if e.g. a USB drive is plugged in during boot. You know you _can_ use the device UUID which AFAIK should be much more robust than using sdX. I used the following line at some point in an rc.local: bioctl -c C -l b3914b7ba0818788.a softraid0 > Before I resign myself to patching /etc/rc in perpetuity, is there a > better or more canonical way to activate a second encrypted disc using a > key file in /etc before filesystems defined in /etc/fstab are checked or > mounted (it becomes /srv)? That would be rc.local. From rc(8): Normally, rc.local contains commands and daemons that are not part of the stock installation. > The patch I use is below. Ignore the date; I've been using this since > around 6.2 at least. I feel rather silly saying that you're welcome to > use this tiny patch if it's useful, but there it is and you are. I empathize with your drive to get hands-on with the code to find a solution to a problem and the desire to share it, but the solution you are proposing should be discouraged. You are proposing a trivial 1-line patch to a file that isn't meant to be patched; ignoring the man page that contains a valid place for local customizations. For yourself, the closer you stay to the default install especially in regards to infrastructure like rc(8), the less likely you will run into bugs that are not reproducible by others.
Activating second crypted (or other raid) device
I have a laptop with two hard drives, a small fast ssd and a large slow hdd (since replaced with a larger fast ssd). Both drives are encrypted using bioctl. sd1 is the smaller boot device which becomes sd2, sd0 is the larger device which becomes sd3. sd2 is activated before the kernel by the bootloader after I successfully type in the password. sd3 is activated during the boot phase using (only) a key in /etc/sd0.key. Currently after every upgrade I patch /etc/rc to run /etc/rc.blockdev (containing bioctl -cC -p /etc/sd0.key -l sd0a softraid0) before the additional filesystems are checked or mounted. Before I resign myself to patching /etc/rc in perpetuity, is there a better or more canonical way to activate a second encrypted disc using a key file in /etc before filesystems defined in /etc/fstab are checked or mounted (it becomes /srv)? The patch I use is below. Ignore the date; I've been using this since around 6.2 at least. I feel rather silly saying that you're welcome to use this tiny patch if it's useful, but there it is and you are. Incidentally the real patch also also runs /etc/rc.early immediately after rm -f /fastboot in order to move X to vt12 and open up vts 5 to 11 because I couldn't find any other way to hook into the boot process early enough but I suspect I'm on my own with that one. (The command to do that, if anyone's interested, is for c in 6 7 8 9 10 11; do wsconscfg $c; done and you also need to update Xservers and ttys). Matthew --- rc.orig Sun Jan 6 10:49:26 2019 +++ rc.mine Sun Jan 6 10:52:03 2019 @@ -353,6 +353,8 @@ exit 0 fi +[[ -f /etc/rc.blockdev ]] && sh /etc/rc.blockdev + # Add swap block-devices. swapctl -A -t blk
