RPM: Reverse Depencies herausfinden

Neulich stolperte ich über einen Loginversuch mit einem Benutzer den ich nicht kannte. Der paranoide Adminteil in mir schlug natürlich sofort Alarm. Zum Glück gehörte der Benutzer nur zu einem Paket, daß ich nicht kannte, war also legitim, aber vermutlich überflüssig.

Jetzt stellt sich natürlich die Frage: was machen?

Erstmal sollte man jetzt Fakten sammeln. Der User gehörte zu einer Lib namens unbound. Sofern man keine selbstkompilierten Programm benutzt, kann man über die Systemtools recht umfangreiche Recherchen und damit Antworten auf diese Frage bekommen. Wenn man selbstkompilierte Programm einsetzt, kann man z.b. verwendete Libs einfach mit „ldd filename | grep libname“ aufspüren. Das setzt aber voraus, daß man ein kleines Script einsetzt, daß alle Binaries raussucht und checkt.

Wir gehen mal vom einfachen Fall aus und identifizieren erstmal das Paket. Dafür gibt es zwei Wege:

# yum provides /usr/lib/libunbound.so.2
 ...
 unbound-libs-1.5.1-2.fc20.i686 : Libraries used by the unbound server and client applications
 Quelle : @updates
 Übereinstimmung von:
 Dateiname : /usr/lib/libunbound.so.2
 ...

oder mit RPM (empfohlen) :

# rpm -qf /usr/lib/libunbound.so.2
 unbound-libs-1.5.1-2.fc20.i686

was darin enthalten ist, kann man sich mit rpm -ql packagename anzeigen lassen:

# rpm -ql unbound-libs
 /etc/cron.d/unbound-anchor
 /etc/unbound
 /etc/unbound/dlv.isc.org.key
 /etc/unbound/icannbundle.pem
 /etc/unbound/root.key
 /usr/lib/libunbound.so.2
 /usr/lib/libunbound.so.2.3.3
 /usr/sbin/unbound-anchor
 /usr/share/doc/unbound-libs
 /usr/share/doc/unbound-libs/LICENSE
 /usr/share/doc/unbound-libs/README
 /var/lib/unbound
 /var/lib/unbound/root.key

Aber wer braucht das Paket jetzt ?

Am Beispiel von Webalizer wollen wir das kurz zeigen. Die Abhängigkeiten eines Pakets auflisten kann man sich mit :

# rpm -q -R webalizer
 /bin/bash
 /bin/sh
 /usr/sbin/useradd
 config(webalizer) = 2.23_08-1.fc21
 crontabs
 httpd
 libbz2.so.1
 libc.so.6
 ...

Das sagt mir zwar, was Webalizer braucht, aber nicht wer das Webalizer Paket benötigt. Wenn die RPM Datenbank in Ordnung ist, geht das ganz leicht mit :

rpm -q –whatrequires packagename

Beispiel:

# rpm -q --whatrequires webalizer
 rdt-webalizer-5-1.i386

Gegencheck :

# rpm -q -R rdt-webalizer
 httpd
 webalizer
 /bin/sh
 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
 rpmlib(CompressedFileNames) <= 3.0.4-1

und schon weiß man, ob man ein Paket löschen kann oder nicht, denn wenn das Paket nicht gebraucht wird und da keine für Einen selbst wichtigen Befehle enthalten sind, kann man es einfach mit yum erase packagename entfernen, wenn, ja, wenn da nicht noch ein dicker Bug wäre 🙂

Das Aber

Am Anfang ging es ja um das Paket unbound-libs und wer das braucht. RPM meinte dazu: niemand . Was aber nicht stimmt:

# yum erase unbound-libs
Geladene Plugins: langpacks
Abhängigkeiten werden aufgelöst
–> Transaktionsprüfung wird ausgeführt
—> Paket unbound-libs.i686 0:1.5.1-2.fc20 markiert, um gelöscht zu werden
–> Abhängigkeit libunbound.so.2 wird für Paket libreswan-3.12-1.fc20.i686 verarbeitet
–> Transaktionsprüfung wird ausgeführt
—> Paket libreswan.i686 0:3.12-1.fc20 markiert, um gelöscht zu werden
–> Abhängigkeitsauflösung beendet

Abhängigkeiten aufgelöst

