Während eines Updates brach ein Rechner regelmäßig bei der Aktualisierung bzw. Installation von net-libs/webkit-gtk-2.4.7 mit einem Linkerfehler(?) ab. Ursache ist die verwendete GCC-Version (x86_64-pc-linux-gnu-4.7.3) – nach einem Wechsel auf x86_64-pc-linux-gnu-4.8.3 per gcc-config ließ sich das Paket fehlerfrei kompilieren.
Schlagwort-Archive: Linux
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…
[ZFS/Linux] Priorisierung und Systemlast durch Scrubbing kontrollieren
Das Scrubbing ist ein wichtiger Part der regelmäßigen Pflege eines ZFS-Systems. Hierbei liest das System alle belegten Dateisystemblöcke, vergleicht den Inhalt mit der hinterlegten Prüfsumme und korrigiert – wenn nötig – Fehler auf dem Speicher. Hierdurch ist sichergestellt, dass kippende Bits auf den Festplatten nicht den Inhalt der Datei beschädigen und Fehler frühzeitig erkannt werden. Ein Scrub wird hierbei über den Befehl „zpool scrub poolname“ gestartet.
Um Wöchentlich ein Scrubbing aller zpools durchzuführen nutze ich etwas Bash-Magie – das folgende Script erstellt eine Liste aller im System bekannten zpools und führt ein scrubbing dieser durch. Da ich zum Teil mehrere zpools auf Partitionen einer Platte habe wird immer nur ein Scrub simultan durchgeführt, so wird das Storage nicht zu stark belastet.
#!/bin/bash
date
for i in `zpool list | cut -d ' ' -f 1 | tail -n +2` ;do
echo $i
zpool scrub $i
#Voodoo to prevent simultanous scrubs
while (zpool status audio | grep scan: | grep scrub > /dev/null) ;do
sleep 60
#Scrub still running
done
done
date
Aber auch ein einzelner Scrub stellt für das System eine nicht unerhebliche Last dar, welche sich negativ bemerkbar machen kann. In meinem Fall ist es eine Datenbank mit vielen kleinen Schreiboperationen, welche während des Scrubs nicht hinzunehmende Delays aufweist. Um hier Abhilfe zu schaffen kann ZFS eine Pause einlegen, sobald IO-Aktivität auf dem Pool entdeckt wird. Kontrolliert wird dieser Wert unter Linux mit dem Parameter /sys/module/zfs/parameters/zfs_scrub_delay – dieser ist per Default auf 4 eingestellt. Die Angabe bezieht sich hierbei laut Dokumentation auf Systemticks, bei den meisten Desktop-PCs ist Tickrate von 1000Hz, bei Server meist 100Hz, üblich. Um zu Prüfen wie das eigene System eingestellt ist kann meist folgender Einzeiler verwendet werden:
zcat /proc/config.gz | grep -E "^CONFIG_HZ_.*=y$" CONFIG_HZ_250=y
Wie zu sehen ist läuft mein System auf 250Hz. Zusammen mit der Angabe oben würde ZFS bei IO also für 16ms (1s/250Hz*4) pausieren. Um mir etwas Zeit zu verschaffen möchte ich diesen Wert auf 250ms erhöhen:
1 Sekunde / 250Hz = 0,004 Sekunden/Tick = 4 Millisekunden/Tick
250 Millisekunden / 4 Millisekunden ~= 63 Ticks
Dieser Wert wird entsprechend dem Parameter zugewiesen.
echo 63 > /sys/module/zfs/parameters/zfs_scrub_delay
Wirklich messbar ist der Unterschied nur schwer, da er sich nur bei kleinen, zeitlich verteilten Operationen und nicht bei den benchmarküblichen und konstanten Sequential und Random-Operationen bemerkbar macht, gefühlt ist die Reaktion jedoch trotz scrub besser geworden.
Natürlich sollte man bedenken, dass der Scrub entsprechend länger dauert, die Werte sollten also nur temporär oder mit viel Vorsicht geändert werden.
Interfacebasiertes OpenVPN-Routing und martian packets
Ab und an sehen meine Wünsche recht speziell aus, ich weiß. Heut sieht die Aufgbe wie folgt aus:
Ein Router besitzt 3 Netzwerkkarten, eth0 ist direkt an das Internet angeschlossen, eth1 versogt das Netzwerk A und eth2 das Netzwerk B. Zusätzlich gibt es über OpenVPN (tap0) einen Link zu einem externen Internetzugang. Ziel ist nun, dass alle Internetanfragen von Netzwerk B (eth2) über das VPN versendet werden, der Rest jedoch nicht.
Der (zusammenkopierte) Entwurf lautete wie folgt:
iptables -t mangle -A PREROUTING -i eth2 -j MARK --set-xmark 0x1/0xffffffff
-> Alles was aus Netzwerk B kommt wird mit Flag 0x1 verseheniptables -t nat -A POSTROUTING -o tap0 -j MASQUERADE
-> Alles was über tap0 raus geht wird per NAT maskiertip route add unreachable default table 42
-> Alles auf der Routingtabelle 42 wird per default abgelehntip rule add from all fwmark 0x1 table 42
-> Alles mit der Markierung 0x1 gehört zur Tabelle 42ip route replace 0.0.0.0/1 via *OpenVPN-IP* table 42
ip route replace 128.0.0.0/1 via *OpenVPN-IP* table 42
-> Alles auf Tabelle 42 wird über den VPN-Server abgewickeltnet.ipv4.ip_forward ist auf 1
Auf den ersten Blick ist auch alles OK, Netzwerk A und der Server funktionieren fehlerfrei. Vom Netzwerk B ist jedoch kein Internetzugriff möglich. Getreu dem guten alten Troubleshooting-Guide also auf die Suche.
Wenn ich von einem Client in Netzwerk B pinge kommt das Paket am Router auf eth2 an:
[eth2] 10.222.100.53 > 8.8.8.8: ICMP echo request
…und wird auf tap0 nach draußen gesendet:
[tap0] 10.8.0.16 > 8.8.8.8: ICMP echo request
Kurz drauf trifft auch von draußen über das VPN eine Antwort ein:
[tap0] 8.8.8.8 > 10.8.0.16: ICMP echo reply
und dann hing es… Die Antwort wird nicht auf eth2 wieder weitergegeben, dort ist kein Traffic erkennbar. Scheint, als ob irgendwas beim NAT schief geht. Wenn ich logging auf Maximum stelle (net.ipv4.conf.tap0.log_martians=1) ist im syslog folgendes zu lesen:
kernel: IPv4: martian source 10.222.100.53 from 8.8.8.8, on dev tap0
Ich vermute, dass hier das NAT durch die verschiedenen Routing-Tabellen ein zu großes Chaos verursacht. Als „Workarround“ ist auf dem VPN-Interface jetzt Source-Filterung ausgeschaltet (net.ipv4.conf.tap0.rp_filter=0). Da die Gegenseite ohnehin nochmals nattet sollte da nichts böses(™) drüber eintrudeln.
Sollte jemand genauer erklären können was hier passiert freue ich mich über einen Kommentar.
BitBastelei #129 – Dancing USB Robot
BitBastelei #129 - Dancing USB Robot
(44.1 MB) 00:20:19
2014-12-28 11:00 🛈Spielzeug… Zu Weihnachten gab es einen tanzenden USB-Roboter der Firma „Dream Cheeky“. Windows only versteht sich. Ohne weitere Ahnung wird also „mal schnell“ ein Linux-Tool zur Ansteuerung improvisiert.
Xrandr: Manuelle Wahl der Auflösung
Xrandr ist auf Laptops und 1-GPU-Setups die einfachste und zuverlässigste Methode zur Steuerung der Bildausgabe. Monitorposition, Auflösung, Drehung – alles lässt sich über die Konsole oder die zahlreichen GUIs steuern – wenn die Hardware mitmacht. Für wenig Geld habe ich vor kurzem einen Acer P191w (Video folgt) in die Finger bekommen, dieser sollte nun „mal kurz“ mein Netbook-Display erweitern. Eigentlich kein Problem: Anklemmen, einschalten, fertig. Leider scheint die DCC-Info des Monitors, welche dem Rechner u.A. die möglichen Auflösungen mitteilt, fehlerhaft und es zeigt sich dieses Bild:
> xrandr
Screen 0: minimum 8 x 8, current 1824 x 600, maximum 32767 x 32767
LVDS1 connected 1024x600+800+0 (normal left inverted right x axis y axis) 190mm x 110mm
1024x600 60.00*+
800x600 60.32 56.25
640x480 59.94
VGA1 connected 800x600+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1024x768 60.00
800x600 60.32* 56.25
848x480 60.00
640x480 59.94
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
Wie man im mittleren Bereich sieht ist die maximal wählbare Auflösung 1024×768 Pixel. Laut Datenblatt sollte das Panel nativ mit 1440×900 Pixeln arbeiten, entsprechend verzerrt und unscharf sieht auch das Bild aus.
Mit ein paar Befehlen kann man xrandr die nicht erkannte Auflösung beibringen. Hierzu benötigen wir erst mal eine Modeline – diese lässt sich mit dem Tool „cvt“ berechnen. Hier für 1440×900 Pixel bei 60Hz:
> cvt 1440 900 60
# 1440x900 59.89 Hz (CVT 1.30MA) hsync: 55.93 kHz; pclk: 106.50 MHz
Modeline "1440x900_60.00" 106.50 1440 1528 1672 1904 900 903 909 934 -hsync +vsync
Diese Info muss man nun in xrandr bekannt machen und dem Monitor zuweisen:
> xrandr --newmode "1440x900_60.00" 106.50 1440 1528 1672 1904 900 903 909 934 -hsync +vsync
> xrandr --addmode VGA1 "1440x900_60.00"
Im Anschluss sollte sich die Auflösung mit dem Tool der Wahl einstellen lassen, auf der Konsole also wie folgt:
xrandr --output VGA1 --auto --mode 1440x900_60.00 --left-of LVDS1
Schon kann auch dieser Monitor mit seiner korrekten Auflösung arbeiten und in den nächsten Tagen mir diverse Metadaten des 31c3 anzeigen.
BitNotice #74 – Multimedia unter Linux – Musikverwaltung
BitNotice #74 - Multimedia unter Linux - Musikverwaltung
(15.3 MB) 00:08:02
2014-12-17 09:00 🛈Gegen Ende der Serie entfernen wir uns vom Erstellen von Multimediainhalten und werfen nochmals einen Blick auf Sortieren und Abspielen – diesmal geht es dabei um die Verwaltung der heimischen Musiksammlung
Banshee
Rhythmbox
Amarok
Clementine
Musik:
Alex S. – Ultimate Sweetie Belle
Ken Ashcorp – 20 Percent Cooler
BitNotice #70 – Multimedia unter Linux – Audiobearbeitung & Composing
BitNotice #70 - Multimedia unter Linux - Audiobearbeitung & Composing
(55 MB) 00:09:09
2014-11-21 23:00 🛈Viel Bild gab es in den letzten Folgen, heute ist dann auch mal der Ton an der Reihe: Mit dem Audioeditor „Audacity“ lassen sich Audiodateien nicht nur aufnehmen und schneiden, sondern auch mit einer Breiten Effektpalette verbessern oder künstlerisch umgestalten. Wer lieber vollständig digital seine Musik entwerfen möchte dürfte mit LMMS fündig werden. Hier kann man neben dem Editor für Beat- und Samplesequenzen auch auf eine Vielzahl von virtuellen Synthesizern, Effektgeräten & Co zugreifen
BitNotice #68 – Multimedia unter Linux – Videos konvertieren
BitNotice #68 - Multimedia unter Linux - Videos konvertieren
(16.3 MB) 00:08:17
2014-11-07 20:14 🛈Nachdem wir nun einige Formen kennen um Videos zu erstellen stehen wir vor dem nächsten Problem: Auch wenn viele moderne Geräte ein breites Spektrum an Codecs unterstützen passt das Format immer irgendwo nicht, wir müssen also ggf. Videos in andere Formate umwandeln. Zwar ist dies prinzipiell auch mit den gezeigten Videoeditoren möglich, die die aber meist Filter erneut anwenden oder einfache Bearbeitungen nicht effizient unterstützen empfiehlt es sich zu passenderen Programmen zu greifen. Als Auswahl zeige ich hier die grafische Lösung HandBrake sowie die eierlegende Wollmilchsau für Konsolennutzer: ffmpeg/avconv.
dd-Backupfortschritt mit pv visualisieren
Vollsicherungen gesamter Festplatten oder Partitionen lassen sich mit dem Unix-Tool „dd“ schnell und einfach anfertigen. Während das Tool automatisiert wohl keine Wünsche offen lässt ist es ein wahrer Quählgeist, wenn man dringend auf die Fertigstellung eines Jobs wartet, denn eine automatische Ausgabe des Fortschirttes ist nicht vorgesehen. Zwar kann man sich hier behelfen, in dem man über den „kill„-Befehl das Signal „SIGUSR1“ an den Prozess sendet und so die Anzeige der verarbeiteten Datenmenge erzwingt, wirklich komfortabel ist dies jedoch nicht.
Senden von SIGUSR1
Bild: https://adlerweb.info/blog/wp-content/uploads/2014/11/pv1-300×98.png
Um das Signal SIGUSR1 an einen Prozess zu senden sollte im ersten Schritt dessen Prozess-ID (PID) ermittelt werden, hierzu kann man in der Ausgabe „ps“ nach dem zuvor gestarteten „dd„-Befehl suchen. Ich nutze zur Suche im Beispiel „grep„. Da zum Zeitpunkt des Schreenshots mehrere „dd„-Prozesse liefen suche ich zudem nach der Quelle des Testjobs (urandom).kronos ~ # ps xa | grep "dd" | grep urandom 23204 pts/24 R+ 0:24 dd if=/dev/urandom of=/dev/zeroMit dieser ID kann man nun das Signal über den Befehl „kill“ absetzen. „dd“ verarbeitetet dieses Signal intern, das Programm wird hierdurch nicht beendet.
kronos ~ # kill -SIGUSR1 23204Während auf der aktuellen Konsole keine Ausgabe erfolgt müsste dd nun einen Status ausgeben, welcher u.A. die verarbeitete Datenmenge sowie die Geschwindigkeit enthält:
162183+0 Datensätze ein 162182+0 Datensätze aus 83037184 Bytes (83 MB) kopiert, 37,7423 s, 2,2 MB/s
Wer sich einen übersichtlicheren und automatisierten Status wünscht kann hier mit dem Zusatztool „pv“ (Pipe Viewer) nachhelfen. Statt die Daten direkt von „dd“ an das Ziel schreiben zu lassen werden sie durch „pv“ geleitet, welches wiederum eine statistische Auswertung anzeigt. Als Ziel kann dann über einen weiteren „dd„-Prozess wieder eine Datei oder Gerät verwendet werden, alternativ gehen natürlich auch Kompressionstools wie „gzip“ oder man lässt die Daten z.B. mittels „nc“ (netcat) oder „SSH“ (Secure Shell) zur Speicherung an einen anderem Rechner senden.
Beispiele mit „pv„
Bild: https://adlerweb.info/blog/wp-content/uploads/2014/11/pv2.png
Daten in Datei speichern
dd if=/dev/lvm/vm-102-disk-1 | pv -pterabs 32g | dd of=vm-102-disk-1.img 15GiB 0:20:34 [ 19MiB/s] [12,5MiB/s] [============================================> ] 46% ETA 0:23:12Daten über gzip komprimieren und in Datei speichern
dd if=/dev/lvm/vm-102-disk-1 | pv -pterabs 32g | gzip > vm-102-disk-1.img.gz 15GiB 0:20:34 [ 19MiB/s] [12,5MiB/s] [============================================> ] 46% ETA 0:23:12Daten über gzip komprimieren, per SSH mit schwacher Verschlüsselung an einen anderen Rechner senden und dort in Datei speichern
dd if=/dev/lvm/vm-102-disk-1 | pv -pterabs 32g | gzip | ssh -c arcfour,blowfish-cbc backup@cautio.lan.adlerweb.info 'dd of=/var/backup/vm-102-disk-1.img.gz' Password: 251MiB 0:00:23 [12,6MiB/s] [10,8MiB/s] [> ] 0% ETA 0:49:38
Wichtig hierbei ist, dass „pv“ am Ende die Größe der Quelldatei/des Quellgerätes genannt wird, in diesem Fall 32 GB. Ingesamt bedeuten die Optionen folgendes:
-p Fortschrittsbalken anzeigen
-t Bisher vergangene Zeit anzeigen
-e ETA, also erwartete Restzeit, anzeigen
-r Aktuelle Datenrate, also „Geschwindigkeit“, anzeigen
-a Durchschnittliche Datenrate anzeigen
-b Bereits kopierte Datenmenge anzeigen
-s Größe der Quelle in Byte, k,m,g,… möglich
Alternative Reihenfolge zum besseren Merken: pertabs (per tabs) oder für Nutzer diverser Imageboards betraps.
Die Ausgabe ist wie folgt zu lesen:
15GiB 0:20:34 [ 19MiB/s] [12,5MiB/s] [====== ] 46% ETA 0:23:12 Kop.Datenmenge|Verg.Zeit|Datenrate|Ø Datenrate | Fortschritt |Restzeit
Damit wäre der nervöse Admin mit beruhigenden Statistiken versorgt und weiß wie lange er sich noch gedulden muss – eine Ausrede weniger die Backups zu vernachlässigen. Natürlich kann „pv“ auch für andere Konstrukte verwendet werden, welche mit einer Pipe arbeiten.