gleiche RPMs aus verschiedenen Quellen

Ein bisschen speziell ist unser heutiger Fall von Systemupgrade. Wir haben mehrere Repositories/Quellen von RPM Paketen für ein Paket, wollen aber das System per DNF upgraden und ein Paket aus einem bestimmten Repo benutzen.

Das Problem

Wir haben Fedora 25 als OS mit dem Default PHP von Fedora und zwei anderen PHP Versionen von Remi, einem französischen Repository für Serversoftware. Ein Serverupgrade kann man leicht mit

dnf –allowerasing –releasever=26 –setopt=deltarpm=false distro-sync

durchführen. Damit alle zusätzlichen Rpms von Drittrepos auch mitkommen beim Update, muß das jeweilige Repo global aktiviert sein, oder man gibt es in der Zeile mit an :

dnf –enablerepo=remi –allowerasing –releasever=26 –setopt=deltarpm=false distro-sync

Wenn man das in unserer Ausgangssituation tut, bekommt man einen Quellwechsel ins Spiel, denn man nicht unbedingt haben will. Remi hat nämlich eine neuere Version von PHP als das Fedorarepo.

Der Unterschied

Das hat natürlich einen Grund, Remi hat sich genau dem gewidmet, neigt aber dazu ohne umfangreiche Testrepos zuarbeiten. Fedora dagegen hat eine Communitytestumgebung, auf der Tester die Pakete bewerten müssen, bevor Sie ins Stablerepo gepusht werden.

Fedora hat also ggf. die stabiler laufenden Pakete, weil überhaupt jemand mal testhalber so ein Paket installiert hat. Auf einer Serverumgebung wollen wir natürlich genau dies haben, außerdem könnten die Remi Pakete anders kompiliert sein, und daher unerwartete Nebenwirkungen haben, was strikt zu vermeiden ist.

Quellrepowechsel verhindern

Gibt man jetzt das Upgradekommando ein und hat alle Quellrepos aktiviert, sieht Dnf das „neuere“ PHP Paket bei Remi und wechselt die Quelle, genauso, also wenn man das Testrepository aktiviert und dort ein neueres Paket vorhanden ist.

Daher muß man das Remirepo deaktivieren und erstmal normal upgraden. Nach dem Reboot kann man dann einfach dnf update benutzen um die Pakete zu aktualisieren, die im Remirepo vorhanden sind.

Überraschung

Bei unserem Beispiel F25 zu F26 und PHP kommt es zu einem Versionssprung von PHP 7 auf PHP 7.1 . Damit haben wir jetzt ggf. zweimal 7.1. drauf, einmal von Fedora und einmal von Remi, wo man doch eigentlich 7.0 und 7.1. haben wollte.

Also lösen wir das auf, indem wir 7.1 von Remi entfernen und 7.0 aufspielen:

dnf –enablerepo=remi update php56* php72*
dnf –enablerepo=remi erase php71*
dnf –enablerepo=remi install -y php70-php-process php70-php-cli php70-runtime php70-php-imap php70-php-common php70 php70-php-pdo php70-php-mbstring php70-php-json php70-php-pear php70-php-gd php70-php-mcrypt php70-php-mysqlnd php70-php-xml

Glückwunsch. Sie haben jetzt vier PHP Versionen auf Ihrem Server 😀

Mit FedUP, dem eigentlichen Upgradetool, hätte man das so nicht geschafft, da wäre das PHP dann auch von Remi gekommen.

Linux – Warnung Firefox 57 im Update

Fedora hat Firefox 57 ins Stable Repository gepusht. Damit schalten Sie allerdings auch alle Securityrelevanten Addons ab, da diese mit dem neuen Plugin-System nicht mehr kompatibel sind. Themes ergeht es genau so.

Wer also auf seine Sicherheit beim Browsen nicht verzichten will, ist in der schizophrenen Situation, daß er auf FF 56 downgraden muß. FF 56 läßt sich aber nicht direkt installieren, man muß tatsächlich erst FF55 und dann als Update FF 56 installieren.

Anstatt einen Firefox II Zweig rauszubringen, werden alle Benutzer vom FireFox mit automatischem Tracking, Flash, Javascriptdrivebys usw. beglückt und Ihr könnt Euch drauf verlassen, daß einen 0-Day für das neue System gibt, weil das ja auch so laaaaaaaaaannnnge getestet wurde 🙁 Cool geht anders!

 

Flatpak & Linphone 4

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.