2. Update: Verschlüsselungsverbot in England – Grundrechte in Gefahr

Am 13. Januar ging es in meinem Tagesblogeintrag um die Vorratsdatenspeicherung. Gestern ist eine Stellungnahme der Bundestagsabgeordneten Frau Reimann auf die Frage, wie sie sich bei einem Entscheid über die VDS entscheiden würde.

Ihre Antwort kann im Detail im Antworteil zu meiner Anfrage bei Abgeordneten Watch nachgelesen werden. Hier der relevante Auszug aus der Antwort:

Zitat Fr. Reimann / SPD :

„Für die SPD-Bundestagsfraktion zählt, dass trotz der Ereignisse in Paris, purer Aktionismus fehl am Platz ist. Der Koalitionsvertrag weist ausdrücklich darauf hin, dass es keine deutschen Alleingänge geben wird.

Die Entscheidung des Europäischen Gerichtshofs, die europäische Richtlinie über den Abruf und die Nutzung von Telekommunikationsverbindungsdaten für nichtig zu erklären, zeigt, dass die Bedenken zur Vorratsdatenspeicherung, die es auch innerhalb des SPD-Bundestagsfraktion gibt, richtig gewesen sind.

Wichtig ist nun, mit der europäischen Ebene zusammenzuarbeiten. Die Kommission sollte daher eine neue Richtlinie erarbeiten, über die dann innerhalb der Bundesregierung beraten werden kann.“

Im nicht zitierten Teil führt sie lediglich aus, daß sie sich jetzt ja nicht entscheiden könne, weil keine Entscheidung ansteht. Kein Wunder, die Frage war ja auch nur hypothetisch gestellt worden 🙂

Der hervorgehobene Teil der Antwort, liest sich für mich so, daß die SPD keine Problem mit einer VDS hätte, so diese Richtlinie wieder über Europa Einzug findet. Eine klare Absage an eine verdachts- und anlasslose Massenüberwachung wäre die erhoffte Antwort gewesen. Diese ist aber ausgeblieben.

Mit Yum Paketupdates rückgängig machen

Ab und zu kann es vorkommen, daß neue Pakete von Treiber oder Programmen zu Fehlern führen. Jüngstes Beispiel ist der Nvidia Treiber für Fedora 20. Da die Auswirkungen erst nach dem Neustart des Computers wirksam werden, benötigt man zum Beheben des Problems Rootrechte.

Pakete identifizieren

Zunächst einmal muß man die Pakete finden, die aktualisiert wurden. Dazu schaut man sich die letzten Zeilen des Yum Logfiles an :

# tail /var/log/yum.log
Jan 29 00:42:04 Updated: 1:kmod-nvidia-340xx-3.17.8-200.fc20.x86_64-340.65-4.fc20.x86_64
Jan 29 00:42:04 Updated: 1:kmod-nvidia-340xx-340.65-4.fc20.x86_64
Jan 29 00:45:22 Installed: 1:kmod-nvidia-3.17.8-200.fc20.x86_64-331.113-1.fc20.1.x86_64

Pakete die mit der Sache nichts zu tun haben, könnten natürlich auch installiert worden sein, im obigen Beispiel ist das nicht der Fall.

Pakete downgraden

Die Pakete wieder los zu werden ist ganz einfach, wenn man den korrekten Namen ermittelt hat:

# yum downgrade kmod-nvidia-340xx-3.17.8-200.fc20.x86_64
# yum downgrade kmod-nvidia-340xx-340

Updates verhindern

Damit die Pakete beim nächsten Update nicht wieder mit eingespielt werden, trägt man diese in die Liste der ausgeklammerten Pakete in der YUM Konfiguration ein:

# vi /etc/yum.conf

