Snap von AusweisApp2 unter Fedora 30

Heute hatte mich Andreas angeschrieben, weil unter Fedora 30 die AusweisApp2 keinen Treiber für den Kartenleser finden konnte. Das ist immer ein Anzeichen dafür, dass irgendetwas mit dem PCSC-Daemon nicht stimmt.

Das Problem lässt sich zum Glück relativ einfach auf zwei Arten lösen. Die einfache Variante deaktiviert SELinux bzw. setzt es auf den reinen Logging-Modus, die zweite setzt die korrekten Policies für SELinux.

SELinux deaktivieren

Diese Variante wird nicht unbedingt empfohlen. Es ist aber die einfachere und schnellere Lösung. Man muss dazu nur die Datei „/etc/sysconfig/selinux“ öffnen und den Parameter „SELINUX“ auf „permissive“ setzen. Nach einem Neustart funktioniert der Card-Daemon wie gewollt.

Policy für SELinux anlegen

Für diese Methode ist es notwendig, dass das Snap von AusweisApp2 installiert ist. Die beiden folgenden Befehle müssen als „root“ ausgeführt werden:

ausearch -c 'snap' | audit2allow -M snap.ausweisapp2-ce
semodule -i snap.ausweisapp2-ce.pp

Danach muss man den Rechner neu starten.

Kurztipp: Alte Snap-Revisionen deinstallieren

Snap hat die Eigenschaft, dass es standardmäßig drei Revisionen eines Pakets vorhält. Der Vorteil ist, dass man dadurch sehr schnell auf eine ältere Version eines Programms zurückwechseln kann, falls eine neue Version Probleme machen sollte. Der Nachteil ist, dass jede Revision Plattenplatz benötigt. Die Deinstallation ist kein großer Aufwand, bei vielen Snaps ist es aber relativ viel Tipparbeit. Deshalb hier mal ein Einzeiler, welcher alle alten Revisionen in einem Rutsch deinstalliert:

snap list --all | grep deaktiviert | awk '{system("sudo snap remove " $1 " --revision " $3)}'

Wer eine andere Systemsprache als Deutsch benutzt, muss den Begriff „deaktiviert“ entsprechend anpassen.

Warum ich Pakete für den Snap-Store bereitstelle

Neben der AusweisApp2 habe ich mit PyMOL eine weitere Anwendung für den Snap-Store paketiert.

Was ist PyMOL?

PyMOL ist ein 3D-Viewer und Editor für Proteine und im Bereich der Protoemik eine Standardanwendung. Nahezu alle Bilder, welche die Struktur von Proteinen zeigen, wurden mit Hilfe von PyMOL erstellt. Ein Beispiel sieht man hier:

PDB 1ABI: Thrombin (Grüne und rote Oberflächen) mit Hirudin („Stick“-Darstellung) gerendert mit PyMOL (Eigene Arbeit).

Ein Problem der Software ist, dass sie in zwei Versionen vertrieben wird:

Eine kommerzielle Version mit Support und eine freie Version (MIT-Lizenz). Letztere enthält etwas weniger Features (z.B. kein Antialiasing in der OpenGL-Darstellung), für die meisten Benutzer ist diese aber vollkommen ausreichend. Die freie Version dürfte von den meisten Benutzern verwendet werden, da die günstigste Lizenz der kommerziellen Version $99 pro Jahr kostet.

Die kommerzielle Version wird mit einer kompletten Python-3.7-Umgebung ausgeliefert (Conda), die freie Version ist in vielen Distributionen verfügbar. Leider liefern gerade die LTS-Distributionen nur die Version 1.8 oder noch ältere Versionen aus. Als Anwender hat man also nur die Möglichkeit die kommerzielle Version einzusetzen oder das Programm aus dem Quellcode selbst zu bauen.

PyMOL selbst ist eine Mischung aus Python -und C++-Code. Die Oberfläche ist dabei in Python (PyQT, früher Tcl/Tk) realisiert, der grundlegende Code in C++. Die Anzahl der Abhängigkeiten ist zwar relativ klein, aber in dem Umfeld wo das Programm üblicherweise eingesetzt wird, finden sich nur sehr wenige versierte Linux-Benutzer, welche einfach so mal ein Programm kompilieren können. Vor allem, weil PyMOL ein externes Python-Modul und eine externe C++-Headerdatei benötigt, welche jeweils händisch installiert werden müssen.

„Warum ich Pakete für den Snap-Store bereitstelle“ weiterlesen

AusweisApp2 als Snap #3

Ich habe eine neue Version des Snap-Pakets veröffentlicht. Dieses beinhaltet das Treiberpaket von „Reiner SCT“ für den PC/SC-lite Daemon.

