☰

/etc/apt/sources.list에 비해 /etc/apt/sources.list.d의 이점은 무엇입니까

tag-icon • tag-icon linux apt etc
/etc/apt/sources.list에 비해 /etc/apt/sources.list.d의 이점은 무엇입니까

이 질문이 이전에 요청된 적이 있다는 것을 알고 있지만 "사용자 정의 추가 사항을 명확하게 볼 수 있습니다"라는 답변을 받아들이지 않습니다. ppa를 추가할 때(몇 년 동안 해본 적이 없음) 키보드에서 "Enter"라고 표시된 키를 누르면 새 항목 앞에 빈 줄을 추가할 수 있습니다(설명 주석도 추가하겠지만 저는 기술 작가, 그래서 ....). 나는 sources.conf깨끗하고 깔끔한 것을 좋아합니다.

/etc/apt/sources.d

즉, 구문 분석할 파일이 단 하나가 아니라 여섯 개가 있다는 뜻입니다.

AFAIK, 6개에 비해 하나의 구성 파일을 갖는 것에는 "절대적으로" 이점이 없습니다.

누군가 합리적인 이점을 생각해 낼 수 있습니까? "사용자 정의 추가 사항을 명확하게 볼 수 있습니다"는 불쌍한 사람의 변명입니다.

나는 변화를 좋아한다는 점을 덧붙여야 합니다. 그러나 변화로 인해 이점이 있을 때만 그렇습니다.

첫 번째 응답 후 편집:

중복 항목을 추가하지 않도록 플랫 파일을 검색할 필요가 없도록 자체 저장소가 필요한 새 설치를 허용합니다.

이제 그들은 플랫 파일 대신 디렉터리에서 속이는 파일을 검색해야 합니다. 관리자가 상황을 바꾸지 않는다고 가정하지 않는 한 ...

이를 통해 시스템 관리자는 모놀리식 파일을 편집할 필요 없이 저장소 세트를 쉽게 비활성화(이름 변경)하거나 제거(삭제)할 수 있습니다.

관리자는 이름을 바꿀 적절한 파일을 찾기 위해 디렉터리를 grep해야 합니다. 그 전에는 하나의 파일을 검색하고 "거의" 모든 관리자에 대한 sed 한 줄짜리 줄을 주석 처리해야 합니다.

이를 통해 패키지 관리자는 관련 없는 저장소의 구성을 실수로 변경하는 것에 대해 걱정할 필요 없이 저장소 위치를 업데이트하는 간단한 명령을 제공할 수 있습니다.

나는 이것을 이해하지 못합니다. 패키지 관리자가 자신의 저장소의 URL을 알고 있다고 "가정"합니다. 다시 말하지만, sed단일 파일 대신 디렉터리 가 있어야 합니다 .

답변1

각 저장소(또는 저장소 모음)를 자체 파일에 포함하면 수동으로나 프로그래밍 방식으로 관리하기가 더 간단해집니다.

  • 중복 항목을 추가하지 않도록 플랫 파일을 검색할 필요가 없도록 자체 저장소가 필요한 새 설치를 허용합니다.
  • 이를 통해 시스템 관리자는 모놀리식 파일을 편집할 필요 없이 저장소 세트를 쉽게 비활성화(이름 변경)하거나 제거(삭제)할 수 있습니다.
  • 이를 통해 패키지 관리자는 관련 없는 저장소의 구성을 실수로 변경하는 것에 대해 걱정할 필요 없이 저장소 위치를 업데이트하는 간단한 명령을 제공할 수 있습니다.

답변2

기술적인 측면에서 볼 때, 몇 가지 크고 인기 있는 시스템 정보 도구에서 이러한 변경 사항을 처리해야 했던 사람으로서 기본적으로 다음과 같은 결과가 나옵니다.

source.list.d/의 경우

# to add
if [[ ! -e /etc/apt/sources.list.d/some_repo.list ]];then
  echo 'some repo line for apt' > /etc/apt/sources.list.d/some_repo.list
fi

# to delete
if [[ -e /etc/apt/sources.list.d/some_repo.list ]];then
  rm -f /etc/apt/sources.list.d/some_repo.list
fi

아래와 같은 검사를 수행하지 않는 한 repo 라인을 주석 처리했다면 이 테스트는 잘못된 것입니다. 아래와 같이 동일한 검사를 수행하는 경우 하나가 아닌 여러 파일에 대해 수행된다는 점을 제외하면 복잡성은 동일합니다. 또한 가능한 모든 파일을 확인하지 않는 한 중복 항목을 추가할 수 있으며 종종 그렇게 합니다. 그러면 해당 항목 중 하나를 삭제할 때까지 불평하기 쉽습니다.

소스 목록의 경우

