Dinge, die die Welt nicht braucht

Da ich gerade die Länge von Dateinamen herausfinden musste und mir nicht eingefallen ist wie man das elegant und schnell lösen könnte hab ich mir in der Shell eben was zusammengehackt. Vielleicht weiß jemand eine bessere Lösung:


for i in `ls -1`; do echo -n "$i:" ;echo $i |wc -m ; done | awk -F':' '{print $2 ":" $1}' | sort -n

Eine Änderung von IPv6 gegenüber IP4 besteht darin, dass per Voreinstellung jeder Teilnehmer eines Netzes immer eine sogenannte Link-Local Adresse besitzt. Dieser SLAAC (Stateless Address Autoconfiguration) genannte Automatismus ersetzt und erweitert das von IPv4 bekannte Zeroconf. Während Zeroconf immer durch zusätzliche Software implementiert wird, ist SLAAC Bestandteil des IPv6 Stacks. Das heißt: ist auf einem Host IPv6 aktiviert, so hat dieser auch immer ein IP Adresse auf die zugegriffen werden kann.

Eine Besonderheit ist dabei, dass der Link-Local Adressraum aus dem die IPs vergeben werden (fe80::/10) auf jedem Interface anliegt und man daher immer das Interface angeben muss auf dem man eine solche IP erreichen will. Dem Kommando ping6 wird das Interface mit -I übergeben:

krusty ~ # ping6 -c1 fe80::20a:e4ff:fe3a:cda9
connect: Invalid argument
krusty ~ # ping6 -I eth0 -c1 fe80::20a:e4ff:fe3a:cda9
PING fe80::20a:e4ff:fe3a:cda9(fe80::20a:e4ff:fe3a:cda9) from fe80::20a:e4ff:fe3a:1dc9 eth0: 56 data bytes
64 bytes from fe80::20a:e4ff:fe3a:cda9: icmp_seq=1 ttl=64 time=0.042 ms

--- fe80::20a:e4ff:fe3a:cda9 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.042/0.042/0.042/0.000 ms




Der ssh client bietet nun leider keinen solchen (offensichtlichen) Parameter. Hier wird das Interface direkt an die Adresse, getrennt von einem Prozentzeichen angehängt:

uwe@krusty ~ $ ssh fe80::20a:e4ff:fe3a:cda9%eth0
Last login: Sun Aug 14 16:04:38 CEST 2011 from fe80::20a:e4ff:fe3a:cda9%eth0 on pts/5
uwe@krusty ~ $


Nur ein kurzer Eintrag als Gedächtnisstütze wie die Logitech Webcam C250 unter Gentoo zum funktionieren zu bewegen ist. Folgende Kernel-Einstellungen (2.6.34 in diesem Fall, bei anderen Kerneln kann der Pfad unter Umständen ein wenig anders sein) sind vonnöten:

Device Drivers  --->

  Multimedia support  --->

    Video capture adapters --->

      V4L USB devices  --->

        USB Video Class (UVC)

Sound card support  --->

  Advanced Linux Sound Architecture  --->

    USB sound devices  --->

      USB Audio/MIDI driver

Diese Optionen als Modul konfiguriert und mit make ; make modules_install gebaut und udev sollte nach dem Anschluss der Webcam alles automagisch laden. Mit media-video/guvcview sollte dann bereits alles funktionieren. Die C250 bringt zwar ein Mikrofon mit, allerdings hat die schon vorhandene Soundkarte üblicherweise eine niedrigere Device Nummer in ALSA (und damit eine höhere Priorität) und ist damit das Standardgerät. Somit müsste in jedem Programm in dem man das Mikrofon der C250 benutzen will extra konfigurieren. Es ist jedoch auch möglich in ALSA verschiedene Standardgeräte für Wiedergabe und Aufnahme zu definieren. Dies kann entweder Global in der /etc/asound.conf oder für den entsprechenden Benutzer in der ~/.asoundrc geschehen. Zunächst muss man herausfinden welches Gerät welche Nummer hat:

$ cat /proc/asound/cards

 0 [Intel          ]: HDA-Intel - HDA Intel

                      HDA Intel at 0xf3ff8000 irq 22

 1 [NVidia         ]: HDA-Intel - HDA NVidia

                      HDA NVidia at 0xf7cfc000 irq 17

 2 [U0x46d0x804    ]: USB-Audio - USB Device 0x46d:0x804

                      USB Device 0x46d:0x804 at usb-0000:00:1d.0-1.5.1, high speed

Mein Onboard Sound hat demnach Nummer 0 und die Webcam Nummer 2. Mit diesen Infos kann die ALSA Konfigurationsdatei schon korrekt angepasst werden:

pcm.!default {

         type asym

         playback.pcm {

                 type plug

                 slave.pcm "hw:0,0"

         }  

         capture.pcm {

                 type plug

                 slave.pcm "hw:2,0"

         }  

 }

Sollten die entsprechenden Geräte andere Nummern haben muss die Zahl hinter hw: natürlich angepasst werden. Es geht garantiert einfacher, eleganter und schöner mit ALSA, allerdings bin ich mit der Konfiguration nie wirklich grün geworden und das da oben "works for me" :)

Ich kenne bisher niemanden der auf die Frage "Hast du Capslock/die Feststelltaste schonmal gebraucht?" mit ja geantwortet hätte. Bei der Anschlussfrage, ob Capslock schon einmal genervt hat antworteten bisher auch alle überinstimmend mit "Ja".

