В чем преимущество /etc/apt/sources.list.d перед /etc/apt/sources.list

Я знаю, что этот вопрос задавался ранее, но я не принимаю ответ: «Вы можете четко видеть пользовательские дополнения». Когда я добавляю ppa (что я не делал годами), я нажимаю клавишу на клавиатуре с надписью «Enter», которая позволяет мне добавить пустую строку перед новой записью (я бы даже добавил пояснительный комментарий, но я технический писатель, так что ....). Мне нравится мой sources.confчистый и опрятный.

/etc/apt/sources.d

Значит, у меня есть полдюжины файлов для анализа вместо одного.

AFAIK, «абсолютно» нет никакого преимущества в том, чтобы иметь один конфигурационный файл против 6 (ради аргумента, может быть, у вас есть 3 или даже 2, не имеет значения ... 1 по-прежнему бьет 2).

Может кто-нибудь, пожалуйста, придумайте рациональное преимущество, «вы можете ясно видеть пользовательские дополнения» - оправдание для бедного человека.

Однако я должен добавить, что я люблю перемены, ТОЛЬКО тогда, когда эти перемены приносят пользу.

Изменить после первого ответа:

Это позволяет новым установкам, которым требуются собственные репозитории, не выполнять поиск плоского файла, чтобы убедиться, что он не добавляет повторяющиеся записи.

Теперь они должны искать в каталоге dupe вместо плоского файла. Если только они не предполагают, что администраторы ничего не меняют ...

Это позволяет системному администратору легко отключить (переименовав) или удалить (удалив) набор репозитория без необходимости редактирования монолитного файла.

Администратор должен grep каталог, чтобы найти соответствующий файл для переименования, прежде чем он будет искать ОДИН файл и закомментировать строку, однострочную sed для «почти» любого администратора.

Это позволяет сопровождающему пакета давать простую команду для обновления расположений репозитория, не беспокоясь о случайном изменении конфигурации для несвязанных репозиториев.

Я не понимаю этого, я «предполагаю», что сопровождающий пакета знает URL своего репозитория. Опять же, должен sedкаталог вместо одного файла.

На техническом уровне, как человек, которому приходилось обрабатывать эти изменения в нескольких крупных и популярных инструментах системной информации, в основном все сводится к следующему:

Для sources.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

Обратите внимание, что если они не выполняют ту же проверку, что и ниже, если вы закомментировали строку репо, эти тесты будут ошибочными. Если они выполняют ту же проверку, что и ниже, то это точно такая же сложность, за исключением того, что выполняется для многих файлов, а не для одного. Кроме того, если они не проверяют ВСЕ возможные файлы, они могут и часто добавляют дублирующий элемент, который затем вызывает жалобу, пока вы не удалите один из них.

Для sources.list

# 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 создаст для присутствия. Во всех остальных случаях они будут создавать новый файл в sources.list.d, который будет назван именно так, как они хотят.

Чтобы увидеть, какие источники у вас есть, конечно, это не так красиво, так как вы не можете легче читать и поддерживать, чем:

cat /etc/sources.list

Так что в основном это было сделано с целью автоматического обновления и предоставления простых однократных команд, которые вы могли бы давать пользователям, насколько я могу судить. Для пользователей это означает, что они должны прочитать много файлов вместо одного файла, чтобы увидеть, есть ли у них добавленные репозитории, а для apt это означает, что он должен прочитать много файлов вместо одного файла.

Поскольку в реальном мире, если вы собираетесь делать это хорошо, вы должны поддерживать проверки для всех файлов, независимо от того, как они названы, и затем проверять, требуется ли выполнение действия или не требуется.

Однако, если вы не собираетесь делать это хорошо, вы просто проигнорируете проверки, чтобы увидеть, находится ли элемент где-то в источниках, и просто проверите имя файла. Я полагаю, что это то, что делает большинство автоматизированных программ, но, в конце концов, мне просто нужно было проверить все, чтобы я мог составить список и действовать в зависимости от того, соответствует ли один из этих файлов, единственный реальный результат сделал его намного более сложным.

Массовые правки

Учитывая наличие множества серверов, у меня возникнет соблазн просто написать сценарий для ночной работы, которая просматривает /etc/apt/sources.list.d/ и проверяет сначала, чтобы убедиться, что элемент уже не находится в sources.list, а затем, если он нет, добавьте этот элемент в sources.list, удалите файл sources.list.d, а если уже есть в sources.list, просто удалите файл sources.list.d

Поскольку НЕЛЬЗЯ отрицательно использовать только исходники. Перечислите простоту и удобство обслуживания, добавление чего-либо подобного не может быть плохой идеей, особенно с учетом творческих случайных действий администраторов системы.

