☰

시스템 종속성은 장치의 "ExecStart" 작업에만 적용될 수 있습니까?

tag-icon • tag-icon arch-linux mount systemd cryptsetup
시스템 종속성은 장치의 "ExecStart" 작업에만 적용될 수 있습니까?

이동식 암호화 USB "키링" 플래시 드라이브에 포함된 키를 사용하여 여러 스토리지 볼륨을 암호화하는 시나리오가 있습니다. 저는 Arch Linux를 실행 중이며 이 질문은 시스템 종속성 구성에 관한 것입니다.

키링이 존재하는 한 시스템은 볼륨을 부팅하고 마운트하도록 구성되어 있습니다. 키링 비밀번호는 시작 중에 수동으로 입력됩니다.

시스템 부팅 후 USB 키링을 제거할 수 있기를 원하지만 systemd가 모든 것을 제거하기 때문에 문제가 발생합니다.

다음은 제가 한 일의 예입니다. 첫 번째,/etc/crypttab

# <name>  <device>           <password>             <options>
keyring   PARTLABEL=keyring  none                   noauto
abc       /dev/lvm/abc       /root/keyring/abc.key  header=/root/keyring/abc.hdr
xyz       /dev/lvm/xyz       /root/keyring/xyz.key  header=/root/keyring/xyz.hdr

  • 저는 systemd이 옵션을 지원하는 최근 Git 체크아웃을 사용하고 있습니다 header. 이 옵션은 1월 8일에 저장소에 추가되었습니다.

  • 백업/편의를 위해 물리적 키링이 여러 개 있기 때문에 키링에 파티션 레이블을 사용합니다. UUID는 다를 수 있지만 동일한 PARTUUID 설정을 사용합니다.

  • 제가 사용하고 있는 noauto키링은 암호를 해독해야 하는 모든 장치에 대한 종속성일 뿐입니다.

다음은 다음과 같습니다 /etc/fstab.

# <file system>     <dir>         <type>    <options>
/dev/mapper/keyring /root/keyring ext4      ro,noauto
/dev/mapper/abc     /srv/abc      ext4
/dev/mapper/xyz     /srv/xyz      ext4

마찬가지로 키링은 noauto종속성이기 때문에 설치됩니다. 게다가 읽기 전용으로 마운트되어 있어 안전하게 끌어올 수 있다.

이제 볼륨과 키링 간의 종속성을 생성하기 위해 다음을 사용했습니다.재정의 삽입, 예를 들어:

# /etc/systemd/system/systemd-cryptsetup\@abc.service.d/override.conf
[Unit]
Requires=root-keyring.mount

이것은 모두 훌륭하고 부팅하기에 좋습니다. 문제는 키링을 제거하면 이에 의존하는 장치가 중지된다는 것입니다. 저는 이런 일이 발생하는 것을 원하지 않습니다. 종속성은 볼륨이 잠금 해제될 때 키와 헤더에 액세스할 수 있도록 하는 데만 필요합니다. 잠금이 해제되면 키와 헤더가 더 이상 필요하지 않습니다.

그래서 내 질문은 묻는 것입니다."ExecStart" 명령 기간 동안에만 존재하는 키링에 대한 종속성을 정렬하는 방법[이메일 보호됨]단위?

또는 이것이 잘못된 접근 방식이라면 개선된 솔루션을 환영합니다.

답변1

명시적인 종속성 대신 다음을 사용할 수 있습니다.자동 마운트.

Systemd가 있었던 것을 기억합니다.Poettering의 블로그 원본 게시물, 암시적 종속성입니다. 이는 (systemd를 사용하여) 소켓에 요청을 작성한 다음 적절한 서비스(예: "소켓 활성화")가 시작되는 방법과 같습니다. 이 경우 파일 시스템에 액세스하면 해당 파일 시스템이 마운트됩니다.

이 접근 방식을 사용하면 서비스나 파일 시스템이 준비될 때까지 차단할 수 있습니다. 노트: 이는 시스템에 해당 디렉토리를 보려고 하면("키링" 드라이브를 삭제한 후) 차단되는 디렉토리가 있다는 의미입니다. 아마도 다른 용도로 /root를 사용한다면 설치하는 것이 더 나을 것입니다. 예를 들어 /automount/keyring, 걸려 넘어지는 것을 방지하기 위해 다른 곳에 두십시오 . 개인적으로 저는 이와 같은 문제가 자동 마운트를 다소 혼란스럽게 한다고 생각합니다. 하지만 문제를 매우 빠르게 해결하는 것 같습니다.

파일 시스템이 에 나열되어 있으면 옵션 목록에 /etc/fstab추가하기만 하면 됩니다 .x-systemd.automount

네이티브 파일로 .mount설명하는 경우 .automount동일한 이름의 파일을 만들어야 할 것 같습니다. 예를 들어 다음 root-keyring.automount을 포함합니다.

[Automount]
Where=/root/keyring

답변2

현재 버전의 systemd(이 글을 쓰는 시점에서는 218)에서는 항목으로 인해 /etc/crypttab시스템 시작 시 systemd가 실행하는 유닛에 의해 인스턴스가 생성됩니다.[email protected]systemd-cryptsetup-generator

생성된 단위에는 키 파일 경로에 대한 종속성이 포함됩니다.

RequiresMountsFor=/path/to/key_file

이 종속성 레코드는 지정된 경로에 액세스하는 데 필요한 모든 설치된 종속성이 man systemd.unit연결되는 위치를 설명합니다 .Requires=After=

이러한 종속성으로 인해 마운트 장치가 비활성화된 경우 Requires=systemd는 cryptsetup 장치를 중지합니다 .

즉, 키가 포함된 장치를 마운트 해제하면 cryptsetup 장치가 볼륨을 비활성화하고 잠그게 됩니다.

현재 유일한 해결 방법은 /etc/crypttab문제를 일으킬 수 있는 볼륨을 사용하지 않고 RequiresMountsFor=종속성을 포함하지 않는 사용자 지정 단위를 제공하는 것입니다. . 다음은 생성기에서 생산된 단위를 기반으로 한 적합한 사용자 정의 단위입니다.

# /etc/systemd/system/systemd-cryptsetup\@.service 
[Unit]
Description=Cryptography Setup for %I
Documentation=man:crypttab(5) man:systemd-cryptsetup-generator(8) man:[email protected](8)
DefaultDependencies=no
Conflicts=umount.target
BindsTo=dev-mapper-%i.device
IgnoreOnIsolate=true
After=cryptsetup-pre.target
Before=cryptsetup.target
BindsTo=dev-lvmvg-%i.device
After=dev-lvmvg-%i.device
Before=umount.target

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=0
ExecStart=/usr/lib/systemd/systemd-cryptsetup attach '%i' '/dev/lvmvg/%i' '/root/keyring/%i.key' 'header=/root/keyring/%i.hdr'
ExecStop=/usr/lib/systemd/systemd-cryptsetup detach '%i'

[Install]
WantedBy=dev-mapper-%i.device

이 항목 대신 다음 예가 사용됩니다 /etc/crypttab.

 # <name>  <device>       <password>              <options>
mail      /dev/lvmvg/mail /root/keyring/mail.key  header=/root/keyring/mail.hdr

이 문제는 systemd 개발자에게 제기되었으며 다음에 추가되었습니다.할 일 목록.

관련 정보