☰

/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

즉, 구문 분석할 파일이 1개가 아닌 6개가 있다는 의미입니다.

AFAIK, 6개보다 하나의 프로필을 갖는 것에는 "절대적으로" 이점이 없습니다(논의를 위해 3개 또는 2개가 있을 수도 있지만 상관 없습니다... 1이 여전히 2보다 낫습니다).

누가 정당한 이점을 생각할 수 있겠는가, "커스텀 추가가 확실히 보인다"는 것은 불쌍한 사람의 변명이다.

나는 변화를 좋아하지만 그것이 이익을 가져올 때만 가능하다는 점을 덧붙여야 합니다.

첫 번째 답변 후 수정:

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

이제 그들은 플랫 파일 대신 디렉터리에서 중복 항목을 검색해야 합니다. 관리자가 상황을 바꾸지 않을 것이라고 생각하지 않는 한 ...

이를 통해 시스템 관리자는 전체 파일을 편집하지 않고도 저장소 세트를 쉽게 비활성화(이름 변경)하거나 삭제(삭제)할 수 있습니다.

관리자는 이름을 바꿀 적절한 파일을 찾기 위해 디렉토리를 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

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

소스 목록의 경우

# 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 소스가 존재하는지 확인하는 대신 Google Chrome 개발자는 Chrome 패키지에서 생성된 정확한 파일 이름을 사용하여 표시합니다. 다른 모든 경우에는 resources.list.d에 새 파일을 만들고 원하는 대로 이름을 지정합니다.

물론, 다음보다 읽고 유지 관리하기 쉬운 방법이 없기 때문에 어떤 리소스가 있는지 확인하는 것은 그다지 좋지 않습니다.

cat /etc/sources.list

내가 아는 한 이는 기본적으로 업데이트를 자동화하고 사용자에게 간단한 단일 명령을 제공하는 것입니다. 이는 사용자의 경우 리포지토리가 추가되었는지 확인하기 위해 1개의 파일이 아닌 많은 파일을 읽어야 함을 의미하고, apt의 경우 하나의 파일이 아닌 많은 파일을 읽어야 함을 의미합니다.

현실 세계에서 이 작업을 잘 수행하려면 이름이 무엇이든 모든 파일 검사를 지원하고 원하는 작업을 수행해야 하는지 테스트해야 하기 때문입니다.

하지만 잘 할 수 없다면 항목이 소스 어딘가에 있는지 확인하는 것을 무시하고 파일 이름만 확인하면 됩니다. 나는 그것이 대부분의 자동화된 작업이라고 생각하지만 결국에는 모든 것을 확인하여 나열하고 해당 파일 중 하나가 일치하는지 여부에 따라 조치를 취할 수 있으므로 유일한 실제 결과는 파일을 더 복잡하게 만드는 것입니다. .

일괄 편집

많은 서버를 실행하는 것을 고려하면 /etc/apt/sources.list.d/를 반복하는 야간 작업을 작성하고 먼저 항목이 resources.list에 없는지 확인한 다음 그렇지 않은 경우 source.list에 항목을 추가하고, source.list.d 파일을 삭제하고, 이미 source.list에 있는 경우 source.list.d 파일을 삭제합니다.

단순성과 유지 관리의 용이성 외에 resources.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를 수정해야 하는데, 이는 많은 시스템 관리자를 약간 불안하게 만들 수 있습니다.

관련 정보