Schlagwort-Archive: Arch Linux

SSH: Fingerprint-Algorithmus ändern

Bild: https://adlerweb.info/blog/wp-content/uploads/2015/04/sshmd5-300×45.pngMit einem der letzten Updates scheint OpenSSH einen Schritt in Richtung Gegenwart getätigt zu haben. Nun werden Fingerprints nicht mehr als MD5 sondern mit SHA256 präsentiert. Was auf der einen Seite eine tolle Sache ist kann aber auch zum Problem werden: Eine hiesige Debian-Kiste kann mit dem dort als stable deklarierten OpenSSH 7.0 auch optional keinen SHA256-Hash herausrücken. Manueller Abgeleich mit dem neueren Client des ArchLinux-Systems unmöglich. Um hier wieder auf einen gemeinsamen Nenner zu kommen bleibt nur den neuen Client auf den älteren Hash-Algorithmus zurückzutrimmen. Das funktioniert über die SSH-Config (/etc/ssh/ssh_config or ~/.ssh/config) mit folgenden Zeilen – zum Glück auch für einzelne Hosts:

Host oldserver.org
FingerprintHash md5

Schon erhält man beim Verbinden wieder den gewohnten MD5-Hash und kann sich – bis auch andere Distros sha256 herausrücken – behelfen.

Nvidia/X.org: OpenGL-Fehler bei einigen Spielen

Vor kurzem mussten die mehr als 10 Jahre alten Grafikkarten meines Rechners einem neueren Modell weichen. Schneller, weniger Strom und – das Wichtigste – ich kann wieder die aktuelle Treibergeneration nutzen. Die Umrüstung ist unter Linux ja kein Problem: Umstecken, den alten Nvidia 340 “Legacy”-Treiber gegen einen aktuellen 346er ersetzen und fertig ist. Dank nvidia-settings sind die Monitore schnell sortiert und der 3D-Test glxgears zeigt trotz Rendering auf 4 Monitoren zugleich solide 60 Frames (aka vsync-Maximum). Auch Videobearbeitung und Co reagieren solide. Also schnell die Arbeit fertig gemacht und eine Runde zocken. Oder auch nicht.

X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 3 (X_GLXCreateContext)

so lautete die Meldung, welche ich beim Starten von RTCW:ET erhielt. Na gut, eventuell ja was daran kaputt, also graben wir mal UT99 aus. Nichts. UT2004? Nichts. $randomgame in wine? Nichts. WTH?

Genervt klicke ich mich durch meinen Game-Ordner und bleibe bei OpenTTD und ArmagetronAD hängen. Beide funktionieren fehlerfrei und dürfen nun den Feierabend versüßen. Die nächsten Tage blieb keine Zeit für Spiele.

Heute konnte ich mich dem Problem nochmal genauer annehmen und mein Kopf machte soeben Bekanntschaft mit der Tischkante. Wer aufgepasst hat wird feststellen: Nur binär vertriebene Spiele machten das Problem, Open-Source Games laufen. Kein Wunder, denn letztere werden – egal wie alt – passend zum System kompiliert. 64Bit. Die Binärspiele hingegen laufen – wie auch wine – im 32 Bit Modus und greifen entsprechend auf die Kompatibilitätslibraries zurück…die ich natürlich nicht aktualisiert hab. Also schnell die lib32-nvidia-340xx-libgl gegen die aktuelle lib32-nvidia-libgl getauscht und voilà: Auch die Binärblobs können auf wundersame Weise wieder 3D. Doh’!

Unreal Tournament (1999) unter Arch Linux

Zugegeben, mit über 15 Jahren ist das originale UT etwas betagt, aber wenn man die Installationsmedien findet weckt das doch das Bastlerego – ob es auf einem aktuellen Linux läuft? Sollte eigentlich – das Spiel selbst kann bereits seit längerem über den Loki Installer auf Linux lauffähig zu bekommen. Eher Bedenken hatte ich da bei den Libraries: Sound in Kombination mit Pulseaudio hat mir schon bei RTCW:ET eine Menge Bastelzeit gekostet. Auch der Installer setzt GTK1.2 voraus – findet man heute eher nicht mehr. Glücklicherweise bin ich bei Arch da gleich doppelt im Vorteil: Während man bei Ubuntu & Co. das alte GTK manuell installieren muss kann ich auf ein passendes AUR-Paket zurückgreifen. Oder es sein lassen, denn ein Paket namens “UT1999” erlaubt die Installation ohne den GUI-Installer. Leider ist auch das Paket nur ein Ansatz, aber keine Lösung. Nachdem die Installations-CDs vom Paket erfolgreich in /opt/ut platziert wurde folgte schnell Ernüchterung. Der Befehl wird ohne Meldung beendet, als Exitcode erscheint ein Fehler.

