Was ist der Vorteil von /etc/apt/sources.list.d gegenüber /etc/apt/sources.list?

14

Ich weiß, dass diese Frage bereits gestellt wurde, aber ich akzeptiere die Antwort "Sie können benutzerdefinierte Ergänzungen deutlich sehen" nicht. Wenn ich ppa's hinzufüge (was ich seit Jahren nicht getan habe), drücke ich eine Taste auf meiner Tastatur mit der Aufschrift "Enter", mit der ich vor dem neuen Eintrag eine leere Zeile einfügen kann (ich würde sogar einen erläuternden Kommentar hinzufügen, aber ich bin ein Tech Schriftsteller, so ....). Ich mag meine sources.confsauber und ordentlich.

/etc/apt/sources.d

Bedeutet, dass ich ein halbes Dutzend Dateien zu analysieren habe, anstatt nur eine.

AFAIK, es ist "absolut" kein Vorteil, eine Konfigurationsdatei gegenüber 6 zu haben (vielleicht haben Sie 3 oder sogar 2, egal ... 1 schlägt immer noch 2).

Kann mir bitte jemand einen rationalen Vorteil einfallen lassen? "Man kann die kundenspezifischen Ergänzungen klar erkennen" ist eine Entschuldigung für einen armen Mann.

Ich muss hinzufügen, ich liebe Veränderung jedoch NUR, wenn die Veränderung Vorteile mit sich bringt.

Nach der ersten Antwort bearbeiten:

Neuinstallationen, die eigene Repos benötigen, müssen keine Flatfiles durchsuchen, um sicherzustellen, dass keine doppelten Einträge hinzugefügt werden.

Jetzt müssen sie ein Verzeichnis nach dupe's durchsuchen, anstatt nach einer flachen Datei. Es sei denn, sie gehen davon aus, dass der Administrator die Dinge nicht ändert ...

Ein Systemadministrator kann einen Repository-Satz auf einfache Weise deaktivieren (durch Umbenennen) oder entfernen (durch Löschen), ohne eine monolithische Datei bearbeiten zu müssen.

Der Administrator muss das Verzeichnis grep durchsuchen, um die entsprechende Datei zu finden, die umbenannt werden soll, bevor er EINE Datei durchsucht und eine Zeile auskommentiert, die einzeilig für "fast" jeden Administrator steht.

Es ermöglicht einem Paketbetreuer, einen einfachen Befehl zum Aktualisieren von Repository-Speicherorten einzugeben, ohne sich Gedanken darüber machen zu müssen, dass die Konfiguration für nicht verwandte Repositorys versehentlich geändert wird.

Ich verstehe das nicht, ich gehe davon aus, dass der Paketbetreuer die URL seines Repository kennt. Auch hier muss sedein Verzeichnis anstelle einer einzelnen Datei angelegt werden.

thecarpy
quelle
2
Die Kommentare und Fragenbearbeitungen haben sich schnell von "Versuchen, die Frage zu beantworten" zu "Schimpfen über die Existenz des Problems" entwickelt. Die nützlichen Kommentare erscheinen bereits in der akzeptierten Antwort
Michael Mrozek

Antworten:

14

Auf technischer Ebene kommt es als jemand, der diese Änderungen in einigen großen und beliebten Systeminfo-Tools bewältigen musste, im Grunde auf Folgendes an:

Für 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

Beachten Sie, dass diese Tests falsch sind, wenn Sie eine Repo-Zeile auskommentiert haben, es sei denn, sie führen dieselbe Prüfung wie unten durch. Wenn sie dieselbe Prüfung wie unten durchführen, ist die Komplexität identisch, außer dass sie für viele Dateien ausgeführt wird, nicht für eine. Außerdem können sie, sofern sie nicht ALLE möglichen Dateien prüfen, ein doppeltes Element hinzufügen, das sich dann beschwert, bis Sie eine von ihnen löschen.

Für 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

Die Google Chrome-Entwickler haben nicht auf das Vorhandensein von Google Chrome-Quellen geprüft und sich darauf verlassen, dass der genaue Dateiname, den das Chrome-Paket erstellen würde, vorhanden ist. In allen anderen Fällen würden sie eine neue Datei in sources.list.d erstellen, die genau so heißt, wie sie es wollten.

Um zu sehen, welche Quellen Sie haben, ist es natürlich nicht so hübsch, da Sie nicht einfacher zu lesen und zu pflegen sein können als:

cat /etc/sources.list

