#3147 Issue closed
: clevis luks bind (no clevis support in ReaR)¶
Labels: enhancement
, support / question
, no-issue-activity
Herpgon opened issue at 2024-02-08 01:35:¶
-
ReaR version ("/usr/sbin/rear -V"):
Relax-and-Recover 2.6 / 2020-06-17
-
If your ReaR version is not the current version, explain why you can't upgrade:
Enviroment has no direct internet access. Limited to a Nexus-Repository only. -
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
NAME="Rocky Linux"
VERSION="8.9 (Green Obsidian)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="8.9"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Rocky Linux 8.9 (Green Obsidian)"
ANSI_COLOR="0;32"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:rocky:rocky:8:GA"
HOME_URL="https://rockylinux.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
SUPPORT_END="2029-05-31"
ROCKY_SUPPORT_PRODUCT="Rocky-Linux-8"
ROCKY_SUPPORT_PRODUCT_VERSION="8.9"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="8.9"
- ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
OUPUT=ISO
BACKUP=NETFS
BACKUP_PROG_EXCLUDE=('/tmp/*' '/media/*' '/mnt/*' '/dev/shm/*')
UEFI_BOOTLOADER=/boot/efi/EFI/rocky/grubx64.efi
SECURE_BOOT_BOOTLOADER="/boot/efi/EFI/rocky/shimx64.efi"
USE_STATIC_NETWORKING=y
BACKUP_URL=nfs://10.160.148.128/backups/lukstest2
-
Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):
ESXi 7.0 U2 VM -
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
x86-64 -
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
UEFI Secure boot enabled -
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
Local VMHD -
Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
NAME KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT
/dev/sda /dev/sda disk 256G
|-/dev/sda1 /dev/sda1 /dev/sda part vfat 1G /boot/efi
|-/dev/sda2 /dev/sda2 /dev/sda part ext4 1G /boot
`-/dev/sda3 /dev/sda3 /dev/sda part crypto_LUKS STEELUKS 254G
`-/dev/mapper/luks-76ff4e74-cb27-47d8-b846-a3b6a600fa9e
/dev/dm-0 /dev/sda3 crypt LVM2_member 254G
|-/dev/mapper/rl-root /dev/dm-1 /dev/dm-0 lvm ext4 50G /
|-/dev/mapper/rl-swap /dev/dm-2 /dev/dm-0 lvm swap 16G [SWAP]
|-/dev/mapper/rl-home /dev/dm-3 /dev/dm-0 lvm ext4 33G /home
|-/dev/mapper/rl-var /dev/dm-4 /dev/dm-0 lvm ext4 20G /var
|-/dev/mapper/rl-var_log /dev/dm-5 /dev/dm-0 lvm ext4 20G /var/log
|-/dev/mapper/rl-var_tmp /dev/dm-6 /dev/dm-0 lvm ext4 20G /var/tmp
|-/dev/mapper/rl-var_log_audit /dev/dm-7 /dev/dm-0 lvm ext4 20G /var/log/audit
`-/dev/mapper/rl-tmp /dev/dm-8 /dev/dm-0 lvm ext4 75G /tmp
- Description of the issue (ideally so that others can reproduce it):
I have a LUKS encrypted LVM that can be successfully captured and
restored using rear.
The problem is when I use
clevis luks bind -d /dev/sda2 tang '{"url":"http://tang.srv"}'
to enable NBDE unlocking the rear restore no longer works.
After using clevis to bind the key you have to run dracut in order for
the VM to boot properly as described
here.
I can capture a backup and restore the image but upon reboot the error I receive is:
dracut-initqueue[683]:
Failed to start systemd-cryptsetup@luks\x2d....service:
Unit systemd-cryptsetup@lus\x2d.....service not found
Dependency failed for cryptography Setup for luks-...
I went through this post but
my UUIDs in the crypttab matched fine.
I even set a partlabel on the working VM LUKS partition and modified the
crypttab to use PARTLABEL= instead of UUID but that did not work
either.
Is there a module that is not getting put into the initrd upon restore?
- Attachments, as applicable ("rear -D mkrescue/mkbackup/recover"
debug log files):
rear-mkbackup.log
Herpgon commented at 2024-02-09 21:47:¶
I just wanted to update that I found a workaround for this issue by
using the PRE_BACKUP_SCRIPT and POST_BACKUP_SCRIPT settings.
The pre script unbinds the tang key and then the post script adds it
back.
Seems to work well.
The PRE_BACKUP_SCRIPT is set to run right before the backup phase from
what I understand.
I needed it to happen earlier in the process.
I changed the name and moved
/usr/share/rear/backup/default/010_pre_backup_script.sh
to /usr/share/rear/init/default/001_pre_backup_script.sh
and this ran the script earlier in the process
and I was able to achieve the outcome that is needed.
If there is a better way to change the order of processes, then please
let me know.
Thanks
github-actions commented at 2024-04-10 02:03:¶
Stale issue message
jsmeix commented at 2024-04-10 06:21:¶
@Herpgon
sorry that noone replied to your posting here.
I assume this is because everyone was busy with other issues
and/or noone has sufficient clevis knowlegde or uses clevis.
At least I know nothing about clevis nor did I ever use it.
Currently there is no support for clevis in ReaR
('clevis' does not appear in any ReaR source file).
So what is needed - as far as I see - is adding
at least basic clevis support in ReaR.
As far as I see your workaround is "OK-ish".
ReaR is meant to be adapted for specific use cases
(even with quick and dirty hacks if needed).
If you like to do it and if you would also maintain it
for some reasonable time until basic clevis support
works reasonably well in ReaR, we would appreciate
a GitHub pull request from you that adds basic clevis
support in ReaR.
github-actions commented at 2024-06-11 02:18:¶
Stale issue message
[Export of Github issue for rear/rear.]