adlerweb@zeus /opt/ut/System $ ./ut-bin
adlerweb@zeus /opt/ut/System $ echo $?
1

Könnte natürlich eine Library sein, da UT99 eine 32-Bit Binary ist und ich auf einem 64-Bit System arbeite. Kurzer Blick: libgl, SDL, openal – alles genannte ist auch in 32-Bit bereits vorhanden. Nach etwas Suchen half dann der Parameter “-log” den Fehler genauer zu identifizieren:

adlerweb@zeus /opt/ut/System $ ./ut-bin -log
Unreal engine initialized
Bound to SDLDrv.so
Joystick [0] : Unknown Joystick
SDLClient initialized.
Bound to Render.so
Lighting subsystem initialized
Rendering initialized
LoadMap: Entry
Failed to load 'Entry': Can't find file 'Entry'
Failed to load 'Level None.MyLevel': Can't find file 'Entry'
appError called:
Failed to enter Entry: Can't find file 'Entry'
Executing UObject::StaticShutdownAfterError
Executing USDLClient::ShutdownAfterError
UGameEngine::Init
InitEngine
Preparing to exit.
Purging garbage
Unbound to Engine.so
Unbound to Core.so
-0.0ms Unloading: Package Engine
-0.0ms Unloading: Package Core
Game engine shut down
Unbound to SDLDrv.so
SDL client shut down.
Unbound to Render.so
-0.0ms Unloading: Package Render
Lighting subsystem shut down
Rendering shut down
Garbage: objects: 231->0; refs: 0
Object subsystem successfully closed.
Exiting.
Name subsystem shut down

Hintergrund: Das Paket kopiert die Daten an die falsche Stelle. Doll. (Der offizielle Installer veranstaltet angeblich das selbe). Also räumen wir mal auf:

cd /opt/ut/System/
cp -Rv Entry.unr Entry
cp -Rv AS-* CTF-* DM-* DOM-* EOL_* ../Maps

Und siehe da – kurz darauf sieht man das gute, alte

In 2291, in an attempt to control violence among deep space miners, the New Earth Government legalized no-holds-barred fighting.

Ja, sieht. Denn Ton ist wie erwartet ein Problem. Dankenswerterweise muss man sich hier nicht mit PunkBuster o.Ä. herumärgern und darf direkt herumdoktern. Zuerst wird das Audiosystem auf OSS erzwungen, so ist das Basteln einfacher. Hierzu unter /home/[user]/.loki/System/UnrealTournament.ini die Zeile

AudioDevice=ALAudio.ALAudioSubsystem

durch

AudioDevice=Audio.GenericAudioSubsystem

ersetzen. Danach würde ich eigentlich mit padsp starten, aber dieser lädt lediglich die 64Bit-Version, welche der UT-Binary nichts anhaben kann. Dann machen wir es halt manuell:

LD_PRELOAD="/usr/lib32/pulseaudio/libpulsedsp.so"

Viola:

Liandri Mining Corporation, working with the NEG, established a series of leagues and bloody public exhibitions.

– diesmal aus den Boxen. Auch eine kleine Testrunde lief selbst auf 1920×1080 in bester Qualität (für ’99). Da steht einem Onlinespiel auf einem der über 600 aktiven Gameservern ja nichts im Wege…

Arch Linux: Grafik-Software streikt nach Mesa-Update (10.2.7-2)

Seit vermutlich dem letzten Mesa-Update auf 10.2.7-2 vom letzten Wochenende ist offenbar OpenGL nicht mehr voll funktionsfähig – in meinem Fall verabschiedete sich Hugin mit der folgenden Meldung:

Der Fehler ist schon im Arch-Bugtracker zu finden. Eine aktualisierte Mesa-Version (10.2.7-3) findet sich in Testing, hiermit tritt der Fehler nicht mehr auf.