# to add. Respect commented out lines. Bonus points for uncommenting
# line instead of adding a new line
if [[ -z $( grep -E '\s*[^#]\s*some repo line for apt' /etc/apt/sources.list ) ]];then
  echo 'some repo line for apt' >> /etc/apt/sources.list
fi

# to delete. Delete whether commented out or not. Bonus for not
# deleting if commented out, thus respecting the user's wishes
sed -i '/.*some repo line for apt.*/d' /etc/apt/sources.list

Google Chrome 개발자는 Chrome 패키지가 생성하는 정확한 파일 이름에 의존하여 Google Chrome 소스가 있는지 확인하지 않았습니다. 다른 모든 경우에는 원하는 방식으로 정확하게 이름이 지정된 source.list.d에 새 파일을 생성합니다.

물론 어떤 소스가 있는지 확인하려면 다음보다 읽고 유지 관리하기가 더 쉬울 수 없기 때문에 그다지 좋지 않습니다.

cat /etc/sources.list

따라서 이는 기본적으로 자동화된 업데이트를 목적으로 수행되었으며 제가 알 수 있는 한 사용자에게 제공할 수 있는 쉬운 단일 명령을 제공하기 위한 것입니다. 사용자의 경우 repo가 ​​추가되었는지 확인하기 위해 1개의 파일이 아닌 많은 파일을 읽어야 함을 의미하고, apt의 경우에도 하나의 파일이 아닌 많은 파일을 읽어야 함을 의미합니다.

실제 세계에서 이 작업을 제대로 수행하려면 이름에 관계없이 모든 파일에 대한 검사를 지원해야 하며 수행할 작업이 필요한지 여부를 테스트해야 합니다.

하지만 잘 할 수 없을 것 같으면 항목이 소스 어딘가에 있는지 확인하는 검사를 무시하고 파일 이름만 확인하면 됩니다. 나는 그것이 대부분의 자동화된 작업이 하는 일이라고 믿지만 결국에는 모든 것을 확인하여 목록을 작성하고 해당 파일 중 하나가 일치하는지에 따라 조치를 취해야 했기 때문에 유일한 실제 결과는 훨씬 더 복잡해졌습니다.

대량 편집

많은 서버를 실행하는 경우 /etc/apt/sources.list.d/를 반복하는 야간 작업을 스크립트로 작성하고 항목이 이미 source.list에 없는지 확인한 다음 항목이 있으면 아니요, 해당 항목을 source.list에 추가하고, source.list.d 파일을 삭제하고, 이미 source.list에 있는 경우 source.list.d 파일을 삭제하세요.

단순성과 유지 관리의 용이성 이상으로 source.list만 사용하는 데 부정적인 점은 없으므로, 특히 시스템 관리자의 창의적인 무작위 작업을 고려할 때 이와 같은 것을 추가하는 것은 나쁜 생각이 아닐 수 있습니다.

위의 설명에서 언급했듯이 inxi -r은 활성 저장소를 파일별로 깔끔하게 인쇄하지만 편집하거나 변경하지는 않으므로 솔루션의 절반에 불과합니다. 배포판이 많으면 각각의 배포 방식을 배우는 것이 고통스럽습니다. 확실히 그렇습니다. 그리고 무작위성은 확실히 예외가 아닌 규칙입니다.

답변3

서버를 수동으로 관리하는 경우 상황이 더 혼란스러워진다는 데 동의합니다. 그러나 프로그래밍 방식의 관리(예: "코드로 구성")에는 이점이 있습니다. Puppet, Ansible, Chef 등과 같은 구성 관리 소프트웨어를 사용하는 경우 apt update파일을 구문 분석하여 특정 줄을 추가하거나 제거하는 대신 디렉터리에 파일을 삭제하거나 제거하고 실행하는 것이 더 쉽습니다 .

/etc/apt/sources.list특히 이렇게 하면 제3자가 작성한 여러 독립 모듈에서 단일 '파일' 리소스(예: )의 콘텐츠를 관리할 필요가 없으므로 더욱 그렇습니다 .

나는 이러한 특정한 이유로 Ubuntu가 ".d" 디렉토리를 광범위하게 사용하는 것에 감사드립니다(예: sudoers.d, rsyslog.d, sysctl.d., cron.d, logrotate.d 등).

답변4

이를 통해 패키지는 스크립트를 사용하지 않고도 추가 소스를 추가할 수 있습니다.

예를 들어, Microsoft의 Skype 패키지를 설치하면 skype.com의 소스가 업데이트를 다운로드하도록 자동으로 구성됩니다. 시스템에서 Skype 패키지를 제거하면 이 패키지 소스도 다시 비활성화됩니다.

플랫 파일로 동일한 효과를 얻으려면 Skype용 설치 스크립트에서 source.list를 수정해야 합니다. 이는 아마도 많은 시스템 관리자가 약간 불안해할 것입니다.

관련 정보