[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=kmod-nvidia-340xx*

Damit wäre man vorerst vor Updates sicher.  Das nächste Kernelupdate kommt aber todsicher und dann braucht man die neue Version der Pakete für diesen neuen Kernel. Man muß sich also jetzt sofort darum kümmern, daß dieser Fehler bekannt und natürlich behoben wird.

Bugzilla

RPMFusion und Fedora haben jeweils eine eigen Fehlertrackersoftware namens Bugzilla im Einsatz. Da die Nvidiatreiber über RPMFusion bekommen sind, muß man das Paket dort als Fehlerhaft melden.

Details zur Anmeldung kann man auf rpmfusion.org finden.

Es geht aber auch direkter, was in diesem Fall wohl dringend nötig ist. Dazu lädt man sich die defekten RPMS aus dem Repository direkt auf die Platte. Wie das geht habe ich hier beschrieben: Aus Yum ableiten wo ein RPM findet

Dann schaut man sich die Infos zu diesem RPM an : less xorg-x11-drv-nvidia-340xx-*

Neben allerlei Informationen zu dem Paket selbst, kann man hier auch direkt das Changelog sehen:

* Di Jan 27 2015 Leigh Scott <leigh123linux@googlemail.com> – 1:340.65-5
– revert last commit

Nun können Sie das direkt an den Entwickler melden, der das „verbockt“ hat 🙂

wenn das Paket bereits installiert ist …

geht das Aufrufen des Changelogs wesentlich einfacher :

# rpm -q –changelog xorg-x11-drv-nvidia-340xx
* Do Jan 15 2015 Przemysław Palacz <pprzemal@gmail.com> – 1:340.65-4
– Replace main nvidia driver in F20 with this legacy version

* So Jan 11 2015 Przemysław Palacz <pprzemal@gmail.com> – 1:340.65-3
– Switch libnvidia-ml and nvidia-debugdump to the cuda subpackage again

… die Logs gehen bis zur ersten Release des Pakets zurück …

* So Jun 22 2003 Andreas Bierfert (awjb) <andreas.bierfert[at]awbsworld.de> – 0:1.0.4363-0.fdr.1
– Initial RPM release, still some ugly stuff in there but should work…

Kein Wunder, daß die Pakete immer länger brauchen bis sie geladen worden sind.

Teamviewer für Linux auf Version 10 Updaten

Dein Update von Teamviewer 9 auf Teamviewer 10 hat funktioniert, aber Dein Desktop Icon ist weg ?

Dann hast Du vermutlich den gleichen kleinen Fehler gemacht, der mir unterlaufen ist: das Icon nicht vor der Installation zu löschen, sondern erst, wenn Teamviewer 10 drauf ist. Es ist nicht Deine Schuld, das Desktopiconmanagement der Gnome-Shell hat noch Platz für Verbesserungen.

Der Reinstall des RPM, so man es denn von hier runter lädt, nutzt mal rein gar nichts, weil das DesktopIcon nicht neu installiert wird.

Natürlich könnte man jetzt das RPM deinstallieren mit „erase“ und es dann noch mal ganz frisch installieren, aber das ist gar nicht nötig. Einfach das Desktopfile aus dem Installdirectory kopieren und dann neue Rechte setzen :

cp /opt/teamviewer/tv_bin/desktop/teamviewer-teamviewer10.desktop ~/Schreibtisch/
chmod 755 ~/Schreibtisch/teamviewer-teamviewer10.desktop

Fertig.

Ursachenforschung:

Das alte TV 9 Icon lag noch als „Zombie“ auf dem Desktop rum, nachdem das Paket ersetzt wurde. Wenn man das aber dann per Contextmenü löscht, löscht man eigentlich das neue Desktopfile von TV 10. Die Gnomeshell hat den Wechsel nicht mitbekommen und hält das geänderte File für ein neues File und räumt nicht sauber auf dem Desktop auf.

Wie man es vermeiden kann ..

Damit man sich dies erspart beim Wechsel von 10 auf 11, einfach nach dem das 11er Icon aufgetaucht ist, den Desktop mit ALT+F2 und dem Befehl „r“ neuladen. Schon ist die Leiche weg, ohne das man etwas zerschiesst.

 

EU diskutiert über Herausgabe/Hinterlegung von Kryptokeys

Der neueste politische Unsinn der politisch Beteiligten ist, überhaupt darüber nachzudenken, ein Gesetz zu verabschieden, daß die Hinterlegung von Kryptokeys bei einer Behörde festschreibt.

Wer bitte glaubt ernsthaft, daß ein Krimineller seinen Schlüssel rausgibt, nur weil es im Gesetz steht ?

Da lacht sich doch jeder ernsthaft Kriminelle drüber tod  !

Ganz abgesehen von den praktischen Überlegungen, daß bei Behörden alles wichtige für den richtigen Preis auf einem USB Stick oder Laptop auf Parkbänken und -plätzen verloren gehen wird. Da würde ich mich als legales, sicherheitsbewußtes Unternehmen doch veralbert fühlen und einfach einen Schlüssel abgeben, der nicht zu meinen Daten paßt 🙂  War dann im Zweifel wohl veraltet 😉

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.