Schlagwort-Archive: Linux

Gentoo: net-misc/bridge-utils lässt sich nicht installieren

Dafuq? Während einer Gentoo-Installation ließ sich plötzlich eine 802.1d Ethernet-Bridge nicht mehr korrekt ansprechen. Ein „brctl“ zeigt lediglich „Command not found“. Kann doch nicht sein – net-misc/bridge-utils habe ich eben noch emerged und es gab keine Fehler. Ein „equery files bridge-utils“ zeigt ebenfalls seltsames:

equery files bridge-utils
* Searching for bridge-utils ...
* Contents of net-misc/bridge-utils-1.4:
/usr
/usr/share
/usr/share/doc
/usr/share/doc/bridge-utils-1.4
/usr/share/doc/bridge-utils-1.4/AUTHORS.bz2
/usr/share/doc/bridge-utils-1.4/ChangeLog.bz2
/usr/share/doc/bridge-utils-1.4/FAQ.bz2
/usr/share/doc/bridge-utils-1.4/FIREWALL.bz2
/usr/share/doc/bridge-utils-1.4/HOWTO.bz2
/usr/share/doc/bridge-utils-1.4/PROJECTS.bz2
/usr/share/doc/bridge-utils-1.4/README.bz2
/usr/share/doc/bridge-utils-1.4/RPM-GPG-KEY.bz2
/usr/share/doc/bridge-utils-1.4/SMPNOTES.bz2
/usr/share/doc/bridge-utils-1.4/THANKS.bz2
/usr/share/doc/bridge-utils-1.4/TODO.bz2
/usr/share/doc/bridge-utils-1.4/WISHLIST.bz2
/usr/share/man
/usr/share/man/man8
/usr/share/man/man8/brctl.8.bz2

Die Binary fehlt?!

Ein neues emerge unter Aufsicht zeigt auch warum:

[...]
error: field 'ip6' has incomplete type
make[1]: *** [libbridge_if.o] Error 1
make[1]: *** [libbridge_init.o] Error 1
make[1]: *** [libbridge_devif.o] Error 1
[...]

Das kompilieren bricht wegen modifizierter Header-Dateien bei Kerneln => 3.8 ab, das ebuild registriert dies jedoch nicht und meldet eine erfolgreiche Installation. Die Lösung sollte inzwischen bereits verfügbar sein: Mit der seit einigen Tagen stabilen Version net-misc/bridge-utils-1.5 sollte das Problem behoben sein.

et-sdl-sound: Segfault – Patch

Der ET-spielenden Linux-Bevölkerung ist „et-sdl-sound“ sicher ein Begriff: Dieser „Hack“ erlaubt es über LD_PRELOAD das Spiel vom bisherigen „Open Sound System“ (OSS) loszulösen und per SDL auch z.B. mit ALSA oder Pulse zu betreiben und somit die Sondausgabe auf aktuellen Distributionen zu ermöglichen. Leider haben die letzten Updates meines Arch Linux Systems gleich mehrere Fehler ausgelöst: Im ersten Schritt änderte sich (durch die /usr/bin-Migration?) die CRC der ET-Binary. Da über diese Prüfsumme der Hack das Spiel erkennt war keine Tonausgabe mehr möglich. Ein weiteres Problem stellt inzwischen wohl die Nutzung von stdout dar – warum auch immer, bei jeder Ausgabe verabschiedet sich das Spiel per Segfault.

Für beide Probleme habe ich nun eine aktualisierte Version in meinem Github-Repo – die CRC der Arch-Linux Version wurde ergänzt, der Code grob für neuere Compiler umgestellt und die Info-Ausgaben in die Datei /tmp/et-sdl-sound.log umgeleitet.

Ascel AE20125 Linux-GUI

Die Firma Ascel Elektronic bietet mit dem AE20125 einen günstigen Funktionsgenerator-Bausatz an, welcher sich durch Technische Daten und Preis zwischen den „Billigteilen“ auf Fernost und ausgewachsenen Modellen platzieren kann.

Die Sinus- (bis 10 MHz), Dreieck- und Rechtecksignale (bis 2,5 MHz) lassen sich am Gerät selbst über Taster und ein 2x16er LCD einstellen, wer es komfortabler mag kann das Gerät über eine optionale USB-Schnittstelle mit dem PC verbinden.

Ich selbst stehe derzeit mit dem Bausatz noch auf Kriegsfuß: Einige der Taster funktionieren nicht und da der Quellcode des verbauten AVRs nicht verfügbar und das LockBit gesetzt ist, stellt sich die Fehlersuche als etwas kompliziert heraus. Um die restlichte Funktion zu prüfen sollte der USB-Port herhalten – leider gibts die Software nur für Windows und dessen Nutzung erhöht bei mir das Frustpotential doch erheblich. Da das Protokoll einfach aufgebaut und in der Anleitung dokumentiert ist habe ich auf die schnelle eine GUI in Qt gezaubert, welche die Steuerung auch unter Linux (und vermutlich auch Windows NT/2K/XP/Vista/7/CE5/CE6, MacOSX und anderen Unixen) ermöglicht. Bis auf die noch nicht implementierte Preset-Funktion sollten alle Möglichkeiten der Originalsoftware gegeben sein. Quellen gibts wie immer auf GitHub.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2013/07/Bildschirmfoto-AE20125gui-1-289×300.png