Grund genug dieses Ungetüm aus der grauen Schreibmaschienenvorzeit auf den digitalen Friedhof zu verbannen. Das Projekt CAPSoff hat sich der endgültigen Lösung des Problems verschrieben, ich möchte jedoch die "softe" Variante und Linux vorstellen. Die meisten Beschreibungen zu dieser Taste im Netz schalten sie komplett ab. Dabei wird jedoch übersehen, dass man meistens durchaus einen Tastendruck beabsichtigt hatte und eine der Tasten in umittelbarer Umgebung (Tab, A und Shift) erwischen wollte. Bindet man nun auf Capslock A oder Tab, so muss man das zusätzliche Zeichen bei einem Vertipper wieder löschen/die Aktion rückgängig machen. Bindet man jedoch Shift passiert bei einem Vertipper gar nichts. Aus diesem diesem Grund habe ich mich dazu entschlossen Capslock mit Shift zu belegen. Lange Vorrede, kurze Lösung:

Zunächst muss eine Datei (bei mir $HOME/.Xmodmap) mit folgendem Inhalt erzeugt werden:

clear Lock
add shift = Caps_Lock

Diese kann dann einfach mit einem xmodmap $HOME/.xmodmap geladen werden. Um dies Automatisch bei der KDE Ameldung auzuführen habe ich die Datei $HOME/.kde/Autostart/xmodmap erstellt:

#!/bin/bash
xmodmap $HOME/.Xmodmap

Noch mit chmod 755 $HOME/.kde/Autostart/xmodmap ausführbar machen und Capslock sollte nie wieder Probleme verursachen.

Um die Uhrzeit unter Linux mit der Koordinierten Weltzeit (UTC) synchron zu halten sollte NTP als standardisierte und offenes Protokoll benutzt wurden. Hierbei stehen einige Programme zur Auswahl, welche unterschiedliche Strategien zum Abgleich verfolgen. Das einfachste in dieser Katagorie ist sicher ntpdate, welches einen Server nach der aktuellen Uhrzeit befragt und diese hart im System setzt. Dieses Vorgehensweise übergeht jedoch Daemons wie z.B. cron und so können geplante Backups schlicht "vergessen" werden. Auch wenn man gerade am Rechner arbeitet kann eine plötzliche Veränderung der Zeit den Bildschirmschoner anspringen lassen.

Auch aus diesen Gründen sollte dem ntpd als Standardimplementation der Vorzug gegeben werden. Dieser gleicht Gangdifferenzen zur korrekten Uhrzeit durch Beschleunigung bzw. Verlangsamung der lokalen Systemuhr aus. Stimmt die Zeit wieder, stellt der Daemon die richtige Geschwindigkeit her. Die oben angeführten Nachteile von ntpdate sind damit schon einmal umschifft. Natürlich bringt das eine etwas aufwendigere Konfiguration mit sich, allerdings sollte dies mit den zahlreichen Tutorials im Netz kein Problem sein.

Vereinfacht wird die "richtige" Geschwindigkeit der Systemuhr normalerweise durch einen Baustein auf dem Motherboard bestimmt, wobei ein Quarzkristall x-mal pro Sekunde schwingt. Da es bei solchen Bauteilen allerdings immer auch Fertigungstoleranzen gibt, ist die Sekunde sogar auf auf zwei Motherboards des gleichen Modells unterschiedlich lang. Diese Sekunden unterscheiden sich dann auch noch einmal von der einer (extrem genauen) Atomuhr. Dieser Unterschied wird auch Drift genannt, der bei jedem Computer unterschiedlich ist. Diesen Drift speichert der ntpd standardmässig unter /var/lib/ntp/ntp.drift und kann die Uhrzeit so auch ohne Verbindung in Netz sehr genau halten.

Mit dem Kommandozeilenprogramm ntpq kann man dem ntpd bei der Arbeit zusehen und Problemen auf den Grund gehen. Die verbundenen ntp Server werden mit dem Kommando "peers" angezeigt:

uwe@krusty ~ $ ntpq -n -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
*129.70.132.33 129.70.130.70 2 u 45 64 377 65.492 4.168 0.805
+85.214.29.92 131.188.3.222 2 u 3 64 377 72.744 -0.136 0.702
+78.47.136.197 143.93.99.252 2 u 55 64 377 59.573 1.509 1.118
-92.51.130.224 85.214.71.202 3 u 60 64 377 69.906 -5.627 0.654


Hier sollte mindestens ein Server mit einem * markiert sein. Dieser ist für den ntpd am "stabilsten" zu erreichen und der eigene Referenzserver. Die mit + markierten Hosts wären die nächsten Kandidaten falls der Referenzserver nicht mehr verfügbarsein sollte. Mit "associations" kann man sich diese Beziehungen auch ansehen


uwe@krusty ~ $ ntpq -n -c associations

ind assID status conf reach auth condition last_event cnt
===========================================================
1 54760 9624 yes yes none sys.peer reachable 2
2 54761 9424 yes yes none candidat reachable 2
3 54762 9424 yes yes none candidat reachable 2
4 54763 9324 yes yes none outlyer reachable 2


Es gibt auch einen Kommandozeilenmodus von ntpq in dem man sich austoben kann:


uwe@krusty ~ $ ntpq
ntpq> ?
ntpq commands:
addvars debug lopeers passociations rl
associations delay lpassociations passwd rmvars
authenticate exit lpeers peers rv
cl help mreadlist poll showvars
clearvars host mreadvar pstatus timeout
clocklist hostnames mrl quit version
clockvar keyid mrv raw writelist
cooked keytype ntpversion readlist writevar
cv lassociations opeers readvar
ntpq>


