PrivateTmp: 훅이 파일을 썼는데, 어디로 갔을까요?

훅은 성공을 보고하지만, 같은 경로는 셸에서 보면 여전히 비어 있습니다. 두 진술은 동시에 참일 수 있습니다. systemd 서비스가 사설 임시 디렉터리를 가진 자체 마운트 이름 공간에 살 수 있기 때문입니다. 그것을 이해하고 나면 흥미로운 질문은 쓰기가 애초에 성공했는가입니다.

두 임시 디렉터리, 하나의 경로

격리 설정은 임시 디렉터리를 읽기 전용으로 만드는 대신 유닛에 사설 보기를 제공합니다. 유닛 외부의 프로세스는 그곳에 무엇이 쓰이는지 볼 수 없고, 유닛이 멈추면 남긴 것은 모두 버려집니다. 따라서 훅이 출력한 경로와 셸에서 확인한 경로는 같은 이름의 다른 객체를 가리킬 수 있습니다.

이것은 가시성 문제이며, 데이터 손실 문제처럼 보입니다. 아무것도 삭제되지 않았습니다. 파일이 셸이 구성원이 아닌 이름 공간에 있을 뿐입니다. 같은 명령도 유닛 내부에서 실행하면 다르게 동작하며, 보통 그 관찰이 논쟁을 해결합니다. 쓰기에 대해 무엇이든 결론 내리기 전에 유닛 설정을 읽으십시오.

보이지 않는 것과 쓸 수 없는 것을 구분하라

성공한 쓰기와 실패한 열기는 서로 다른 증거를 남기며, 그 차이가 수리를 결정합니다. 훅이 파일이 만들어졌다고 하는데 외부 판독자가 찾지 못한다면 이름 공간 문제입니다. 만약 훅이 권한 오류나 실패한 열기를 보고한다면, 파일은 기록된 적이 없고 이름 공간을 바꿔도 도움이 되지 않습니다.

systemctl show [email protected] -p PrivateTmp -p User -p Group -p RuntimeDirectory
systemctl show [email protected] -p MainPID --value
sudo ls -l /proc/PID/root/tmp/client-state

프로세스 루트 경로는 서비스 자체의 파일 시스템 보기를 드러내며, 프로세스가 아직 실행 중인 동안 그 프로세스에 대한 권한 검사를 받습니다. 같은 세션에서 유닛의 저널을 읽으십시오. 누군가 이미 원인을 정해 두면 쓰기 오류와 사라진 파일을 혼동하기 쉽습니다.

공유 데이터에 명시적 위치를 주라

서비스만 필요한 데이터는 사설 임시 디렉터리에 속합니다. 다른 프로세스가 읽어야 하는 데이터에는 양쪽 모두를 위해 정의된 경로가 필요하며, 소유자와 모드와 만료가 명시되어야 합니다. 유닛을 편집하기 전에 두 경우 중 어느 것인지 결정하십시오. 이런 사건의 대부분은 사설 파일을 공유 파일로 취급하는 데서 옵니다.

[Service]
RuntimeDirectory=openvpn-hook-office
RuntimeDirectoryMode=0750

런타임 디렉터리는 폴더를 시스템 런타임 영역 아래에 두고, 유닛에 구성된 사용자와 그룹을 위해 만들며, 유닛이 멈추면 제거합니다. 패키지의 유닛이 그대로 유지되도록 drop-in으로 추가한 다음 관리자를 다시 불러오고 해당 인스턴스를 재시작하십시오. 클라이언트가 다시 연결되는 것은 감수해야 합니다.

설치된 유닛이 이미 요구하는 런타임 디렉터리는 유지하십시오. 목록에 추가하는 대신 교체하는 것은 변경과 무관한 기능을 깨뜨리는 흔한 방법입니다.

두 권한 계층이 어긋날 수 있다

서비스 관리자는 유닛에 구성된 사용자를 위해 디렉터리를 만들지만, VPN 데몬은 연결 훅을 실행하기 전에 따로 자신의 계정으로 내려갈 수 있습니다. 이것은 다른 계층이며, 서로 다른 신원을 가리킬 수 있습니다.

제한적 모드의 root 소유 디렉터리는 이미 권한을 포기한 데몬에게 완전히 보이지만, 그래도 그 데몬은 쓸 수 없습니다. 그때 오류는 권한 문제로 읽히지만 경로는 기대한 바로 그곳에 있습니다. 디렉터리 소유자와 훅이 보고하는 신원을 비교하십시오. 둘이 다르다면 모드는 처음부터 문제가 아니었습니다.

소유권을 바꾸기 전에 훅이 실제로 어떤 신원으로 실행되는지 확인하십시오. 디렉터리를 고치려고 서비스의 실행 사용자를 바꾸면 다른 곳의 장치 접근과 네트워크 권한이 달라질 수 있으며, 작은 문제에 큰 대가입니다.

전체 인계를 검증하라

네 가지를 동시에 확인하십시오. 훅이 실제 신원으로 쓰는지, 의도한 판독자가 파일을 소비할 수 있는지, 무관한 사용자는 할 수 없는지, 유닛을 멈추면 설계대로 정리되는지입니다. 호스트의 공유 임시 디렉터리에 파일이 나타나는 것은 요구 사항이 아니며, 보통 교환이 자체 경로를 얻지 못했다는 신호입니다. 재시작 후에 판독자를 시험하십시오. 첫 실행 때만이 아니라. 정리 동작은 설계의 일부이므로 가정하지 말고 관찰하십시오.

영구 상태는 수명이 맞는 곳에 속합니다. 런타임 디렉터리는 사라지도록 만들어졌기 때문입니다. 위치는 편의가 아니라 수명으로 고르십시오. 그 습관이 같은 조사의 다음 판을 막습니다.