Jaka jest korzyść z /etc/apt/sources.list.d nad /etc/apt/sources.list

Wiem, że to pytanie zostało już zadane, ale nie akceptuję odpowiedzi „możesz wyraźnie zobaczyć niestandardowe dodatki”. Kiedy dodam ppa (czego nie robiłem od lat), nacisnąłem klawisz na klawiaturze z etykietą „Enter”, który pozwala mi dodać pusty wiersz przed nowym wpisem (dodałbym nawet komentarz wyjaśniający, ale jestem pisarz techniczny, więc ....). Lubię moją sources.confczystość i porządek.

/etc/apt/sources.d

Oznacza to, że mam do przeanalizowania pół tuzina plików zamiast jednego.

AFAIK, „absolutnie” nie ma żadnej korzyści z posiadania jednego pliku konfiguracyjnego w porównaniu do 6 (dla argumentu, może masz 3 lub nawet 2, nie ma znaczenia ... 1 nadal bije 2).

Czy ktoś może wymyślić racjonalną przewagę, „wyraźnie widać niestandardowe dodatki” to wymówka biedaka.

Muszę dodać, że uwielbiam zmianę TYLKO wtedy, gdy zmiana przynosi korzyści.

Edytuj po pierwszej odpowiedzi:

Pozwala nowym instalacjom, które potrzebują własnych repozytoriów, na przeszukiwanie płaskiego pliku w celu upewnienia się, że nie dodaje duplikatów.

Teraz muszą przeszukać katalog w poszukiwaniu duplikatów zamiast płaskiego pliku. Chyba że założą, że administratorzy nie zmieniają rzeczy ...

Umożliwia administratorowi systemu łatwe wyłączenie (przez zmianę nazwy) lub usunięcie (przez usunięcie) zestawu repozytoriów bez konieczności edytowania pliku monolitycznego.

Administrator musi grep katalogu, aby znaleźć odpowiedni plik do zmiany nazwy, wcześniej przeszukał JEDEN plik i skomentował wiersz, sed jeden wiersz dla „prawie” dowolnego administratora.

Pozwala opiekunowi pakietu wydać proste polecenie aktualizacji lokalizacji repozytorium bez martwienia się o przypadkową zmianę konfiguracji niepowiązanych repozytoriów.

Nie rozumiem tego, „zakładam”, że opiekun pakietu zna adres URL swojego repozytorium. Ponownie, musi do sedkatalogu zamiast jednego pliku.

Na poziomie technicznym, ponieważ ktoś, kto musiał poradzić sobie z tymi zmianami w kilku dużych i popularnych narzędziach do informacji o systemie, w zasadzie sprowadza się do tego:

Dla 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

Zauważ, że jeśli nie wykonują oni tej samej kontroli, co poniżej, jeśli skomentowałeś linię repo, testy te byłyby błędne. Jeśli przeprowadzają tę samą kontrolę, co poniżej, to jest dokładnie taka sama złożoność, z wyjątkiem wielu plików, a nie jednego. Ponadto, chyba że sprawdzą WSZYSTKIE możliwe pliki, mogą i często dodają zduplikowany element, co powoduje, że apt narzeka, dopóki nie usuniesz jednego z nich.

Dla źródeł.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

Twórcy Google Chrome nie sprawdzali obecności źródeł Google Chrome, opierając się na dokładnej nazwie pliku, który utworzyłby ich pakiet Chrome. We wszystkich innych przypadkach utworzyliby nowy plik w sources.list.d o nazwie dokładnie tak, jak chcieli.

Aby zobaczyć, jakie masz źródła, nie jest to oczywiście tak ładne, ponieważ nie możesz być łatwiejszy do odczytania i utrzymania niż:

cat /etc/sources.list

Tak więc zostało to zasadniczo zrobione w celu zautomatyzowanych aktualizacji i zapewnienia łatwych pojedynczych poleceń, które można wydawać użytkownikom, o ile wiem. Dla użytkowników oznacza to, że muszą odczytać wiele plików zamiast 1 pliku, aby sprawdzić, czy mają dodane repozytorium, a dla apt oznacza, że ​​musi również odczytać wiele plików zamiast jednego pliku.