Dies geschah also im Wesentlichen zum Zweck automatisierter Updates und um einfache Einzelbefehle bereitzustellen, die Sie den Benutzern geben können, soweit ich das beurteilen kann. Für Benutzer bedeutet dies, dass sie viele Dateien statt einer Datei lesen müssen, um zu sehen, ob ein Repo hinzugefügt wurde, und für apt bedeutet dies, dass sie auch viele Dateien statt einer Datei lesen müssen.

Da in der realen Welt, wenn Sie dies gut machen wollen, müssen Sie die Überprüfung aller Dateien unterstützen, unabhängig von deren Namen, und dann testen, ob die auszuführende Aktion erforderlich ist oder nicht.

Wenn Sie es jedoch nicht gut machen würden, würden Sie einfach die Überprüfungen ignorieren, um festzustellen, ob sich das Element irgendwo in den Quellen befindet, und einfach nach dem Dateinamen suchen. Ich glaube, das ist, was die meisten automatisierten Dinge tun, aber da ich am Ende einfach alles überprüfen musste, um es aufzulisten und danach zu handeln, ob eine dieser Dateien übereinstimmt, war das einzige echte Ergebnis, dass es viel komplizierter wurde.

Massenbearbeitung

Angesichts der Tatsache, dass viele Server ausgeführt werden, wäre ich versucht, einfach einen nächtlichen Job zu schreiben, der /etc/apt/sources.list.d/ durchläuft und zuerst überprüft, ob das Element bereits in sources.list enthalten ist Fügen Sie dieses Element nicht zu sources.list hinzu, löschen Sie die Datei sources.list.d, und löschen Sie, falls bereits in sources.list vorhanden, einfach die Datei sources.list.d

Da es KEIN Negativ ist, nur sources.list zu verwenden, was nicht nur einfach und wartungsfreundlich ist, ist das Hinzufügen einer solchen Liste möglicherweise keine schlechte Idee, insbesondere bei kreativen, zufälligen Aktionen von Systemadministratoren.

Wie im obigen Kommentar erwähnt, druckt inxi -r die aktiven Repos ordentlich pro Datei aus, bearbeitet oder ändert sie aber natürlich nicht, so dass dies nur die halbe Lösung wäre. Wenn es sich um viele Verteilungen handelt, ist es mit Sicherheit eine Qual, zu lernen, wie die einzelnen Verteilungen funktionieren, und Zufälligkeit ist leider eher die Regel als die Ausnahme.

Lizardx
quelle
Kommentare sind nicht für eine längere Diskussion gedacht. Diese Unterhaltung wurde in den Chat verschoben .
Terdon
38

Wenn Sie jedes Repository (oder jede Sammlung von Repositorys) in einer eigenen Datei haben, ist die Verwaltung sowohl manuell als auch programmgesteuert einfacher:

  • Neuinstallationen, die eigene Repos benötigen, müssen keine Flatfiles durchsuchen, um sicherzustellen, dass keine doppelten Einträge hinzugefügt werden.
  • Ein Systemadministrator kann einen Repository-Satz auf einfache Weise deaktivieren (durch Umbenennen) oder entfernen (durch Löschen), ohne eine monolithische Datei bearbeiten zu müssen.
  • Es ermöglicht einem Paketbetreuer, einen einfachen Befehl zum Aktualisieren von Repository-Speicherorten einzugeben, ohne sich Gedanken darüber machen zu müssen, dass die Konfiguration für nicht verwandte Repositorys versehentlich geändert wird.
