Tag Archives: rpm

Pinephone: GPS Ergebnis verbessern

Posted on by

Es klingt wie ein schlechter Scherz, aber da hängen Satelliten im All, die helfen, die eigene Position auf cm genau zu bestimmen, und dann landet man in einem Fluß in Leipzig 😉

Pinephone: GPS Ergebnis verbessern

Ihr könnt Euch sicher vorstellen, wo ich wohne. Wenn ich mein Pinephone frage, wo ich denn bin, sagt es mir entweder präzise, daß ich bei mir Zuhause bin, weil es mein WLAN erkennt, oder das ich in einem Fluß bei Leipzig schwimmen bin, im Oktober.

Mit dem Ergebnis kann man natürlich nichts anfangen und bevor jemand über das Pinephone herzieht, Android oder iOS-Geräten ergeht es mit reinem GPS auch nicht anders.

Technisch kann man die Genauigkeit und vor allem die Geschwindigkeit bis zur Fixierung der Position mit Hilfe von vorgefertigten Hilfsdaten deutlich beschleunigen. Die XtraPath Daten werden ins Modem geladen und verbessern da die GPS Verarbeitung. Zunächst muß man diese natürlich erst einmal Laden:

curl -LO http://xtrapath2.izatcloud.net/xtra3gr.bin

Dann müssen wir es Modem zuführen:

mmcli -m any –location-inject-assistance-data=xtra3gr.bin

anschließend noch AGPS aktivieren:

mmcli -m any –location-enable-agps-msb

und dann wären wir auch schon im Geschäft, wenn da nicht die echt schlechte GPS Antenne vom Pinephone wäre. In einem Innenraum nahe am Fenster könnt Ihr GPS vergessen, da schwimme ich immer noch in der Weißen Elster rum.Die Hardware von Samsung ist da besser, die schafft eine Lokalisierung auch dort schon.

Die Genauigkeit bis zum Lock verbessern

Wenn man nicht weiter in Leipzig sein möchte, dann hilft leider nur der naheliegendste Schritt: Der Schritt vor die Tür 😉  GPS funktioniert auf dem Pinephone tatsächlich nur dort, wo man es wirklich braucht: draußen.

Überprüfen könnt Ihr das damit:

mmcli -m any –location-status

Wenn sich die Ausgabe verändert, hat das Pine ein Signal von einem oder mehreren Satelliten aufgefangen. Bleibt die Anzeige eher statisch stehen, wird kein Signal empfangen. Ohne die sich ändernden Signale, kann man die Position nicht bestimmen, da hier die Laufzeiten der Signale benutzt werden und dazu muß man die dauerhaft empfangen.

In dem AGPS RPM, das ich gestern verteilt habe ist ein Script drin, daß Euch das alles beim Systemboot abnimmt: modemmanager-agps-1-1.aarch64.rpm

Da es sich nicht um Fedora spezifische Dinge handelt, könnt Ihr das RPM überall verwenden, wo man mit RPMs arbeitet: RHEL, CentOS, Fedora, YellowDog usw. wichtig wäre nur, daß da auch systemd drauf ist. Sollte das nicht der Fall sein, müßt Ihr Euch wohl ein eigenes Init-Script basteln.

Was uns jetzt noch fehlt

Ok, die GPS Basisfunktionalität ist vorhanden, man bekommt raus, wo man ist. Jetzt brauchen wir noch etwas Komfort in Gnome-Maps z.b. für Live Routing Tracking. Falls das jemand vom Gnome-Projekt mitliest, stellt Euch schon mal auf einen Featurerequest ein 😉

Was weniger schön an GPS ist, es zieht richtig viel Energie aus dem Akku. Laßt es also nicht lange offen, wenn der Akku nicht voll ist. Ein USB-C Ladeadapter für Auto wird in Zukunft eine gute Investition sein.

 

Sicherheitslücke in RPM: alte Keys werden nicht ungültig

Posted on by

Wie ZDNET gerade berichtet, haben RPM / DNF System wie Fedora, CentOS , RHEL und andere ein kleines Problem mit einer möglichen Supply-Chain-Attack.

Sicherheitslücke in RPM: alte Keys werden nicht ungültig

RPM Pakete aus Distro Repos werden i.d.R. signiert mit dem Key der jeweiligen Distro. RPM / DNF prüfen nach dem Download die Signatur des Pakets und nur wenn die gültig ist, wird das Paket installiert oder aktualisiert.

Die Prüfung ist leider nicht vollständig, weil alte Schlüssel nicht ungültig werden, da keine Revocationliste gefragt wird, ob der Key nicht zurückgezogen oder abgelaufen ist.

Das führt zu einer Supply-Chain-Attacke die uns allen dumm auf die Füsse fallen kann, wenn jemand die Repo Mirrors knacken sollte um dort geänderte Pakete mit alten Keysignaturen zu versehen. Damit wäre die Sicherheit der ganzen Installation gefährdet. Erschweredn kommt hinzu das immer noch unsignierte Pakete akzeptiert werden, auch wenn die GPG Signaturenprüfung aktiviert ist, meinen jedenfalls die Finder der Lücke.