Will man mit einem DSL Anschluss in Deutschland per IPv6 ins Internet und nicht extra dafür zu einem der wenigen Provider die IPv6 nativ anbieten wechseln, so bleibt als einzig praktikable Möglichkeit derzeit nur ein 6in4 Tunnel. Der amerikanische Konzern Hurricane Electric (oder der einfacheit halber: HE) bietet unter http://tunnelbroker.net/ einen kostenlosen IPv6 Tunnelbroker an, zu welchem man von jedem beliebigen DSL aus einen Tunnel betreiben kann. Nach der Registrierung kann unter "Create Regular Tunnel" ein neuer Tunnel beantragt werden. Dabei muss die eigene DSL IP (herauszufinden z.B. bei www.whatismyip.org) allerdings pingbar sein, sonst scheitert der Antrag. Ausserdem sollte man gleich ein "Routed /48" beantragen, damit man die Clients hinter dem eigenen Router gleich mit IPv6 versorgen kann.

Ich benutze auf meinem DSL Router WRT54GL derzeit die Linuxdistribution OpenWRT. Es exitiert zwar eine Anleitung für IPv6 auf dieser Distribution, allerdings ist diese nicht mehr wirklich aktuell. Diese Anleitung wurde erfolgreich mit der OpenWRT Version 8.09.1 (Kamikaze) entwickelt. Um IPv6 mit HE zum fliegen zu bringen sind folgende Schritte notwendig:

Zunächst müssen mit opkg install folgende Pakete installiert werden


ip6tables
kmod-ip6tables
kmod-ipv6
radvd


Der Tunnelbroker geht von einer statischen IP aus, bei DSL ändert sich diese jedoch üblicherweise mit jeder Neueinwahl. Um den Tunnelendpunkt bei jeder Änderung wieder aufzusetzen habe ich ein Shellskript erstellt. Es wird immer aufgerufen wenn sich ein Interfacestatus ändert. Zunächst wird die Benutzernummer gebraucht, welche auf der Hurricane Electric Tunelbroker Homepage direkt neben "UserID" steht. Ebenfalls auf der HE Seite unter "Tunnel Details" ist die "Global Tunnel ID" zu finden. Der letzte notwendige Wert ist das mit MD5 gehashte Passwort. Dies lässt sich am einfachsten an der Shell erstellen:


$ echo -n 'XXX' | md5sum
bc9189406be84ec297464a514221406d -


Die MD5 Summe das Passworts XXX ist in diesem Beispiel also bc9189406be84ec297464a514221406d. Der letzte Wert der benötigt wird ist die "Client IPv6 address", welche sich ebenfalls bei den "Tunnel Details" befindet.

Diese Werte müssen in das Skript unten eingetragen und in der Datei /etc/hotplug.d/iface/10-ipv6 gespeichert werden:


#!/bin/sh

USER="XXX"
PASS="XXX"
ID="XXX"
CLIENT="XXX/64"
REMOTEV4="216.66.80.30"
ROUTEDNET="XXX::/48"

EXT="wan"
INT="lan"
TUNNEL="he-ipv6"

. /etc/functions.sh # common functions
include /lib/network # include /lib/network/*.sh
scan_interfaces # read and parse the network config


if [ "$ACTION" = "ifup" -a "$INTERFACE" = "$EXT" ]
then
config_get IPV4 "$EXT" ipaddr
logger "updating ipv4 tunnel endpoint to $IPV4"
wget -O - "http://ipv4.tunnelbroker.net/ipv4_end.php?ipv4b=$IPV4&pass=$PASS&user_id=$USER&tunnel_id=$ID" > /dev/null 2>&1
ip tunnel add $TUNNEL mode sit remote $REMOTEV4 local $IPV4 ttl 255
ip link set $TUNNEL up
ip addr add $CLIENT dev $TUNNEL
ip route add ::/0 dev $TUNNEL
config_get LANIF "$INT" ifname
ip route add $ROUTEDNET dev $LANIF
fi

if [ "$ACTION" = "ifdown" -a "$INTERFACE" = "wan" ]
then
ip tunnel del $TUNNEL
config_get LANIF "$INT" ifname
ip route del $ROUTEDNET dev $LANIF
fi



Um die Kommunikation mit dem Tunnelbroker zu erlauben muss dieser in der OpenWRT IPv4 Firewall (/etc/config/firewall) freigeschaltet werden:


config rule
option src_ip 216.66.80.30
option proto 41
option target ACCEPT


Um den Router auch gegenüber dem Internet zu schützen sollten in die Datei /etc/firewall.user folgende Zeilen hinzugefügt werden:


### ipv6 stuff
ip6tables -F INPUT
ip6tables -P INPUT DROP
ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT
ip6tables -A INPUT -p icmpv6 -j ACCEPT
ip6tables -F FORWARD
ip6tables -A FORWARD -j ACCEPT


Diese Firewall schützt nur den Router und nicht die Clients im Netz dahinter. Entweder man erweitert die Regeln oben entsprechend oder man spendiert jedem Client eine IPv6 Firewall. Die oben gemachten Änderungen werden nach einem "/etc/init.d/firewall restart" aktiv.

Die Einstellungen sind gemacht und nach einem "ifdown wan; ifup wan" sollte der Tunnel stehen. Dies kann gleich mit ping6 geprüft werden:


root@OpenWrt:~# ping6 -c3 www.kame.net
PING www.kame.net (2001:200:0:8002:203:47ff:fea5:3085): 56 data bytes
64 bytes from 2001:200:0:8002:203:47ff:fea5:3085: seq=0 ttl=51 time=294.092 ms
64 bytes from 2001:200:0:8002:203:47ff:fea5:3085: seq=1 ttl=51 time=292.718 ms
64 bytes from 2001:200:0:8002:203:47ff:fea5:3085: seq=2 ttl=51 time=293.255 ms