[Kurztipp] Standby nach mehreren Aufgaben

Derzeit bin ich auf meinem Rechner einige Videos am recodieren – über Nacht stört es nicht, aber praktisch wäre es schon den PC nach getaener Arbeit abzuschalten. Ein einfaches anhängen des Kommandos funktioniert nicht, da ich mehrere Prozesse simultan am laufen habe. Da alle CPU-intensiv sind sieht die qnd-Lösung jetzt folgendermaßen aus: Alle 5 Sekunden wird die Systemload geprüft, ist sie unter 1 schaltet das System ab. Einfach, aber sollte seinen Zweck erfüllen.

while : ;do echo -n '.' ; if [ `cat /proc/loadavg | cut -d '.' -f 1` -lt 1 ] ;then pm-hibernate ; break ;fi ; sleep 5 ;done

Videostabilisierung unter Linux

Egal wie ruhig man ist: Auf großen Zoomstufen oder beim Bewegen verwackelt fast jedes Video. Professionelle Aufnahmegeräte bieten für diesen Zweck meist eine Stabilisierung in Kamera oder Objektiv, dies ist jedoch aufwändig und kostet entsprechend viel Geld. Besitzer von Consumergeräten müssen aber nicht ganz auf eine solche Stabilisierung verzichten: Viele Videoeditoren bieten entsprechende Bildfilter, welche (auf Kosten der Videoqualität) softwareseitig die Stabilisierung übernehmen. Als kostenlose Lösung ist vielen die entsprechende Funktion der Videoplatform YouTube bekannt, jedoch lässt sich diese nur auf komplette Videos anwenden und ist nicht konfigurierbar, zudem möchte man nicht jedes Video auf der zu Google gehörenden Platform bereitstellen. Leider sieht es unter Linux dünn aus – zwar kann man über wine die Lösung Virtualdub/Deshaker nutzen und der Editor KDEnlive bietet passende Filter im Menü, beide Lösungen lassen sich jedoch nur schwer automatisieren und leidet unter nervigen kleinen Bugs.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2013/05/kdenlivestab.png

Um nun bei mir das ganze zu erschlagen habe ich ein Script geschrieben, welches alles nötige übernimmt. Die eigentliche Stabilisierung steckt in der Software transcode, da diese jedoch mit vielen Codecs Probleme hat muss das Video entsprechend vorbereitet werden. Durch den Zwischenschritt als MPEG2 ist temporär ein vielfaches des ursprünglichen Speicherplatzes nötig, der sollte beim Umgang mit Videos ja ohnehin reichlich vorhanden sein. Das Ausgabeformat ist derzeit auf 8MBit/s x264 mit 128k MP3 eingestellt, der Stabilisierungsfilter läuft mit Standardwerten.

ffmpeg -i $1 -vcodec mpeg2video -b:v 10000k $1.mpg
ffmpeg -i $1 -acodec libmp3lame -b:a 128k $1.mp3
transcode -J stabilize -i $1.mpg -y null,null -o dummy
transcode -J transform -i $1.mpg -y xvid,pcm -w 10000k -o $1.stab.temp.mp4
ffmpeg -i $1.stab.temp.mp4 -i $1.mp3 -vcodec libx264 -acodec copy -b:v 8000k -map 0:0 -map 1:0 $1.stab.avi
rm $1.stab.temp.mp* $1.mp3 $1.mpg $1.*.trf

Voraussetzungen sind ffmpeg und transcode. Debian/Ubuntu liefern zum Teil statt ffmpeg dessen Fork avconf, in diesem Fall einfach im Script den Befehl anpassen.

http://www.youtube.com/watch?v=HMkRF2yz8M0

Linux: Anzahl der geöffneten Dateien pro Prozess anzeigen

*Poff* – das war die Wand der maximal geöffneten Prozesse auf einem Linux-System – praktisch wäre es jetzt noch zu wissen welcher Prozess dafür verantwortlich ist. In diesem Fall hilft folgender Befehl – er erstellt eine Liste aller Prozesse mit der Anzahl der geöffneten Dateien, die verschwenderichsten oben:

lsof | cut -d ' ' -f 1 | uniq -c | sort -r

Auf der Suche nach den inodes

So ein Linux-Server mit ext4 ist nicht so schnell klein zu bekommen – ich schaffs aber natürlich trotzdem. Auf einem meiner App-Server verabschiedete sich übers Wochenende der Datenbankserver. Diagnose eindeutig: Platte voll, 0 Bype frei. Der Auslöser ist auch schnell ausgemacht – mangels logrotate haben sich über 8GB in /var/log angesammelt. Klare Sache – Logs löschen, Dienste neustarten undnichts. Platte voll. Dafuq? Am Platz liegts nicht – dort sind die 8GB nun frei – ich vermute Böses…