Dadurch unterstützt der Daemon z.B. den „Reiner SCT cyberJack RFID standard. Dessen Treiber wurde im CCID-Treiber 1.4.30 auf Bitte von „Reiner SCT“ deaktiviert.

Das Update wird von „snap“ automatisch durchgeführt. Man kann es auch per „snap refresh ausweisapp2-ce“ anstoßen.

AusweisApp2 als Snap #2 (Update 06.04.19)

Nach Wochen der Bastelei habe ich es endlich geschafft ein Snap-Paket für die AusweisApp2 zu bauen, welches auch mit dem Confinement funktioniert. Die einzige Einschränkung, die aktuell noch existiert, ist das man nach der Installation einmalig die benötigten Interfaces des Snap-Pakets „connecten“ muss. Danach funktioniert die Anwendung ohne weitere Einschränkungen:

sudo snap install ausweisapp2-ce
sudo snap connect ausweisapp2-ce:raw-usb :raw-usb
sudo snap connect ausweisapp2-ce:hardware-observe :hardware-observe
sudo snap connect ausweisapp2-ce:network-manager :network-manager
sudo snap connect ausweisapp2-ce:network-observe :network-observe
sudo systemctl restart snap.ausweisapp2-ce.pcscd.service

Letzterer Befehl ist notwendig, damit der Card-Daemon noch vor dem ersten Start der Anwendung die passenden Rechte besitzt.

Ich habe im Snap-Store einen Request zum Auto-Connecten gestellt. Falls dieser genehmigt wird, kann man die Anwendung auch ohne explizites „connecten“ installieren.

Update

Ich habe gestern (05.04.19) die Freigabe des Stores für das automatische „connecten“ der benötigten Interfaces erhalten. Es reicht jetzt also aus das Snap zu installieren. Es sind keine weiteren Schritte notwendig.

AusweisApp2 als Snap (Update 25.01.19)

Da ich im Moment Urlaub und viel Zeit habe, habe ich mich mal daran gemacht ein Projekt zu vollenden, welches ich schon seit ein paar Monaten in die Augen gefasst habe:

Das Paketieren der AusweisApp2.

Falls jemand nicht weiß, wozu dieses Programm dient, hier mal der Link zum passenden Wikipedia-Artikel:

https://de.wikipedia.org/wiki/AusweisApp2

Offiziell unterstützen die Entwickler Linux nicht, dadurch dass der Quellcode aber unter Github und unter einer freien Lizenz verfügbar ist, kann man wenigstens den Versuch wagen das Programm unter Linux zum Laufen zu bekommen.

„AusweisApp2 als Snap (Update 25.01.19)“ weiterlesen

Eine Lanze für moderne Computer brechen

Retrocomputing ist in. Wer, wie ich, seine ersten Erfahrungen mit Computern in den 80er Jahren gemacht hat, ist für dieses Thema besonders empfänglich. Dabei ist der Blick zurück häufig ziemlich verklärt und die alte Zeit wird als die bessere angesehen. Dabei wird übersehen, dass früher nicht alles eitel Sonnenschein war.
Der folgende Artikel bezieht sich allein auf meine Erfahrungen, welche sehr stark von Heimcomputern und PCs mit MS-DOS geprägt wurden und weniger von Konsolen. Ich habe exemplarisch das Jahr 1992 als Grundlage des Artikels genommen, wobei ich auch spätere Jahre (bis ca. 1997) anspreche um bestimmte Sachverhalte zu verdeutlichen.


Kurze Biographie meinerseits:
Jahrgang 1977. Der erste C64 irgendwann im Jahr 1988. Im Oktober 1990 folgte ein Atari ST mit 1 MB RAM, im Mai 1992 dann ein PC (AMD 386SX25 CPU, 1 MB RAM und 40 MB HDD).

Warum ausgerechnet 1992? Weil ich in diesem Jahr meinen ersten PC gekauft habe und zusätzlich weil zu diesem Zeitpunkt der Computermarkt noch sehr viel heterogener war als heute. Neben den PCs waren noch sehr häufig Heimcomputer (Amiga, Atari ST oder C64) im Einsatz und viele Spiele und Programme wurden noch für mehrere Plattformen entwickelt. Zudem war der Leistungsunterschied zwischen den PCs und den Heimcomputern noch nicht so groß, obwohl Letztere mit der breiten Verfügbarkeit von 386er CPUs und VGA-Grafikkarten ins Hintertreffen gerieten.

Hier mal einige Punkte, welche meine Sicht auf die damalige Hardware und Software aufzeigen soll:

„Eine Lanze für moderne Computer brechen“ weiterlesen

Kleines Downloadskript für Mainline-Kernel