--- www.kame.net ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 292.718/293.355/294.092 ms
root@OpenWrt:~# ping6 -c3 ipv6.google.com
PING ipv6.google.com (2001:4860:a003::68): 56 data bytes
64 bytes from 2001:4860:a003::68: seq=0 ttl=59 time=19.912 ms
64 bytes from 2001:4860:a003::68: seq=1 ttl=59 time=15.248 ms
64 bytes from 2001:4860:a003::68: seq=2 ttl=59 time=15.082 ms

--- ipv6.google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 15.082/16.747/19.912 ms


Um nun die Clients im eigenen Heimnetz per Autokonfiguration mit IPv6 zu versorgen muss der Linux Router Advertisement Daemon konfiguriert werden. Dazu wird das oben beantragte Routed /48 benötigt. Die Konfiguration sieht bei mir folgendermassen aus:

/etc/config/radvd

config interface

        option interface        'lan'

        option AdvSendAdvert    1

        option AdvManagedFlag   0

        option AdvOtherConfigFlag 0

        option ignore           0



config prefix

        option interface        'lan'

        # If not specified, a non-link-local prefix of the interface is used

        option prefix           '2001:470:9888::/64'

        option AdvOnLink        1

        option AdvAutonomous    1

        option AdvRouterAddr    0

        option AdvPreferredLifetime     600

        option AdvValidLifetime 1200

        option ignore           0



config rdnss

        option interface        'br-lan'

        # If not specified, the link-local address of the interface is used

        option addr             ''

        option ignore           1

Für die option "prefix" muss das eigene bei HE beantragte /48 eingetragen werden. Achtung: als Netzmaske für radvd ist /64 zwingend notwendig, denn nur so können sich die Clients mit Hilfe von EUI-64 selbst eine Adresse würfeln. Trägt man hier /48 bleiben 16 Bits übrig, von denen der Client nicht weiss, wie er sie füllen soll. Nachdem man den Daemon aktiviert und gestartet ist sollten alle Clients im dahinterliegenden Netz automatisch mit IPv6 versorgt werden, sofern das Betriebssystem dies unterstützt.


root@OpenWrt:~# /etc/init.d/radvd enable
root@OpenWrt:~# /etc/init.d/radvd start


Konfigurationsdateien unter *nix Systemen werden üblicherweise in /etc abgelegt. Da es sich dabei meist um reine Textdateien handelt bietet sich eine Versionierung mit einem der bekannten Systeme an. Ich habe mich aus reiner Faulheit (meine Diplomarbeit enstand bereits damit) für Subversion entschieden. Die Einführung in SVN, so die Abkürzung für Subversion, und in Versionsverwaltung allgemein spare ich mir an dieser Stelle da es dazu schon viele hervorragende Quellen im Web gibt.

Ich habe diverse Rechner, deren /etc ich auf diese Weise sichern und will und einen Rootserver welchen ich als zentrales Repository zur Speicherung benutzen möchte.

Als erstes wird das dazu das SVN Repository angelegt:

uwe@maninthemiddle ~ $ svnadmin create /home/uwe/repos

