.deb 패키지로 생성된 디렉토리를 이동하기 위해 심볼릭 링크를 사용합니다. 문제가 발생합니까?

.deb 패키지로 생성된 디렉토리를 이동하기 위해 심볼릭 링크를 사용합니다. 문제가 발생합니까?

때로는 tmpfs/flash 또는 SSD/하드 드라이브 간에 패키지 디렉터리를 이동하는 것이 유용해 보입니다. 플래시 수명, 디스크 회전 또는 여유 공간만 관리하세요.

패키지에서 사용하는 디렉터리가 심볼릭 링크로 바뀌면 패키지 관리자가 가끔 혼란을 겪지 않나요? 예를 들어 debsum을 고려하십시오 ...

번들 마운트가 이를 더 잘 숨길 수 있을까요?

답변1

dpkg는 분명히 이것을 지원하도록 설계되었습니다..

반면에, 나는 systemd그러한 심볼릭 링크에 대한 지원이 일반적으로 고려되지 않는다고 생각합니다. 예를 들어 이제 /var/log심볼릭 링크인 경우 시작 시 경고가 표시됩니다 .

systemd-tmpfiles[432]: "/var/log" already exists and is not a directory.

이 때문입니다 /usr/lib/tmpfiles.d/var.conf. 내가 이해한 바에 따르면 이는 /usr시스템 상태의 나머지 부분을 어떻게든 시작하고 자동으로 초기화할 수 있는 개념의 일부로 설정됩니다 . 예를 들어, 간단히 /etc를 지우고 재부팅하면 시스템이 시스템 기본 설정으로 되돌아갑니다.

또 다른 경고 - 출발지인 경우중첩됨바인딩 마운트. 종속성을 관리해야 합니다. 시작 시 일반적으로 설치가 자동으로 정렬되는데 이는 매우 좋습니다. 그러나 설치가 서로 직접적으로 의존하지 않고 심볼릭 링크를 통해 이루어지면 마술처럼 작동하지 않는 것 같습니다. (부팅시 설치는 systemd에 의해 수행된다고 생각합니다.)

심볼릭 링크를 사용하려는 가능한 이유는 다음과 같습니다.

  • 예를 들어 업그레이드하는 동안 디렉터리가 변경된 경우 dpkg는 이를 제대로 처리하지 않습니다.
  • 이는 별도의 것으로 처리되므로 fatrace개별 장치에 대한 쓰기를 모니터링하기가 더 어렵습니다. (기술적으로 이것은 완전히 버그가 아니며 fatrace사용하는 커널 인터페이스의 특이한 점에 가깝습니다).
  • 그들은 그것에 능숙하지 않습니다 df. icinga디스크 공간 모니터링은 바인드 마운트된 디렉토리가 누구나 읽을 수 없는 경우 경고를 발행합니다.
  • tmpfs의 일부를 바인드 마운트하려고 하면,넌 토끼굴로 떨어지고 있어;디렉토리를 먼저 생성하려면 사용자 정의 쉘 스크립트가 필요합니다.

관련 정보