Edit: Laut Website soll 10.2.7-3 wohl seit gestern in extra sein, auf meinem Mirror war dies jedoch noch nicht der Fall.

Arch Linux/Systemd: Screen-Sitzung als Daemon

Nicht immer kann oder möchte man ein Linux-Programm als Daemon starten – fehlende Daemon-Funktion, die Möglichkeit direkt auf STDOUT/STDERR zu schauen, etc. In den meisten Fällen bemühe ich für diese Fälle den Terminal Multiplexer “screen”. Hiermit wir die Software mit komplettem Terminal gestartet, man kann jedoch die Verbindung trennen, sodass das Programm im Hintergrund weiter seinen Dienst tut. Bei einem späteren Reconnect sind alle vorherigen Ausgaben wieder sichtbar.

Bisher startete ich diese Programme von Hand, auf einem System habe ich nun aber ein Shell-Script, welches sinnigerweise direkt beim Boot gestartet werden soll – bauen wir uns einen passenden Systemd-Service:

Wie unschwer zu erkennen handelt es sich um einen DDNS-Update-Daemon. Zwar würde der auch direkt laufen, da jedoch ab und an mal manuell ein Befehl abgesetzt werden muss ist mir screen lieber. Die Bedingung nach network.target zu laufen ist rein durch die DNS-Funktion bedingt und für Screen nicht notwendig.
Interessant wird es in [Service] – Erst wird der Nutzer festgelegt, welcher den Screen starten soll – da der Daemon Systemeinstellungen ändert komme ich hier um root nicht herum. Unter ExecStart wird der passende Befehl angegeben – es wird eine screen-Sitzung mit dem Namen “ddns” gestartet und dort das Script “/usr/local/sbin/ddns.sh” ausgeführt. In der nächsten Zeile wird zum Stoppen der Screen mit dem Namen “ddns” beendet.

Die Datei wird unter /etc/systemd/system/ddns.service abgelegt und ist danach wie jeder andere Dienst nutzbar. Ist er mit “systemd start ddns” gestartet kann der Nutzer root sich mittels “screen -x ddns” zur laufenden Sitzung verbinden. Mit der Tastenkombination “Ctrl-a d” wird die Verbindung wieder getrennt.

Einige Warnungen noch:
– Die Sitzung hat ggf. nicht alle Umgebungsvariablen, die man von einer “normalen” Shell-Sitzung gewohnt ist
– Bricht das Script ab wird der Screen beendet, in dem Fall ist die Ausgabe/Fehlermeldung nicht mehr sichtbar. Hier kann man ggf. eine interaktive Shell nach dem Script starten und so die Sitzung offen halten. Beispiel:

VsFTPd 3.x und 64Bit-Server

Bein Aufsetzen eines FTP-Servers mittels VsFTPd kam es zu einem etwas anderen Problem: Der Server startete, beim Connect erhielt der Client jedoch lediglich die Meldung “500 OOPS: child died”. Im Log selbst war keine Meldung auffindbar.

Auslöser ist offenbar ein zu strikter Sicherheitsfilter in Verbindung mit 64Bit-Kerneln. Gentoo scheint nicht betroffen zu sein, dort lief die Version 3.0.2 fehlerfrei, selbige unter Arch Linux verursacht den Fehler. Als Workarround kann man die neuen Sicherheitsfunktionen durch setzen des Wertes “seccomp_sandbox=NO” in der vsftpd.conf abschalten.

Anzeige von Leerzeichen/Tabs unter Pluma (Mate-Text-Editor)

Tabulator oder Leerzeichen zum Einrücken, da ist sich die Programmierwelt noch nicht so ganz einig. Ein Mix aus beiden sieht allerdings unprofessionell aus und kann – je nach Editorkonfiguration – eine inkonsiste Anzeige erzeugen. Besser wäre es die unsichtbaren Biester direkt im Auge zu halten. Viele Editoren bieten eine Möglichkeit u.A. Tabs und Leerzeichen zu visualisieren, wenn es aber mal schnell gehen muss nutze ich auch den Texteditor meiner DE “Mate”, welcher sich “Pluma” schimpft und ein Nachfolger des alten “Gedit” aus dem “Gnome”-Projekt darstellt.

