Ja, Gnome3 ist toll – wenn man auf grafischen Schnickschnack steht. Zugegeben, auf Netbook und co nutze ich Gnome3 gerne, aber auf meinem PC zählen die Grafikeffekte nicht – im Gegenteil: Sie stören beim Arbeiten. Fehlende Panels, mangelnde Leistung und Probleme mit mehreren Monitoren haben mich seit dem Update nach über 10 Gnome-Jahren dazu gezwungen auf Fluxbox zu wechseln. Das läuft zwar schnell, aber die schonen Panels fehlen mir noch immer – doch jetzt naht Rettung! Mit dem Projekt „MATE“ gibt es einen Gnome2-Fork, welcher einen Großteil der Funktionen der guten, alten 2er-Version auch auf aktuellen Systemen herstellen kann. Für Archlinux gibt es entsprechende AUR-Pakete, für Faule auch ein eigenes Repository. Fühlt man sich gleich wieder daheim…
Archiv der Kategorie: Software
Alles was mit Software zu tun hat
Sniffing over the Net – Mit Wireshark und tcpdump auf entfernten PCs sniffen
Ja, ich weiß, Paket-Sniffer sind böse Hackertools und so weiter – wer das Denkt sollte hier aufhören zu lesen und erst eine Prise Praxis zu sich nehmen. Gerade wenn es um das Debuggen von Fehlern in Netzwerkverbindungen geht kommt man nur schwer dran vorbei – wenn man nicht gerade zwischen den Geräten sitzt wird es jedoch schnell ungemütlich. Gehen wir fon folgender Konstellation aus, welche bei mir derzeit aufgetreten ist: Ein Mobilgerät kommuniziert mit einer Webbasierten API über HTTP – der Server steht nicht unter meiner Kontrolle und das Mobilgerät ist selbstverfreilich entsprechend vernagelt. Natürlich könnte man nun einen Monitoring-Port an einem Switch zwischen Mobilgerät und Internetzugang nutzen, aber der liegt weit entfernt und ich müsste zwischen zwei Orten pendeln.
Bisher hieß das für nicht: 2-Schritt-Debugging. Erst verband ich mich auf den (Linux-basierten) Router, fertigte mit tcpdump ein Capture-File an und lud es auf den PC um in Wireshark einen Blick in die Pakete zu werfen. Dank eines Hinweises auf einen Artikel bei Commandlinefu kann ich mir das nun sparen – dank Pipes und ssh lassen sich tcpdump und Wireshark so verschalten, dass ein Live-Capture des Remote-Servers im lokalen Wireshark einläuft. Macht das Ganze wesentlich einfacher…
Ein möglicher Befehl wäre z.B.
ssh root@internetrouter tcpdump -i eth0 -U -s0 -w - 'port 80 and host 192.168.1.2' | wireshark -k -i -
der letzte Teil des SSH-Commands entspricht den üblichen tcpdump-Filtern – hier sollte man auf jeden Fall drauf achten, dass man den ssh-Traffic nicht mitschneidet – in diesem Fall ists durch die Host/Port-Einschränkung ja ohnehin gegeben, ansonsten sollte ein ’not port ssh‘ helfen.
Gentoo-Look & Feel für die Archlinux-Bash
Auch wenn Gentoo eigentlich mein Haputsystem ist: Auf Netbooks o.Ä. macht das ganze recht wenig Spaß, daher bin ich vor einiger Zeit über Archlinux gestolpert. Auch, wenn die Stabilität und Flexibilität nicht immer an meine Gentoo-Erfahrungen heran kommen, so kann man sich dank sehr großem Binärrepository und den einfach zu erstellenden PKGBUILDS (ähnlich ebuilds) schnell helfen.
Eins, was mir jedoch gewaltig auf den Keks ging war die Bash-Konfiguration: Viele der „Komfortfunktionen“ wie Farbschemata, Historysuche o.Ä. sind unter Archlinux nicht vorhanden oder haben andere Tastenkombinationen – Abhilfe kann wie folgt erfolgen:
Als erstes muss die .bashrc dran glauben – hier sind die meisten Einstellungen drin. Am einfachsten geht das über das Paket aur/gentoo-bashrc, welches unter /usr/share/gentoo-bashrc/bashrc eine Kopie der Gentoo-Konfiguration anlegt. Nach Prüfung kann man diese Datei als persönliche Einstellungsdatei unter /home/
Was fehlt ist der von mir häufig genutzte Schnellzugriff auf die Bash-History. Damit meine ich, dass wenn ich z.B. „ls“ Tippe mit dem Tasten PgUp und PgDown durch die letzten Befehle, welche mit ls beginnen scrollen kann. Dies läuft über die Datei /etc/inputrc – diese habe ich vollständig durch das Gentoo-Pendant ersetzt:
# /etc/inputrc: initialization file for readline # # For more information on how this file works, please see the # INITIALIZATION FILE section of the readline(3) man page # # Quick dirty little note: # To get the key sequence for binding, you can abuse bash. # While running bash, hit CTRL+V, and then type the key sequence. # So, typing 'ALT + left arrow' in Konsole gets you back: # ^[[1;3D # The readline entry to make this skip back a word will then be: # "\e[1;3D" backward-word # # do not bell on tab-completion #set bell-style none set meta-flag on set input-meta on set convert-meta off set output-meta on # Completed names which are symbolic links to # directories have a slash appended. set mark-symlinked-directories on $if mode=emacs # for linux console and RH/Debian xterm # allow the use of the Home/End keys "\e[1~": beginning-of-line "\e[4~": end-of-line # map "page up" and "page down" to search history based on current cmdline "\e[5~": history-search-backward "\e[6~": history-search-forward # allow the use of the Delete/Insert keys "\e[3~": delete-char "\e[2~": quoted-insert # gnome / others (escape + arrow key) "\e[5C": forward-word "\e[5D": backward-word # konsole / xterm / rxvt (escape + arrow key) "\e\e[C": forward-word "\e\e[D": backward-word # gnome / konsole / others (control + arrow key) "\e[1;5C": forward-word "\e[1;5D": backward-word # aterm / eterm (control + arrow key) "\eOc": forward-word "\eOd": backward-word # konsole (alt + arrow key) "\e[1;3C": forward-word "\e[1;3D": backward-word $if term=rxvt "\e[8~": end-of-line $endif # for non RH/Debian xterm, can't hurt for RH/Debian xterm "\eOH": beginning-of-line "\eOF": end-of-line # for freebsd console "\e[H": beginning-of-line "\e[F": end-of-line $endif # fix Home and End for German users "\e[7~": beginning-of-line "\e[8~": end-of-line
Arch Linux Bug: „cron for user root job sys-hourly“-Mails
Durch einen Fehler in pacman kommt es seit einigen Wochen zu einem Fehler während der Arch Linux Systemupdates. Unter anderem wird ein Script zum synchronisieren der Systemuhr aus den stündlichen Cronjobs entfernt – dummerweise ist dann das Verzeichnis /etc/cron.hourly leer und Pacman hat die Angewohnheit leere Verzeichnisse zu löschen. Entsprechend kann Cron das Verzeichnis nicht mehr finden und quittiert das ganze stündlich mit einer Email „cron for user root job sys-hourly“.
Als Workarround reicht ein simples „mkdir /etc/cron.hourly“ als root – die Rechte sollten mit root:root OK sein.
Hallo Gnome 3! (Rant)
Hallo Gnome 3! Schön, dass du dich zu mir gesellt hast. Kennst du noch deinen Vorgänger? Der hat mir gute Dienste geleistet – auf 4 Monitoren verteilt tat er seinen Dienst, die Panels saßen Dank GConf auf dem richtigen „Hauptmonitor“, waren mit allerhand Widgets bestückt und das Home auf NFS hat ihn auch nicht gestört. Gestern dann mein Gedanke – ich könnte ja schnell noch Updaten. Mit dem üblichen „Wird-schon-schief-gehen“-Doppelenter gestartet, im Vorbeiflug noch etwas von Kernel gelesen und einen reboot dran gehängt. Teatime. Nach dem Rückweg hatte der PC neu gestartet und mein Blick erspähte deine ersten Ausläufer – der Loginscreen sieht irgendwie anders aus…
Schnell die Userdaten eingehämmert und … krawautz … „Ihr System ist zu blöd für Gnome, willkommen im Fallback-Mode“ – oder so ähnlich vermeldest du. Der Funktionsumfang ist nahezu nicht vorhanden: Die Panels leer, an hinzufügen von Items nicht zu denken – auch zeigst du sie stur auf dem linken Monitor an – da wo ich nur selten hinschaue. Verschieben erlaubst du mir nicht – warum auch. Ein Blick ins Forum: Mit der Installation der gnome-shell soll sich deine ganze Macht entfalten. Installiert, GDM neu gestartet und… Krach… Kein Bild mehr… WTF?… „Could not acquire name“ – von mit bekommst du jetzt Namen, aber keine netten. Einen Neustart später lande ich wieder im GDM – Logindaten und – na – ein schwarzer Bildschirm.OK, Schnautze voll, vielleicht updatest du ja nur irgendwas, ich geh schlafen.
Neuer Tag, neues Glück, gleicher schwarzer Bildschirm – wohl doch kein Update. OK, ziehen wir mal meine Besonderheiten raus – ein neues Userprofil auf der lokalen HDD darf sich versuchen – mit dem selben düsteren Ergebnis. Tja, wenn du mich nicht ran lässt muss ich wohl fremd gehen und siehe da: Deine fiese Schwester KDE öffnet mir bereitwillig und ohne zu murren alle Fenster zu ihrer bonbonfarbenen Kitschwelt. Ergo: Kein Xorg-Fehler. Nochmal ein Versuch mit Gnome – Gewinner: Keiner. (Verzeit mir, aber mit den 4 Screens im Text-/ASCII-Art-modus kommt langsam Wargames-Feeling auf). Mit passender Wargames-DVD auf dem Laptop nebenan (woho, Grafik!) rüste ich mich für die nächste Runde. Hätten wir noch die 4 Monitore. Reduzieren wir das mal auf ein Haushaltstypisches Maß von einer Guckplatte. Schnell noch GDM neu starten – NIIIICHT. Reboot. Ach schau an – dein GDM hat auch einen farbigen Hintergrund? Der war vorher doch in deiner Lieblingsfarbe – Schwarz. Und nun lässt du mich auch in deinen pachtvollen Neubau…
Ein kurzer Blick – ein längerer Blick – mir fällt nur ein Wort ein: REGRESSION! Die Optik sieht aus als hätte man mir einen angefressenen Obstkorb vor die Nase gestellt. Warum brauch ich meinen halben Bildschirm für den Fensterrahmen? Mich interessieren die Inhalte und nicht das Design außenrum. die UI ist vielleicht für nen Kindergarten eine tolle Sache, aber sicher nicht zum Arbeiten zu gebrauchen. Wollt ihr vielleicht eine Anleitung zum Arsch-Abwischen beilegen oder warum muss jede Pissfunktion auf ein idiotenkompatibles Maß reduziert werden? Nicht jeder vorm PC ist auf dem Bildungsstand eines Zirkusaffen. Flexibilität Funktionen? Brauchen wir nicht – wen interessiert schon die Systemlast im Panel… User sicher nicht… Also löschen wirs gleich für alle, die Bastler interessieren ja keinen. Softwarediktatur FTW! Ich hab ja mit der Umstellung Amarok 1.4 -> Amarok 2 schon einiges mitgemacht, auch da wurden viele Features gedropt, aber es war immerhin in Grundfunktionen noch nutzbar – das kann ich von Gnome 3 nicht sagen. Jetzt, da sich dieser Codehaufen in Stable befindet, habe ich erst mal die Arschkarte – fürs Erste mag ich noch Gnome 2 weiter nutzen können, aber die Updates laufen nicht ewig. Ein Gnome 2 Fork ist nicht in Sicht, meine anderen PCs haben Updateverbot – bleibt nur zeitnah auf etwas Anderes zu wechseln und wieder tagelang Anpassung zu tätigen um am Ende wieder halbwegs das zu können, was schon ausgereift da war. Eine Schande um die jahrelang gereiften Konfigurationsdateien. Gnome 3 mag ja eine schöne Idee sein, aber es ist nicht Gnome. Früher(tm) war es halbwegs schnell, unaufdringlich und Funktionen waren zwar vor DAUs Versteckt, aber trotzdem vorhanden. Ich installiere dann mal grade XFCE und versuche mich daran – tja, liebes Gnome-Team – „Schönen Tag und auf Wiedersehn“. Eventuell wird irgendwann Gnome wieder ein ernstzunehmendes DE, aber das jetzt Veröffentlichte ist ein Komplett neues Projekt und hat nichts mit dem zu tun, für das Gnome einmal bekannt war.
END OF RANT
Disclaimer: Ja, es ist meine Schuld, ja, ich weiß, dass ich forken kann, ja, ich weiß, dass $hier-argument-einsetzen
2GB-Files ext4,xfs,btrfs Benchmark
Da ich derzeit meinen Server aufrüste stellt sich unter anderem die Frage nach dem Dateisystem. Für Root & Homes habe ich bereits auf anderen Systemen ext4 seit längerem im Einsatz, für meine Video-Partition war ich aber nicht ganz sicher. Auf dieser liegen Rohdaten z.B. meines Podcasts oder von Konvertieren von VHS etc, also viele große Dateien. Bisher durfte sich xfs um die Dateien kümmern, mit ext4 soll aber nun xfs Konkurrenz bekommen haben. Da die meisten Tests recht allgemein gehalten waren musste ein eigenes Script ran. Zusätzlich zu xfs und ext4 habe ich noch ext4 mit aktivem „nobarrier“ sowie btrfs getestet. System ist ein AMD Opteron 2358 (Quad 2,4GHz) mit 4GB RAM, Storage ein 3-Disk RAID5 mit ~235MB/s Durchsatz bei hdparm -t.
I/O-Performance
Erst ein Blick auf lesen, schreiben, simultanen Lese-/Schreibzugriffen und löschen. Datenquelle fürs schreiben war ein tmpfs, lesen ging auf /dev/null:
| write | read | rw | del | |
| ext4 | 84,4 | 114,0 | 49,3 | 1.941,5 |
| ext4nb | 83,1 | 197,0 | 29,9 | 10.077,5 |
| xfs | 54,6 | 207,0 | 29,9 | 109.462,1 |
| btrfs | 86,0 | 200,0 | 51,9 | 2.006,6 |
Wie man sieht hat bei Schreibzugriffen btrfs die virtuelle Nase knapp vor den ext4-Varianten, xfs ist gut ein Fünftel langsamer. Wenns ums Lesen geht kann xfs deutlich punkten, auch wenn btrfs hier knapp dran ist. Der Ausrutscher von ext4 mit Barriers mach für mich zwar keinen Sinn, war aber reproduzierbar. Bei parallelen Zugriffen spielt btrfs wieder sein Asse aus, ext4 mit Barriers ist aber knapp dahinter. Xfs leidet hier unter der schlechten Schreibperformance, Ext4nb – tja, gute Frage… Beim Löschen zahlt sich das XFS-Design wieder aus: Löschen geht fast zehn mal schneller als bei ext4nb – mit Barriers macht ext4 jedoch eine eben so schlechte Figur wie btrfs.
Schaut man nur auf die (theoretischen) Zahlen zeigt sich btrfs schon jetzt als klarer Sieger, jedoch ist es noch in der Entwicklungsphase und kann entsprechend zu Stabilitätsproblemen führen. XFS hält sich bei großen Dateien noch knapp vor EXT4 ohne Barriers, mit Barriers ist die (hier) mangelhafte Lesegeschwindigkeit nicht entschuldbar.
Praxis
Da ich noch ein paar Sachen zu schneiden Habe einfach mal ein Praxistest: Jedes Dateisystem bekommt eine Rohdatei (2GB +/- paar MB) von einem tmpfs drauf kopiert, diese wird erst geprüft (md5sum) in ein anderes Containerformat konvertiert, danach wird von der neu erstellten Datei erneut eine MD5-Summer erstellt, im Anschluss greift eine vorbereitete Schnittliste und speichert eine geschnittene Version. Zum Abschluss wird die Quell- und Zwischendatei gelöscht. Alles nahezu reine I/O-Operationen, da nichts umcodiert werden muss.
| Dateisystem | Zeit in Sec. |
|---|---|
| 171 | |
| 174 | |
| 187 | |
| 199 |
Wie man sieht kann btrfs seinen theoretisch deutlichen Vorsprung nicht halten und fällt auf Platz 3 – hier fehlen wohl noch die nötigen Optimierungen um in der Praxis die guten I/O-Werte auszuspielen. ext4nb schafft es auf den ersten Platz, dicht gefolgt von xfs. Ext4 mit aktiven Barriers, welche auf druck der Community nun Standard sind, liegt auch in diesem Test abgeschlagen auf dem letzten Platz.
Fazit
Wenn es um große Dateien geht sind ext4 ohne Barriers und XFS nahezu gleich auf. XFS ist jedoch fast 14 Jahre älter und ist daher als stabiler anzusehen, zumdem nutzt es vorhandenen Speicherplatz besser aus. Die technischen Grenzen der Dateisysteme sind für aktuelle Rechner eher uninteressant, jedoch unterstützt nur ext4 das nachträgliche verkleinern einer Partition.
Ich für meinen Teil werde für große Dateien damit bei XFS bleiben.
Auf in dunkle Zeiten – Softwaregesteuerte Helligkeitskontrolle unter X11
Mein Netbook ist ansich ja ein praktisches Teil: Klein und leicht genug um neben dem Fernsehen ein bisschen rumtippen zu können – leider gibt es einen großen Nachteil, der anscheinend inzwischen bei vielen Geräten modern ist: Selbst auf der niedrigsten Helligkeitsstufe lässt sich mit dem Display das halbe Zimmer beleuchten – an gemütliches Fernsehn ist angesichts dieses Scheinwerfers vor der Nase nicht zu denken. Inzwischen habe ich einen kleinen Workarround gefunden: Mit der Software „xbrightness“ lässt sich die Helligkeit unter X11 auf Softwareebene verringern. Eine solche Softwarelösung führt zwar zu einem gewissen Kontrastverlust, für Web & Code ists jedoch noch erträglich.
Für Archlinux ist das Paket jetzt in AUR.
Mal wieder ein neuer Server
Schon ein paar Jahre her, dass der Unterbau meiner Webseite gewechselt hat, also Zeit für etwas Neues: Soeben ist diese Seite als Erste auf meinen neuen Server umgezogen. Neue Hardware und bessere Infrastruktur sollten auch in Zukunft meine inzwischen 15GB umfassende Gallerie sowie den Blog in hervorragender Geschwindigkeit ins Netz befördern können. Auch ein weiterer und von mir lange erwarteter Punkt ist damit endlich erledigt: Meine Seite ist ab sofort vollständig per IPv6 erreichbar – wehe dem, der seinen Router verbastelt hat! SSL funktioniert prinzipiell, aber aus technischen Gründen bekomme ich bisher keine passenden Zertifikate für TLDs ausgespuckt.
Die Umstellung selbst war mit gewisser PITA verbunden, da sich Dateipfade geändert haben und das vor allem mit der (veralteten) Gallerie kollidiert. Nach mehreren tausend Dateien und der Magie von sed & SQL sollte aber inzwischen alles passen. Dann nehmen wir uns doch gleich den nächsten Kandidaten vor…
IPv6: Lets rename NAT?
Hier zu Archivzwecken ein Copy&Paste meines Beitrags aus dem OVH-Forum. Es geht um die Möglichkeit IPv6 in ein lokales Netz weiter zu routen – dürfte sicher in Zukunft für einige interessant werden…
… Ich verwende feste IPv6-Adressen für Host und Gäste, das Routing läuft über den Host (Also nicht die virtuellen MAC-Adressen, die es inzwischen gibt). Für den Host gilt: eth0=OVH-Netz,br0=Netz mit den Gästen. Ich schreibe nur die nötigen Befehle – da die Config je nach Linux-Distri verschieden sind überlasse ich euch das übersetzen selbst (bei mir tuts aus Faulheit die rc.local). Wie man IPv6-Abkürzt (führende 0en weglassen, kürzen per ::) erklärt bei Bedarf google.
Host:
Als erstes benötigt der Host natürlich eine feste Adresse. Hierzu geht ihr in den OVH-Manager und sucht euer IPv6-Subnet (Steht bei Interfaces in der Server-Übersicht). Ich gehe hier von 2001:41D0:F0F0:F0F0::/64 aus. Das bedeutet, dass euch die IPs 2001:41D0:F0F0:F0F0:0000:0000:0000:0001 bis 2001:41D0:F0F0:F0F0:FFFF:FFFF:FFFF:FFFE gehören – genug Platz. Der Einfachheit halber nummeriere ich nur die letzte Zahl durch – ist aber natürlich keine Pflicht.
Als erstes erhält der Host auf beiden(!) Interfaces eine IP:
ifconfig eth0 inet6 add 2001:41D0:F0F0:F0F0::1/64
ifconfig br0 inet6 add 2001:41D0:F0F0:F0F0::99/64
Zudem benötigen wir ein Routing. Teilweise erhält der Server bereits über die IPv6-Autokonfiguration die korrekten Routen von OVH. Dummerweise unterstützen einige Switche bei OVH kein IPv6 und blockieren diese Autokonfiguration, daher funktioniert es nicht bei jeden. Da es nichts schadet die Route fest einzutragen werden wir das tun. Die Router-IP ermittelt sich wie folgt:
OVH-Hilfe
Der Router (Standardgateway) für jede IPv6 befindet sich immer auf IP:v:6:FF:FF:FF:FF:FFEin Beispiel:
Die IPv6 des Servers: 2001:41D0:1:46e::/64 wird zu 2001:41D0:1:4 + 5 Mal FF.
IPv6 Gateway: 2001:41D0:1:4FF:FF:FF:FF:FFDie IPv6 des Servers: 2001:41d0:1:209::/64 wird also zu 2001:41d0:1:2 + 5 Mal FF.
IPv6 Gateway: 2001:41d0:1:2FF:FF:FF:FF:FF
In unserem Beispiel ergibt sich also der Router 2001:41D0:F0F0:F0FF:FF:FF:FF:FF. Die Route setzen wir mit
route -A inet6 add 2000::/3 gw 2001:41D0:F0F0:F0FF:FF:FF:FF:FF
Da wir zudem den Host als Router verwenden wollen benötigen wir Forwarding, das schalten wir mit diesem Befehl ein:
sysctl -w net.ipv6.conf.all.forwarding=1
Um auch zu wissen wo die Gäste hin sollen tragen wir hier entsprechende Routen ein. Ich habe es pro Host gemacht, sollte aber auch blockweise funktionieren:
route -A inet6 add 2001:41D0:F0F0:F0F0::10 dev br0
route -A inet6 add 2001:41D0:F0F0:F0F0::11 dev br0
Zum Schluss folgt dann der IPv6-Fubar, der meine Probleme auslöste: Ich nenns mal das IPv6-NAT. Die komplette Erklärung was und warum das nötig ist („Proxy the neighbors“) habe ich am Ende verlinkt.
sysctl -w net.ipv6.conf.all.proxy_ndp=1
ip -6 neigh add proxy 2001:41D0:F0F0:F0F0::10 dev eth0
ip -6 neigh add proxy 2001:41D0:F0F0:F0F0::11 dev eth0
Wichtig hierbei: Das eth0 ist kein Typo! Die Zeile bedeutet, dass der Host auf dem Interface eth0 bekannt geben soll, dass er für die genannte IP eine passende Route kennt.
Auf dem Gast sind dann nur analog zu oben die IPs einzurichten, die IP des Host-Interface br0 spielt dabei den Router:
ifconfig eth0 inet6 add 2001:41D0:F0F0:F0F0::10/64
route -A inet6 add 2000::/3 gw 2001:41D0:F0F0:F0F0::99
Weitere Ressourcen:
Ruckelnde Maus bei RDP-Zugriff auf Windows 7
Remote Desktop ist eigentlich recht flott und ich hatte bisher nie wirklich Probleme, seit jedoch Windows 7 unterm Volk ist macht RDP keinen Spaß mehr: Die Maus lagt wie verrückt und bewegt sich nur hakend über den Schirm. Den Schuldigen habe ich inzwischen Dank Coredump gefunden: Das Aero-Cursor-Theme, welches bei Windows 7 standardmäßig aktiv ist. Stellt man unter Systemsteuerung -> Maus -> Zeiger ein anderes Theme ein (z.B. „Windows invertiert (Systemschema)) funktioniert die Maus wieder in Echtzeit.