Tag Archives: fedora

Flatpak & Linphone 4

Posted on by

Da grade ein OSBN Blogkollege LinPhone 4 vorgestellt hat, dachte ich mir, schau doch mal, obs das nicht auf für Fedora fertig gibt. Zunächst findet man im Repo tatsächlich eine LinPhone 3 Version, aber die ist komplett unbrauchbar. Versucht es erst gar nicht. Der korrekte Umgang damit ist : dnf -y erase linphone

Das Programm war so dämlich, sich darüber zu beschweren, daß es sich nicht auf Port 5060 ( SIP ) binden kann, weil es sich dort bereits im ersten Versuch beim Start der eigenen Instanz gebunden hatte 😉 Alle 3 Sekunden 😀 Mehr muß man nicht schreiben.

LinPhone 4 sieht anders aus. Das funktioniert tatsächlich irgendwann mal. Leider braucht man FlatPak um es zu installieren, weil die Autoren auf ein RPM verzichtet haben. Dafür darf man sich dann ein 144 MB GnomeBundle plus diverse Treiber ziehen, als wenn Gnome nicht schon auf dem Rechner drauf wäre 🙁

Die Installation von LinPhone 4

Mit Hilfe von Flatpak ist die Installation

[marius@eve ~]$ flatpak –user install –from https://linphone.org/flatpak/linphone.flatpakref
This application depends on runtimes from:
https://sdk.gnome.org/repo/
Configure this as new remote ‚gnome‘ [y/n]: y
Installieren: com.belledonnecommunications.linphone/x86_64/4.1.1
Erforderliche Laufzeit für com.belledonnecommunications.linphone/x86_64/4.1.1 (org.freedesktop.Platform/x86_64/1.6) ist nicht installiert. Suche läuft …
Found in remote gnome, do you want to install it? [y/n]: y
Installieren: org.freedesktop.Platform/x86_64/1.6 von gnome
[####################] 11 delta parts, 81 loose fetched; 141011 KiB transferred in 53 seconds
Installieren: org.freedesktop.Platform.GL.nvidia-375-66/i386/1.4 von gnome
[####################] Downloading: 44,8 MB/44,8 MB (4,1 MB/s)
Installieren: org.freedesktop.Platform.GL.nvidia-375-66/x86_64/1.4 von gnome
[####################] Downloading: 42,2 MB/42,2 MB (4,2 MB/s)
Installieren: org.freedesktop.Platform.Locale/x86_64/1.6 von gnome
[####################] 18 metadata, 73 content objects fetched; 955 KiB transferred in 7 seconds
Installieren: com.belledonnecommunications.linphone/x86_64/4.1.1 von com.belledonnecommunications.linphone-1-origin
[####################] 353 metadata, 2718 content objects fetched; 117296 KiB transferred in 81 seconds

Die Apps finden

[marius@eve ~]$ flatpak list
Ref Options
com.belledonnecommunications.linphone/x86_64/4.1.1 user,current
org.freedesktop.Platform.GL.nvidia-375-66/i386/1.4 user,runtime
org.freedesktop.Platform.GL.nvidia-375-66/x86_64/1.4 user,runtime
org.freedesktop.Platform/x86_64/1.6 user,runtime

Der Start

[marius@eve ~]$ flatpak run com.belledonnecommunications.linphone/x86_64/4.1.1
Qt: Session management error: None of the authentication protocols specified are supported
[12:13:16:118][0x2219d80][Info]/run/build/linphone-qt/src/app/App.cpp:106: „Use locale: en“
[12:13:25:406][0x2219d80][Info]:0: „Running app…“
… ab hier jede Menge lustiger und völlig überflüssiger Fehlermeldungen …

Irgendwie blöd wenn man sich nicht ausweisen kann, aber es geht am Ende doch, den ganzen Fehlermeldungen die da noch folgen zum Trotz 🙂

am sieht den Startbildschirm von Linphone

Startbildschirm

Es fällt natürlich sofort das rote Ausrufezeichen ins Auge, daß anzeigt, daß die unsinnige Standardeinstellung erwartungsgemäß nicht funktioniert. Ist auch kein Wunder, denn es versucht sich auf der IP des DSL-Routers als SIP Server zu etablieren.

Wenn man dann über den Assistenten endlich mal ein SIPGATE Konto erstellt hat, kann man am Ende dann tatsächlich darüber am Rechner telefonieren. Funktionieren tut es also. Allerdings nur per UDP, alles andere was an Optionen zur Verfügung stand, warf auch nur rote Ausrufezeichen und sonst nix. Nicht so tragisch, es sollte trotz dessen mit ZRTP verschlüsselt sein.

Die Fritzbox habe ich dann auch noch irgendwie an das Phone angeschlossen bekommen. Ob man sich damit selbst erfolgreich anrufen kann, habe ich dann nicht noch ausprobiert.

Wozu allerdings die Videooptionen da sind, hat sich mir nicht erschlossen, da SIP ja für Telefon da ist und einen Jabberserver habe ich nicht dran bekommen. Genauso wenig konnte ich damit Chatten, was mich auch gewundert hätte.

Was negativ auffällt ist, daß man das unsinnige Defaultkonto nicht entfernen und durch ein funktionierendes Konto ersetzen kann. Das fällt dann wohl unter failed.

Fazit: Jitsi ist cooler, kann mehr, ist einfacher zu installieren / konfigurieren und nimmt nicht soviel Platz auf dem Desktop ein.

Dies ist meine erste Erfahrung mit Flatpak, und sehr wahrscheinlich auch die letzte, weil sich alle Vorurteile bestätigt haben:

  • – Doppelt und Dreifache OS Umgebung
    – Platzverschwendung
    – Updates – Was sind Updates ? Muß man selbst einspielen .. args ..
  • Sorry, Flatpak und Snaps sind der falsche Weg.

FireFox auf Version 55 aktualisieren

Posted on by

In FireFox < 55 klaffen mehrere dicke Sicherheitslücken, daher ist ein sofortiges Update nötig.

Leider stellt Fedora noch keine Updates im Testrepository bereit, so daß man selbst Hand anlegen muß.

Wie üblich muß dazu Koji bemüht werden, denn das entsprechende Firefoxupdate gibt es dort bereits:

firefox-55.0-5.fc25.x86_64.rpm

firefox-55.0-5.fc26.x86_64.rpm

Für Fedora 27 hat der Build nicht geklappt, daher muß man hier noch warten.

Warum hier die Update nicht gepusht werden, obwohl die Lücken gravierend sind, weiß der Geier. Bereits gestern wurden die CERTs darüber informiert und haben die entsprechenden Warnungen an die Listen weitergegeben.

Jitsi kann keine SIP Anrufe mehr annehmen

Posted on by

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.