Category Archives: Linux

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.

FFMPEG: automatisch Rahmen entfernen

Jeder Videofan kennt das, auf der DVD war ein 4:3 der eigentlich ein 16:9 Film war und nun oben und unten schwarze Streifen hat. Die müssen irgendwie weg und FFmpeg hat die Lösung :

ffplay -i YourMovie.mp4 -vf "cropdetect=24:16:0"

Dieser Befehl erkennt schwarze Balken und gibt die nötigen Werte dafür dann aus. FFmpeg gibt dann so einen Wert aus: „crop=480:320:0:130“, das meint, das Bild ist 480×320, ab Links 0px und Oben 130px, oder anders ausgedrückt, er schneidet oben 130px weg. Da nur 320px benutzt werden, fallen unten die restlichen schwarzen Pixel weg.

Das führt uns dann zu diesem Befehl, wo dies Ergebnis angegeben wird:

ffmpeg -threads 8  -i test.avi -f avi  -r 25 -vcodec libxvid -vtag XVID -aspect 16:9 -maxrate 900k -b:v 700k -qmin 3 -qmax 5 -bufsize 4096 -mbd 2 -bf 2  -c:v:0 libxvid -c:a:0 libmp3lame -b:a:0 192k -vf "crop=480:320:0:130" -s:v 480x320 "test2.avi"

 

Systemd und die Limits : The Revenge of Mariadb

Posted on by

Es hätte so ein schöner Tag werden können, Weihnachten ist grade rum, der deutsche Wetterdienst droht uns endlich mit Schnee und das Upgrade von Fedora 19 auf Fedora 20 lief gestern Nacht ohne Probleme ab. In freudiger Erwartung einer guten Meldung laß ich den morgendlichen Report meiner Serverfarm. Ok, es ist die Serverfarm meines Arbeitgebers, aber da ich mich morgens drum kümmern muß, ist es meine Farm. Mein System, meine Farm ! Pah.

Ich laß also im Bett die Emails der Nacht und alle Server schienen glücklich zu sein, nur einer meldete um 3 Uhr nachts über 500 Emails in seiner Mailqueue. Ein typischer Fall von Mailspam über ein gehacktes Mailkonto, doch dann wurde mir klar, es ist der Server der gestern sein Upgrade hatte und der hat gar keine Mailkonten die man hacken könnte. Mifft!

Einer ersten Analyse nach, liefen alle Dienste, schon mal ein gutes Zeichen. Dann schaute ich in das Logfiles des Mailserver und stiess auf eine große Anzahl von Fehlermeldungen, da der Mailserver nicht in den Datenbankserver einloggen konnte. Da aber die Emails über diesen Server angekommen waren, schien das nur ein temporäres Problem zu sein:

„gave DEFER: MYSQL connection failed: Too many connections“

Ohoh… nicht schon wieder.. In 2013 hatte wir nach einem Upgrade ein ähnliches Problem mit dem Httpd, der wollte nach Umstieg auf Systemd auch nicht mehr mit seinen Limits arbeiten. Zum Glück kann man das auf die gleiche Weise lösen, sollte man jedenfalls meinen.

Zunächsteinmal einen Blick in die /etc/my.cnf ob noch alles da ist, man weiß ja nie ..

[mysqld]
max_connections = 2000
max_join_size = 10M

noch alles da. Merkwürdig. Ein Blick ins Mysql-Logfile zeigte dann das hier :

10:26:15 [Warning] Changed limits: max_open_files: 1024  max_connections: 214  table_cache: 400

Das macht der liebe Mysqld, wenn das Open-Files-Limit nicht stimmt, denn Sockets sind auch nur Filedescriptoren. Aber moment, das hatten wir doch beim letzten Upgrade schon mal behoben! Wieso geht das nicht mehr ?

Ein Blick in /etc/systemd/system/mariadb.service zeigt uns: (u.a.)

[Service]
LimitNOFILE=1000000
Type=simple
User=mysql
Group=mysql

Da steht doch, daß er das Filelimit anheben soll, wieso tut er das nicht? Ab dieser Stelle haßte ich den Systemd wiedermal.. wie sich rausstellte, ist das Teil einfach großer „Mifft!“ wie Bernd sagen würde.

Es reicht nicht mehr, das NOFILE Limit ins eigene Servicefile zu packen, man muß es (auch noch) in einer eigenen Limitsdatei eintragen :

# cat /etc/systemd/system/mariadb.service.d/limits.conf 
[Service]
    LimitNOFILE=1000000

Wenn ich jetzt nostalgisch werde, müßt Ihr das verzeihen : Früher war alles besser !

Da gab es son Mist nicht. Der Systemd hat auch Vorteile, daß kann man nicht leugnen, aber für das Teil braucht man ein ganzes Handbuch, wo man vorher einfach mal „ulimit -n 100000“ im Initscript benutzen konnte und die Welt war wieder ok. Das war wirklich besser !