===========================================================================================================================================================================================================
Package                                             Arch                                        Version                                             Paketquelle                                     Größe
===========================================================================================================================================================================================================
Entfernen:
unbound-libs                                        i686                                        1.5.1-2.fc20                                        @updates                                        869 k
Entfernt für Abhängigkeiten:
libreswan                                           i686                                        3.12-1.fc20                                         @updates                                        3.1 M

Transaktionsübersicht
===========================================================================================================================================================================================================
Entfernen  1 Paket (+1 Abhängiges Paket)

Installationsgröße: 4.0 M
Ist dies in Ordnung? [j/N] :n

Das bedeutet, das RPM uns nicht alles gesagt hat, was es wußte und leider haben wir keine Möglichkeit das aus RPM rauszuquetschen. Eingangs habe ich ja auf ldd hingewiesen und mit dem überprüft man die Binaries direkt :

# ldd  /usr/libexec/ipsec/* | grep unbound
    libunbound.so.2 => /lib/libunbound.so.2 (0x4004f000)
    libunbound.so.2 => /lib/libunbound.so.2 (0x40394000)
    libunbound.so.2 => /lib/libunbound.so.2 (0x40047000)

Da haben wir die unbound-libs und damit die Abhängigkeit. Dank der Gründlichkeit von Yum, die einem desöftern auf den Senkel geht, konnte das System gerettet werden, denn hinter libreswan steht Pluto und damit die IPSEC VPN Serverfiles. Keine gute Idee, die zu löschen.

Munin unter Fedora 21 zum Laufen bringen

Munin hat speziell mich die letzten zwei Wochen auf Trab gehalten, seitdem unsere Testserver für die neuen Softwarekomponenten auf Fedora 21 umgestellt wurden. Jeden Tag haben wir hunderte Emails von Munin bekommen, daß alles auf dem Server ok wäre. Eine Konsultation mit den Entwicklern von Munin brachte nur ein „Kann ich nicht reproduzieren“ hervor, ja.. also.. kann passieren 😉

Da mir das nun langsam auf die Nerven gegangen ist, habe ich mich dann selbst an Munin versucht.

Das Problem

Das DiskFree Modul und die DiskFree-Inodes Modul von Munin ( kurz df und df_inode) gehen die Liste von Filesystemen eines Servers durch und prüfen, ob diese voll oder fast voll sind. Dabei wird scheinbar alles geprüft, was irgendwie ein Filesystem ist, selbst romfs, ramfs  und debugfs, die ja nun keine echten Filesysteme mit möglichen Belegungsproblemen sind. Komischerweise schickte uns Munin immer nur OK Meldungen, aber keine Warnmeldungen zu df und df_inode zu. Die Filesysteme auf den Servern hatten zudem auch gar keine Belegungsprobleme, trotzdem haben wir alle 15 bis 30 Minuten so eine Email bekommen.

testdomain.de :: testdomain.de :: Inode usage in percent OKs: /run/user/0 is 0.00, /sys/fs/cgroup is 0.01, /opt/root/dev/shm is 0.00, /run is 0.88, / is 3.78, /run/user/496 is 0.00, /dev/shm is 0.00, /dev is 0.24.

Die Analyse

Munin bietet zwar von Haus aus Debugfunktionen an, aber keine führte zum Ziel. Damit man Munin debuggen kann, muß man zunächst zum Munin User werden, der „normalerweise“ keine Shell hat, damit man sich nicht einloggen kann:
# su munin -s /bin/bash

Dann gibt mal als erstes mal munin-limits ein, um sich einen Überblick zuverschaffen.

# /usr/share/munin/munin-limits --debug

pre>2014/12/22 15:41:19 [DEBUG] processing critical: _dev_xvda1 ->  : 98
2014/12/22 15:41:19 [DEBUG] processing warning: _dev_xvda1 ->  : 92
2014/12/22 15:41:19 [DEBUG] processing unknown_limit: _dev_xvda1 -> 3
2014/12/22 15:41:19 [DEBUG] processing field: localhost::localhost::df::_dev_xvda1
2014/12/22 15:41:19 [DEBUG] field: $VAR1 = {
‚#%#name‘ => ‚_dev_xvda1‘,
‚critical‘ => ’98‘,
‚graph_data_size‘ => ’normal‘,
‚label‘ => ‚/‘,
‚update_rate‘ => ‚300‘,
‚warning‘ => ’92‘
};
2014/12/22 15:41:19 [DEBUG] value: localhost::localhost::df::_dev_xvda1: 22.62 (crit: :98) (warn: :92)
2014/12/22 15:41:19 [DEBUG] generating service message: localhost::localhost::df
2014/12/22 15:41:19 [DEBUG] Contact list for localhost::localhost::df:
2014/12/22 15:41:19 [DEBUG] processing service: fw_conntrack
2014/12/22 15:41:19 [DEBUG] state_file: /var/lib/munin/state-localhost-localhost.storable

