crypttab
시스템 시작 시( LUKS 파일 키 사용) 자동으로 마운트되도록 두 개의 LUKS 암호화 드라이브를 설정했습니다 . 잘 작동하지만 불행하게도 드라이브 중 하나의 연결을 끊고 이를 내 PC에 다시 연결하면(Fedora 실행) "자동 암호 해독" 프로세스가 실행되지 않으며 수동으로 설치한 후 제거해야 합니다. 시스템 시작 시 systemd가 트리거하는 것과 동일한 프로세스를 트리거하여 메시지가 표시될 때 드라이브가 자동으로 마운트되고 암호가 해독되도록 하려면 어떤 명령을 사용할 수 있습니까? 아니면 실패하면 어떻게 systemd가 자동으로 암호를 해독하고 설치하게 할 수 있나요?
참고로 드라이브를 설정하는 데 사용한 튜토리얼은 다음과 같습니다.https://www.golinuxcloud.com/mount-luks-encrypted-disk-partition-linux/
답변1
의 각 항목은 /etc/crypttab
시작 또는 런타임 시 systemd에 의해 자동으로 systemd-cryptsetup-generator
단위로 변환됩니다 sudo systemctl daemon-reload
. 예를 들어, LUKS 파일 시스템의 UUID가 1111...
(전체는 표시하지 않음) 항목 이라고 가정해 보겠습니다.
mytest /dev/disk/by-uuid/1111... /etc/luks/mykeyfile luks
종속성 등과 함께 파일이 생성됩니다. 새 디스크에 UUID가 나타나면 장치가 실행됩니다./run/systemd/generator/[email protected]
BindsTo=dev-disk-by\x2duuid-1111....device
cryptsetup
/etc/fstab
마찬가지로 systemd의 모든 항목은 자동으로 systemd-fstab-generator
단위로 변환됩니다. 예를 들어, 항목
/dev/mapper/mytest /mnt/mytest ext4 defaults
파일이 존재할 때 /run/systemd/generator/mnt-mytest.mount
(아마도 udev를 통해) 마운트를 생성하는 /dev/mapper/mytest
(에 의해 생성될 ) 파일이 생성됩니다 .cryptsetup
다음 명령을 사용하여 두 장치의 상태를 확인할 수 있습니다.
systemctl status systemd-cryptsetup@mytest mnt-mytest.mount
일반적으로 암호 해독 및 마운트가 성공적으로 완료되면 다음과 같이 나타납니다.
Active: active (exited)
Active: active (mounted)
디스크를 완전히 삭제하려면 먼저 다음 명령을 내리십시오.
sudo systemctl stop mnt-mytest.mount
sudo systemctl stop systemd-cryptsetup@mytest
디스크를 다시 삽입하면 자동으로 마운트됩니다.
이를 수행하지 않고 설치된 디스크를 제거하면 장치가 고장난 상태로 남을 수 있습니다. journalctl -f
메시지를 보려면 systemd 로그를 추적하세요 .
때로는 마운트 해제하지 않고 플러그를 뽑을 때 커널이 파일 시스템의 I/O 오류에 대한 메시지를 표시하지만 파일 시스템을 성공적으로 마운트 해제하고 crypt detach로 장치를 성공적으로 종료합니다. 이 경우 장치를 다시 연결하면 개입 없이 자동으로 성공적으로 설치됩니다.
그러나 때로는 I/O 오류 후에 커널이 파일 시스템을 읽기 전용으로 다시 마운트하기로 결정합니다. 이로 인해 장치가 사용 중이기 때문에 실패하는 crypt detach 명령에 문제가 발생합니다(systemd에 의해 마운트 해제되어야 할 때 마운트됨). 일반적으로 파일 시스템이 마운트 해제되기 때문에 경쟁 문제가 있는 것 같습니다. 장치를 다시 연결하면 암호 해독을 통해 볼륨이 이미 활성화된 것으로 표시되므로 마운트가 트리거되지 않는 것으로 보입니다.
이 경우 중지된 작업의 실패 상태를 지우고 분리 명령을 수동으로 실행하는 것이 작동하는 것으로 보입니다. 장치를 다시 연결하면 암호 해독 메커니즘이 정상적으로 시작되고 설치가 완료됩니다. 명령은
sudo systemctl reset-failed systemd-cryptsetup@mytest
sudo /usr/lib/systemd/systemd-cryptsetup detach mytest
dev-mapper-mytest.device
상태를 확인할 수 있는 장치 도 있습니다 . 분리가 실패하면 활성 상태로 유지되지만 위의 수동 분리 명령을 실행한 후에는 비활성화됩니다.
답변2
(LUKS 위에 추가 LVM 레이어를 다루는 관련 답변은 다음을 참조하세요.https://serverfault.com/a/1120163/582319)
문제는 모든 종류의 "동적" 부착/분리 장치에 대해 기본 장착 메커니즘이 설정되지 않았다는 것입니다.하지만 systemd
(와 함께 udev
) 그러한 기능을 지원하는 데 필요한 모든 메커니즘을 제공합니다...
도구
systemctl show <unit>
, systemctl status <unit>
그리고 udevadm info /device/file
함께 journalctl -e
단위가 서로 연결되는 방식을 이해/검증하는 데 유용/필요합니다.
질문
systemctl show systemd-crptsetup@<luksvolume>.service
기본적으로 활성화된 서비스 단위는 luksvolume
시스템 시작 시 WantedBy=
표준 cryptsetup.target
이며 그 이상은 아님을 나타냅니다.
noauto,nofail
(BTW: 모든 부분을 직접 연결하는 책임이 있으므로 "동적" luks 볼륨에 대해 항상 crypttab 옵션을 추가하는 것이 좋습니다 .)
떨어져 있는
udev를 통해 기본 장치에 서비스 연결
udev
우리가 원하는 것은 장치가 (재)연결된 것으로 확인될 때마다 서비스 장치를 트리거하는 것입니다. 이는 다음과 같은 규칙을 사용하여 수행할 수 있습니다 udev
.
ACTION=="add", SUBSYSTEM=="block", ENV{ID_FS_UUID}=="your-UUID", ENV{SYSTEMD_WANTS}+="systemd-cryptsetup@<luksvolume>.service"
/etc/udev/rules.d/
디렉토리에 위치하며 이름을 지정합니다. 예를 들어 99-usbactivation.rules
장치별 환경 변수 및/또는 속성 값을 쿼리하여 사용하는 것이 중요합니다 udevadm info /device/name
. 이는 ==
일치 항목인 반면 =
(and +=
)는 할당 항목임을 기억하세요.
한 가지 특이한 점(적어도 내 설정에서는)은 새로 생성된 관계가 표시 systemctl show
되지 않는 경우가 많지만 자동으로 표시 되면 작동하는지 알 수 있다는 것입니다 .udevadm info
wants
luksvolume
lsblk
기기를 추가로 조사한 결과 sytemd-cryptsetup@<luksvolume>.service
해당 기기가 기본 기기라는 사실이 밝혀졌습니다 BindsTo=
. 즉, 기기가 사라지자마자 자동으로 중지되므로 이와 관련하여 특별한 조치를 취할 필요가 없습니다.
다음을 통해 서비스를 마운트 지점에 연결합니다./etc/fstab
fstab
마운트 지점은 초기에 생성기를 통해 시스템을 통해 단위 /mnt/foo
로 변환됩니다 .mount
. mnt-foo.mount
번역된 단위 자체는 그 안에서 찾을 수 있는 실제 파일입니다 /run/systemd/generator/
(또는 콘텐츠를 표시하는 데만 사용됩니다 systemctl cat <unit>
). 모든 시스템 단위는 , , 등의 동일한 기본 속성과 , Before=
, 등 의 속성을 가질 수 있으며 , 등 일반적으로 사용되는 도구를 사용하여 검사 할 수 있습니다.After=
Requires=
Wants=
.mount
.device
.target
systemctl show
시스템 단위 파일에 대한 변경 사항(예: 파일을 직접 /etc/fstab
호출하거나 편집하는 등)과 마찬가지로 에 대한 모든 변경 사항 은 호출 후에만 systemd에 의해 선택됩니다 . 마운트 지점의 경우 디렉터리와 포함된 문서가 완전히 다시 생성됩니다. .systemctl edit <unit>
/etc/systemd/sytem/
systemctl daemon-reload
/run/systemd/generator
관련 마운트 지점은 /etc/fstab
다음과 같습니다.
/dev/mapper/<luksvolume> /mnt/foo ext4 defaults 0 2
~처럼마운트 유닛에 대한 systemd 문서선언은 일반적 으로 일반적인 정적/사용자 트리거 설치 및 제거를 에뮬레이션하는 데 충분하도록 systemd에서 필요하고 주문한 속성 과 장치를 BindsTo=
연결 합니다 .RequiresMountsFor=
After=
Before=
x-systemd.after=systemd-cryptsetup@<luksvolume>.service
마운트 장치가 cryptsetup이 작업을 완료할 때까지 기다리도록 특별한 시스템 마운트 속성을 추가해야 합니다 .
마지막으로, udev 규칙에 의해 시작된 "원하는 체인"(내 용어)을 계속하여 cryptsetup 서비스가 마운트 장치를 "시작하고 싶게" 만듭니다. 이는 섹션 요소와 동일한 fstab인 를 사용하여 수행됩니다 x-systemd.wanted-by=
. 이는 에 표시된 대로 마운트 장치 파일에 대한 심볼릭 링크를 사용하여 디렉터리를 생성합니다. 셀은 셀을 생성하기 위해서만 존재하므로 를 통해 이 셀을 처리할 수도 있습니다.[Install]
WantedBy=<unit>
<unit>.wants
/run/systemd/generator
systemd-cryptsetup@<luksvolume>.service
dev-mapper-<luksvolume>.device
x-systemd.wanted-by=dev-mapper-<luksvolume>.device
이 모든 결과는 fstab
다음과 같은 항목이 됩니다.
/dev/mapper/<luksvolume> /mnt/foo ext4 defaults,x-systemd.wanted-by=dev-mapper-<luksvolume>.device,x-systemd.after=systemd-cryptsetup@<luksvolume>.service 0 2
이제 모든 것이 "제대로 작동"해야 하며 드라이브를 제거하더라도 시스템 장치가 순서대로 종료되어야 합니다.
"제거"
모든 관련 유닛은 "상향식"에서 기본 유닛에 의해 "원"되고 유닛 수명주기가 "BindsTo=" 관계(명시적 또는 암시적)를 통해 기본 유닛에 바인딩되므로 비활성화될 수 있습니다. 이것을 systemd-cryptsetup@<luksvolume>.service
통해 systemctl stop
충분할 것입니다.
또 다른 가능성은 사용자 정의 "하향식" [email protected]
유닛을 생성하고 실행하는 것입니다. 이 유닛의 전체 목적은 Conflicts=
필드 선언을 위해 관련 유닛을 사용하는 것입니다. 즉, 사용자가 대상을 실행하면 충돌하는 유닛이 중지됩니다. 이는 단순히 설치 장치를 비활성화하기 때문에 필요합니다.확실히cryptsetup 서비스를 중지합니다. 서비스 단위를 수정하거나 속성을 sytemctl edit
추가하여 이를 수행할 수 있습니다 BindsTo=
. 그러나 관련 장치가 이미 서로 순서대로 실행되고 실행되고 있으므로 대상 장치를 시작하면 이러한 장치가 순서대로 중지되도록 보장할 수 있습니다.
이러한 대상 유닛은 다음과 같습니다.
[Unit]
Conflicts=mnt-foo.mount systemd-cryptsetup@<luksvolume>.service
After=mnt-foo.mount systemd-cryptsetup@<luksvolume>.service
변형: .mount
장치 에 직접 연결
추가 LVM 레이어를 추가하는 방법에 대한 연구 중(다시 참조)서버 장애 답변), 대신 .mount
장치 에 직접 연결하기 위해 개인(LUKS만 해당, LVM 레이어 없음) 설정을 다시 연결했습니다 . udev 규칙은 이제 다음과 같습니다:udev
[email protected]
ACTION=="add", SUBSYSTEM=="block", ENV{ID_FS_UUID}=="your-UUID", ENV{SYSTEMD_WANTS}+="mnt-foo.mount"
입구 /etc/crypttab
:
<luksvolume> UUID=<uuid> /dir/keyfile luks,nofail,noauto
/etc/fstab
이를 통해 특별한 마운트 옵션 없이도 일반 마운트 지점 정의를 제거할 수 있습니다 x-systemd.<opt>
.
/dev/mapper/<luksvolume> /mnt/foo ext4 defaults,nofail,noauto 0 2
유일한 성가심은 기본적으로 다음을 추가하는 새 conf 파일을 생성하는 systemd-cryptsetup@<luksvolume>.service
등의 추가 구성을 첨부해야 한다는 것입니다.systemctl edit systemd-cryptsetup@<luksvolume>.service
/etc/systemd/system/systemd-cryptsetup@<luksvolume>.service.d/override.conf
[Unit]
BindTo=mnt-foo.mount
Before=mnt-foo.mount
cryptsetup 서비스의 수명주기는 이제 기본 장치 장치에 바인딩됩니다.또한지원 장치가 사라질 경우 마운트 지점의 수명또는마운트 지점이 중지되고(예: 사용자 요청 시) 서비스도 중지됩니다(올바른 순서로).
개념적으로 이 접근 방식의 장점은 사용자가 cryptsetup 단위를 무시하고 마운트 지점만 시작/중지할 수 있다는 것입니다. 불행히도, 적어도 내 배포판에서는 mount
어떤 이유로든 클래식 명령이 (실제로) 작동하지 않습니다. umount
항상 사용하는 systemctl start/stop /mnt/foo
것이 좋습니다. 예상대로 작동합니다.
답변3
다른 두 답변은 매우 유용하며 많은 정보와 지침을 제공합니다. 서비스 .mount
와 systemd-cryptsetup
생성된 서비스 간의 종속성을 정의하는 부분이 하나 누락된 것 같습니다 .
/etc
아래와 같이 심볼릭 링크를 생성하면 됩니다 . 단위 종속성 및 기호 링크에 대한 자세한 내용은 다음을 참조하세요.남자 시스템 유닛.
완전성을 위해 전체 설정은 다음과 같습니다.
USB 인클로저를 통해 원격 서버에 드라이브를 연결했기 때문에 드라이브나 인클로저에 오류가 발생하더라도 서버가 부팅되기를 원합니다. 필요하지 않은 경우 automount
및 옵션을 건너뛸 수 있습니다 noauto
. 하지만 어쨌든 마운트된 드라이브 없이는 마운트 지점에 액세스할 수 없기 때문에 어느 쪽이든 괜찮다고 생각합니다. 이는 설정에 더 많은 유연성을 제공합니다.
- /etc/fstab(참고: UUID는 설정 스택 방법에 따라 LV 또는 LUKS 볼륨 위에 생성된 파일 시스템의 UUID입니다.)
UUID=42a1f3eb-ba45-4e00-996c-a6c492fe345a /media/mymount xfs defaults,x-systemd.automount,nofail 0 0
- /etc/crypttab (참고: UUID는 우리가 암호화한 LV입니다. 원시 장치를 암호화하는 경우 경로를 지정해야 할 수도 있습니다
/dev/disks/by-*
.)
mycryptdevice UUID=3682cae2-cf73-4a5e-8904-b83a9b4c2e47 /etc/luks-keyfile nofail,noauto
* 마법은 여기에 있습니다 ↓ ↓ ↓ 링크 서비스 지금
sudo mkdir /etc/systemd/system/media-mymount.mount.requires
sudo ln -s /run/systemd/generator/[email protected] /etc/systemd/system/media-mymount.mount.requires/
- systemd 장치 및 initrd 다시 로드
sudo systemctl daemon-reload
sudo dracut -f # or whatever your init system requires
파티션, LVM 논리 볼륨, 암호화된 파티션 또는 LV를 생성하고 UUID를 검색하는 것은 이 질문의 범위를 벗어납니다. 포인터용으로 몇 가지 유용한 명령이 있습니다.
(umask 077 && dd if=/dev/random bs=64 count=1 of=/etc/luks-keyfile)
vgcreate VGName /dev/sdc1 /dev/sdc2
lvcreate --size 200GiB -n lvname
mkfs.xfs -L fslabel /dev/mapper/VGName
cryptsetup luksFormat/luksAddKey/luksUUID/luksDump/open/close
LUKS 장치에서 VG를 생성하거나 LUKS/cryptsetup을 사용하여 LV를 암호화할 수 있습니다. 기본적으로 LV는 udev 규칙을 통해 자동으로 활성화되므로 이에 대한 서비스를 만들 필요가 없습니다.
내 LV가 여러 원시 장치에 걸쳐 있는 설정의 경우 내가 만드는 각 개별 PV 대신 LV를 암호화하는 것이 더 간단하다는 것을 알았습니다.
화타이