Da ich wegen meines Notebooks immer eine aktuelle stabile Vanilla-Version von Linux einsetze, habe ich mir in der Vergangenheit angewöhnt regelmäßig bei „www.kernel.org“ nachzuschauen, welches gerade die aktuellste stabile Linux-Version ist. Danach führte der Weg immer zum Mainline-PPA“ um dort dann die die Debian-Pakete des Kernels herunterzuladen. Diese sind in der Regel kurz nach der Freigabe einer neuen Version verfügbar. Da ich ein bequemer Mensch bin und mir vor allem das händische Herunterladen irgendwann auf den Geist ging, habe ich ein kleines Skript geschrieben, welches diese Schritte automatisiert:

Das Skript schaut auf der Kernel-Webseite nach, welches die aktuellste stabile Version ist und lädt dann aus dem Mainline-PPA die passenden Dateien für den eingesetzten CPU-Typ herunter. Das Skript hat noch drei Parameter, welche für alle selbsterklärend sind, die schon einmal einen Kernel aus dem Mainline-PPA heruntergeladen haben. Das Skript prüft selbstständig ob die CPU und der Kerneltyp zusammenpassen (z.B. macht es keinen Sinn zu versuchen einen „i386“-Kernel vom Typ „snapdragon“ herunterzuladen. Letzteren gibt es nur für den CPU-Typ „arm64“) und lässt nur den Download einer verfügbaren Kombination zu.

Das Skript ist in Python3 geschrieben und benötigt ein zusätzliches Python-Modul, welches aber in allen noch unterstützten Ubuntu und Debian-Versionen vorhanden ist:

sudo apt install python3-lxml

Das Skript habe ich auf Github gehostet: https://github.com/glasen/download_kernel

Direkter Download des Skripts: download_kernel.py

Eine kleine Einführung in die Bioinformatik und warum Linux dort so weit verbreitet ist

Wie ich in meinem Blog irgendwann mal erwähnt habe, studiere ich im Moment Bioinformatik an der THM und JLU in Gießen. Da ich nebenbei auch  noch einen Job in einer der Arbeitsgruppen habe, bekomme ich einen Recht guten Eindruck davon, was aktuell Forschungsgebiet in der Bioinformatik ist und vor allem welche Software und Hardware dort eingesetzt wird. Einen Überblick über beispielsweise die Hardware des Bioinformatikfachbereichs an der THM liefert der z.B. folgende Link:

mni.thm.de: Bioinformatik erweitert Infrastruktur

Ubuntu ist im Bioinformatik-Umfeld sehr weit verbreitet. Ich würde sogar sagen, dass knapp 80% aller Bioinformatiker Ubuntu (Mit verschiedenen Desktops) einsetzen. Der Rest verteilt sich auf Debian und Arch-Linux. Es gibt auch Windows-Nutzer, aber diese sind deutlich in der Unterzahl. Ein sehr nettes Feature seitens Ubuntu und Debian ist die Tatsache, dass nahezu alle wichtigen Bioinformatik-Tools direkt in den Paketquellen vorhanden sind. Das ist auch einer der Hauptgründe für die weite Verbreitung.

Die Bioinformatik ist grundsätzlich sehr Unix-affin. Nahezu alle Server, die irgendwas mit Bioinformatik und verwandten Gebieten zu tun haben, laufen unter einem Unix-System (Heutzutage hauptsächlich eine Linux-Distribution). Und wer tagtäglich auf einem Unix-System unterwegs ist, arbeitet auch privat eher mit so einem System.

„Eine kleine Einführung in die Bioinformatik und warum Linux dort so weit verbreitet ist“ weiterlesen

Intel Management Engine des T460 unter Linux aktualisieren

Letzten Monat wurde eine gravierende Sicherheitslücke in der Intel Management Engine bekannt. Ob das eigene System von der Lücke betroffen ist, kann man mit dem „SA00086 Detection Tool“ überprüfen.

Sollte das Tool eine Meldung ähnlich der folgenden ausspucken, dann ist man erst einmal auf der sicheren Seite:

Based on the analysis performed by this tool: This system is not vulnerable. It has already been patched.

Lenovo hatte recht schnell eine aktualisierte Firmware für das T460 bereitgestellt, aber uns Linux-Benutzer leider außen vor gelassen. Da ich keine Lust hatte nur wegen eines Firmware-Updates ein Windows 10 zu installieren, habe ich die Suchmaschine meines Vertrauens bemüht und nachgeschaut ob es nicht eine Möglichkeit gibt die „Management Engine“ plattformunabhängig zu aktualisieren. Und siehe da, ich bin relativ schnell über einen Thread im Win-Raid-Forum gestolpert, der genau das ermöglicht. Dort gibt es mehrere Links zu Archiven, welche die aktuellsten Versionen der ME-Firmware und diverse Tools zum Flashen der Firmware enthalten.