Das obige Beispiel ist natürlich nur ein Ausschnitt, im Normalfall kommen dort Dutzende verschiedene Werte zur Ausgabe. Interessant ist diese Zeile:
value: localhost::localhost::df::_dev_xvda1: 22.62 (crit: :98) (warn: :92)
Der Wert des Feldes „df“ war 22.62 % für /dev/xvda1 ( unsere Rootpartition ). Eine Warnung gibt es bei  92 % Belegung und einen Critical ab 98%.  In diesem Beispielfall kommt also keine Email zustande, weil alles im Toleranzbereich ist.
Munin schickt laut Sourcecode nur dann noch Emails, wenn sich der Zustand geändert hat, also z.b. vorher Critical war und dann bei nächsten Check wieder OK ist. Genauso in die andere Richtung ( ok -> fail ).
d.h., wenn Munin keinen anderen tieferen Bug hat, muß es so einen Wechsel festgestellt haben und da die Platte als Quelle ausschied, weil dich dort nicht geändert hat, mußte die Warnung für ein anderes Filesystem gekommen sein, auch wenn man das nicht gesehen hat. Allzuviele kommen da nicht in Frage:
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/xvda1       78G     17G   58G   23% /
devtmpfs        490M       0  490M    0% /dev
tmpfs           500M       0  500M    0% /dev/shm
tmpfs           500M    3,1M  497M    1% /run
tmpfs           500M       0  500M    0% /sys/fs/cgroup
tmpfs           500M    4,0K  500M    1% /opt/root/dev/shm
tmpfs           100M       0  100M    0% /run/user/0
Scheinbar hatten sich die Ausgaben für tempfs und devtempfs von Fedora 20 zu Fedora 21 verändert,
was Munin verwirrt hat.

Die Lösung

Nach einigen Tests gelang es mir dann, Munin zur Aufgabe zu bewegen.

Dazu muß man in der plugin-conf für df das devtempfs und das tempfs excluden. Es macht sowieso kaum Sinn ein Ramlaufwerk zu checken, da Ramlaufwerke i.d.R. immer zu 100% voll sind, außer man hat ein fixed Ram-Drive gewählt.

# cat /etc/munin/plugin-conf.d/df
[df*]
env.exclude none unknown iso9660 squashfs udf romfs ramfs debugfs binfmt_misc rpc_pipefs fuse.gvfs-fuse-daemon tmpfs devtmpfs

Das alleine half aber nur bei dem Wert für df, df_inode sendete fleißig weiter OK Meldungen. Wie sich dann herausstellte, kann man auch für das df_inode eine eigene Configdatei ablegen. Dazu braucht man nur die df Datei zu kopieren „cp df df_inode“ und dann das System neustarten : systemctl restart munin-node . Den letzten Schritt sollte man nicht vergessen, denn auch wenn Munin alle 5 Minuten vom Cron gestartet wird, heißt das nicht, daß die Limits dann eingelesen werden, da die Node als eigener Prozess läuft.

 

 

TAR erfolgreich per SSH tunneln

Jeder Admin kennt das Problem, man muß irgendwann mal in seinem Leben ein System backupen, ohne das man Platz dafür hat oder die Platte ist nur noch lesbar.

Natürlich kommt einem dabei sofort die Idee, daß per SSH auf einen anderen Server zu übertragen. TAR muß aber irgendwo die Daten ausgeben, das geht nur in die PIPE. Mit den Daten kann man aber mit SSH als Ziel nicht viel anfangen, außer man schafft es den Datenstrom in die richtigen Bahnen zu lenken.

Genau das geht mit dieser Anweisung:

tar czv / | ssh user@backup.server.de "cat - > backup.tgz"

Cat leitet am Zielserver die Daten von Stdin in das File backup.tgz um.