Яка перевага /etc/apt/sources.list.d над /etc/apt/sources.list

Я знаю, що це питання було задано і раніше, але я не приймаю відповідь, "ви можете чітко побачити спеціальні доповнення". Коли я додаю файли ppa (що я не робив за роки), натискаю клавішу на клавіатурі з написом "Enter", яка дозволяє мені додати порожній рядок перед новим записом (я б навіть додав пояснювальний коментар, але я є тех-письменник, так ....). Мені подобається моя sources.confчиста і акуратна.

/etc/apt/sources.d

Значить, я маю півдесятка файлів для розбору, а не лише один.

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

Чи може хтось, будь ласка, придумати раціональну перевагу, "ви можете чітко побачити користувацькі доповнення" - це привід бідної людини.

Треба додати, я люблю зміни, однак ТІЛЬКИ, коли є користь, внесена зміною.

Редагувати після першої відповіді:

Це дозволяє новим установкам, для яких потрібні власні репозиції, не потрібно шукати рівний файл, щоб переконатися, що він не додає повторюваних записів.

Тепер їм доведеться шукати каталог для dupe замість плоского файлу. Якщо вони не припускають, що адміністратор не змінить речі ...

Це дозволяє системному адміністратору легко відключити (перейменувавши) або видалити (видаливши) набір сховищ без необхідності редагувати монолітний файл.

Адміністратору доводиться вибирати каталог, щоб знайти відповідний файл для перейменування, раніше він шукав ОДИН файл і коментував рядок, sed one-liner для "майже" будь-якого адміністратора.

Це дозволяє обслуговуючому апарату давати просту команду для оновлення місць сховища, не турбуючись про ненавмисну ​​зміну конфігурації для непов'язаних сховищ.

Я цього не розумію, я "припускаю", що обслуговуючий пакет знає URL-адресу свого сховища. Знову ж, має до sedкаталогу замість одного файлу.

На технічному рівні, як хтось, кому довелося впоратися з цими змінами у кількох великих та популярних системних інформаційних інструментах, в основному це зводиться до цього:

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

Зауважте, що якщо вони також не роблять таку ж перевірку, як нижче, якби ви прокоментували рядок репо, ці тести були б помилковими. Якщо вони роблять таку ж перевірку, як нижче, то це така ж точна складність, за винятком багатьох файлів, а не одного. Крім того, якщо вони не перевіряють ВСІ можливі файли, вони можуть, а часто і робити, додавати повторюваний елемент, який потім примушує скаржитися, поки ви не видалите один із них.

Для source.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. У всіх інших випадках вони створювали б новий файл у source.list.d, названому саме так, як вони хотіли.

Зрозуміло, які джерела у вас є, звичайно, це не так красиво, оскільки читати та підтримувати їх не можна легше, ніж:

cat /etc/sources.list

Отже, це в основному було зроблено з метою автоматизованих оновлень, а також для надання простих одиночних команд, які ви могли б дати користувачам, наскільки я можу сказати. Для користувачів це означає, що їм доводиться читати багато файлів замість 1 файлу, щоб побачити, чи додано репо, а для apt це означає, що він повинен прочитати багато файлів, а не один файл.

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

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

Масові редагування

Зважаючи на запуску багатьох серверів, я б спокусився просто скриптувати нічну роботу, яка проходить через /etc/apt/sources.list.d/ і перевіряє спочатку, щоб переконатися, що елемент вже не в source.list, потім, якщо він є ні, додайте цей елемент у source.list, видаліть файл source.list.d, а якщо вже є у source.list, просто видаліть файл source.list.d

Оскільки НЕ негативно використовувати лише source.list, окрім простоти та простоти обслуговування, додавання чогось подібного може не бути поганою ідеєю, особливо з урахуванням творчих випадкових дій системних адміністраторів.