Zwei Workarounds sind denkbar:

  1. Mirrorliste der Repos abschalten und nur noch die Hauptserver von Fedora /CentOs/ RHEL benutzen. Temporär wäre das eine Maßnahme, aber es belastet die Hauptserver kräftig.
  2. Die alten Keys vom System entfernen, dann sind die Signaturen nicht prüfbar => Problem erst einmal gelöst, außer es lassen sich wirklich unsignierte Pakete installieren, das wäre fatal.

Quelle: https://www.zdnet.com/article/major-linux-rpm-problem-uncovered/

Fedora: wie man mit RPM sein System auf Integrität prüft.

Posted on by

Heute geht es um Dateiintegrität und wie man das mit RPM prüft und ggf. behebt. Grund ist das Pinephone.

Fedora: wie man mit RPM sein System auf Integrität prüft.

Wenn man sein Pinephone zum ersten mal bootet, startet es mit dem Image auf der internen Storage mmcblk2. Will man etwas anderes Booten, so steckt man eine SD Karte rein, auf dem das Bootimage drauf ist. Das ist gerade am Anfang, wenn man viel Testet eine normale Sache, weil man die MicroSD Karte leicht wieder mit einem SD-Kartenreader am PC neu bespielen kann.

Wenn man aber zu an einen Punkt gekommen ist, wo das System gut genug funktioniert, möchte man es auf die interne Speicherkarte kopieren. Das könnt Ihr via rsync machen, oder Ihr kopiert die SD-Karte mit dem Tool dd rüber. Das hat aber einen Haken: Von dem System habt Ihr gerade gebootet und das läuft noch. Da man die Karte im laufenden Betrieb nicht wechseln sollte, steht Ihr vor einem Problem. Rsync umgeht das, aber Systemfiles lassen sich nicht so einfach syncen. Würde man so z.b. ein Fedora 33 auf ein anderes Fedora 33 syncen, würde es vermutlich laufen, aber (wie hier) ein Fedora auf Manjaro Syncen, geht sehr wahrscheinlich voll in die Hose.

Wenn wir also dd benutzen steigt zwar die Erfolgschance, aber ein Datenverlust steht im RAM, weil die Programme auf der Partition rumwerkeln und die sich beim Kopieren ändern. Also am besten ALLES was geht beenden: Desktop, Services, alles bis auf SSHd und das Netzwerk.

Schritt 1 – Ermitteln was drauf ist

Dazu führt Ihr „rpm -qa > rpms“ aus. Nicht vergessen das File nachher wieder zu löschen.

Schritt 2 – jedes Paket prüfen

Dazu brauchen wir awk und ein klein wenig Bashmagie:

awk < rpms ‚{print „rpm -V –nolinkto –nomtime –nomode –nouser –nogroup –nordev –nodeps „$1;}‘ | bash > log

Das liest die Liste der RPMs Zeile-für-Zeile ein und prüft das Paket, ob die Checksummen mit den Dateien übereinstimmen. Einige Tests sind absichtlich abgeschaltet worden, weil für den Test, ob eine Datei beschädigt ist oder nicht, nicht nötig. Ob ich da mal dran war und die absichtlich verändert habe, war nicht die Aufgabe, kann man so aber auch machen, wenn man die –no Flags weglässt. „–nodeps“ sollte man aber drin lassen, weil sonst jedes Paket immer mit allen Abhängigkeiten geprüft wird und wir prüfen eh alle einzeln 😉

Schritt 3 – Defekte Dateien finden

Da wir in Schritt 2 eine Log-Datei angelegt haben, werten wir die aus und lassen uns gleich die Paketnamen der defekten Dateien geben. Das „sort -u“ wirft doppelte raus:

grep „\.5\.\.“ log | grep -v “ c “ | grep -v “ d „| grep -v ^S | awk ‚{print „rpm -qf „$2;}‘ | bash | sort -u

.5… ist die Ausgabe, wenn die Datei beschädigt ist und z.b. keine Configdatei ist. Configs können sich natürlich jederzeit ändern, deswegen sind die nicht gleich defekt.

Ein paar Beispiele was die Ausgaben so meinen:

S.5…… c /etc/ssh/sshd_config  Datei hat andere Checksumme, ist aber eine Configdatei
fehlend d /usr/share/man/fr/man1/manconv.1.gz Datei ist eine Dokumentation, nicht tragisch, wenn die nicht da ist.
fehlend /boot/efi/overlays/adau1977-adc.dtbo Datei fehlt und sollte aber da sein.
..5…… /usr/bin/mokutil Datei ist defekt und sollte ersetzt werden.

Schritt 4 – Reparieren

Nun haben wir eine Liste mit Paketnamen und müssen die nur noch reparieren. In meinem Fall waren es vier defekte Pakete:

dnf reinstall dcraw efibootmgr f2fs-tools mokutil -y

Das muß natürlich bei Euch so nicht passen, es könnte auch gut gehen oder andere Dateien betreffen!

Vom efibootmgr wissen wir jetzt, daß er gar nicht nötig ist auf einem Pinephone, weil das U-Boot benutzt und so gesehen kein EFI Bios vorhanden ist.

Ein Wort noch zum Pinephone:

Kopiert das System ruhig auf die interne Karte, weil das dann ca. 5x schneller ist: beim Booten, beim Runterfahren, Apps starten und updaten. Es lohnt sich wirklich.