I'm not sure what vaultlocker is.
trigger might be appropriate together with a '--settle' flag, if/where
available.
instead of manually opening things, i'd expect crypttab to be adjusted
with `systemctl daemon-reload` re-run to regenerated systemd-cryptsetup@
units and "open" the encrytped device using systemd-cryptsetup@ instance
unit.... However that might be "too" systemd specific for vaultcrypt
upstream...
If one injects uuid onto a drive, it might not generate any kernel udev
events for udevd to react to and create/update symlinks.
It would be nice to have an interleaved log of udev events from udevadm
monitor, to see if there are any events emitted after "format" action is
done. If there are none, then vaultlocker needs to be fixed to trigger
things.
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
** Changed in: cryptsetup (Ubuntu)
Status: New => Incomplete
** Changed in: systemd (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1780332
Title:
vaultlocker does not ensure that udev is triggered to create /dev/disk
/by-uuid/<uuid-in-luks-header> symlink and fails
Status in vaultlocker:
Fix Released
Status in cryptsetup package in Ubuntu:
Incomplete
Status in systemd package in Ubuntu:
Incomplete
Bug description:
When an encrypted device is setup up a UUID (osd_fsid) is passed from
the charm to be used in the cryptsetup command which accepts a UUID to
place into the LUKS header (shown in cryptsetup luksDump <path-to-
block-device>).
https://github.com/openstack/charm-ceph-osd/blob/stable/18.05/lib/ceph/utils.py#L1788-L1804
UUID comes from osd_fsid
https://github.com/openstack-charmers/vaultlocker/blob/8c9cb85dc3ed5dbf18c66a810d189a5230d85c34/vaultlocker/shell.py#L69-L80
# else statement is used here
block_uuid = str(uuid.uuid4()) if not args.uuid else args.uuid
dmcrypt.luks_format(key, block_device, block_uuid) # creates a LUKS
header
# ...
dmcrypt.luks_open(key, block_uuid) # sets up a device with device mapper
decrypting it via dmcrypt
https://github.com/openstack-
charmers/vaultlocker/blob/d813233179bdf2eec8ed101c702a8e552a966f44/vaultlocker/dmcrypt.py#L44-L56
This UUID is visible in blkid output
/dev/sdc: UUID="<luks-header-uuid>" TYPE="crypto_LUKS"
and a udev rule exists to create a /dev/disk/by-uuid/<luks-header-
uuid> symlink (which is normally used for filesystem -> block device
resolution)
https://git.launchpad.net/~usd-import-team/ubuntu/+source/lvm2/tree/udev/13-dm-disk.rules.in#n25
ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{ID_FS_UUID_ENC}=="?*",
SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}"
Where vaultlocker fails is in luks_open command (right after luks_format)
# cryptsetup --batch-mode --key-file - open UUID=<luks-header-uuid>
crypt-<luks-header-uuid> --type luks
because it tries to access /dev/disk/by-uuid/<luks-header-uuid> which
does not exist.
This happens since udev rules are not re-triggered to create this
symlink after a LUKS device is created.
Solution: call the command below after luks_format before luks_open
udevadm settle --exit-if-exists=/dev/disk/by-uuid/<luks-header-uuid-
equal-to-osd-fsid>
To manage notifications about this bug go to:
https://bugs.launchpad.net/vaultlocker/+bug/1780332/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
