Wer kennt das nicht, in der Firma läuft es ruhig. Kunden melden sich nur per Email, aber das Telefon schweigt seit Tagen. Das alljährliche Sommerloch, wegen dessen wir alle in den Urlaub fahren …, oder ?
Paranoide Menschen würden jetzt per Telefon sich selbst anrufen und entsetzt feststellen, daß die Telefone nicht klingeln, weil .. ja .. scheisse, wieso klingeln die nicht ????!!!!!!
Ab jetzt herrscht Panik in der IT-Abteilung: Was ist passiert ?
Ist der SIP Provider pleite gegangen ?
Haben Mäuse die Glasfaserkabel geknackt ?
Oder liegt es etwa an uns ?
Gab es ein Update der Telefonsoftware ?
Gab es überhaupt irgend ein Update ?
Also prüfen wir zunächst mal, ob alle betroffen sind und stellen fest : Alle Jitsi SIP Softphones sind quasi tod, aber normale Telefone für SIP nicht. Jitsi kann zwar noch raustelefonieren, sonst wäre das ja auch eher aufgefallen, aber ankommende Anrufe gehen nicht mehr. Komischerweise geht Jitsi auf den Handies noch.
Das schliesst per se ein DSL Router und Netzwerkproblem aus, außer die lokale Firewall wäre im Spiel:
TEST:
systemctl stop firewalld
Anruf => kein Klingeln
systemctl start firewalld
Das wars nicht. Hatte Jitsi ein Update ? Seit Monaten nicht mehr. Fällt somit als Ursache auch weg. Hmm…
2 Tage und eine systematische Suche später ..
Das Problem, das Jitsi keine SIP Calls mehr annehmen konnte, ist behoben worden.
Es lag NICHT an Jitsi, Sipgate, den Mäusen, dem DSL Router, den Kabeln, der Firewall sondern an : JAVA.
Die Ursache
Fedora hat vor zwei Tagen ein neues openjdk 1.8.0.141_b16 eingespielt, das hat Jitsi und vermutlich andere Apps beeinträchtigt. Das Update war als Security Update markiert, es ist also potentiell gefährlich, die App weiter zu betreiben. Ist es in dem Fall nicht, da das Update pauschal als Security Update eingestuft wurde, weil 4 Security Tests beim Build nicht liefen. Dazu noch eine Menge normaler Updates, von denen vermutlich eins die Ursache ist.
Der Workaround
Der schnellste Workaround ist natürlich, Java zu downgraden auf die letzte funktionierende Version:
java-1.8.0-openjdk-1.8.0.131-5.b12.fc25.x86_64.rpm
java-1.8.0-openjdk-devel-1.8.0.131-5.b12.fc25.x86_64.rpm
java-1.8.0-openjdk-headless-1.8.0.131-5.b12.fc25.x86_64.rpm
java-1.8.0-openjdk-javadoc-1.8.0.131-5.b12.fc25.noarch.rpm
Wenn man das jetzt mit „dnf downgrade java-*“ macht, landet man bei einer uralten Version, was Securitymäßig keine gute Idee ist. Also lädt man die Pakete hier runter:
https://kojipkgs.fedoraproject.org//packages/java-1.8.0-openjdk/1.8.0.131/5.b12.fc25/noarch/java-1.8.0-openjdk-javadoc-1.8.0.131-5.b12.fc25.noarch.rpm
https://kojipkgs.fedoraproject.org//packages/java-1.8.0-openjdk/1.8.0.131/5.b12.fc25/x86_64/java-1.8.0-openjdk-headless-1.8.0.131-5.b12.fc25.x86_64.rpm
https://kojipkgs.fedoraproject.org//packages/java-1.8.0-openjdk/1.8.0.131/5.b12.fc25/x86_64/java-1.8.0-openjdk-devel-1.8.0.131-5.b12.fc25.x86_64.rpm
https://kojipkgs.fedoraproject.org//packages/java-1.8.0-openjdk/1.8.0.131/5.b12.fc25/x86_64/java-1.8.0-openjdk-1.8.0.131-5.b12.fc25.x86_64.rpm
Aber natürlich nur passenderweise für Fedora 25, andere Versionen bitte selbst bei koji suchen.
Nicht vergessen: /etc/dnf/dnf.conf editieren und java auf die Sperrliste setzen, sonst kommt das Update gleich wieder rein.
Warum ist jetzt der Downgrade auf b12 akzeptable und der auf die Fedora Downgrade Version nicht ?
Weil Jitsi nur Verbindungen zu bestimmten, vertrauenswürdigen Servern aufnimmt. Es ist daher kaum möglich etwaige SecBugs in Java über diesen Channel auszunutzen, zumal in der ML von OpenJAVA keine Hinweise zu Securitybugs enthalten waren. 4 Tests beim Build failten, das kann alles sein. in nächster Zeit wird es sicher Updates von Jitsi geben, damit es auch mit der aktuellen Java Version läuft, denn es steht zu befürchten, daß Openjdk, den „Bug“ nicht fixt.