DopeGhoti
quelle
11
Das ist besser als die akzeptierte Antwort ... Das Schlüsselkonzept ist "Eigentum". Das .dDesign trennt den Konfigurationsstatus der verschiedenen Entitäten klar voneinander. Man könnte von einem Paket besessen sein. Ein anderer könnte über installiert werden wget .... Woher "weiß" eine automatisierte oder halbautomatisierte Prozedur mit einer einzelnen Monsterdatei, welches Teil der Konfiguration sie besitzt? Dies ist nicht der Fall, weshalb das .dDesign überlegen ist.
Nemo
12
Ich bin mir nicht sicher, was Handarbeit angeht, aber das habe ich seit Jahren nicht mehr gemacht. Es kommt der programmatischen Verwaltung zugute. Wenn Sie eine Konfigurationsverwaltungssoftware wie Puppet verwenden, ist es einfacher, eine Datei im Verzeichnis abzulegen oder zu entfernen und apt update auszuführen, als eine Datei zu analysieren, um Zeilen hinzuzufügen oder zu entfernen. Zumal dadurch vermieden wird, dass eine einzelne 'Datei'-Ressource von mehreren unabhängigen Modulen verwaltet werden muss. Ich schätze Ubuntus breite Verwendung von ".d" -Dateien aus diesem Grund.
Martijn Heemels
2
@MartijnHeemels Ich würde Ihren Kommentar hundertmal positiv bewerten, wenn ich könnte. Für mich persönlich wurden die Vorteile des .dDesigns sofort deutlich, als ich anfing, ein umfangreiches Puppet / Salt-Konfigurationsmanagement durchzuführen.
Smitelli
3
@thecarpy, wenn deine Admins dich täuschen wollen, solltest du mehr vertrauenswürdige Admins finden. Das, was ich (oder in der Tat jemand) als "völligen Müll" bezeichne, ist bestenfalls unhöflich.
DopeGhoti
7
Bestätigung aus Sicht von ops. Es ist viel sauberer, wenn ganze Dateien entweder von bestimmten Paketen oder von Modulen Ihres Konfigurationsverwaltungssystems bereitgestellt und verwaltet werden, als wenn Sie versuchen, für jede Anwendung, die Sie konfigurieren, sofort einen Parser zu schreiben. Es mag für apt trivial erscheinen, aber dann gibt es eine Reihe anderer Systeme, die dieselbe Strategie anwenden können (logrotate, cron, sysctl, sudoers, rsyslog, modprobe, ... Configs aus service.d/*Dateien laden ). Dateien bereitstellen, anstatt vorhandene zu ändern Einsen ist auch besser für das Zwischenspeichern / Vergleichen von Bildern.
Viraptor
10

Wenn Sie Ihre Server manuell verwalten, werden die Dinge verwirrender. Es kommt jedoch der programmatischen Verwaltung zugute (dh "Konfiguration als Code"). Wenn Sie Konfigurationsverwaltungssoftware wie Puppet, Ansible, Chef usw. verwenden, ist es einfacher, eine Datei in einem Verzeichnis abzulegen oder zu entfernen und auszuführen apt update, als eine Datei zu analysieren, um bestimmte Zeilen hinzuzufügen oder zu entfernen.

Zumal dadurch vermieden wird, dass der Inhalt einer einzelnen 'Datei'-Ressource verwaltet werden muss, z. B .: /etc/apt/sources.listvon mehreren unabhängigen Modulen, die von Dritten geschrieben wurden.

Ich schätze Ubuntus breite Verwendung von ".d" -Dateien aus diesem speziellen Grund, dh sudoers.d, rsyslog.d, sysctl.d, cron.d, logrotate.d usw.

Martijn Heemels
quelle
5

Wie nemo in einem Kommentar betonte, besteht einer der Hauptvorteile eines Verzeichnisses darin, dass der Begriff "Eigentum" zugelassen wird.

Moderne Linux-Distributionen und -Installer basieren alle auf der Idee von Paketen - unabhängigen Software-Teilen, die so weit wie möglich atomar hinzugefügt und entfernt werden können. Wann immer Sie ein Paket mit dpkg(und damit apt) installieren , wird protokolliert, welche Dateien auf dem System von diesem Installationsprogramm erstellt wurden. Das Deinstallieren des Pakets kann dann weitgehend aus dem Löschen dieser Dateien bestehen.

Die derzeit akzeptierte Antwort geht davon aus, dass ein Google Chrome-Installer davon ausgegangen ist, dass er nur einen Eintrag an der von ihm erwarteten Position erstellen oder löschen sollte. Die Automatisierung aller anderen Vorgänge führt jedoch zu allen Arten von schrecklichen Randfällen. zum Beispiel:

  • Wenn die Zeile sources.listbei der Installation vorhanden, aber auskommentiert ist, sollte das Installationsprogramm sie auskommentieren oder ein Duplikat hinzufügen?
  • Wenn das Deinstallationsprogramm die Zeile entfernt, der Benutzer jedoch Kommentare daneben hinzugefügt oder bearbeitet hat, bleibt die Datei mit einem fehlerhaften Kommentar zurück.
  • Wenn der Benutzer die Zeile manuell hinzufügt, weiß das Installationsprogramm möglicherweise, dass es sie nicht hinzufügt. aber woher weiß das Deinstallationsprogramm, dass es nicht entfernt werden soll?

Separate Dateien sind für den Besitz nicht erforderlich. Das Installationsprogramm kann beispielsweise einen Kommentarblock enthalten, der besagt, dass es einen bestimmten Satz von Zeilen "besitzt". In diesem Fall wird die Datei immer nach genau diesem Block durchsucht, nicht nach einer anderen Erwähnung desselben Repositorys.

Wenn alles andere gleich ist, ist das Automatisieren von Änderungen an einer einzelnen Konfigurationsdatei immer komplizierter als das Automatisieren des Erstellens und Löschens einer separaten Datei. Zum Entfernen von Linien ist zumindest die Verwendung eines Mustersuchwerkzeugs erforderlich, z sed. In einer komplexeren Datei ist zum Hinzufügen und Entfernen von Zeilen möglicherweise ein Skript-Tool erforderlich, das das Dateiformat kennt, um sie einem geeigneten Abschnitt hinzuzufügen oder zu entfernen, ohne die umgebende Formatierung zu beschädigen.

Da ein Installateur ohnehin vermeiden müsste, mit manuell bearbeiteten Konfigurationen herumzuspielen, ist es sinnvoll, automatisierte, werkzeugeigene Konfigurationen in einem Format abzulegen, das für automatisierte Werkzeuge einfach zu verwalten ist.

IMSoP
quelle
3

Auf diese Weise können Pakete zusätzliche Quellen hinzufügen, ohne auf Skripte zurückgreifen zu müssen.

Wenn Sie beispielsweise das Skype-Paket von Microsoft installieren, wird automatisch eine Quelle für skype.com zum Herunterladen von Updates konfiguriert. Durch das Entfernen des Skype-Pakets vom System wird auch diese Paketquelle wieder deaktiviert.

Wenn Sie den gleichen Effekt mit einer Einfachdatei erzielen möchten, müssen die Installationsskripte für Skype Ihre sources.list ändern, was wahrscheinlich viele Systemadministratoren als etwas nervig empfinden.

Simon Richter
quelle
-3

Ich bin nicht davon überzeugt, dass es einen guten Grund gibt - außer es scheint in Mode zu sein. Für mich verstößt es gegen eine Regel, dass ein Verzeichnis entweder ein Blatt oder ein Knoten sein sollte - dh, dass es nur Dateien oder Verzeichnisse enthalten sollte, nicht eine Mischung aus beiden.

Ich nehme an, dass es Dateien kleiner macht, so dass sie leichter zu lesen sind - zum Beispiel bei Sudo-Regeln, die ziemlich lang sein können, ist es einfacher, einen standardisierten Satz von Regeln für einen Benutzertyp zu haben (sagen wir einen Entwickler) ), und fügen Sie diese dem Konfigurationsverzeichnis hinzu, wenn devs auf diesem Rechner sudo dürfen; Daher müssen Sie weniger Dateien verwalten - nur eine Datei für Entwickler, Administratoren, Systemadministratoren usw. und nicht für jede mögliche Kombination davon.

Dort habe ich mir widersprochen.

Graham Nicholls
quelle
3
Ich würde in der Regel nicht "ein Verzeichnis sollte entweder ein Blatt oder ein Knoten sein" nehmen. Schauen Sie sich als erfundenes Beispiel an /var/log. Ein einfacher Daemon könnte eine einzige Datei schreibt direkt in: /var/log/simple.log. Ein komplexeres Daemon könnte sein eigenes Unterverzeichnis benötigen /var/log/complex/a.log, /var/log/complex/b.log, /var/log/complex/c.log... ähnliche Muster mit configs.
smitelli
Ich würde das als /var/log/simple/log.1 .2 usw. gestalten. Der Pfad gibt Ihnen Informationen. SO var log würde Unterverzeichnisse für jeden Protokolltyp enthalten, und jedes Unterverzeichnis könnte eine oder mehrere Dateien enthalten. Ich gebe zu, es gibt Beispiele, bei denen Ausnahmen angemessen sind, aber im Allgemeinen ist es gut. Ich hasse es, private Verzeichnisse zu sehen, in denen sich Akten befinden, IMO der Desorganisation.
Graham Nicholls
3
Es gibt einen guten Grund, aber Sie müssen als Administrator denken, bevor Sie es verstehen. Siehe die Antwort von DopeGhoti.
Reinierpost
Nun, das hat mich an meinen Platz gebracht, nicht wahr? Offensichtlich kann ich nicht als Administrator denken - oder ich bin einfach anderer Meinung als Sie.
Graham Nicholls