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

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.

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.

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.

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.

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.

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.

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.