Ponieważ w prawdziwym świecie, jeśli zamierzasz to zrobić dobrze, musisz obsługiwać kontrole wszystkich plików, niezależnie od ich nazwy, a następnie przetestować, czy działanie, które ma zostać wykonane, jest wymagane, czy nie.

Jeśli jednak nie zamierzałeś tego zrobić dobrze, po prostu zignoruj ​​kontrole, aby sprawdzić, czy element znajduje się gdzieś w źródłach, i po prostu sprawdź nazwę pliku. Sądzę, że to właśnie robi większość zautomatyzowanych rzeczy, ale ponieważ w końcu musiałem po prostu sprawdzić wszystko, aby móc je wypisać i działać na podstawie dopasowania jednego z tych plików, jedynym prawdziwym rezultatem było uczynienie go o wiele bardziej skomplikowanym.

Edycje zbiorcze

Biorąc pod uwagę uruchamianie wielu serwerów, kusiłoby mnie, aby po prostu napisać nocne zadanie, które przechodzi przez /etc/apt/sources.list.d/ i sprawdza najpierw, czy element nie znajduje się już w source.list, a jeśli jest nie, dodaj ten element do sources.list, usuń plik sources.list.d, a jeśli już znajduje się w sources.list, po prostu usuń plik sources.list.d

Ponieważ nie ma negatywnego wpływu na używanie tylko źródeł. Lista poza prostotą i łatwością konserwacji, dodanie czegoś takiego może nie być złym pomysłem, szczególnie biorąc pod uwagę kreatywne losowe działania administratorów sys.

Jak zauważono w powyższym komentarzu, inxi -r starannie wydrukuje dla każdego pliku aktywne repozytorium, ale nie będzie ich oczywiście edytować ani modyfikować, więc byłoby to tylko połowa rozwiązania. Jeśli jest wiele dystrybucji, to z pewnością uczenie się, jak to robi, z pewnością jest przypadkiem, a przypadkowość z pewnością jest raczej regułą niż wyjątkiem.

Posiadanie każdego repozytorium (lub zbioru repozytoriów) we własnym pliku ułatwia zarządzanie, zarówno ręcznie, jak i programowo:

• Pozwala nowym instalacjom, które potrzebują własnych repozytoriów, na przeszukiwanie płaskiego pliku w celu upewnienia się, że nie dodaje duplikatów.
• Umożliwia administratorowi systemu łatwe wyłączenie (przez zmianę nazwy) lub usunięcie (przez usunięcie) zestawu repozytoriów bez konieczności edytowania pliku monolitycznego.
• Pozwala opiekunowi pakietu wydać proste polecenie aktualizacji lokalizacji repozytorium bez martwienia się o przypadkową zmianę konfiguracji niepowiązanych repozytoriów.

Jeśli ręcznie zarządzasz swoimi serwerami, zgodzę się, że to czyni zamieszanie bardziej skomplikowanym. Korzystne jest jednak zarządzanie programowe (tzn. „Konfiguracja jako kod”). Podczas korzystania z oprogramowania do zarządzania konfiguracją, takiego jak Puppet, Ansible, Chef itp., Łatwiej jest po prostu upuścić lub usunąć plik w katalogu i uruchomić apt update, zamiast analizować plik w celu dodania lub usunięcia niektórych linii.

Zwłaszcza, że ​​pozwala to uniknąć konieczności zarządzania zawartością pojedynczego zasobu „plikowego”, np .: /etc/apt/sources.listz wielu niezależnych modułów napisanych przez strony trzecie.

Doceniam szerokie zastosowanie katalogów „.d” przez Ubuntu z tego konkretnego powodu, tj. Sudoers.d, rsyslog.d, sysctl.d., Cron.d, logrotate.d itp.

