Über Konfiguration. oder, was es mit all den conf.d Verzeichnissen auf sich hat.

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Über Konfiguration. oder, was es mit all den conf.d Verzeichnissen auf sich hat.

    An verschiedenen Stellen trifft man immer wieder auf conf.d Verzeichnisse. Und oft liegen darin Dateien, deren Dateinamen mit Nummern beginnen.
    Schon aus dem Namen configuration.d kann man leicht erahnen, dass es sich um die Konfiguration der jeweiligen Programme handelt.

    Programme kann man grob einteilen in schlichte, die mit ein paar Parametern vollständig konfiguriert sind, oder gar keine Konfiguration benötigen.
    Und Programme, die sich auf verschiedene Arten konfigurieren lassen und ein paar bis ziemlich unendliche viele Einstellungen kennen.

    Die Konfiguration eines Programmes kann man meist über ENVironment Variablen steuern, oder über Optionen, die man beim Aufruf angibt, oder über Konfigurationsdateien.
    Meist verwenden richtig große Programme alle Varianten sogar gleichzeitig.
    Das ist gewollt und bietet ziemliche Flexibilität.
    Und natürlich gnadenlose Verwirrung.

    Die ich erst mal auf eine breitere Basis stellen möchte, damit wir auch angemessen verwirrt starten können.
    Es gibt nämlich mehrere Syntaxen, die verwendet werden, und dann natürlich auch anders behandelt werden wollen.
    Jede davon hat nämlich ihre eigenen Macken.

    So gibt es in Linux Konfigdateien, die, wie eine Windows.ini Datei aufgebaut sind. Die sehen dann so aus:

    Quellcode

    1. [Sectionsname halligalli]
    2. ein_Eintrag_in_Section_halligalli = prima
    3. [nächste Sektion mit vielleicht einer Leerzeile davor]
    4. erster_Eintrag_nächste_Sektion_mit_vielleicht_einer_Leerzeile_davor = oberprima
    5. was anderes = nicht so ganz oberprima
    Und es gibt die sogenannten Key-Value Datenbanken. Die sind ziemlich alt, und erscheinen ganz brandaktuell unter neuen Buzzword- Bezeichnungen, wie "nosql" oder dergleichen wieder. Alter Wein in neuen Schläuchen.
    Ihr wesentliches Merkmal ist, dass das allererste Wort in einer Zeile den Schlüssel darstellt, alle weiteren Worte den Wert.
    Der fast überall laufende MTA (==MailTransferAgent) postfix verwendet diese Art.

    Quellcode

    1. # eine Zeile aus /etc/postfix/master.cf
    2. submission inet n - - - - smtpd
    3. -o syslog_name=postfix/submission
    4. -o smtpd_tls_wrappermode=no
    5. -o smtpd_tls_security_level=encrypt
    6. -o smtpd_sasl_auth_enable=yes
    Und ja! Das wird als eine Zeile gelesen. Obwohl am Ende jeder tatsächlichen Zeile auch wirklich ein NeueZeilezeichen ( \n ) steht, ist es dennoch nur eine einzige Zeile, weil am Anfang der folgenden Zeilen Leerzeichen stehen. ( Zeilen die mit " -option ..." beginnen)

    Eine Besonderheit dieses Formates. Bei allen anderen kann man auch sehr lange Zeilen schreiben, die am Bildschirm auch umgebrochen dargestellt werden können, aber die dürfen dann KEIN Newlinezeichen enthalten.

    Dieses Format nennt sich übrigens tatsächlich "Berkeley Datenbank Format". Es ist wirklich eine Datenbank, die auch sehr, sehr schnell beim Finden einzelner Einträge ist.

    Und es gibt natürlich noch einfache Konfigurationsdateien, die einfach in Zeilen organisiert sind. Die können ein "=" - Zeichen verlangen, oder auch nicht. Sie können auch den Doppelpunkt als Trenner von Key und Value verwenden, und es gibt noch ein paar Exoten.
    Es gibt sogar ein eigenes Paket, mit dem man selber eine solche Syntax festlegen kann, und dann solche Dateien damit auch einlesen und analysieren kann.

    Ein Sonderfall sind Konfigurationsdateien für die Shells. Die müssen der Shellsyntax folgen. Und deshalb gibt es dort nur das "="-Zeichen als Trenner und es dürfen keine Leerzeichen zwischen dem "="-Zeichen und dem Variablennamen (==Key in dieser Nomenklatur genannt) stehen.

    Shell-Script

    1. # eine Shell Konfigdatei
    2. # Definition einer Function
    3. stupidFunc () {
    4. echo 'Hello world!'
    5. }
    6. # Ein Konfigparameter
    7. my_start_directory="/var/run/"
    Aber auch das Gleiche: An genau dieser Stelle wird das andere Script/konfig gelesen und ausgeführt, danach geht es zeilenweise weiter.

    Selbstverständlich kann man mehr oder weniger unbegrenzt viele solcher Include- oder Source-Anweisungen verwenden. Nicht, dass es gar am Ende zu einfach wäre.

    Ein Programm, wie ein Webserver oder der graphische X-Server haben unglaublich viele Parameter, die sich in Konfigurationsdateien einstellen lassen. Würde es den Include-Mechanismus nicht geben, müssten wir riesige Konfigurationsdateien bearbeiten, was ziemlich unübersichtlich ist und deshalb mühsam und fehlerträchtig.

    Darum wird die Konfiguration in thematisch geordnete Teilbereiche aufgesplittet und eben in vielen Dateien gespeichert, die ihrerseits wieder viel leichter bearbeitet werden können. Dazu liest das jeweilige Programm beim Start seine Haupkonfigurationsdatei ein. Und in dieser steht meist gegen Ende eine Include- Anweisung.
    Der Mechanismus der Include-Anweisung ist einfach. Die Include-Zeile selbst wird ignoriert, und an deren Stelle wird der Inhalt der includierten Dateien eingesetzt.
    Der Webserver Apache verwendet zum Beispiel für die Konfiguration der einzelnen Websiten, die er ausliefern soll (die virtuellen Host aka. vhosts)
    die Include-Anweisung IncludeOptional /etc/apache2/vhosts.d/*.conf. Die findet sich in einer seiner Hauptkonfigdateien namens /etc/apache2/httpd.conf Damit werden Includiert falls vorhanden, also Optional aus dem Verzeichnis /etc/apache2/vhosts.d alle Dateien, die im Namen ".conf" enthalten. Also z.B. www.meine-geniale-Seite.de.conf, aber auch www.meine-geniale-Seite.de.confitüre (Ob er dann an dieser Datei kleben bleibt, sei dahingestellt). Bei Debian wird in dieser httpd.conf das Verzeichnis /etc/apache2/sites-enabled includiert (was seinerseits nur Links auf das Verzeichnis /etc/apache2/sites-available enthält, und so das Ein- und Ausschalten einzelner Vhosts erleichtert).
    Andere Distri, andere Art, aber dergleiche Mist.

    Natürlich spielen die Shells auch hier eine andere Rolle. Da heißt es halt nicht "include", sondern "source".

    Shell-Script

    1. # einbinden eines weiteren Scriptes/Konfiguration
    2. source /Pfad/zu/irgendeinScript
    3. # gleichbedeutend ist
    4. . /Pfad/zu/irgendeinScript
    5. # weil das ein bashinternes Kommando ist,
    6. # ist die Hilfe dazu erreichbar mit
    7. help source

    Wenn wir nun eine unübersichtliche Riesenmenge an Konfigurationsdateien haben, werden auch zwei andere Punkte plötzlich sehr wichtig. Was passiert, wenn -gewollt, oder nicht- ein Eintrag zweimal erscheint?
    Manche Programme warnen dann. Postfix gibt dann eine Zeile aus, wie "Warning: Overwriting config entry blablabla line soundso" aus. Andere Programme machen es einfach. Fast immer gilt: Die letzte Anweisung gewinnt. Und es ist nicht immer ein Fehler! Das kann auch pure Absicht sein, dass solche Anweisungen mehrfach auftauchen. Man sollte das nur im Hinterkopf behalten.

    Damit das nun so halbwegs geordnet von statten gehen kann, gibt es noch die Reihenfolge. Die kann ganz einfach dadurch festgelegt werden, dass die Dateinamen mit einer zweistelligen Ziffer gefolgt von einem Bindestrich beginnen. Und die werden dann ganz einfach in der jetzt klar ersichtlichen Reihenfolge eingelesen.
    Aber die Ziffern sind keine Zahlen, sondern Zeichen!!
    Es gibt keine Minushundert-irgendwas.conf!

    Quellcode

    1. -99-VorAllen.conf
    2. 00-Toiletten.conf
    Das funktioniert ganz sicher nicht. Es gibt vor den Scheixxhäusern nichts. Nichts vor dem Anfang aller Kultur.

    Es ist die lexikalische Sortierreihenfolge entscheidend. Und da kommt halt der Bindestrich/Minuszeichen NACH der Null. Es sind Zeichen, keine Zahlen!
    Aber für uns in der Wahrnehmung leicht zu verstehen.


    Wenn nicht besondere Gründe dagegen stehen -Sicherheit oder Performance wären da zu nennen-, sind alle Konfigurationsdateien ganz normale Textdateien, die Klartext "Anweisungen" enthalten.
    Man kann sie also alle bedenkenlos mit jedem Editor öffnen, lesen und bearbeiten.
    Sogar verstehen, falls man den jeweiligen Dialekt schon gelernt hat.
    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von Berichtigung ()

    Für den Inhalt des Beitrages 107529 haftet ausdrücklich der jeweilige Autor: Berichtigung