Leider unterstützt Pluma eine solche Anzeige nicht nativ, ein passendes Plugin ist aber im Plugin-Paket auf GitHub verfügbar, welches insgesamt folgendes beinhaltet:

Für Arch Linux steht das Ganze jetzt im AUR bereit, andere Distros müssen sich ggf. mit ./autogen.sh && make && make install behelfen. Die Plugins können nach einem Neustart des Editors in den Einstellungen aktiviert und konfiguriert werden.

Aria2 als Daemon mit Webinterface unter Arch Linux

Kurz und knapp: Aria2 ist ein Downloadmanager für Linux, welcher ein sehr großes Funktionsspektrum bietet – Downloads werden per HTTP/HTTPS, FTP, BitTorrent oder Metalink abgewickelt. Im HTTP-Bereich ist es möglich Downloads in mehrere Parts zu stückeln und diese von verschiedenen Mirror-Servern zu laden.

In meinem Fall soll das Ganze auf einem (GUI-losen) Linux-System laufen und von einem PC verwaltbar sein – so kann z.B. die neue Linux-Distro gemächlich über meine alte DSL-Leitung vor sich hin laden ohne meine Kabel-Hauptleitung zu belasten oder mich zu Zwingen den Rechner durchlaufen zu lassen. Als Host genügt dabei durchaus ein Linux-Embedded-System wie z.B. viele Router oder auch der Raspberry Pi.

Aria2 findet sich in den offiziellen Arch-Repos und lässt sich entsprechend direkt installieren. Für den Daemon-Modus nutze ich einen eigenen Benutzer namens “aria2”. Im Home-Verzeichnis des Nutzers wird (wenn nicht vorhanden) ein Ordner .aria2 erstellt (führenden Punkt nicht vergessen). Dort wiederum eine Datei namens aria2.daemon mit folgendem Inhalt:

Die Konfiguration weist Aria2 an als Daemon zu starten und alle Downloads in /home/aria2/Downloads zu speichern. Pro Server werden maximal 4 Verbindungen geöffnet, insgesamt 3 Downloads werden parallel geladen. Eine Bandbreitenbeschränkung für den Download ist nicht hinterlegt. In den letzten Zeilen werden die Zugangsdaten für das Frontend hinterlegt.

Anm: rpc-user und rpc-pass sind “deprecated” und sollten nicht mehr verwendet werden, zum aktuellen Zeitpunkt wurde das hier verwendete Frontend jedoch noch nicht auf die neue Authentifizierungsmethode portiert

Anm2: file-allocation=falloc weist aria2 an den für den Download nötigen Platz im Vorfeld zu reservieren, dies verhindert Fragmentierung der Daten, jedoch kann es beim Start des Download einige Sekunden bis Minuten dauern bis die ersten Daten übertragen werden. falloc ist nur auf neueren Dateisystemen wie ext4, btrfs oder xfs nutzbar, bei älteren Systemen kann prealloc genutzt werden. Mit none wird die Reservierung abgeschaltet.

Um den Daemon automatisch beim Boot zu starten wird zudem die Datei /etc/systemd/system/aria2c.service erstellt:

Auch hier ggf. die Pfade an das eigene Setup anpassen.

Per systemctl start aria2c wird der Dienst gestartet – läuft dies ohne Fehlermeldung kann er mit systemctl enable aria2c in den “Autostart” des Servers gelegt werden. Alles ist auch nochmal in der Arch-Wiki zu finden.

Für das Webinterface verwende ich webui-aria2. Es nutzt ausschließlich Javascript/HTML5 (Websockets/AJAX) für die Kommunikation, daher ist es weder notwendig die Daten auf dem selben System abzulegen, PHP/Python/Perl… zu installieren oder einen Webserver zu nutzen. Theoretisch kann die Datei auf der lokalen Festplatte des verwaltenden PCs/Laptops liegen und dort geöffnet werden. In meinem Fall liegen die Dateien auf einem bereits vorhandenen Webserver, so muss ich bei Updates nicht immer zwischen all meinen Geräten hin und her kopieren.

Beim öffnen der HTML-Datei werden die Zugangsparameter abgefragt. Bei Host wird die IP des Servers mit Aria2 eingetragen, der Port ist bereits hinterlegt. User/Passwort wurden in der zuvor erstellten Konfigurationsdatei eingerichtet.

