Activating second crypted (or other raid) device

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Activating second crypted (or other raid) device

chohag
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

Reply | Threaded
Open this post in threaded view
|

Re: Activating second crypted (or other raid) device

Thomas Frohwein-2
On Sun, May 05, 2019 at 08:57:55PM +0300, [hidden email] 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.

Reply | Threaded
Open this post in threaded view
|

Re: Activating second crypted (or other raid) device

chohag
Thomas Frohwein writes:

> On Sun, May 05, 2019 at 08:57:55PM +0300, [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

Re: Activating second crypted (or other raid) device

trondd-2
On Sun, May 5, 2019 3:57 pm, [hidden email] wrote:

> Thomas Frohwein writes:
>> On Sun, May 05, 2019 at 08:57:55PM +0300, [hidden email] 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.

Reply | Threaded
Open this post in threaded view
|

Re: Activating second crypted (or other raid) device

chohag
trondd writes:

> On Sun, May 5, 2019 3:57 pm, [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

Re: Activating second crypted (or other raid) device

Paul de Weerd
In reply to this post by trondd-2
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/<database_of_choice> 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/