Tag Archives: Abhängigkeiten

Fedora: RPM Depencies in Paketen rausbekommen

Posted on by

Wer wissen will, welche Pakete ein anderes Programmpaket min. braucht, der wird mit diesem Bashcode glücklicher:

# rpm -qR php | grep „\.so\.“ | grep -v „(“ | awk ‚{print „rpm -qf `locate „$1″|sort -u |grep -v opt`“;}‘ | bash | sort -u
glibc-2.22-18.fc23.i686
krb5-libs-1.14.3-8.fc23.i686
libcom_err-1.42.13-3.fc23.i686
libxml2-2.9.3-2.fc23.i686
openssl-libs-1.0.2j-1.fc23.i686
pcre-8.39-6.fc23.i686
zlib-1.2.8-9.fc23.i686

rpm -qR gibt die Abhängikeiten in Dateien an und spuckt leider meistens nur Libnamen ( *.so.* ) aus. Damit diese Paketen zugeordnet werden können, müssen wir das RPM erneut zum Prüfen vorlegen, dazu finden wir die Datei auf dem Computer mit „locate“, sortieren aus, was wir nicht wollen ( hier fremdinstallierte Dateien in /opt ), fragen RPM zu welcher Datei diese Files gehören ( rpm -qf ) und sortieren doppelt Antworten raus ( sort -u ).

 

 

RPM: Reverse Depencies herausfinden

Posted on by

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.

YUM: Abhängigkeitsprobleme lösen

Posted on by

Es kann vorkommen, daß einzelne Abhängigkeiten bei einem Update über mehrere Repositories nicht aufgelöst werden können. Z.b. weil im Fedora Hauptrepo eine neuere Version des Pakets verteilt werden soll, wie in den anderen Repos referenziert werden. Oder anders ausgedrückt, jemand hat sein Update noch nicht fertig und hinkt hinterher.

Am Beispiel des jüngsten QMMP Updates, möchte ich das mal verdeutlichen :

---> Paket qmmp.x86_64 0:0.7.4-1.fc20 markiert, um aktualisiert zu werden
 --> Abhängigkeit qmmp(x86-64) = 0.7.4 wird für Paket qmmp-plugins-freeworld-0.7.4-1.fc20.x86_64 verarbeitet
 --> Abhängigkeitsauflösung beendet
 --> Transaktionsprüfung wird ausgeführt
 ---> Paket qmmp.x86_64 0:0.7.4-1.fc20 markiert, um aktualisiert zu werden
 --> Abhängigkeit qmmp(x86-64) = 0.7.4 wird für Paket qmmp-plugins-freeworld-0.7.4-1.fc20.x86_64 verarbeitet
 --> Abhängigkeitsauflösung beendet
 Fehler: Paket: qmmp-plugins-freeworld-0.7.4-1.fc20.x86_64 (@rpmfusion-free-updates)
 Benötigt: qmmp(x86-64) = 0.7.4
 Entfernen: qmmp-0.7.4-1.fc20.x86_64 (@updates)
 qmmp(x86-64) = 0.7.4-1.fc20
 Aktualisiert durch: qmmp-0.7.7-1.fc20.1.x86_64 (updates)
 qmmp(x86-64) = 0.7.7-1.fc20.1
 Verfügbar: qmmp-0.7.2-1.fc20.x86_64 (fedora)
 qmmp(x86-64) = 0.7.2-1.fc20
 Sie können versuchen, mit --skip-broken das Problem zu umgehen.
 Sie könnten Folgendes versuchen: rpm -Va --nofiles --nodigest

Was steht da jetzt wirklich ?

QMMP soll von 0.7.4 auf 0.7.7 aktualisiert werden,
ABER das qmmp-plugins-freeworld-0.7.4-1 Paket braucht 0.7.4-1 und nicht 0.7.7 .

Den Vorschlag SKIP BROKEN kann man einfach vergessen. Der Zustand kommt öfter vor,
deswegen hier gleich mal die Lösung:

 #  vi /etc/yum.conf

Ans Ende der Main-Sektion schreibt man nun einfach „exclude=qmmp*“ .

Das könnte dann so aussehen :

[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=3
exclude=qmmp*

#  This is the default, if you make this bigger yum won't see if the metadata

Ein „yum update“ wird jetzt durchlaufen. In einer Woche können wir dann mal nachsehen, ob das qmmp-plugins-freeworld Paket auf Stand ist.