Firefox 70 weiterhin ohne sicheres Fritz!box Interface

Letzte Nacht noch mit Hoffnung auf ein besseres LAN Erlebnis ins Bett gegangen, aber Firefox 70 enttäuscht dann auch heute morgen noch mit dem „SEC_ERROR_INADEQUATE_KEY_USAGE“-Fehler 🙁

Fritz!Box Webinterface weiterhin ohne SSL

Auch mit der Installation von Firefox 70 haben sich alle Hoffnungen auf eine Lösung des SSL Problems vorerst in Luft aufgelöst. Die bei Mozilla für diese Komponente zuständige Entwicklerin Dana Keeler hatte da wohl auch eher das Prinzip Hoffnung in Einsatz. Da ich mittlerweile vom AVM Support eine „Wir schauen mal nach“ Meldung bekommen habe, bin ich insofern beruhigt, als daß sich alle Parteien um eine Lösung bemühen.

Klar, man kann mit dem FF ohne SSL ins Interface, aber das ist natürlich nur eine Notlösung. Chrome benutzen geht zwar auch, aber auch das ist eher unschön.

Wer trotzdem dringend einen Firefox 70 braucht

findet hier die FF70 Downloadlinks:

https://kojipkgs.fedoraproject.org//packages/firefox/70.0/1.fc29/x86_64/firefox-70.0-1.fc29.x86_64.rpm

https://kojipkgs.fedoraproject.org//packages/firefox/70.0/1.fc30/x86_64/firefox-70.0-1.fc30.x86_64.rpm

https://kojipkgs.fedoraproject.org//packages/firefox/70.0/1.fc31/x86_64/firefox-70.0-1.fc31.x86_64.rpm

https://kojipkgs.fedoraproject.org//packages/firefox/70.0/1.fc32/x86_64/firefox-70.0-1.fc32.x86_64.rpm

Apache httpd 2.4.41 mit defektem PIPE support

Die Apache Webserver Version 2.4.41 hat einen defekten PIPE Support, was die Ausführung von CGI Scripten wie PHP Prozessen behindert. Abhilfe schafft nur ein Downgrade auf die vorherige Version.

Voraussetzungen für den Fehler

Als Voraussetzungen für den Fehler braucht man lange Ausgaben und die Ausführung von PHP als CGI, aber das ist natürlich nicht auf PHP begrenzt, es darf auf ein eigenes C Exe oder Perl sein. Bei uns war es ein PDF erzeugendes Script.

  1. httpd 2.4.41
  2. Das Script wird per CGI ausgeführt
  3. Das Script erzeugt lange Ausgaben von ~500kb

Die Symptome

Die Symptome an denen Ihr erkennen könnt, daß Ihr betroffen seid:

  1. Der Aufruf eines PHP Scripts per Browser timed aus.
  2. es stappeln sich die PHP Prozesse auf dem Server
  3. ein „strace -f -p ..hier_php_pid_angeben..“  zeigt nur eine Zeile an:
    … write( ………………….. ) = xXxXxx   , wobei die Xxx eine 6-x stellige Anzahl haben wird
  4. kurze Ausgaben, wie bei WordPresswebseiten üblich, werden normal abgearbeitet

Die Lösung

Für Fedora 29 lautet die Lösung einfach Downgraden:

dnf -y downgrade https://kojipkgs.fedoraproject.org//packages/httpd/2.4.39/3.fc29/x86_64/httpd-2.4.39-3.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/httpd/2.4.39/3.fc29/x86_64/mod_ssl-2.4.39-3.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/httpd/2.4.39/3.fc29/x86_64/httpd-tools-2.4.39-3.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/httpd/2.4.39/3.fc29/noarch/httpd-filesystem-2.4.39-3.fc29.noarch.rpm

systemctl restart httpd

Das war es dann auch schon. GGf. müßt Ihr noch liegen gebliebene Prozesse killen, aber die sollten beim httpd restart eigentlich von alleine terminieren, weil die PIPE endlich beendet wird.

Bugreport an Fedora ist raus, hat aber unverständlicherweise noch keine Reaktion hervorgerufen.

Fedora – GDM stürzt wegen SELinux ab

Ein schlecht ausgerolltes Update der SELinux Policies unter Fedora 27 führt dazu, daß der Loginbildschirm, im Fachjargon „Greeter“ genannt, mit einer unschönen Meldung absemmelt.

Fehleranalyse

Betroffene Version:  sellinux-policy 3.13.1-283.35

Wenn Eurer GDM Greeter also mit dem „blah blah ‚Benutzer abmelden'“ Fehler stehen bleibt, dann prüft folgendes:

1. „STRG+F2“ damit Ihr eine Root Konsole bekommt

2. „grep gdm /var/log/messages oderjournalctl -xe | grep gdm

kommt dabei das hier raus:

Jul 8 01:40:51 eve systemd[1627]: selinux: avc: denied { status } for auid=n/a uid=42 gid=42 cmdline=“/usr/libexec/gdm-x-session gnome-session –autostart /usr/share/gdm/greeter/autostart“ scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=system permissive=0

dann hilft Euch das hier weiter, falls keine neuere Version im Repository verfügbar ist (also vorher mit dnf -y update checken) :

dnf -y downgrade selinux-policy*
systemctl restart gdm

und anschließend das erneute Update mit dem Eintrag „exclude=selinux-p*“ in die /etc/dnf/dnf.conf verhindern.

Fazit

So eine Scheiße will einem um 1.10 Uhr nachts wirklich nicht passieren!

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.