Kurztipp: Neue per RPM verteilte Konfigurationsdateien analysieren

Oftmals werden bei der Installation neuer RPM-Pakete auch Konfigurationsdateien ausgetauscht. Bei der Verwendung des Paketmanagers yum wird dies etwa wie folgt angezeigt:

# yum update
...
  Updating   : osad-5.11.33-1.el6.noarch                                  13/32 
warning: /etc/sysconfig/rhn/osad.conf created as /etc/sysconfig/rhn/osad.conf.rpmnew

Wer die Ausgaben des yum-Aufrufs anschließend konsultiert kann die einzelnen neuen Konfigurationsdateien manuell mittels diff vergleichen. Wer mehrere Systeme verwaltet, wird vermutlich eine automatisierende Lösung, wie beispielsweise Red Hat Satellite oder Spacewalk verwenden – hier gibt es u.U. nicht direkt ein solches Log.

Kurzum: das geht eleganter – und zwar mit rpmconf. Das kleine Programm sucht nach Dateien mit den Endungen .rpmsave und .rpmnew und fragt, wie mit diesen Dateien verfahren werden soll. So können leicht neue Versionen von Konfigurationsdateien mit den bereits vorhandenen verglichen werden. Oftmals lohnt sich das Ersetzen (und anschließende Überarbeiten) der manuell angepassten Konfigurationsdateien nicht, da sich nur Kommentare oder Konfigurationswerte, die nicht benötigt werden, ändern.

Die interessantesten Parameter von rpmconf dürfen wohl die folgenden sein:

  • -a – sucht nach neuen Konfigurationsdateien jedes installierten RPM-Pakets
  • -c – sucht und löscht verwaiste neue Konfigurationsdateien

Findet der kleine Helfer eine neue Konfigurationsdatei kann diese mit der installierten Version verglichen, vereint, verworfen oder übersprungen werden. Die Steuerung erfolgt mit Buchstabenkommandos (siehe unten).

Es erscheint durchaus sinnvoll, nach jedem größeren Systemupdate den Befehl auszuführen, um nach neuen Konfigurationsdateien zu suchen:

# rpmconf -a

Configuration file `/etc/sysconfig/rhn/osad.conf'
-rw-rw-r--. 1 root root 1833 Jan 28 22:40 /etc/sysconfig/rhn/osad.conf
-rw-rw-r--. 1 root root 1785 Feb  6 17:50 /etc/sysconfig/rhn/osad.conf.rpmnew
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      M        : merge configuration files
      Z     : background this process to examine the situation
      S     : skip this file
 The default action is to keep your current version.
*** aliases (Y/I/N/O/D/Z/S) [default=N] ? 
Your choice:

Standardmäßig werden neue Konfigurationsdateien verworfen und die installierten Versionen beibehalten.

Sharing is caring

2 Kommentare Schreibe einen Kommentar

  1. Mich wundert bei Updates eigentlich immer, weshalb ICH als User gefragt werde ob ich Konfigurationsdateien ersetzen möchte.
    Ich würde eigentlich erwarten, dass die Daten der Konfiguration vom Update Mechanismus eingelesen werden die zwingenden Modifikationen automatisch vorgenommen werden und ich lediglich über die Elemente Informiert werde über die ich auch wirklich eine Entscheidung treffen muss.

    Ob das nun ein Programm wie yum, rpmconf oder apt-get macht oder das jeweilige Programm selbst ist mir dabei Egal. Aber ich will nicht während eines Upgrade-Vorganges noch das Manual konsultieren müssen oder Textfile diffs analysieren um Kommentaränderungen oder ungebrauchte leere Einträge oder sonstigen Firlefanz zu prüfen.

    Scheissdreck ist das und das noch in der heutigen modernen Zeit. Da bin ich bald einmal versucht zu Poettering zu beten, dass er hier seinen Hammer der Änderung nieder fahren lässt.

    PS: Danke für die Gelegenheit sich hier mal auszusprechen. Auf Grund eines aktuellen Vorfalles kommt der Post gerade gelegen.

    Freundliche Grüsse
    Kaputtion

    • Hi Kaputtion,

      das kann ich nachempfinden. Besonders, wenn man „mal eben“ ein Update macht, kann es wirklich sehr nervig sein, wenn man noch herausfinden muss, was sich denn nun überhaupt geändert hat.

      Aber letztendlich ist das auch irgendwie elementarer Bestandteil des Designkonzepts von *NIX-Software, bei welcher eben die Konfiguration in eine ASCII-Daten und nicht in eine Registry o.ä. gepackt wird. Ich glaube aber auch nicht, dass sich das durch Systemd radikal ändern wird – 40 Jahre historisches Wachstum kann man nicht in so kurzer Zeit „re-designen“. Mit Systemd geht es aber, meiner Meinung nach, definitiv stark in Richtung Zukunft. Fakt ist auch, dass sich einige Dinge siginifikant vereinfachen werden (z.B. Aktivierung von DHCP auf einem Interface: systemctl enable dhcpcd@IFACE; systemctl start dhcpcd@IFACE).

      Es bleibt also spannend. 🙂

      Beste Grüße,
      Christian.

Schreibe einen Kommentar