staging.inyokaproject.org

noisefloor schrieb:

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.

Ich verstehe nicht ganz, was Du meinst? Also, es ging mir nicht um die lexikalische Reihenfolge oder so, sondern um das Grundprinzip; das in Linux - neben conf.d-Modell - vielfach übliche Model der Trennung der Konfigurationsdateien in zwei Ordnern:

• conf-available - hier liegen meist vom Paketbetreuer vorgefertigte aber nicht dringend notwendige Konfigurationen, die der User nach Belieben aktivieren oder deaktivieren kann, in dem er sie im:

• conf-enabled verlinkt

Mein Vorschlag wäre, das mit aufzunehmen. So wäre der Artikel auch nicht so steif auf das conf.d-Modell fixiert, sondern würde die gängigsten und üblichen Konfigurations-Architekturen nahe bringen. Deshalb...

noisefloor schrieb:

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

...würde ich das genau so machen +1 , damit der Artikel flexibler auf das Thema Konfigurations-Architekturen eingeht bzw noch eingehen kann, wenn Du oder jemand anders das irgendwann ergänzen will.

Aber grundsätzlich sollte der Artikel sich nicht nur um das conf.d-Modell drehen, sondern conf.d sollte als eine der wichtigsten Konfigurations-Architekturen aufgeführt werden.

Hallo,

was mir dazu gestern auch noch später eingefallen ist: das, was mit der lexikalischen Reihenfolge unter Funktionsweise steht, trifft ja auch noch mehr Konfig-Verzeichnisse nicht zu, nicht nur auf Apache. Bei systemd ist es auch nicht so, bei nginx auch nicht. Werde den Artikel nochmal entsprechend erweitern, dann passt denke ich auch das von Apache rein.

Gruß, noisefloor

noisefloor schrieb:

[…] lexikalischen Reihenfolge […] trifft ja auch noch mehr Konfig-Verzeichnisse nicht zu […]. Bei systemd ist es auch nicht so

Doch, bei systemd-Programmen ist es in der Regel so, aber nicht immer. Bei systemd-sleep ist es etwas anders. Bei systemd-networkd ist es, wie ich es im Wiki beschrieben habe. Bei udev gilt es auch.

Ich würde das von udev und systemd-networkd gelebte Verhalten als den Standardfall ansehen. Der Artikel könnte dann weitere Programme benennen, die diesen Standardfall realisieren und ebenso solche mit Abweichungen. Bei den Abweichlern würde ich erst einmal nur auf die Manpage verweisen, welche ja das jeweilige Verhalten beschreibt.

Mir gefällt „lexikalische Reihenfolge“, aber ich bin unsicher, ob es der richtige Begriff ist. Gemeint ist jedenfalls: Lexikographische Ordnung

Hallo,

hab's nochmal erweitert, bitte nochmal drüber schauen.

Gruß, noisefloor

1. Diesen Satz verstehe ich nicht:

Dies passiert einerseits aus der Notwendigkeit, dass Paketbetreuer eines Paketes XYZ nicht den Inhalt der Konfigurationsdatei von Paket ABC verändern dürfen, selbst wenn es für den Gebrauch von Paket B unerlässlich ist.

• Gemeint ist: „Dies passiert einerseits aus der Notwendigkeit, dass Paketbetreuer eines Paketes B nicht den Inhalt der Konfigurationsdatei von Paket A verändern dürfen, selbst wenn es für den Gebrauch von Paket B unerlässlich ist.“ ?

2. In der Auflistung der wichtigen Programm fehlt udev, welches das gleiche Spiel mit seinen Verzeichnissen rules.d aufführt.

3. „lexographischer Ordnung“ gefällt mir auch, ist aber wohl ungebräuchlich und wird bei Google zu „lexikographischer Ordnung“, was auch gemeint ist.

4. Dreckfuhler: Dateiemn

5. Der Satz

Werden die Dateiemn in lexographischer Ordnung gelesen überschreiben später gelesene Werte frühere.

stimmt nicht immer bzw. er stimmt so nur für Skalare. Es gibt auch das Verhalten, dass bei bestimmten Optionen spätere Werte Listen erweitert werden. (Kommt später im Text, wird mir aber aus dem Text so nicht klar.)

6. Neben /lib und /etc gibt es auch noch /run. Meist in der Variante lib < run < etc, wenn man „<“ liest als „rechte Seite überschreibt linke Seite“.

7. Ein Idiom zur Abfrage des gesamten Regelschatzes für ein Programm, hier am Beispiel systemd-networkd, welches etwas andere Namen für die Verzeichnisse verwendet:

grep -r = /etc/systemd/networkd.conf /{lib,run,etc}/systemd/network/ 

Hallo,

done. Bei Punkt 7 ist mir nicht klar, wie du das wo in den Artikel einbauen würdest.

Gruß, noisefloor

noisefloor schrieb:

[…] wo in den Artikel einbauen

Z.B. unter Problembehebung. Wenn etwas nicht funktioniert, ist ein sinnvoller erster Schritt eine lesbare Übersicht der verstreut liegenden Konfiguration zu erzeugen.

Ok... kannst du das einbauen? Ich glaube zwar zu verstehen, was du meinst. Aber effektiver ist wahrscheinlich, wenn du es einbaust ☺

Gruß, noisefloor

noisefloor schrieb:

Ok... kannst du das einbauen?

… getan.

Der Satz

Dies passiert einerseits aus der Notwendigkeit, dass Paketbetreuer eines Paketes XYZ nicht den Inhalt der Konfigurationsdatei von Paket ABC verändern dürfen, selbst wenn es für den Gebrauch von Paket ACB unerlässlich ist.

verwirrt mich noch immer. Neben einem Schreibfehler (?) vermute ich zusätzlich noch einen fehlerhaften Bezug.

Hallo,

sonst noch Einwände oder Verbesserungsvorschläge von jemandem?

Gruß, noisefloor

Hallo,

Artikel ist jetzt im Wiki, Danke für den Input zur Fertigstellung des Artikels ☺

Gruß, noisefloor

Auch von mir ein Danke, dass mein stümperhafter Anlauf in etwas Brauchbares verwandelt wurde. 👍

Hallo,

dass mein stümperhafter Anlauf

Nee, dass stimmt ja mal nicht! Der Ansatz war schon gut und der aktuelle Artikel basiert ja immer noch darauf. Das ganze ist halt nur ein bisschen komplexer, wenn man ein wenig tiefer gut.

Dir gebührt nichts desto trotz die Ehre, auch nach > 20 Jahren ubuntuusers.de Wiki noch eine gute Idee für einen Grundlageartikel gehabt zu habe. 👍