Skip to content

Versionierte Konfigurationsfiles

Geschrieben von Bernd Eckenfels am
Software ist nicht perfekt und wird auch ständig weiter entwickelt. Das führt dazu, dass bestimmt Konfigurationen der Software sehr viele Generationen überleben müssen. Problem dabei ist, dass durch neue Erkenntnisse Defaults geändert werden, neue Parameter notwendig werden, und dass es eben generell schwer ist den Benutzer bei Upgrades zu unterstützen:
  • Welche Parameter müssen hinzugefügt werden
  • Welche Defaults haben sich geändert
  • Für welche Version ist die Konfiguration
Eine gute Möglichkeit ist es einen Versions-Identifier in den Dateien mitzuführen, und bei jeder (nicht kompatibler) Änderung diesen hochzuzählen. Anwendungen haben dann die Möglichkeit entweder den Start zu verweigern, bis das Konfigurationsfile angepasst wurde, oder sich wie die alte Version der Anwendung zu verhalten. Welche alternative Strategien existieren? Nun eine Möglichkeit ist die Konfiguration der Anwendung zu trennen in Defaults (vom Hersteller) und Änderungen (installationsspezifisch). Damit kann der Hersteller neue Defaults ausliefern und muss nicht ermitteln welche Parameter der Anwender geändert haben möchte. Der Nachteil dabei ist allerdings, dass der Anwender sich natürlich auf bestimmte Defaults verlassen hat, und wenn diese geändert werden (typisches Beispiel: der Default für einen wenig benutzen Netzwerk Server wird von "on" auf "off" gendert. Der Anwender hatte in seiner Konfiguration die Option nicht überschrieben, da der Default ja OK war. Nach einem Update der Software kommt es zu einem Funktionalitätsverlust, weil der Benutzer nicht dazu agehalten wurde, sich über die geänderte Sematik zu informieren. Somit bleibt so oder so nur eine ausführliche Dokumentation der Änderungen. Üblicherweise geschieht dies in Release Notes, die zu umfangreichsind um die wichtigen von den unwichtigen Informationen zu trennen. Deswegen ist für den Anwender dabei hilfreich eine Versionsnummer zu sehen, die sein File aktuell hat, die von der Anwendung erwartet wird, und welche Änderungen dazu notwendig sind.
Angenommen wir haben folgendes initiale File: 
# /etc/conf
Version=1
# netserver=off
basedir=/root
Beim Start einer neuen Software Version gibt es folgende Fehlermeldung: Das Konfigurationsfile /etc/conf besitz die Version=1. Diese Anwendung benötigt die Version=4. Bitte nehmen Sie die notwendigen Änderungen anhand des kommentierten Templates /etc/conf.sample vor. 
# /etc/conf.sample
basedir=/var
loglevel=4
# Versions
# 1 Initial  Version
# 2 Added required Parameter loglevel (0-5)
# 3 Changed Default for netserver=on to off
# 4 changed default for basedir to /var
Version=4
Damit bleibt dem Anwender jetzt die Möglicheit sein Logfile folgendermassen anzupassen: 
# /etc/conf
Version=4
basedir=/root
netserver=on
loglevel=0
Denn, er hat den neuen Parameter loglevel hinzugefügt, hat den netserver Parameter dessen Default sich geändert hat überschrieben mit dem benötigten Wert damit die Netzwerk Funktionen weiter bereit stehen. Die Änderung des Defaults für das basedir kann der Anwender bewusst ignorieren. D.h. er weiss, dass er das Default für netserver überschreiben muss um die Funktionalität zu erhalten, und dass er den loglevel parameter angeben muss. Er entscheidet sich dafür sein basedir beizubehalten. Durch die Modifikation des version= parameters signalisiert der Administrator der Anwendung, dass er sich mit dem Upgrade befasst hat. Das ganze läßt sich nicht nur auf Konfigurationsfiles anwenden, sondern auch auf andere Objekte die eine bestimmte Sematik eines Containers voraussetzen. So werden IT-Systeme deutlich besser über längere Zeiten pflegbar.

Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Noch keine Kommentare

Kommentar schreiben

BBCode-Formatierung erlaubt
Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Um einen Kommentar hinterlassen zu können, erhalten Sie nach dem Kommentieren eine E-Mail mit Aktivierungslink an ihre angegebene Adresse.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA