staging.inyokaproject.org

Habe soeben den Artikel erstellt.

Die Konfigurationsverzeichnisse conf.d finden zwar in einigen Artikeln* bereits Erwähnung, aber ich finde man könnte die Erklärung dazu in einem separaten Artikel auslagern. Spätere Verlinkung erwünscht.

Im Großen und Ganzen ist es das, was ich dazu schreiben wollte. Kritik, Anregung, … ?

*) bspw.

• XServer (Abschnitt „xorg-conf-d“)

• systemd/Umgebungsvariable (Abschnitt „Verzeichnis-system-conf-d“)

• Monit (Abschnitt „Allgemeine-Konfiguration“)

Viele Programme benutzen ein oder mehrere (!) Verzeichnisse conf.d, auch in Kombination mit oder Konkurrenz zu herkömmlichen Konfigurationsdateien. Dabei ist die Behandlung dieser Dateien individuell für jedes Programm.

Die von Dir beschriebene Funktionsweise ist also nicht allgemein gültig. Manchmal überschreiben z.B. später gefundene Werte nicht zuvor genannte, sondern erweitern Listen.

Ohja, ich hatte nur die Sicht des Anwenders im Blick und dabei höhere Ansprüche außen vor gelassen. So geht es natürlich nicht.

Habe es nun ergänzt.

Hallo,

vom Prinzip ein guter, allgemeiner Artikel. Wenn du nichts dagegen hast, würde ich ein paar Formulierungen ändern und ggf. ein paar Ergänzungen machen.

Gruß, noisefloor

Finde auch, so ein allgemeiner Artikel ist ein gute Idee. 👍

... gibt es immer mehr Verzeichnisse conf.d, in denen die Konfiguration auf mehrere kleine Dateien ...

Könnte man so verstehen, als wäre das eine neuere "Erfindung", bzw. wird jetzt gerade erst populär. Vielleicht besser so etwas wie

... verwenden zahlreiche Programme und Dienste Verzeichnisse mit dem Namen conf.d, ...

Ergänzungsvorschläge:

• conf.d steht für die englischsprachige Bezeichnung configuration directory, zu Deutsch Konfigurationsverzeichnis.

• Das Prinzip der sich überschreibenden Files nennt man, wenn ich mich an Ausbildungszeiten noch richtig erinnern kann, "cascading configuration files", bin mir aber nicht mehr sicher. ☺

Einige Programme haben mehrere Konfigurationsdateien und -verzeichnisse – verteilt auf /lib, /usr und /etc.

/usr ist hier falsch. Wenn, dann muss es /usr/lib lauten. Aber das ist redundant, denn /lib ist ja bereits /usr/lib.

Manche Programme verwenden auch zusätzlich /var/lib/, z.B. NetworkManager. Alle Programme, welche mir einfallen, verwenden grundsätzlich zusätzlich /run/, oft mit der Reihenfolge /lib, dann /run, dann /etc, aber eben nicht immer.

Noch einmal: Es gibt für die konkrete Verwendung dieser …/conf.d/… keine allgemein gültige Vorgabe!.Und der Artikel sollte nicht den Eindruck erwecken, das wäre nicht so. Jedes Programm macht es etwas anders, lediglich zufällige Gemeinsamkeiten sind möglich.

Und der Artikel sollte auch die wirklich wichtigen Programme benennen, die diesen Mechanismus überhaupt verwenden. Dazu gehören udev, systemd-networkd, NetworkManager, …

mubuntuHH schrieb:

Finde auch, so ein allgemeiner Artikel ist ein gute Idee.

Im Allgemeinen ist eine allgemeine Beschreibung eine gute Idee für allgemein gleichartig verwendete Ideen/Konzepte/Vorgehensweise/Begriffe usw.

Für die …/conf.d/… trifft dieses Kriterium leider nicht zu.

kB schrieb:

… Es gibt für die konkrete Verwendung dieser …/conf.d/… keine allgemein gültige Vorgabe! …

Dann ist der Artikel ein Fall für „Einen Löschbefehl bereitstellen, der den Papierkorb umgeht“. Was nützt ein Übersichtsartikel, der in „tausende“ Verzweigungen zerfleddert?

Anders gesagt: Ich schmeiße das Handtuch! Wenn die Baustelle jemand übernehmen möchte, …

kB schrieb:

mubuntuHH schrieb:

Finde auch, so ein allgemeiner Artikel ist ein gute Idee.

Im Allgemeinen ist eine allgemeine Beschreibung eine gute Idee für allgemein gleichartig verwendete Ideen/Konzepte/Vorgehensweise/Begriffe usw.

Für die …/conf.d/… trifft dieses Kriterium leider nicht zu.

Da ist was dran. Aber a) Deine Punkte könnten man ja berücksichtigen und einbauen und b) Ist conf.d schon ein üblicher "Standard". Im Link, den fleet_street im Artikel stellte, wird das als "Basics" für Debian beschrieben.

fleet_street schrieb:

Ich schmeiße das Handtuch!

Schade!