Як зазначено у вищенаведеному коментарі, inxi -r буде акуратно роздруковувати на файл активні репозитори, але, звичайно, їх не редагувати чи змінювати, так що це буде лише половина рішення. Якщо це багато розповсюджень, це біль, що навчається, як це робити, це точно, і випадковість, безумовно, є правилом, а не сумним винятком.

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

• Це дозволяє новим установкам, для яких потрібні власні репозиції, не потрібно шукати рівний файл, щоб переконатися, що він не додає повторюваних записів.
• Це дозволяє системному адміністратору легко відключити (перейменувавши) або видалити (видаливши) набір сховищ без необхідності редагувати монолітний файл.
• Це дозволяє обслуговуючому апарату давати просту команду для оновлення місць сховища, не турбуючись про ненавмисну ​​зміну конфігурації для непов'язаних сховищ.

Якщо ви керуєте своїми серверами вручну, я погоджуюся, що це робить більш заплутаним. Однак це приносить користь програмному керуванню (тобто "конфігурація як код"). Використовуючи програмне забезпечення для керування конфігураціями, як Puppet, Ansible, Chef тощо, простіше просто скинути або видалити файл у dir та запустити apt update, а не розбирати файл, щоб додати чи видалити певні рядки.

Тим більше, що це дозволяє уникати керування вмістом одного "файлового" ресурсу, наприклад: /etc/apt/sources.listз декількох незалежних модулів, написаних третіми сторонами.

Я вдячний за те, що Ubuntu широко використовує ".d" dir з цієї конкретної причини, тобто sudoers.d, rsyslog.d, sysctl.d., Cron.d, logrotate.d тощо.

Як неможливо зазначив у коментарі, однією з ключових переваг каталогу є те, що він допускає поняття "право власності".

Сучасні дистрибутиви та інсталятори Linux базуються на ідеї пакетів - незалежних програм, які можна, наскільки це можливо, додавати та видаляти атомним шляхом. Щоразу, коли ви встановлюєте пакет з dpkg(і, отже apt), він відслідковує, які файли в системі були створені цим інсталятором. Видалення пакета може значною мірою полягати у видаленні цих файлів.

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

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

Окремі файли не потрібні для власності; наприклад, інсталятор може включати в себе блок коментарів, вказуючи, що він "володіє" певним набором рядків. У цьому випадку він завжди шукатиме у файлі саме той блок, а не якусь іншу згадку того самого сховища.

За умови рівності, автоматизація редагування одного файлу конфігурації завжди буде складніше, ніж автоматизація створення та видалення окремого файлу. Як мінімум, для видалення ліній потрібно використовувати якийсь інструмент відповідності шаблону, такий як sed. У більш складному файлі і для додавання, і для видалення рядків може знадобитися інструмент сценаріїв зі знанням формату файлу, додати його до відповідного розділу або видалити, не пошкодивши формати навколишнього середовища.

Оскільки інсталятору все-таки потрібно уникати возитися з налаштованою вручну конфігурацією, має сенс розмістити автоматизовану конфігурацію, що належить інструменту, у форматі, який легко управляє автоматизованими інструментами.

Це дозволяє пакетам додавати додаткові джерела, не вдаючись до скриптів.

Наприклад, при встановленні пакету Skype від Microsoft, джерело для skype.com автоматично налаштовується для завантаження оновлень; видалення пакета Skype із системи також знову відключає це джерело пакету.

Якщо ви хотіли б мати такий самий ефект з плоским файлом, то сценарії встановлення для Skype повинні були б змінити ваш source.list, який, напевно, багато системних адміністраторів виявив би злегка нервовим.

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

Я припускаю, що це робить файли меншими, тому їх легше читати - у випадку, наприклад, правил sudo, які можуть бути досить довгими, це спрощує створення стандартизованого набору правил для одного типу користувачів (скажімо, розробник ), і додайте їх до каталогу config, якщо розробникам слід дозволити судо на цій машині; Таким чином, вам потрібно підтримувати менше файлів - просто файл для розробників, для адміністраторів, для sysops тощо, а не для кожної можливої ​​їх комбінації.

Там я суперечив собі.