eli encrypted providers for zfs raidz1
Marco Steinbach
coco at executive-computing.de
Sun Nov 18 02:25:06 UTC 2018
On Sat, 17 Nov 2018 08:42:18 +0800
Ben Woods <woodsb02 at gmail.com> wrote:
> On Sat, 17 Nov 2018 at 06:36, Marco Steinbach
> <coco at executive-computing.de> wrote:
>
> > I'm trying to wrap my head around on how to avoid a zpool resilver
> > on a non-booting ZFS raidz1 of off four equally sized (GPT)
> > partitions on four distinct drives using eli for encyption.
> >
> > IOW: I do struggle with finding a way to attach all the
> > providers such, that ZFS does not initiate a resilver due to the
> > providers being attached sequentially.
> >
>
>
> ZFS doesn't auto-mount by itself - there are other elements at work
> doing this.
> 1. During boot, the /etc/rc.d/zfs script will call "zfs mount -va" to
> automount any available datasets. Note this only happens once during
> boot (not continuously after boot), and it happens *after*
> the /etc/rc.d/geli script has already attached any geli providers.
> 2. The daemon zfsd(8) was newly introduced in FreeBSD 11.0 will
> online any vdevs as new GEOM devices appear. It also handles other
> devctl(4) events. This daemon is not enabled by default - you have to
> specify zfsd_enable="YES" in /etc/rc.conf if you want this behaviour.
>
>
> I suspect your problem is the second items here. Have you enabled it?
I think what I was seeing was the result of me not being aware of the
geli rc script, and the rc order at boot with regards to zfs.
I didn't use zfsd -- I am not even sure I was aware of its existance.
From the man page of zfsd it looks like it'll help with what until
now was my main worry with ZFS on FreeBSD: Commands not returning,
forcing a reboot, due to devices dying or erroring out. I need to
check that with pulling a (USB) drive from under zfs's feet :)
> I've created and initialized the partitions as follows (generic
> > notation, comments on chosen encryption algo welome, since this
> > testing setup lacks AES-NI):
> > # gpart create -s gpt /dev/ada[2-5]
> > # gpart add -t freebsd-zfs /dev/ada[2-5]
> > # geli init -e AES-CBC -l 128 /dev/ada[2-5]p1
> >
>
> I suspect you are just using the [2-5] as shorthand in your email
> here, and not running this exact command on FreeBSD 11.2.
Yes, that was shorthand notation.
> For reference, geli has been updated on FreeBSD 12.0 such that you
> could run this exact command to init multiple providers in a single
> command (they will all use the same password/file with unique salt).
>
>
> > Then I attached the geli partitions like so:
> > # geli attach /dev/ada[2-5]p1
> >
>
> Same for geli attach - this could all be done in the one command like
> this on FreeBSD 12.0.
>
>
> > And finally created a raidz1 spanning all four partitions:
> > # zpool create u0001 raidz1 /dev/ada[2-5]p1.eli
> >
> > That works flawlessly. And naturally, after a reboot none of the
> > encrypted devices is available to the zpool then, unless I attach
> > them.
>
> You can configure the /etc/rc.d/geli script to attach additional
> devices (e.g. non-root ZFS) during userland boot. You can add the
> following to /etc/rc.conf:
> geli_devices="ada2p1 ada3p1 ada4p1 ada5p1"
> This will prompt you to type your password in 4 times during userland
> boot, and each would be attached one at a time.
>
> In FreeBSD 12.0, you can make this only prompt you for your password
> once by putting the following in /etc/rc.conf:
> geli_groups="u0001"
> geli_u0001_devices="ada2p1 ada3p1 ada4p1 ada5p1"
>
Pure gold. I just tried this back and forth on 12-RC1 (and 11.2 minus
the neat provider name expansion), and it does exactly what I'm after.
> >
> > Doing so using geli attach requires me to attach them sequentially,
> > which then results in ZFS resilvering the pool.
> >
>
> This would only occur if there was something automatically onlining
> the vdevs and mounting the datasets, such as zfsd.
>
>
> > So, here's my questions:
> >
> > 1. Is the inavoidable resilver intended behaviour based on current
> > implementation, or am I missing something ?
> >
>
> I suspect this is zfsd working against you in this instance.
>
> 2. In case I use a bootable zfsroot (cudos to allanjude@, I highly
> > recommend his BSDCan presentations on the matter), is there a way to
> > hand over the zfsroot passphrase to eli for automatically attaching
> > other providers ?
> >
>
> The geli attach for root ZFS devices would be handled by the boot
> loader, whilst the geli attach for non-root ZFS devices should be
> handled by the userland /etc/rc.d/geli script.
> Whilst you will need to type in your password separately for root and
> non-root devices, FreeBSD 12.0 at least makes it so you don't have to
> type the password multiple times for non-root devices.
> There might be a way to get the boot loader to handle the non-root
> devices also - I don't have experience with this.
I think I'll start by looking at how encrpyted swap is mounted --
since, oddly, I have 11.2 occassionally ask me again for the eli swap
providers passphrase during boot from a encrypted zroot. The system was
installed using the encrypted swap and zroot option of the installer.
> > Please note, that I'd like to stick as close as possible to what the
> > base system offers for this use-case.
> >
> > MfG CoCo
> >
>
>
> Good luck!
Thank you for your explanations -- much appreciated. I don't think
that stack of new SMR drives likes the look on my face -- time for some
encrypted cold storage testing ...
MfG CoCo
More information about the freebsd-geom
mailing list