Mehr muss auf dem Server auch nicht mehr gemacht werden. Der Rest wird vom Clientrechner (in meinem Fall mit dem Namen "Krusty" über SSH erledigt. Dazu bietet es sich an Key-basierende Authentifizierung für SSH zu benutzen. Auch hier sei auf die vielen guten Tutorials im Web verwiesen. Da ich SSH normalerweise als unprivilegierter Anwender benutze /etc aber nur als root vollständig gelesen werden kann, sollte das SSH profil von root dementsprechend angepasst werden. Dies beinhaltet den richtigen Benutzernamen, sowie eine identity Datei welche den private key enthält. Die entsprechende Konfigurationsdatei /root/.ssh/config sieht bei mir dementsprechend so aus:

Host maninthemiddle.de
User uwe
IdentityFile /home/uwe/.ssh/id_rsa

Nun muss im Repository ein Verzeichnis angelegt werden in dem die Dateien später landen sollen:

krusty etc # svn mkdir svn+ssh://maninthemiddle.de/home/uwe/repos/etc-krusty

Dieses wird im Verzeichnis /etc auf dem lokalen Rechner ausgecheckt und ist damit mit diesem verbunden:

krusty etc # svn co svn+ssh://maninthemiddle.de/home/uwe/repos/etc-krusty /etc

Mit svn add können nun Dateien hinzugefügt und mit svn commit ins Repository hochgeladen werden. Unschön ist dabei allerdings, dass nicht hinzugefügte Dateien bei svn status mit einem Fragezeichen auftauchen und die Übersichtlichkeit stark leidet:

krusty etc # svn status
M .
? xinetd.conf
? opera6rc.fixed
? nanorc
? racoon
? java-config-2
...

Bei der Softwareentwicklung sorgt dieser Mechanismus dafür, dass keine Datei vergessen wird. Hier tauchen in diesem Fall jedoch in der Mehrzahl Dateien auf die gar nicht ins Repository kommen sollen. Um den Überblick zu behalten habe ich deshalb SVN angewiesen alle Dateien zu ignorieren, die nicht eingecheckt sind.

krusty etc # svn propset svn:ignore '*' /etc

Für alle anderen Rechner einfach die gleichen Schritte durchführen, womit Probleme mit gelöschten/verschlimmbesserten Konfigurationsdateien der Vergangenheit angehören sollten.

Nachtrag:
Gerade unter gentoo sollte auch die aktuelle Kernelkonfiguration gesichert werden. Ich setze dazu einfach einen Symlink nach /etc und füge diese Datei zum Repository hinzu.

barney etc # ln -s /usr/src/linux/.config kernelconfig
barney etc # svn add kernelconfig
A kernelconfig

Nachtrag 2:
Die alten Versionen einzelner Dateien kann man mittels svn export -r REVISION holen:

uwe@barney ~/tmp $ svn log svn+ssh://maninthemiddle.de/home/uwe/repos/etc-barney/lilo.conf
------------------------------------------------------------------------
r18 | uwe | 2009-11-26 21:49:23 +0100 (Do, 26. Nov 2009) | 1 Zeile


------------------------------------------------------------------------
r17 | uwe | 2009-11-26 21:43:01 +0100 (Do, 26. Nov 2009) | 1 Zeile


------------------------------------------------------------------------
uwe@barney ~/tmp $ svn export -r 17 svn+ssh://maninthemiddle.de/home/uwe/repos/etc-barney/lilo.conf
A lilo.conf
Export abgeschlossen.

Nachtrag 3:
Um z.B. die /etc/X11/xorg.conf ins Repository hinzufügen zu können muss auch das Verzeichnis /etc/X11/ im Repository vorhanden sein. Subversion fügt mit svn add /etx/X11 allerdings auch alle Dateien unterhalb dieses Verzeichnisses ein. Stattdessen möchste man die Option --non-recursive benutzen:

barney etc # svn add --non-recursive X11/
A X11

Versehentlich ins Repository aufgenomme Dateien kann man mit svn delete wieder aus diesem entfernen, allerdings löscht svn dann auch die lokale Kopie. Hier sollte man --keep-local als Option mitgeben:

barney portage # svn delete --keep-local savedconfig/
D savedconfig/sys-apps/busybox-1.13.2
D savedconfig/sys-apps
D savedconfig

Wer kennt das nicht. Nach dem Urlaub werden Fotos am Bildschirm bestaunt und es dauert nicht lange bis das kollektive Kopfkippen nach rechts oder links beginnt. Glücklicherweise haben inzwischen sogar Handykameras Neigungssensoren eingebaut, womit die Elektronik die Ausrichtung in den EXIF Daten eines Bildes speichern kann. Somit ist es für ein Ausgabegerät möglich das Foto anhand dieser Daten wieder richtig herum auf den Bildschirm zu bringen. Der Bildbetrachter beispielsweise gqview kann die Fotos so schon vor der Anzeige drehen. Allerdings wirkt sich dies nur auf die Darstellung aus und die gespeicherten Fotos behalten ihre Ausrichtung. Da nicht alle Bildbetrachter so eine Funktion enthalten will man natürlich das gespeicherte Material zurecht rücken. Dabei ist zu bedenken, dass JPEG ein verlustbehaftetes Format ist und das Laden, Drehen und erneute Speichern zur Qualitätsminderung führen würde. Glücklicherweise wurden solche Fälle von der Joint Photographic Experts Group bei der Entwicklung des Formats bedacht. Aus diesem Grund wurden einige spezielle verlustfreie JPEG Operationen definiert wie z.B. drehen um vielfache von 90° und das Beschneiden eines Bildes um vielfache von 16 Pixeln. Das Verarbeitende Programm muss diese JPEG Operationen allerdings explizit unterstützen, sonst werden in der Regel verlustbehaftete Operationen durchgeführt. Genug der Theorie, hier die Linux Praxis:

Unter Gentoo befinden sich alle hier genannten Tools im Paket media-libs/jpeg. Das Programm jpegtran unterstützt besagte JPEG Operationen und kann die Bilder wie gewünscht drehen. Es empfiehlt sich außerdem immer den Parameter -copy all zu verwenden, damit die EXIF Daten erhalten bleiben. Allerdings stimmt nun die in den EXIF Daten gespeicherte Ausrichtung nicht mehr. Diese kann man dann mit dem Tool jpegexiforient und dem Parameter -1 auf Normalausrichtung setzen. Das ganze ist natürlich automatisierbar und mit dem Skript exifautotran umgesetzt. Zunächst wird die Ausrichtung gelesen, dann richtig gedreht und zum Schluss wird im EXIF Teil wieder die Normalausrichtung gesetzt. Ein exifautotran *.jpg entlastet also die Nackenmuskulatur während des Fotoabends.

Update: unter Ubuntu heißt das entsprechende Paket libjpeg-progs

Scapy ist ein ziemlich cooler Packetgenerator/Analyzer/vielesmehr. Die Projektseite gibt mit der "Quick Demo" schon eine kleine Einführung in die Fähigkeiten dieses Tools.

Leider ist die Dokumentation im im Gegensatz zum Programm noch weitgehend unbrauchbar und deshalb will ich versuchen hier immer mal wieder nützliche Scapy Skripte/Einzeiler vorzustellen.

Wilde DHCP Server finden

Problem: irgendwo im Netz schwirrt ein nicht genemigter DHCP Server herum und vergibt IP Adressen. Die umständliche Methode wäre das eigene Interface umzukonfigurieren und einen DHCP Request zu machen. Scapy schafft das ohne diesen lästigen Mehraufwand.

>>> dhcp_request(iface="eth1")
WARNING: conf.checkIPaddr is not 0, I may not be able to match the answer
Begin emission:
Finished to send 1 packets.
.......................................
Received 39 packets, got 0 answers, remaining 1 packets

Ein gleichzeitiger tcpdump offenbart ide MAC-Adresse des Übeltäters:

# tcpdump -e -i eth1 port 67 or port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes

21:43:17.938745 00:11:11:11:11:11 (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 286: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:11:11:11:11:11 (oui Unknown), length 244

21:43:17.952684 00:22:22:22:22:22 (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: ..bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300

Mit einem managbaren Switch lässt sich die Adresse 00:22:22:22:22:22 nun schnell einem Port zuordnen. Unter IOS z.B. mit show mac-address-table oder unter CatOS mit show cam dynamic. Dann muss man nur noch das Kabel verfolgen und dem User auf die Finger klopfen ;).

Heutzutage ist es sinnvoll und nur vernüftig TCP Verbindungen abzusichern. Dies geschieht bei HTTP (aber auch einigen anderen Protokollen) über TLS/SSL. Falls allerdings Probleme auftreten ist die Möglichkeit durch Mitsniffen Hinweise auf Fehler zu erhalten verbaut. Auch die beliebte Methode eine Serveranwendung mit telnet oder netcat zu testen ist nicht mehr ohne weiteres durchführbar. Die bekannteste SSL Implementation OpenSSL bietet allerdings ein Dienstprogramm, welches dies wieder ermöglicht. Zur besseren Übersicht sind die getippten Kommandos grün hinterlegt:

$ openssl s_client -host www.gmx.de -port 443
CONNECTED(00000003)
depth=0 /C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=www.gmx.net
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=www.gmx.net
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=www.gmx.net
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=www.gmx.net
i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDUzCCArygAwIBAgIQSrsfqH7F4QWACHs9HWpPkzANBgkqhkiG9w0BAQQFADCB
zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE
CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhh
d3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNl
cnZlckB0aGF3dGUuY29tMB4XDTA2MDIxMDA5NTUxNloXDTA3MDIxNzA4NTcwMVow
WDELMAkGA1UEBhMCREUxDzANBgNVBAgTBkJheWVybjEPMA0GA1UEBxMGTXVuaWNo
MREwDwYDVQQKEwhHTVggR21iSDEUMBIGA1UEAxMLd3d3LmdteC5uZXQwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBALv4J7mPoIhpMzqWmGEJKIxLlkD/Y4bKhXGP
EN11bdPPL1xcaCB95+r1lW4yvrC+NOQRre/Zt1vvXUtw+CKjzWL17xk5ORxejx5d
WCaZ+AtjKL3j7PrZkErx7X7ZqNcRgmPn2bfPfYnYR3gjp7AJitslmb+5Cp2a7dfo
pjYGOEnbAgMBAAGjgaYwgaMwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMC
MEAGA1UdHwQ5MDcwNaAzoDGGL2h0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ
cmVtaXVtU2VydmVyQ0EuY3JsMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYW
aHR0cDovL29jc3AudGhhd3RlLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEB
BAUAA4GBABrINqdDTKfUd7BTpZLl4i0zHzWCff851588VxUL8+3OUqIHgTzdvWmx
9JeM8RoiCXfX84dt5y3pdeYi9FWJM5rBRxbijzw3f5zSyJloz7xSpV08F/Ii+svs
MKUhTkNSbMwa9vnWIogK4prbUj0yHfCrdsZLmHI4zAliK0e8lHfF
-----END CERTIFICATE-----
subject=/C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=www.gmx.net
issuer=/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com
---
No client certificate CA names sent
---
SSL handshake has read 1419 bytes and written 322 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 67DE63728E1EF1E860BFE2B8E54A65EA52DA8AFA8F5D3A202746A36D2BCC5558
Session-ID-ctx:
Master-Key: E6C37C6E7C56A8C95366C26102A41BE8233E079A4371AA20996EFF7DC539BDCE424F326A3F494F81C3CA03712D91F08E
Key-Arg : None
Start Time: 1165442910
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
GET / HTTP/1.0
HOST: www.gmx.de

HTTP/1.1 302 Found
Date: Wed, 06 Dec 2006 22:08:42 GMT
Server: Apache
Location: https://www.gmx.net/de/
Vary: Accept-Encoding
Content-Length: 207
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://www.gmx.net/de/">here</a>.</p>
</body></html>
closed

Auch wenn die meisten Webentwickler mit dem Internet Explorer aufgrund der unzureichenden Umsetzung der Standards und des katastrophalen Sicherheitsmodells auf Kriegsfuss stehen surfen im insbesonderen amerikanische Nutzer oft noch mit diesem Browser.

Neu entwickelte Webseiten müssen also auch noch mit diesen IE Versionen getestet werden. Dafür ist allerdings nicht zwangsläufig die Installation von Windows notwendig. Das Projekt IEs4Linux installiert die Versionen 5, 5.5 und 6 des Internet Explorers vollautomatisch unter Linux. Der kostenlose Programm Wine gaukelt dem IE Versionen dabei die richtige Systemumgebung vor.


Die Verfügbarkeit dieses Browsers ist nicht nur für Entwickler ein Segen. Auch wenn fremde Webseiten nur mit dem Internet Explorer funktionieren (ja solche gibt es immer noch) lässt sich der unter Linux laufende IE einsetzen. Allerdings sollte man sich überlegen, ob die Seite wirklich unverzichtbar ist und man nicht auch woanders, wo man Besucher und die Standards respektiert, fündig wird.

Darüber hinaus muss natürlich ein anständiger Browser her. Mein Favourit ist dabei Mozilla Firefox, dessen größter Vorteil eindeutig die zahllosen Plugins sind.

Die folgende Begebenheit hat sich vor einigen Monaten ereignet und deshalb muss ich es aus meinem Gedächtnis rekonstruieren. Daher hoffe ich, dass die Datails noch stimmen.

Ein Notebook mit Debian an Board sollte umgestöpselt werden. Am neuen Standort war Windows (vermutlich Server 2003, aber ich weiss es nicht genau) für die Adressvergabe per DHCP zuständig. Der geneigte Leser wird es an dieser Stelle sicher ahnen: hätte das Notebook seine Adresse problemlos erhalten, wäre dieser Artikel nicht zustande gekommen. In tcpdump erschienen DHCPDISCOVER vom Notebook und DHCPOFFER vom Server und danach herrschte Funkstille. Im Windows-eigenen Paketsniffer wurde zur Verwunderung der Beteiligten keines der Pakete angezeigt.

Nachdem etwas im Nebel gestochert worden war, kam mir die Idee es könnte sich um ein Datumsproblem handeln. Denn im Notebook war der Akku defekt und auch die Sekundärversorgung war offensichtlich so leer, dass die Uhrzeit nicht mehr gehalten werden konnte. Die Zeit wurde bei jedem stromlosen Flurgang (oder Umzug) auf den 01.01.2002 zurückgesetzt. Nachdem Uhrzeit und Datum wieder richtig eingestellt waren erhielt der Client seine IP ohne Probleme. Warum allerdings keines der beteiligten Systeme es für nötig gehalten hat irgendeine Fehlermeldung in das Logfile zu schreiben ist mir bis heute ein Rätsel.

Wenn man Linuxhilfe benötigt, wird man oft dazu aufgefordert Konfigurationsdateien bei Services wie zum Beispiel pastebin oder nopaste zu hinterlegen. Viele machen es den Helfern aber unnötig schwer. Eingestreute Kommentar- und Leerzeilen verschlechtern die Übersichtlichkeit für den Profi. Daher sollte diese vorher entfernt werden:

egrep -v '^[[:space:]]*$|^[[:space:]]*#' /path/to/file

Zum Vergleich meine vollständige /etc/rc.conf

# /etc/rc.conf: Global startup script configuration settings

# UNICODE specifies whether you want to have UNICODE support in the console.
# If you set to yes, please make sure to set a UNICODE aware CONSOLEFONT and
# KEYMAP in the /etc/conf.d/consolefont and /etc/conf.d/keymaps config files.

UNICODE="no"

# Set EDITOR to your preferred editor.
# You may use something other than what is listed here.

#EDITOR="/bin/nano"
EDITOR="/usr/bin/vim"
#EDITOR="/usr/bin/emacs"

# XSESSION is a new variable to control what window manager to start
# default with X if run with xdm, startx or xinit. The default behavior
# is to look in /etc/X11/Sessions/ and run the script in matching the
# value that XSESSION is set to. The support scripts are smart enough to
# look in all bin directories if it cant find a match in /etc/X11/Sessions/,
# so setting it to "enlightenment" can also work. This is basically used
# as a way for the system admin to configure a default system wide WM,
# allthough it will work if the user export XSESSION in his .bash_profile, etc.
#
# NOTE: 1) this behaviour is overridden when a ~/.xinitrc exists, and startx
# is called.
# 2) even if ~/.xsession exists, if XSESSION can be resolved, it will
# be executed rather than ~/.xsession, else KDM breaks ...
#
# Defaults depending on what you install currently include:
#
# Gnome - will start gnome-session
# kde-<version> - will start startkde (look in /etc/X11/Sessions/)
# Xsession - will start a terminal and a few other nice apps

#XSESSION="Gnome"
XSESSION="kde-3.5"

Und die gekürzte Fassung

UNICODE="no"
EDITOR="/usr/bin/vim"
XSESSION="kde-3.5"

Versicht ist allerdings bei Shellscripten geboten, da die Shebang hierbei auch entfernt wird.

In einer perfekten Welt wären Verbindungsprobleme nicht existent und Netzwerke würden immer funktionieren. Leider leben wir nicht in einer solchen und so muss man mit den Auswirkungen dieser Fehler klar kommen. Unterbricht eine SSH Verbindung weil die Gegenstelle nicht mehr reagiert (und auch keine ICMP Message schickt, die anzeigt, dass die Verbindung unterbrochen ist), so wartet der Client unter Umständen eine kleine Ewigkeit bis der Timeout zuschlägt und das Terminal wieder freigibt. Die übliche Abbruchmethode für Konsolenprogramme via CTRL+C funktioniert nicht, da der SSH Client dieses Tastenkombination einfach an den Server durchleitet. Das gleiche gilt für Telnet, dass auch oft benutzt wird um andere Dienste wie zum Beispiel HTTP oder POP3 zu testen.

Das Terminal zu schliessen oder den Prozess zu töten kann natürlich keine Lösung sein, zumal die Entwickler dieser Clients bereits an dieses Problem gedacht haben. Sowohl für SSH als auch für Telnet existiert ein so genannter Escape Character, um aus der Session zu entkommen und Zugriff auf das Programm zu erhalten.

Dieses Zeichen ist für SSH in der Voreinstellung die Tilde (~). Auf einer deutschen Tastatur ist sie über AltGr+ zu erreichen. Natürlich kann auch ein anderes Zeichen definiert werden. Die SSH Manpage sagt dazu:

-e escape_char
Sets the escape character for sessions with a pty (default: `~'). The
escape character is only recognized at the beginning of a line. The
escape character followed by a dot (`.') closes the connection; followed
by control-Z suspends the connection; and followed by itself sends the
escape character once. Setting the character to ``none'' disables any
escapes and makes the session fully transparent.

Folgende Befehle sind dann laut Manpage möglich

The supported escapes (assuming the default `~') are:

~. Disconnect.

~^Z Background ssh.

~# List forwarded connections.

~& Background ssh at logout when waiting for forwarded connection / X11 ses-
sions to terminate.

~? Display a list of escape characters.

~B Send a BREAK to the remote system (only useful for SSH protocol version 2
and if the peer supports it).

~C Open command line. Currently this allows the addition of port forward-
ings using the -L and -R options (see above). It also allows the cancel-
lation of existing remote port-forwardings using -KR hostport. !command
allows the user to execute a local command if the PermitLocalCommand
option is enabled in ssh_config(5). Basic help is available, using the
-h option.

~R Request rekeying of the connection (only useful for SSH protocol version
2 and if the peer supports it).

Ein Zirkumflex (^) steht übrigens für die Taste Ctrl (Strg). Funktionieren diese Kombinationen nicht, so ist auf dem Client PC vielleicht deadkeys als Tastaturlayoutvariante eingestellt. In diesem Fall muss die Tilde zwei mal gedrückt werden um diese Kommandos ausführen zu können. Soll die Tilde auf der Shell der Gegenseite ankommen ist sogar ein viermaliger Druck notwendig.

Telnet zeigt das Escape Zeichen beim Verbindungsauf an:

$ telnet www.google.de 80
Trying 72.14.221.104...
Connected to www.google.de.
Escape character is '^]'.

Dieses eckige Klammer (]) ist auf Tastaturen mit englischem Layout leicht zu erreichen und es muss tatsächlich nur Ctrl (Strg) und die ]-Taste gedrückt werden. Beim deutschen Layout wird zusätzlich noch AltGr gebraucht, wodurch die Kombination fast schon zum Affengriff wird. Dort muss Strg+AltGr+9 gedrückt werden, damit man in den Kommandomodus von telnet wechselt. Natürlich lässt sich auch dieses Zeichen ändern:

-e escapechar
Sets the initial telnet escape character to escapechar. If escapechar is
omitted, then there will be no escape character.

Mit einem einfachen Druck auf Return wechselt telnet vom Prompt zurück in die Verbindung.

Sorry. Aber ich muss jetzt meinem Ärger mal eben Luft machen. Ich benutze im Büro Debian, weil eigentlich alle Linux Büchsen hier damit laufen. Bei dieser Distribution sind in der Datei /etc/apt/sources.list URIs eingetragen, von denen sich das System Paketlisten besorgen kann (vergleichbar mit den RSYNC mirrors bei Gentoo). Dort sind bei mir sowohl einige HTTP als auch FTP Sourcen eingetragen. Das man bei Debian immer zig Einträge in dieser Datei braucht, damit man seine Software zusammenbekommt (mplayer, acroread, etc.), empfinde ich zwar als ziemlich störend, aber es hat immerhin einen nachvollziehbaren Grund (Lizenzgeraffel, falls sich jemand dafür intressiert).

Das Netz hier ist ziemlich dicht, nach außen geht es nur über den HTTP oder FTP Proxy. Das ganze lässt sich auch im Konfigurationsfile (/etc/apt/apt.conf) das Paketmanagement Frontends apt einstellen:

Acquire::ftp
{
Proxy "ftp://foobar:2121";
ProxyLogin
{
"USER $(SITE_USER)@$(SITE)";
"PASS $(SITE_PASS)";
};
};
Acquire::http::Proxy "http://barfoo:8080";

Dann aber wurde der FTP Proxy im Zuge einer Umstellung abgeschaltet. Glücklicherweise ist FTP ins Internet damit noch nicht gekappt, denn der HTTP Proxy beherrscht auch dieses Protokoll. Die FTP-in-HTTP-Verpackung sieht dann zum Beispiel in etwa so aus:

GET ftp://ftp.de.debian.org HTTP/1.1
...

Diese Umstellung sollte kein Problem darstellen, da der entsprechenden Konfigurationszeile das Zugriffsschema voransteht (http:// oder ftp://). Also war ftp://foobar:2121 einfach durch http://barfoo:8080 zu ersetzen. Der Erfolg blieb leider aus und es hagelte nur Connection Timeouts. An dieser Stelle ist der erste Gedanke natürlich: was passiert da auf dem Netz? Ethereal zeigt dann, dass apt offentlich versucht FTP mit dem HTTP Proxy zu sprechen. Klarer Fall: da hab ich etwas falsch konfiguriert. Nach mehrmaliger Prüfung war aber beim besten Willen kein Fehler zu finden. Alle Quellen im Netz hatten es auch so eingestellt. Fast vom Stuhl gefallen bin ich, als ich folgenden Abschnitt in man sources.list lesen konnte.

It is possible to proxy FTP over HTTP by setting the ftp_proxy environment variable to a http url - see the discussion of the http method above for syntax. You cannot set this in the configuration file and it is not recommended to use FTP over HTTP due to its low efficiency.

Hallo? Geht's noch ein bischen schizophrener? Wenn etwas in einer Environment Variable gesetzt ist funktioniert es. Im applikationseigenen Konfigurationsfile wird nicht angenommen. Allein das ist schon krank, aber es geht ja noch weiter. Die Proxyurl, vor der eindeutig http:// steht, dann ohne jegliche Fehlermeldung zu etwas anderem zu verwursten und dann zu behaupten der Server wäre kaputt setzt dem ganzen die Krone auf. Eine leidlich vollständige Dokumentation entbindet nicht davon einigermaßen sinnvolle Fehlermeldungen auszugeben.

Danke. Jetzt geht's mir besser.

Nachtrag
Natürlich will ich nicht nur meckern, sondern auch eine konkrete Problemlösung anbieten. Systemweite Environment Variablen werden bei Debian normalerweise in /etc/environment gesetzt. Allerdings werden diese offensichtlich nur bei einem Login und nicht bei einem Benutzerwechsel zu root ausgelesen. Daher sollte man den Proxy zusätzlich in /root/.profile setzen.

export http_proxy="http://barfoo:8080"
export ftp_proxy="http://barfoo:8080"