# df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/root 23G 14G 8.2G 62% /
# df -i /
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/root 1474560 1474560 0 100% /

Treffer versenkt – die Inodes sind voll. Aber warum? Nach kurzem Gegoogle gehe ich davon aus, dass meist eine Datei = ein Inode ist, also wird die Bash-Keule ausgepackt:

(for i in `find / -xdev -type d 2>/dev/null` ;do (echo -n `ls -1a "$i" | grep -vP "^(.|..)$" |wc -l` && echo " - $i") ;done) | sort -n

Dieser Code erzeugt eine Liste aller Ordner auf dem Device der Root-Partition – aufsteigend nach der Anzahl der Dateien sortiert. In meinem Fall ist der Schuldige relativ eindeutig:

[...]
1460 - /usr/share/man/man1
1620 - /usr/portage/metadata/cache/dev-perl
1620 - /usr/portage/metadata/md5-cache/dev-perl
1692 - /usr/portage/metadata/glsa
4554 - /usr/share/man/man3
972513 - /var/nagios/home/.maildir/new

Ich sollte mal ein paar Mails löschen -Oder auch nicht, denn…

rm *
-bash: /bin/rm: Argument list too long

also muss auch hier getrickst werden:
find ./ -exec rm {} +

NVidia X.Org Video-RAM information leak

Bereits seit etwa einem Jahr ist mir beim Start von X.Org – oder eher gesagt beim laden von Gnome – ein seltsames Flackern auf mehreren Rechnern aufgefallen. Meist trat es nach abstürzen oder Neustarts auf, nicht jedoch wenn der PC vollständig abgeschaltet war. Da mir einige der Muster im Flackern bekannt vor kamen griff ich Heute mal zur Digitalkamera und zeichnete es auf. Das Ergebnis: Es ist tatsächlich kein wildes Flackern, sondern Bildausschnitte diverser vor dem Neustart verwendeten Programme! Hierbei ist es nicht das letzte Bild, sondern z.B. auch Programme, welche im Hintergrund aktiv waren (also z.B. auch Ausschnitte des Browsers wenn der Bildschirmschoner zuletzt aktiv war). Im heutigen Fall hatte ich den Rechner sogar kurz (~500mA) vom Strom genommen (Stecker gezogen), da sich der Kernel aufgehangen hatte und der PC keinen Reset-Knopf besitzt – dennoch konnte man Bildausschnitte erkennen. Bisher ist mir das Phänomen auf meinem Privat-PC (ArchLinux, GeForce 8600GT, X.org 1.12.2-1, nvidia 295.53-1, Xinerama Multihead) und meinem Arbeits-PC (GeForce 9600GT, X.Org 1.11.2-r2, NVidia 295.20-r1, NVidia TwinView) begegnet. Könnte mir durchaus vorstellen, dass ein Angreifer über diese Methode die „Sicherheit“ des Bildschirmschoners umgehen und so an Informationen über die verwendeten Programme gelangen könnte. Da hierzu offenbar nur ein gewisser Zustand der Grafikkarte erreicht werden muss könnte dies auch per OS auf einem Stick erfolgen und so die Informationen trotz Festplattenverschlüsselung preis geben. Im Gegensatz zu den bekannten Cold-Boot-Attacks muss hierzu nichts an der Hardware geschraubt werden.

—EN—
About a year ago i noticed a strange flickering while loading X.Org/GNOME on several of my PCs. It appeared mostly after crashed and restarts, not if the PC was turned off for some time. Since i noticed several patterns inside this flicker i grabed my camera today and recorded the process. The result: its not a random flicker but image-parts of programs that ran before the reboot! They where not limited to the last shown picture before the boot – also programs that where running but not shown (like a browser when a screensaver was active) appeared. In today’s case i even cut the power (~500ms via power cord, Kernel crashed and the pc has no reset-button) – still i was able to recover image-parts. I could observe the behaviour an my home-PC (ArchLinux, GeForce 8600GT, X.org 1.12.2-1, nvidia 295.53-1, Xinerama Multihead) and my PC at work (GeForce 9600GT, X.Org 1.11.2-r2, NVidia 295.20-r1, NVidia TwinView). I could imagine that attackers could use this to bypass a screensaver and get information about running programs. Since you only need to reach a certain state of the GPU it should be possible to use an USB-based OS and grep this info even if the local harddisk is encrypted. Contrary to known Cold-Boot-Attacks there is no need to open the case.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2012/06/capture-clean-300×226.jpgBild: https://www.adlerweb.info/blog/wp-content/uploads/2012/06/capture-cap-300×226.jpg

http://www.youtube.com/watch?v=fuHcbQxl6d0

Back to the Roots: Gnome 2 – Fork „MATE“ auf Archlinux

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…

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.