Jak zauważył nemo w komentarzu, jedną z kluczowych zalet katalogu jest to, że pozwala on na pojęcie „własności”.

Nowoczesne dystrybucje i instalatory Linuksa oparte są na idei pakietów - niezależnych programach, które można w miarę możliwości dodawać i usuwać atomowo. Ilekroć instalujesz pakiet za pomocą dpkg(i dlatego apt), śledzi on, które pliki w systemie zostały utworzone przez tego instalatora. Odinstalowanie pakietu może wówczas polegać głównie na usunięciu tych plików.

Obecnie akceptowane odpowiedź bierze za złe, że instalator Google Chrome zakłada się, że powinien on tylko utworzyć lub usunąć wpis w komórce to oczekiwano, ale Automatyzacja niczego innego prowadzi do wszelkiego rodzaju strasznych przypadków brzegowych; na przykład:

• Jeśli wiersz istnieje sources.listpodczas instalacji, ale jest skomentowany, czy instalator może go odkomentować, czy dodać duplikat?
• Jeśli dezinstalator usunie wiersz, ale użytkownik dodał lub edytuje komentarze obok niego, plik pozostanie z uszkodzonym komentarzem.
• Jeśli użytkownik ręcznie doda wiersz, instalator może wiedzieć, że go nie dodaje; ale skąd dezinstalator mógłby wiedzieć, żeby go nie usuwać?

Oddzielne pliki nie są wymagane do własności; na przykład instalator może dołączyć blok komentarzy stwierdzający, że „jest właścicielem” określonego zestawu wierszy. W takim przypadku zawsze szukałby w tym pliku dokładnie tego bloku, a nie jakiejkolwiek innej wzmianki o tym samym repozytorium.

Wszystkie pozostałe elementy są jednakowe, automatyzacja edycji pojedynczego pliku konfiguracyjnego zawsze będzie bardziej skomplikowana niż automatyzacja tworzenia i usuwania osobnego pliku. Przynajmniej usuwanie linii wymaga użycia narzędzia do dopasowywania wzorców, takiego jak sed. W bardziej złożonym pliku zarówno dodawanie, jak i usuwanie wierszy może wymagać narzędzia skryptowego ze znajomością formatu pliku, aby dodać do odpowiedniej sekcji lub usunąć bez uszkadzania otaczającego formatowania.

Ponieważ instalator i tak musiałby unikać bałaganu przy ręcznie edytowanej konfiguracji, warto zautomatyzować konfigurację będącą własnością narzędzia w formacie łatwym do zarządzania przez automatyczne narzędzia.

Pozwala to pakietom dodawać dodatkowe źródła bez uciekania się do skryptów.

Na przykład po zainstalowaniu pakietu Skype firmy Microsoft źródło skype.com jest automatycznie konfigurowane do pobierania aktualizacji; usunięcie pakietu Skype z systemu również ponownie wyłącza to źródło pakietu.

Jeśli chcesz uzyskać taki sam efekt w przypadku płaskiego pliku, wówczas skrypty instalacyjne dla Skype będą musiały zmodyfikować plik sources.list, co prawdopodobnie dla wielu administratorów systemu byłoby nieco denerwujące.

Nie jestem przekonany, że istnieje dobry powód - inny niż wydaje się modny. Według mnie łamie to zasadę, że katalog powinien być liściem lub węzłem - tzn. Powinien zawierać tylko pliki lub katalogi, a nie mieszankę obu.

Podejrzewam, że dzięki temu pliki są mniejsze, więc łatwiej je odczytać - w przypadku reguł sudo, które mogą być dość długie, łatwiej jest mieć ustandaryzowany zestaw reguł dla jednego typu użytkownika (powiedzmy programista ) i dodaj je do katalogu config, jeśli devs powinno mieć możliwość sudo na tym komputerze; dlatego musisz utrzymywać mniej plików - tylko plik dla programistów, administratorów, sysopów itp., a nie dla każdej możliwej kombinacji tych plików.

Tam zaprotestowałem.