Как отмечалось в приведенном выше комментарии, inxi -r будет аккуратно распечатывать для каждого файла активные репозитории, но, конечно, не будет редактировать или изменять их, так что это будет только половина решения. Если это много дистрибутивов, то узнавать, как каждый из них это делает, непросто, и наверняка случайность, скорее, является скорее правилом, чем исключением.

Наличие каждого репозитория (или коллекции репозиториев) в своем собственном файле упрощает управление как вручную, так и программно:

• Это позволяет новым установкам, которым требуются собственные репозитории, не выполнять поиск плоского файла, чтобы убедиться, что он не добавляет повторяющиеся записи.
• Это позволяет системному администратору легко отключить (переименовав) или удалить (удалив) набор репозитория без необходимости редактирования монолитного файла.
• Это позволяет сопровождающему пакета давать простую команду для обновления расположений репозитория, не беспокоясь о случайном изменении конфигурации для несвязанных репозиториев.

Если вы управляете своими серверами вручную, я согласен, что это делает вещи более запутанными. Однако это выгодно для программного управления (то есть «конфигурация как код»). При использовании программного обеспечения для управления конфигурациями, такого как Puppet, Ansible, Chef и т. Д., Проще просто удалить или удалить файл в apt updateдиректории и запустить , а не анализировать файл для добавления или удаления определенных строк.

Тем более, что это избавляет от необходимости управлять содержимым одного «файлового» ресурса, например: /etc/apt/sources.listиз нескольких независимых модулей, написанных третьими сторонами.

Я благодарен Ubuntu за широкое использование каталогов ".d" по этой конкретной причине, например, sudoers.d, rsyslog.d, sysctl.d., Cron.d, logrotate.d и т. Д.

Как отмечает nemo в комментарии, одним из ключевых преимуществ каталога является то, что он допускает понятие «владение».

Современные дистрибутивы и установщики Linux основаны на идее пакетов - независимых частей программного обеспечения, которые, насколько это возможно, могут быть добавлены и удалены атомарно. Всякий раз, когда вы устанавливаете пакет с dpkg(и, следовательно apt), он отслеживает, какие файлы в системе были созданы этим установщиком. Удаление пакета может в основном состоять из удаления этих файлов.

В настоящее время принятый ответ воспринимается как плохая вещь, так как установщик Google Chrome предполагал, что он должен только создавать или удалять запись в месте, которое он ожидал, но автоматизация чего-либо еще приводит к всевозможным ужасным крайним случаям; например:

• Если sources.listпри установке строка существует , но закомментирована, установщик должен раскомментировать ее или добавить дубликат?
• Если деинсталлятор удаляет строку, но пользователь добавил или отредактировал комментарии рядом с ней, в файле останется неработающий комментарий.
• Если пользователь вручную добавил строку, установщик может знать, не добавлять ли ее; но как деинсталлятор узнает, что не удаляет его?

Отдельные файлы не требуются для владения; например, установщик может включать блок комментариев, в котором говорится, что он «владеет» определенным набором строк. В этом случае он всегда будет искать в файле именно этот блок, а не упоминать о том же хранилище.

При прочих равных автоматизировать редактирование одного файла конфигурации всегда будет сложнее, чем автоматизировать создание и удаление отдельного файла. По крайней мере, удаление линий требует использования некоторого инструмента сопоставления с образцом, такого как sed. В более сложных файлах для добавления и удаления строк может потребоваться инструмент сценариев со знанием формата файла, который можно добавить в соответствующий раздел или удалить без ущерба для окружающего форматирования.

Так как установщик должен был бы в любом случае избегать путаницы с редактируемой вручную конфигурацией, имеет смысл поместить автоматизированную, принадлежащую инструменту конфигурацию в формат, которым легко управлять автоматизированные инструменты.

Это позволяет пакетам добавлять дополнительные источники, не прибегая к скриптам.

Например, когда вы устанавливаете пакет Skype от Microsoft, источник для skype.com автоматически настраивается для загрузки обновлений; удаление пакета Skype из системы также отключает этот источник пакета снова.

Если вы хотите получить тот же эффект с простым файлом, то установочные сценарии для Skype должны будут изменить ваш sources.list, который, вероятно, многих системных администраторов сочтет слегка расстраивающим.

Я не уверен, что есть веская причина - кроме того, что кажется модным. Для меня это нарушает правило, согласно которому каталог должен быть либо листом, либо узлом, то есть он должен содержать только файлы или каталоги, а не смесь обоих.

Я предполагаю, что это делает файлы меньше, что делает их более удобными для чтения - в случае, например, с правилами sudo, которые могут быть довольно длинными, это облегчает создание стандартизированного набора правил для одного типа пользователя (например, для разработчика). ) и добавьте их в каталог конфигурации, если на этом компьютере разработчикам должно быть разрешено использовать sudo; таким образом, вам нужно поддерживать меньше файлов - просто файл для разработчиков, администраторов, сисопов и т. д., а не для каждой возможной их комбинации.

Там я противоречил сам себе.