Anfangs dachte ich noch, dass ich zwingend die UEFI-basierten Tools „MEInfo.efi“ und „FWUpdLcl.efi“ aus dem Archiv für die ME-Version 11 benutzen, ich also EFI-Binärdateien innerhalb einer EFI-Shell ausführen muss (Siehe auch den Info-Kasten am Ende). Interessanterweise sind die gleichen Tools auch in nativen Linux-Versionen in den Archiven vorhanden (Intel denkt also auch an Linux-Benutzer. Nur lässt uns Lenovo im Regen stehen). Mit diesen ist es sehr einfach möglich direkt unter Linux die ME-Firmware zu aktualisieren. Ich habe die zwei notwendigen Dateien „MEInfo“ und „FWUpdLcl“ in ein eigenes Archiv gepackt:

me_tools_11.tar.bz2

Alles was man noch zusätzlich braucht, sind die passenden Firmware-Dateien. Diese bekommt man über den folgenden Link:

Lenovo – Intel Management Engine 11.8 Firmware EXE

Die EXE-Datei muss mit dem Tool „innoextract“ (Unter Ubuntu in den Universe-Quellen, in Debian in Main) entpackt werden:

innoextract r06uj57w.exe

Danach liegen die folgenden Dateien im Verzeichnis „app“ (Die EXE und DLL-Dateien habe ich schon gelöscht):

-rw-r--r-- 1 glasen glasen 2031616 Okt 26 16:56 ME_11.8_Consumer_C0_LP_Production.bin
-rw-r--r-- 1 glasen glasen 7348224 Okt 26 16:56 ME_11.8_Corporate_C0_LP_Production.bin
-rw-r--r-- 1 glasen glasen 1063 Okt 17 11:46 MEUpdate.CMD
-rw-r--r-- 1 glasen glasen 80469 Okt 26 01:13 SLA_TOOLS.pdf

Für das Update benötigt man nur die passende BIN-Datei. Beim T460 muss die „Consumer“-Firmware eingespielt werden. Versucht man es mit der „Corporate“-Firmware, bekommt eine Fehlermeldung:

Error 8746: Firmware update not initiated due to invalid image length

Zum Durchführen des Updates benötigt man noch die „OEM ID“. Diese kann man entweder über das Tool „MEInfo“ auslesen oder aus der Datei „MEUpdate.CMD“ übernehmen (Beide sind identisch):

sudo ./MEInfo -feat „OEM ID“

Intel(R) MEInfo Version: 11.8.50.3425
Copyright(C) 2005 – 2017, Intel Corporation. All rights reserved.

Driverless mode

OEM ID: 4c656e6f-766f-0000-0000-000000000000

Ab hier wird es gefährlich. Wer sich nicht 100% sicher ist, was er tut, sollte von dem Update die Finger lassen oder dieses über eine Windows-Installation durchführen. Bei mir hat es bei meinem T460 problemlos geklappt, aber ich spreche trotzdem eine Warnung aus!

Das Firmware-Update wird über den folgenden Befehl angestoßen:

sudo ./FWUpdLcl -F app/ME_11.8_Consumer_C0_LP_Production.bin -OEMID 4C656E6F-766F-0000-0000-000000000000 -allowsv

Die Ausgabe sollte dann nach einem erfolgreichen Update so ausschauen:

Intel (R) Firmware Update Utility Version: 11.8.50.3425
Copyright (C) 2007 – 2017, Intel Corporation. All rights reserved.

Communication Mode: MEI
Checking firmware parameters…

Warning: Do not exit the process or power off the machine before the firmware update process ends.
Sending the update image to FW for verification: [ COMPLETE ]

FW Update: [ 100% (|)]Do not Interrupt
FW Update is completed successfully.

Danach muss das System nur noch neu gestartet werden und die Firmware der „Management Engine“ ist auf dem aktuellsten Stand.

Im Thread im Win-Raid-Forum gibt es noch Updates für ältere ME-Versionen und auch die passenden Tools. Ich habe z.B. mein Haswell-basiertes Desktop-System mit diesen auf den aktuellsten Stand gebracht. Leider gibt es nur für die ME-Version 11 Linux-Versionen der Tools. Unter den älteren Versionen muss man auf die UEFI-Binaries ausweichen, was den Einsatz einer EFI-Shell erforderlich macht. Ich hatte diese Vorgehensweise als erstes getestet, da ich den Verlust eine 40€ Motherboards eher verkraften kann, als den eines teuren Notebooks.

Die Vorgehensweise lässt sich grundsätzlich auf andere Hersteller übertragen. Man benötigt nur die passende Version der „ME“-Firmware und die passenden Versionen der Tools