Wenn die Baustelle jemand übernehmen möchte, …

Vielleicht ja noisefloor?

noisefloor schrieb:

Wenn du nichts dagegen hast, würde ich ein paar Formulierungen ändern und ggf. ein paar Ergänzungen machen.

Hallo,

Alle Programme, welche mir einfallen, verwenden grundsätzlich zusätzlich /run/,

/run wird doch zur Laufzeit angelegt - d.h. wenn da Konfig-Daten drin stehen sollten müssen die doch voranders her kommen?

Vielleicht ja noisefloor?

Bin dabei ☺

Gruß, noisefloor

Hallo,

habe ein bisschen an dem Artikel weiter gearbeitet. Wenn noch jemand Ergänzungen oder Änderungen machen möchte wäre jetzt ein günstiger Zeitpunkt.

Gruß, noisefloor

👍

Ich finde, man sollte noch die Variante der vorgefertigten oder "parkbaren" Konfigurationsdateien erwähnen, die in den conf-available - Verzeichnissen sind und dann mittels Softlink ins conf-enabled aktiviert werden können. Analog die Deaktivierung. Insbesondere ist das bei Webdiensten beliebt, wie z.B. Apache2 und monit. Apache2 hat ja bekanntlich sogar Befehle, die das sauber für einen erledigen (a2enconf meine.conf und a2disconf). Vielleicht sollte man dann auch den Artikel allgemeiner nennen, z.B. "Konfigurationsverzeichnisse" (ohne "conf.d"). Dort dann die wichtigsten Prinzipien, also das klassische conf.d sowie das conf-enabled-System auflisten. Diese Liste wäre dann (in Zukunft) beliebig erweiterbar und würde weitere (wichtige) Varianten aufführen können. Würde dadurch auch dem Rechnung tragen, was kB erwähnte und jetzt ja auch im Artikel schon gut erklärt wird. Und er ist dann noch allgemeiner und damit auch umfassender.

noisefloor schrieb:

[.] /run wird doch zur Laufzeit angelegt - d.h. wenn da Konfig-Daten drin stehen sollten müssen die doch voranders her kommen?

Ja. Beispielsweise schreibt Netplan während seiner Ausführung per initrd Konfigurationsdateien für systemd-networkd und/oder NetworkManager in das frisch angelegte Verzeichnis /run im späteren Root-Verzeichnis des gerade startenden Betriebssystems.

Man könnte auch vor dem Einschlafen eines Systems etwas in /run hinterlegen, was nach dem Aufwachen berücksichtigt werden könnte.

Oder man schreibt zum Testen selbst etwas nach /run und startet das betreffende Programm neu. Wenn dabei etwas schief geht, kann man brutal den Stecker ziehen und das System mit der erprobten alten Konfiguration neu kalt starten.

Ich habe übrigens gar nichts gegen allgemeine Artikel und bin grundsätzlich sehr dafür, halte es aber für außerordentlich schwierig und anspruchsvoll, bei diesem Thema wirklich allgemeingültige Aussagen zu formulieren. Aber vielleicht ist gerade die Information, dass verschiedene Programme sich hierbei im Detail unterschiedlich verhalten, ein wertvoller Hinweis für die Leser dieses Artikels.

Hallo,

Apache2 hat ja bekanntlich sogar Befehle, die das sauber für einen erledigen (a2enconf meine.conf und a2disconf).

BTW: gestern habe ich im Rahmen der Recherchen für diesen Artikel gelesen, dass das eine "Erfindung" von Debian ist - habe das aber nicht tiefer verfolgt. Aber zumindest bei nginx ist es wohl so, dass Upstream die Verzeichnisse "sites-available" und "sites-enabled" nicht vorhanden sind. Ist aber im Kontext des Artikels hier egal.

Aber vielleicht ist gerade die Information, dass verschiedene Programme sich hierbei im Detail unterschiedlich verhalten, ein wertvoller Hinweis für die Leser dieses Artikels.

Ich denke, dass das auch die Kernaussage des Artikels sein sollte: wenn das Verzeichnis da ist bzw. das Prog es anbietet → nutze es. Wenn nicht → dann nutz' halt den andere, wie auch immer vorgegebenen Weg des Programms.

Gruß, noisefloor

Hallo,

dazu ist mir noch was eingefallen: mubuntuHH schrieb:

Ich finde, man sollte noch die Variante der vorgefertigten oder "parkbaren" Konfigurationsdateien erwähnen, die in den conf-available - Verzeichnissen sind und dann mittels Softlink ins conf-enabled aktiviert werden können.

Passt IMHO im Kontext der Artikels nicht. Weil darin liegen ja einfach "nur" Dateien, die lexikalische Reihenfolge ist AFAIK egal und damit werden auch keine systemseitigen Dateien überschrieben, weil die in dem Kontext gar nicht existieren.

Andere Frage @all: wie nennen wir den Artikel? Mein Vorschlag wäre "Konfigurationsverzeichnisse" und "conf.d" als Redirect.

Gruß, noisefloor