Im Anschluss sollte die Verbindung aufgebaut werden können – am besten Prüft man das über Settings->Server Info, sind hier Daten hinterlegt konnte die Verbindung aufgebaut werden. Lasset die Downloads starten!

Bild: https://adlerweb.info/blog/wp-content/uploads/2014/05/aria2-300×195.png

Downloads direkt auf einem kleinen Linux-System? Check.

Zur Referenz: Der gezeigte Download ist Star Trek Phase II: Kitumba von startrekphase2.de.

Arch Linux: Schlüsselfehler bei Update

Nur “mal kurz” updaten – “pacman -Syu”, paar mal Enter und schon ist das notwenige Übel von der Todo-Liste verschwunden. Nunja, üblicherweise. Auf einem System trat heute nach dem Download folgender Fehler auf:

Fehler: key "B02854ED753E0F1F" could not be looked up remotely
Fehler: Erforderlicher Schlüssel fehlt im Schlüsselbund
Fehler: Konnte den Vorgang nicht durchführen (Unerwarteter Fehler)
Fehler sind aufgetreten, keine Pakete wurden aktualisiert.

Ursache ist ja schon recht gut beschrieben: Ein Paket ist offenbar mit einem Key signiert, den das System noch nicht kennt. Üblicherweise versucht pacman dann diesen von den Arch-Servern(?) nachzuladen. In meinem Fall erfolglos – der Rechner hat keinen direkten Internetzugang und kommt nur per HTTP-Proxy nach draußen.

Um den Fehler zu beheben sollte man vor dem Systemupdate das Paket archlinux-keyring neu installieren. Dieses bringt alle aktuellen Schlüssel mit und aktualisiert die lokale Datenbank, danach sollten auch die restlichen Aktualisierungen problemlos laufen.

Linux: Single-Thread-Programme auf Multicore-Rechnern parallelisieren

*Auf Uhr tipp* Dauert mal wieder lange, das berechnen – kein Wunder, denn die Software, welche ich hier einsetze, kann nur einen einzigen CPU-Kern nutzen. Wäre doch schön, wenn man so Aufgaben beschleunigen kann, oder?

In meinem Fall heißt die “Bremse” Tesseract, ein open source OCR-System um eingescannte Dokumente in Text zu verwandeln. Bisher fütterte ich jede Seite nacheinander an das Programm um im Anschluss eine zusammengesetzte PDF zu generieren. Eine einfache Beschleunigungslösung wäre es mehrere Seiten parallel zu starten, aber dazu ist einiges an Logik notwendig – ich möchte nur bis zu einer maximalen Anzahl an parallelen Prozessen haben (CPU-Kerne) und benötige die Info wann alle Prozesse fertig sind. Viel Scripting für ein bisschen Geschwindigkeit – und unnötig, denn es gibt ein Passendes Tool: GNU parallel von O. Tange aus “;login: The USENIX Magazine, February 2011:42-47“.

Das Tool ist unter Arch nicht vorinstalliert, findet sich aber im Community-Repo. Der Aufruf ist ähnlich zu xargs – in meinem Fall sieht der Befehl so aus:

parallel -j 8 \
tesseract {} {.}.hocr -l deu hocr \
::: ${files}

In der ersten Zeile wird bestimmt, dass maximal 8 Prozesse zugleich gestartet werden. Danach kommt der Aufruf der Software. {} wird durch den Dateinamen ersetzt, {.} durch den Dateinamen ohne Endung. In der dritten Zeile wird nach dem Trennzeichen (:::) die Dateiliste mitgegeben – in meinem Fall in einer Variable, es kann aber auch direkt per Globbing gearbeitet werden (“::: /tmp/out*”).

Der Grundprozess parallel blockt dabei so lange, bis alle Unterprozesse beendet sind – perfekt für meine Anforderung. Durch diese kleine Änderung ist bei mehrseitigen Dokumenten die Verarbeitung um ein vielfaches schneller.

Das Tool ist dabei natürlich nicht auf OCR beschränkt, auch bei anderen Programmen, welche man auf mehrere oder aufteilbare Quellen loslässt, kann es verwendet werden. Ein gutes Beispiel wäre das Umwandeln von Bildern in einer Batch:

parallel -j 8 \
convert {} {.}.png \
::: ./*.bmp