Автономное картографическое устройство dm-integrity потеряно после перезагрузки
Выяснилось, что в моем случае лучшим способом было сгенерировать.pem на сервере, куда я хотел развернуть файлы.
На сервере (ВМ в моем случае):
1- generate ssh key : ssh-keygen -t rsa -b 2048
2- cat keyName.pub >>.ssh/authorized_keys
3- chmod 600.ssh/authorized_keys
4- create pem file : openssl rsa -in id_rsa -outform pem > id_rsa.pe
На клиенте:
1- get pem file
2- chmod 400 id_rsa.pem
For Testing Purpose :
3- ssh -i id_rsa.pem <user>@<host>
В моем случае я использую Java для развертывания файлов, поэтому я использовал sshjдля отправки файлов с помощью newSCPFileTransfer()библиотеки sshj.
К сожалению, пока это довольно сложно. Автономный DM -Integrity вообще не получил широкого распространения, поэтому стандартного способа его настройки просто не существует.
Вы должны создать свой собственный хук initramfs/службу systemd/скрипт инициализации, чтобы справиться с этим самостоятельно . И каждый раз, когда вы загружаете live CD / систему восстановления, вам также приходится настраивать ее вручную.
Если вы хотите пойти по этому пути, вы должны рассмотреть дополнительные проблемы. Например, резервное устройство не имеет UUID, поэтому его невозможно идентифицировать. Вы можете обойти это, используя PARTUUID или PARTLABEL, но это все еще намного менее надежно, чем обычные UUID.
Так что, хотя это и не невозможно, ожидайте появления различных проблем, которые нужно как-то решить.
Если у вас нет веских причин не делать этого, наиболее практичным способом использования DM -Integrity на данный момент является использование LUKS 2 с включенной дополнительной поддержкой целостности(cryptsetup luksFormat --integrity...).
cryptsetup/LUKS получил широкое распространение. Он предоставляет UUID, необходимый для идентификации резервного устройства, а фаза ранней загрузки уже поддерживается практически везде. Если не считать его начальной настройки, как и любого другого устройства LUKS, вам практически не нужно ничего делать, чтобы заставить его работать.