TRITON-1330: joysetup must be aware of zfs encryption


Issue Type:New Feature
Priority:4 - Normal
Created at:2019-03-19T05:45:56.677Z
Updated at:2021-03-26T01:53:34.828Z


Created by:Former user
Reported by:Former user
Assigned to:Former user


Fixed: A fix for this issue is checked into the tree and tested.
(Resolution Date: 2021-03-26T01:53:34.820Z)

Fix Versions

2021-05-20 really tied the room together (Release Date: 2021-05-20)

Related Issues

Related Links




Currently, if one attempts to setup an encrypted CN (using the in-development branches) the filesystem/smartdc will fail because it will be unable to set the dump device. The problem is that dumpadm(1M) does not allow one to use an encrypted zvol for a dump device, so when filesytem/smartdc attempts to set the dump device to the encrypted zvol created by joysetup, it fails, causing the filesystem/smartdc service to fail, preventing CN setup from completing.

Since a dumping/panic context is constrained enough that the normal zfs code (including zfs crypto) is not used, there is no point in changing dumpadm or the kernel to allow the use of encrypted zvols (that is zvols whose encryption property is a value other than off). There is instead a separate effort underway that will perform the encryption of the dump data during the dump process (effectively handling the encryption at a slightly higher level than the zio level). That is not this ticket (it's just to note that protecting the contents of the dump device is being handled in a separate manner).

As such, when joysetup runs on a new to-be-encrypted CN, it must create a non-encrypted dump volume (that is its zfs encrypted property will be off). Since setup can run on a range of PI versions, including ones that will precede zfs crypto support, it must detect if the PI support encryption (currently the only way is to run zpool upgrade -v | grep '^encryption'). If the CN is to be encrypted, joysetup must include -o encryption=off as part of the zfs create command for the dump device.

In addition, when OS-7698 is complete, when setting up an encrypted CN, it should pass the '-e' flag to mkzpool to create an encrypted zpool (instead of an unencrypted zpool).


Comment by Former user
Created at 2019-04-04T22:25:18.455Z

Minor update: a better way to determine if encryption is available (regardless if it's enabled or not) would be:

pool get -o value -pH feature@encryption zones


read encstatus < <(zpool get -o value -pH feature@encryption ${SYS_Zpool}

Comment by Former user
Created at 2019-06-07T14:54:17.396Z

We potentially might also want a way to pass a base64 encoded value for the initial recovery template during setup as well (maybe something like recovery_template=AAAAewwf.....=, but only as an interim measure (or only as part of a demo). Once the gossip protocol is working, we'd want the gossip protocol to manage the recovery templates completely, and no longer allow one to be supplied during setup.

Comment by Jira Bot
Created at 2019-12-19T09:32:02.674Z

sdc-headnode commit 41cf8c7da6821ee97353cdd5d90ccc4550fa4f2f (branch master, by Jason King)

TRITON-1330 joysetup must be aware of zfs encryption