planetknauer.net

Kaum zu glauben: Aber mit Treiberversion 11.7 steht nun endlich ein AMD-Treiber zur Verfügung, welcher sich ohne rumgepatche und langen händischen Kompilierorgien out-of-the-box auf Kernel 2.6.38 aus den Debian Backports installieren lässt. Wird ja auch so langsam Zeit, jetzt wo schon bald Kernel 3.1 vor der Türe steht...

Und ich dachte eigentlich, dass man den Stand-By-Modus bei Stromverbrauchern* vermeiden und stattdessen ganz abschalten sollte. Tja, wieder was gelernt. Danke, Politiker!

*) was mit AKWs passiert, wenn man ihre Stromzufuhr abstellt, hat man ja in Japan mitbekommen...

Das war's dann wohl. Nokia setzt auf Windows. Na dann... wird mein nächstes Gerät wohl nicht von Nokia (und ganz bestimmt auch nicht von Apple) sein. Insbesondere stören mich solche destruktive Ansagen von Microsoft ganz gewaltig:

Es gibt andere mobile Ökosysteme. Wir werden sie zerstören.

Danke, mehr brauche ich nicht zu wissen. Das bestätigt eher meine bisherige Einschätzung von Kleinstweich.

Die Symbian-Plattform hat mir bislang eigentlich gut gefallen. Vor allem hat mich aber die Akku-Laufzeit der Nokia-Geräte sehr überzeugt. Mein derzeitiges Gerät hält doch 10-14 Tage ohne Steckdose durch und kann neben telefonieren auch Emails lesen, Musik abspielen, im Internet surfen und mit Python programmiert werden. Also alles was ich brauche. Schade, dass alle anderen Smartphones nur knapp einen Tag lang autark funktionieren können. Das ist für mich absolut unbrauchbar.

Ich vermute mal, dass sich die Telefonwelt somit in zwei Teile spaltet. Zum einen die alleskönnenden Smartphones mit normiertem Ladestecker und superkurzer Akkulaufzeit. Zum anderen minimale Geräte mit akzeptabler Akkulaufzeit und proprietärem Ladestecker (man muss die alten, schon produzierten Dinger doch noch irgendwie an den Mann bringen). Wie auch immer, alles unbrauchbar. Da werd ich mir wohl fast die Neuauflage des OpenMoko kaufen müssen. Wenn schon keine Akkulaufzeit, dann immerhin frei.

Wie schnell aus fiktiven Erfindungen Realität werden kann, sieht man mal wieder an diesem geekigen Accessoire wie dem Airbag für den Kopf. Kürzlich habe ich das Buch Snow Crash gelesen, worin der Author das genau gleiche Prinzip beschreibt. Im Buch wird der Airbag zwar nicht wie in der realen Erfindung von Velofahrern sondern von skateboardfahrenden Kurieren getragen. Aber letztendlich ist das Funktionsprinzip identisch.

Geekig ist das Ding nicht nur, weil es per USB aufladbar ist. Allerdings bleib ich bei meinem guten, alten Velohelm, denn der hat den Vorteil, dass nicht genau dann, wenn man auf die Schnauze fliegt, die Batterie zufällig leer ist.

Neulich bin ich mal gefragt worden, wie ich Backups mache. Die Antwort: Mit einem relativ simplen Cron-Skript und rdiff-backup per SSH auf den Fileserver. Das gibt ein schönes inkrementelles Backup, bei dem man beliebig weit zurückgehen kann, allerdings behalte ich nur die Daten der letzten zwei Monate. Rdiff-Backup braucht relativ wenig Rechenleistung, Bandbreite und Speicherplatz und funktioniert auch hervorragend über's Internet. Wird das Cron-Skript häufig genug aufgerufen, emuliert dieses Backup recht gut das Verhalten von Apples Time-Machine. Nachteilig ist lediglich, dass es in meinem Fall ein vom Clienten initiiertes Backup ist. Solange der zu sichernde Rechner die Daten auf den Backup-Server schreibt, ist ein Backup nicht sicher vor Manipulationen. Besser wäre es, wenn der Server vom Clienten lesen würde. Nur bräuchte der Server dann root-Login auf dem Clienten, was auch nicht unbedingt der Sicherheit förderlich ist...

Folgendes muss man auf dem Server einrichten:

• SSH-User für's Backup
• Im $HOME/.ssh/authorized_keys die public-SSH-Keys des root-Users der zu sichernden Systeme eintragen (ja, das Backup-Skript wird in der Regel als root laufen, da man z.B. auch /etc sichern will).
• Im Verzeichnis, welches die Backups enthalten soll, muss für jeden zu sichernden Rechner ein Verzeichnis erstellt werden, das so heisst, wie der Host (zu erfahren durch Eingabe von "hostname" auf dem Client)
• In diesen Verzeichnissen muss jeweils eine Verzeichnisstruktur erstellt werden, welche der $DIRECTORIES-Variable aus untenstehendem Skript entspricht.
• Zuletzt chownt man diese gesamte Struktur an den zuerst erstellen SSH-User.

Und so schaut mein Skript aus:

#!/bin/bash

### Settings ###
DIRECTORIES="/etc /home /usr/local/bin"
EXCLUDES="/home/*/.local/share/Trash"
SSHUSER="rdiff-backup"
SSHHOST="192.168.0.1"
REMOTEDIR="/mnt/backup/$(hostname)/"
RDIFF="/usr/bin/rdiff-backup"
RDIFFOPTIONS="ssh -p 2222 %s rdiff-backup --server"
FILEAGE="2M"

NOW=$(date +"%Y-%m-%d")
GZIP="$(which gzip)"
STATUSFILE="/var/tmp/rdiff-backup-status"
LOCKFILE="/var/lock/rdiff-backup-lock"
DUMPDIR="/home/backup"

if [ -e "$LOCKFILE" ]; then
echo "Lockfile exists, quitting..."
exit 255
fi

touch "$LOCKFILE"

### Packages List ###
dpkg --get-selections | $GZIP > $DUMPDIR/dpkg.$NOW.txt.gz
RETVAL=$(($RETVAL + $?))

### File based Backup ###
for DIR in $DIRECTORIES; do
EXCLUDESLIST=""
for EXCLUDE in $EXCLUDES; do
SIZE=$(expr match "$EXCLUDE" "$DIR")
if [ $SIZE -gt 0 ]; then
EXCLUDESLIST="$EXCLUDESLIST --exclude $EXCLUDE"
fi
done
$RDIFF $EXCLUDESLIST --remote-schema "$RDIFFOPTIONS" $DIR $SSHUSER@$SSHHOST::$REMOTEDIR/$DIR
RDIFFRETVAL=$?
RETVAL=$(($RETVAL + $RDIFFRETVAL))
if [ $RDIFFRETVAL = 0 ]; then
$RDIFF --force --remote-schema "$RDIFFOPTIONS" --remove-older-than $FILEAGE $SSHUSER@$SSHHOST::$REMOTEDIR/$DIR
RETVAL=$(($RETVAL + $?))
fi
done

find $DUMPDIR -ctime +7 -exec rm -f '{}' ';'
RETVAL=$(($RETVAL + $?))

echo $RETVAL > "$STATUSFILE"
rm -f "$LOCKFILE"
exit $RETVAL

Was bedeuten nun all die Variablen unter "Settings"?

• DIRECTORIES: Die zu sichernden Verzeichnisse.
• EXCLUDES: Nicht zu sichernde Verzeichnisse
• SSHUSER: Mit welchem User wird per SSH am Server angemeldet
• SSHHOST: Die Adresse des Backup-Servers. Entweder eine IP oder ein Hostname.
• REMOTEDIR: Das Basisverzeichnis, worin auf dem Server die Backups gespeichert werden.
• RDIFF: Pfad zum lokal rdiff-backup Binary
• RDIFFOPTIONS: Wenn man zusätzliche Optionen angeben will, z.B. einen alternativen SSH-Port. Kann man auch leer lassen
• FILEAGE: Nach wie vielen Tagen/Monaten/Jahren die Inkremente gelöscht werden sollen

Video- / Foto- und Tonaufnahmen
Foto-, Bild-, Video- und Tonaufnahmen sind auf dem ganzen Konzertareal verboten. Vorschrift der auftretenden Künstler!

Ja genau. Herzlich willkommen im Zeitalter der Mobiltelefone mit integrierten Kameras ab fünf Megapixel Auflösung und optischem Zoom.

Aber Metallica hatten es ja noch nie so wirklich mit modernen elektronischen Medien.

Eins muss man dem Obsthändler lassen: Das Gerät hab ich am Mittwoch Abend abgegeben, Ersatzteile (d.h. ein neues Mainboard) waren damals nicht vor Ort und mussten erst in die Schweiz transportiert werden. Am Montag Morgen bekomm ich in aller Frühe den Anruf, dass das Gerät repariert sei. DAS nenn ich mal prompten Service. Ausserdem wurde wesentlich mehr als nur der bemängelte Schaden behoben, auch die Handballenablage wurde gleich mitrepariert. Da war nach fast drei Jahren Benutzung ein Splitter abgebrochen.

Bei meinem letzten Apfel-Supportfall war das völlig anders. Damals musste ich aber auch zum Servicepartner gehen, weil es zu dem Zeitpunkt noch keine Obstläden in der Schweiz gab. Bei diesem Servicepartner musste ich das gerade mal zwei Monate junge Gerät vier Wochen lang einlagern lassen, um das CD-Laufwerk zu ersetzen. Zum vereinbarten Abholtermin war das Gerät noch nicht fertig. Ausserdem war danach die Verriegelung des Akkus defekt.

Vor mir liegt grad ein angebissener Apfel mit akutem Wurmbefall und fauliger Stelle. Genau gesagt ist die Netzwerkschnittstelle defekt. Hardwaremässig defekt. Ich hab ja so minimale Grundkenntnisse in Computertechnik und wage zu behaupten, dass ich sowas relativ präzise bestimmen kann, wenn ich das Gerät in der Hand halte und ausgiebig testen darf.

Nun gut. Garantie ist da ja noch drauf, also kann man das auch einfach in die Reparatur geben. Einfach? Nicht bei amerikanischen Technologiesekten! Mein erster Versuch führte mich am Samstag in Richtung Obstgeschäft im nahegelegenen Einkaufszentrum. Der freundliche Verkäufer meinte dann ganz bestimmt, dass das nicht so einfach ginge, da müsse ich erst um eine Audienz beim nächsten verfügbaren Guru betteln. Der hätte dann um 15:20 gnädigerweise Zeit für mich. Blöd nur, jetzt ist grad 13:00 und zwei Stunden lang hab ich weder Zeit noch Lust rumzustehen. Er meinte dann, ich solle einfach vorher rasch anrufen und einen Termin ausmachen.

Na gut, neuer Versuch. Erst hab ich heute Morgen auf der Homepage nach einer Möglichkeit, einen Reparaturtermin zu vereinbaren gesucht. Das schlug fehl, also hab ich die aufgeführte Telefonnummer angerufen. Immerhin handelt es sich um ein Ortsgespräch, was für mich ohne Kostenfolge ist. Da werde ich zuerst mal ganz frech geduzt: "Wenn DU etwas über das hyperphänomenale-ultimativgeniale-allesübertrumpfende Eipätt wissen willst, dann mache DU einen Handstand und hüpfe DU viermal im Kreis herum." Danach habe ich es tatsächlich geschafft, einen Techniker ans Telefon zu bekommen. Dieser wollte natürlich erst noch ein paar Tests durchführen und kam nach ca 15 Minuten rumbasteln zum Schluss, dass ich das Gerät wohl wirklich am besten mal abgeben würde. Schön. Aaalso, betteln wir um Audienz. z.B. heute Nachmittag um 15:00 (nein, dann muss ich ja gar nicht arbeiten). Oder morgen Abend um 18:40 (hmmm, wie lange dauert das denn? Ach, das wissen Sie nicht... na gut, denn halt um 17:20 *grummel*).

Das hat man nun davon, wenn man sich in die Fänge einer Sekte gibt. Und vermutlich wird das dann 4 Wochen dauern, bis der Kram geflickt ist.

Zitat aus dem Tagi:

Zudem wird Skype auch in einige internetfähige Fernseher von Panasonic und LG integriert

Hurra, damit haben wir die komplette Hardware, die man für einen typisch Orwellschen Televisor braucht: Lautsprecher, Bildschirm, Kamera, Mikrophon, Internetanschluss. Von Skype-tauglichkeit in den Überwachungsmodus umschalten ist ja kein grosses Problem, da braucht man nur eine etwas aktualisierte Firmware. Die kann man sogar ohne Wissen des Besitzers installieren, wenn die Zeit dafür gekommen ist.

Und der tägliche One-Minute-Hate wird Billag-finanziert in alle Haushalte übertragen, sobald in jedem Haushalt so ein Gerät steht. Und wer keins hat, hat was zu verbergen und ist somit automatisch verdächtig.

Ich hab mir als neustes Spielzeug ein Shuttle X50 als Mediacenter gekauft. Dabei handelt es sich um ein All-In-One Gerät, sprich einen Bildschirm, worin schon ein komplettes System integriert ist. Als Clou hat das Ding einen Touchscreen. Mein Plan dahinter: Das soll ohne Maus und Tastatur laufen und nur über den Touchscreen gesteuert werden. Die Wahl fiel auf dieses Gerät und nicht den EeeTop, weil der zweiterer nur schlecht verfügbar ist und die schlechtere CPU verbaut hat. Noch bin ich mit der Konfiguration des Geräts nicht komplett fertig, aber hier mal ein kleiner Bericht:

Die Hardware ist ganz passabel für die Medienwiedergabe geeignet. Der Bildschirm hat 15" und 1388x768 Bildpunkte, was dem billigen "HD Ready" entspricht. Als CPU ist ein Zweikern-Atom verbaut, wodurch die Leistung natürlich stark begrenzt ist. 2GB RAM ist mehr als üppig. Die Festplatte mit 160GB ist übergross, da sowieso alle Daten auf dem Server liegen. Aufgrund ihrer mangelhaften Performance werd ich die auch mal gegen eine SSD austauschen, sobald die Dinger erschwinglich werden. Die Festplatte wird auch ordentlich warm, üblicherweise zwischen 48°C und 53°C. Anschlüsse sind ausreichend vorhanden, zumindest 5x USB, Cardreader, Sound (Line Out, Line In, Mic In), Gigabit-Netzwerk, VGA und WLAN ist alles, was ich an so einem Gerät je brauchen werd. Webcam gibt's auch noch, die läuft auch unter Linux. Bluetooth gibt's nicht, wozu auch? Die mickrigen 2W Boxen sind leider viel zu schwach, bei dem Geflüstere kommt keine Stimmung auf. Das Netzteil ist ein Laptop-Netzteil, leider wurde da nur ein Kabel Schuko-Stecker mitgeliefert (der Händler hat wohl das schweizer Kabel vergessen), so dass ich hier erst einen lokalen 3-Pol-Stecker ranschrauben musste.

Das Gerät ist zum Glück frei von Microsoft-Steuer verfügbar, also kann man da grad auf einer jungfräulichen Festplatte ein Linux nach Wahl installieren. Meine erste Wahl fiel auf Debian, womit leider der Touchscreen nicht in Betrieb zu nehmen war. Ein drücken auf den Monitor liess die Maus entweder unkoordiniert rumschwirren (Lenny) oder bewegte gar nichts (Squeeze/Sid). Also hab ich den krüppligen Koala installiert (daher auch in einem der vorhergehenden Beiträgen der Kommentar zur nervigen USB-Startmedien-Erstellung). Derzeit ist die 32Bit-Variante drauf, allerdings ist die CPU tatsächlich 64Bittig, so dass hier noch eine Neuinstallation fällig wird. Mit Ubuntu funktioniert eigentlich alles, nur der Touchscreen von eGalax brauchte nach Installation von xserver-xorg-input-evtouch noch etwas Grob- und Feintuning: Erstens war die X-Achse verkehrt, so dass eine Bewegung von links nach rechts den Mauszeiger von rechts nach links bewegen liess. Und zweitens konnten die äussersten 5cm des Bildschirms nicht erreicht werden. Dafür gibt's ja Kalibrierungstools. Leider funktionieren die überhaupt nicht. Also muss man hier von Hand rangehen. Dazu müssen zunächst allfällige Kalibrierungsinformationen des evtouch-Treibers gelöscht werden, diese sind unter /etc/evtouch/ abgelegt. Anschliessend kann man von Hand anfangen die HAL-Informationen zu erraten. Ja, eigentlich sollte der krüpplige Koala ja HAL durch DeviceKit und udev ersetzen, dennoch läuft noch der HAL-Daemon mit.

Für die HAL-Rekonfiguration sollte die Datei /usr/share/hal/fdi/policy/20thirdparty/50-eGalax.fdi nach /etc/hal/fdi/policy/ kopiert werden, danach bearbeitet man die Kopie in /etc. In einem ersten Schritt müssen nun die Werte für minx und maxx ausgetauscht werden, damit die X-Achse korrigiert ist. Anschliessend kann man die Werte für minx, miny, maxx und maxy so lange anpassen, bis der Touchscreen halbwegs passabel funktioniert. In meinem Fall schauen die betreffenden Zeilen so aus:

<merge key="input.x11_options.minx" type="string">3490</merge>
<merge key="input.x11_options.miny" type="string">750</merge>
<merge key="input.x11_options.maxx" type="string">520</merge>
<merge key="input.x11_options.maxy" type="string">3150</merge>

Damit bin ich vorerst zufrieden, auch wenn ich bei Gelegenheit wohl nochmals daran fummeln werde. In einigen Reviews habe ich gelesen, dass der Touchscreen nervig langsam sei, das kann ich auf jeden Fall nicht bestätigen. Theoretisch würde er wohl auch Multitouch beherrschen (klickt man an zwei unterschiedlichen Stellen, so geht der Cursor in die Mitte davon), allerdings kann der Treiber nicht mal Drag n' Drop, daher kann man da vorerst nur abwarten.

Als Mediacenter sollte da eigentlich auch eine dedizierte Mediacenter-Software drauf. Leider bin ich hier noch nicht fündig geworden. Das Ubuntuusers-Wiki hat zwar eine schöne Auflistung an passender Software, aber überzeugen konnte mich bislang nichts davon. Mediacenter-Software ist üblicherweise auf die Steuerung per Fernbedienung (welche Tastatursignale sendet) ausgelegt. Etwas, das sich nur per Maus-Linksklick bedienen lässt, habe ich so noch nicht gefunden. Lediglich XBMC habe ich allerdings noch nicht testen können, das schmiert bei mir grad ab.

Meine Lösung lautet nun wie folgt: Netbook-Launcher als Starter für Programme und Mediendateien, als Player wird Totem (das Standardprogramm von Gnome) verwendet. Nautilus wurde so konfiguriert, dass Verzeichnisse und Dateien per Singleklick geöffnet werden. Damit ist das System schon ziemlich gut per reinem Linksklick steuerbar. Für input-intensivere Aufgaben kann ich immer noch per SSH oder VNC drauf zugreifen.

Natürlich fehlt für ein vollwertiges Mediacenter noch ein Punkt: Ein Möglichkeit um DVDs abspielen zu können. Diese habe ich leider noch nicht gefunden. Klar, ich könnte mir einfach ein externes Gerät kaufen. Aber das würde einerseits den "ich schlepp nur Monitor und Netzteil"-Gedanken ruinieren, andererseits hab ich ja schon mehrere DVD-Laufwerke in damit vernetzten Geräten verbaut. Also muss irgendwie ein Blockdevice über das Netzwerk transportiert werden. Leider fallen iSCSI, ATA-Over-Ethernet und Network Block Device aus, da diese allesamt nicht mit optischen Laufwerken umgehen können. enbd soll es angeblich können, aber dafür wollen erst mal Kompilierorgien vorgenommen werden (ja, seit Ubuntu bin ich irgendwie schon faul und verwöhnt geworden... Damals unter Gentoo hätt ich bestenfalls mit den Schultern gezuckt.). Den Feinschliff mit der DVD-Wiedergabe tu ich mir folglich ein anderes Mal an.

In einer der letzten Ausgaben des Linux-Magazins war ein Artikel über Fileserver und iSCSI drin. iSCSI ist ein Protokoll, welches SCSI-Befehle über TCP transportiert. Man kann damit also Massenspeicher übers Netzwerk verwenden. Eine sehr interessante Sache. Leider ist der Linux-Magazin-Artikel ausgesprochen unvollständig und geht nur auf die Clientseite ein. Wie also bau ich meinen eigenen iSCSI-Server?

Das Gentoo-Wiki hilft hier mal wieder mit einer simplen Anleitung aus der Patsche. Nun gilt es nur noch, diese auf Debian/Ubuntu anzupassen. Mein iSCSI-Target (Server) läuft auf Debian Lenny, da braucht's folgende Pakete:

aptitude install iscsitarget iscsitarget-modules-$(uname -r)

Danach wird die zu exportierende Festplatte in der Datei /etc/ietd.conf definiert:

Target iqn.2009-05.com.example.debianhost:storage.disk1
Lun 0 Path=/dev/hda,Type=fileio
MaxConnections 1

Und anschliessend der Dienst gestartet:

sed 's/false/true/' -i /etc/default/iscsitarget
/etc/init.d/iscsitarget start

Auf der Clientseite braucht's nur die Installation des Pakets open-iscsi sowie dessen Anpassung. Die Datei /etc/iscsi/initiatorname.iscsi bekommt folgenden Inhalt:

InitiatorName=iqn.2009-05.com.example.debianhost:storage.disk1

Ausserdem wird das zu benutzende Netzwerk-Interface definiert:

ifconfig eth0
iscsiadm -m iface -I iface0 --op=new
iscsiadm -m iface -I iface0 --op=update -n iface.hwaddress -v xx:xx:xx:xx:xx:xx

Danach wird open-iscsi gestartet mittels

/etc/init.d/open-iscsi start

Nun kann man nach Targets suchen, sie einbinden, mounten, nutzen, wieder aushängen... wofür man es halt auch immer nutzen will:

iscsiadm -m discovery -t st -p 192.168.0.6 -P 1
iscsiadm -m node -T iqn.2009-05.com.example.debianhost:storage.disk1 -l
mount /dev/sdc1 /mnt
umount /mnt
iscsiadm -m node -T iqn.2009-05.com.example.debianhost:storage.disk1 -u

Coole Sache, da muss ich auf jeden Fall noch weiter mit rumspielen Insbesondere, da man damit nicht nur SCSI-Geräte übers Netz transportieren kann, wieder Name vielleicht suggeriert. In der Tat habe ich meinen ersten Gehversuch mit einer ganz normalen IDE-Platte gemacht (erkennbar an der Freigabe des Geräts /dev/hda). Das funktioniert also wirklich mit allen Blockgeräten. Sehr cool

Wofür ich das nun abseits eines Servers brauchen könnte? Nun, z.B. kann ich eine DVD ins Laufwerk meines Desktop-Rechners legen und sie dann über WLAN auf meinem Netbook abspielen (sofern die Bandbreite ausreicht... was noch zu testen wäre).

Mein Server ist zwar noch keine zwei Jahre alt, aber dass PCs in ein ausgesprochenes Trötzelalter geraten können, war mir noch nie so bewusst wie heute: Erneut ist mir eine Festplatte ausgestiegen (diese verdammten Seagates!!! Sobald die 2TB-Generation da ist, steig ich wieder auf Samsung um!). Na gut, kein Problem, ist ja alles RAID-1. Also Platte raus. Ein Plattenwechsel bedeutet aber: Runterfahren, rausnehmen, hochfahren.

Hmmm... OK! Bei der Gelegenheit kann ich ja grad noch ein Kernel-Update machen und die Netzwerk-Konfiguration anpassen. Ich möchte ein gebridgtes OpenVPN einsetzen, wofür ich also mein lokales Netzwerkinterface in eine Bridge integrieren muss. Unter Gentoo an sich kein Problem, die genaue Vorgehensweise steht in der /etc/conf.d/net.example drin. Diese wurde rasch angepasst, während der neue Kernel (2.6.29.2, bislang lief 2.6.29.1, ergo ein an sich gefahrloses Minor-Update) durchkompiliert wurde.

Danach wurde die Kiste runtergefahren, Platte rausgenommen, wieder hochgefahren, angepingt, nie Antwort erhalten. Jaaa, man kennt das ja, bestimmt hab ich mich irgendwo in der Netzwerk-Konfiguration vertippt. Also Monitor und Tastatur angeschlossen und ans lokale Debuggen gemacht. Und da zeigen sowohl brctl wie auch ifconfig, ebenso die Link-Status-LEDs an Netzwerkkarte und Switch, dass alles in bester Ordnung sei. Dennoch geht gar nix über br0 raus. Na schön, die Bridge wieder abgerissen und die Netzwerkschnittstelle normal betrieben. Immer noch tot. Na gut, da wird wohl zufällig die Onboard-Netzwerkkarte der Platte über den Jordan gefolgt sein. Aber das ist kein Problem, 100MBit-Karten hab ich wie Sand am Meer rumliegen. Eingebaut, hochgefahren, konfiguriert. Und wen wundert's? Natürlich ging kein Mucks raus über die Karte. Aber der Switch sagt: "doch, doch, ich hab ne 100MBit-Verbindung". Langsam wurde ich ärgerlich. Könnt's an Switch oder Kabel liegen? Folglich hab ich meinen Laptop geholt und anstelle des Servers angeschlossen. Die Infrastruktur zeigte nach kurzem Test ihre absolute Funktionstüchtigkeit. Also hab ich ein faules Ei von Ersatzkarte erwischt? Man weiss ja nie, folglich nächste Karte rein. Test natürlich negativ. Hmmm, OK, nächste Karte? Negativ. Karte in anderen PCI-Slot? Negativ. Nochmals die interne Karte? Heee, hoppla, geht wieder? WTF??? Bridge-Konfiguration? Na einwandfrei. Nach einem Reboot? Einwandfrei.

So ganz nebenbei bemerkt: Das WAN-Interface zum ADSL-Router funktionierte die ganze Zeit ohne zu mucken.

Na wie auch immer: Ich hab jetzt eine Stunde lang sinnlos rumgebastelt um ein durch den Computer selbständig generiertes Problem zu beheben, das sich ebenso selbständig gelöst hat, wie es entstanden ist. Arschloch-PC. Scheiss Trötzelkind (das Drecksding hat bei mir einen akuten Anfall von Koprolalie hervorgerufen). Nächstes Mal fliegt er echt zum Fenster raus!

Zumindest hat man mir das beigebracht.

Bis heute hab ich das auch irgendwie geglaubt.

Dann hat mein Benq FP71E+ im wahnsinnigen Technik-Greisenalter von 37 Monaten und 3 Wochen angefangen rumzuzicken. Detail am Rande: Die Garantiedauer beträgt selbstverständlich 36 Monate. Das Problem äussert sich dadurch, dass beim Einschalten das Herstellerlogo kurz angezeigt wird (beim Einschalten des PCs evtl auch noch kurz der BIOS-Bildschirm), aber dann wird die Anzeige sofort rabenschwarz. Etwas Recherche brachte mich zu einem Forenbeitrag, wo genau mein Problem samt Lösung beschrieben wird. Und die ist:

Einfach obendrauf hauen und nochmals anschalten.

Ich hab's ausprobiert, und siehe da: Er geht tatsächlich wieder. Mal schauen, für wie lange. 17" wird mir sowieso so langsam zu klein.

Apache ist ein äusserst exponierter Dienst. Grad auf Servern mit vielen Seiten und zahlreichen PHP-Skripten ist das durchaus die grösste Bedrohung für die Serversicherheit. Daher empfiehlt es sich, der Absicherung von Apache besonders viel Aufmerksamkeit zukommen zu lassen. Eine wichtige Methode der Absicherung ist das chroot, in dem der Apache in ein Unterverzeichnis des Systems gesperrt wird. Gelingt ein Angriff auf ein Webskript, so sind für den Angreifer noch immer weitere Hürden in den Weg gelegt, bevor er sich im System einnisten kann.

Relativ einfach lässt sich ein chroot mittels mod_chroot einrichten. Es gibt auch unzählige Howtos im Internet. Aber leider kein einziges brauchbares. Apache ins chroot sperren ist an sich keine Sache. Die nötigen Pakete installieren, dann noch zwei Konfigurationseinträge vornehmen und gut. Gut? Nein! Denn damit geht eigentlich gar nichts mehr, ausser der Auslieferung statischer Webseiten und ein Bisschen Basis-PHP. Email? Tot! ImageMagick? Tot! Das muss nicht sein. Daher mein Howto für Apache mit mod_chroot, mod_php5, suhosin und PHP im safe_mode:

Zuerst müssen die nötigen Pakete installiert werden:

aptitude install apache2 libapache2-mod-chroot libapache2-mod-php5 php5-suhosin php5-imagick imagemagick dash msttcorefonts

Weitere PHP-Module können nach Bedarf installiert werden, wie z.B. php5-gd php5-imap php5-ldap php5-mcrypt php5-mysql. Vorsicht ist bei suhosin geboten, einige grössere PHP-Applikationen bekommen dadurch Probleme. Entsprechende Workarounds müssen dann per individueller Konfiguration eingebaut werden. Die meisten wichtigeren Applikationen haben in ihrer Hilfe oder im Supportbereich entsprechende Informationen.

Ein erster Härtungsschritt ist, dass Apache der Zugang zu einer Shell entzogen wird. Eine Shell ist nicht notwendig und nur ein weiterer potentieller Unsicherheitsfaktor. Also:

usermod -s /bin/false www-data

Nun müssen die Module aktiviert werden:

a2enmod mod_chroot && a2enmod php5

In der Datei /etc/apache2/apache2.conf muss folgende Zeile eingefügt werden:

ChrootDir /var/www

Als nächster Schritt wird das chroot gebaut. Das ist ein sehr langer und aufwändiger Prozess. Denn ins chroot müssen sämtliche ImageMagick-Binaries sowie ein SMTP-Server samt ihrer Abhängigkeiten kopiert werden. Ich hab das chroot wie schon bei Teamspeak mit den Thread Local Storage Bibliotheken gebaut. XEN-User sollten davon Abstand nehmen und die "normalen" Bibliotheken verwenden. Als Mini-Mailserver habe ich mich für esmtp entschieden, wer andere vorlieben hat, darf sich natürlich auch gerne ssmtp anschauen oder versuchen mini_sendmail zum Laufen zu überreden.

Mailer vorbereiten

Leider akzeptiert Debian nur die Installation eines MTA gleichzeitig. Da man als Systemmailer wohl lieber Postfix oder Exim einsetzt, muss hier etwas getrickst werden. Verwendet hier bitte für den Download der Pakete (auch wenn sie recht klein sind) den Debian Mirror EURER Wahl, damit sich die Last entsprechend verteilt. Ausserdem muss auf die Versionsnummer acht gegeben werden, die kann sich natürlich mit der Zeit ändern. .deb-Pakete sind mit dem Packer ar gepackt, dieser sollte standardmässig auf jedem Debian-System installiert sein.

mkdir ~/esmtp
cd ~/esmtp
wget http://mirror.switch.ch/ftp/mirror/debian/pool/main/e/esmtp/esmtp_0.5.1-4.1_i386.deb
wget http://mirror.switch.ch/ftp/mirror/debian/pool/main/libe/libesmtp/libesmtp5_1.0.4-2_i386.deb
ar xv esmtp_0.5.1-4.1_i386.deb
tar -zxf data.tar.gz
ar xv libesmtp5_1.0.4-2_i386.deb
tar -zxf data.tar.gz

Basis-Chroot bauen

Bei sämtlichen Befehlen, die nun folgen, wird davon ausgegangen, dass man sich im Verzeichnis /var/www befindet. Ist dem nicht so, so stimmen natürlich die relativen Pfade nicht mehr und das Howto schlägt fehl. Wie schon eingangs erwähnt, sollten XEN-User aus Performancegründen nicht die TLS-Bibliotheken verwenden.

cd /var/www
mkdir bin etc lib tmp usr
mkdir -p lib/tls/i686/cmov usr/lib/i686/cmov var/lib/php5 var/log/apache2 var/run
chown www-data:www-data tmp
chown www-data:www-data var/lib/php5
chown www-data:www-data var/log/apache2
chown www-data:www-data var/run
touch var/run/apache2.pid
ln -sf var/run/apache2.pid /var/run/apache2.pid
cp /bin/dash bin
cd bin
ln -sf dash sh
cd ..
cp /etc/mime.types etc
grep www-data /etc/passwd > etc/passwd
cp /lib/ld-linux.so.2 lib
cp /lib/libgcc_s.so.1 lib
cp /lib/libnss_dns.so.2 lib
cp /lib/tls/i686/cmov/libc.so.6 lib/tls/i686/cmov
cp /lib/tls/i686/cmov/libdl.so.2 lib/tls/i686/cmov
cp /lib/tls/i686/cmov/libpthread.so.0 lib/tls/i686/cmov
cp /lib/tls/i686/cmov/libresolv.so.2 lib/tls/i686/cmov
cp /usr/lib/libz.so.1 usr/lib
cp /usr/lib/i686/cmov/libcrypto.so.0.9.8 usr/lib/i686/cmov
cp /usr/lib/i686/cmov/libssl.so.0.9.8 usr/lib/i686/cmov

Dash wird als Shell mit minimalem Speicherbedarf installiert. Leider benötigt esmtp zwingend eine Shell, ansonsten verweigert er den Dienst. Dies ist natürlich ein klarer Sicherheitsmangel, der durch Workarounds wie safe_mode behoben werden muss.

Nun wird der Mailer ins chroot kopiert:

cp ~/esmtp/usr/bin/esmtp bin
cp -r ~/esmtp/usr/lib usr/lib

Und als nächstes wird der Mailer konfiguriert. Unter Annahme, dass auf dem Server z.B. ein Postfix oder Exim als Mailserver läuft, muss dazu die Datei /var/www/etc/esmtprc mit folgendem Inhalt erstellt werden:

hostname = 127.0.0.1:25
starttls = disabled

Ausserdem ist jetzt der Zeitpunkt gekommen, um PHP mitzuteilen, wie es mailen soll. Ausserdem kann man bei der Gelegenheit auch weitere Absicherungen vornehmen und z.B. den safe_mode einschalten. Dazu müssen ein paar Direktiven in der Datei /etc/php5/apache2/php.ini angepasst oder eingefügt werden. Beachte, dass die Shell in /bin liegt, während als safe_mode_exec_dir /usr/bin konfiguriert wird. PHP-Skripte können also nicht auf die Shell zugreifen.

safe_mode = On
safe_mode_exec_dir = /usr/bin
expose_php = Off
display_errors = Off
log_errors = On
sendmail_path = /bin/esmtp -t

ImageMagick und Schriften

Es müssen ein paar weitere Bibliotheken sowie die benötigten ImageMagick-Binaries ins chroot kopiert werden:

mkdir -p usr/lib/mime/packages/
mkdir usr/bin
cp /lib/tls/i686/cmov/libm.so.6 lib/tls/i686/cmov/
cp /usr/lib/libMagick.so.9 usr/lib/
cp /usr/lib/liblcms.so.1 usr/lib/
cp /usr/lib/libtiff.so.4 usr/lib/
cp /usr/lib/libjasper-1.701.so.1 usr/lib/
cp /usr/lib/libjpeg.so.62 usr/lib/
cp /usr/lib/libpng12.so.0 usr/lib/
cp /usr/lib/libXext.so.6 usr/lib/
cp /usr/lib/libXt.so.6 usr/lib/
cp /usr/lib/libSM.so.6 usr/lib/
cp /usr/lib/libICE.so.6 usr/lib/
cp /usr/lib/libX11.so.6 usr/lib/
cp /lib/libbz2.so.1.0 usr/lib/
cp /usr/lib/libxml2.so.2 usr/lib/
cp /usr/lib/libfreetype.so.6 usr/lib/
cp /lib/tls/i686/cmov/libdl.so.2 usr/lib/
cp /usr/lib/libXau.so.6 usr/lib/
cp /usr/lib/libXdmcp.so.6 usr/lib/
cp /usr/lib/mime/packages/imagemagick usr/lib/mime/packages
cp /usr/bin/animate usr/bin
cp /usr/bin/compare usr/bin
cp /usr/bin/composite usr/bin
cp /usr/bin/conjure usr/bin
cp /usr/bin/convert usr/bin
cp /usr/bin/display usr/bin
cp /usr/bin/identify usr/bin
cp /usr/bin/import usr/bin
cp /usr/bin/mogrify usr/bin
cp /usr/bin/montage usr/bin

Wer noch Schriften braucht, kann diese nach Bedarf installieren. Die Dateinamen der Schriftdateien müssen komplett in Kleinbuchstaben gehalten sein.

mkdir -p usr/share/fonts/truetype/msttcorefonts/
cp /usr/share/fonts/truetype/msttcorefonts/verdana.ttf usr/share/fonts/truetype/msttcorefonts/

DocumentRoot

Der Startvorgang des Apache verläuft in etwa folgendermassen:

1. Apache startet ausserhalb der chroot-Umgebung und wertet die Konfiguration in /etc/apache2 aus.
   
2. Apache schreibt sein PID in die vorgegebene pid-Datei
   
3. Apache prüft die Existenz der DocumentRoot-Verzeichnisse gemäss Konfiguration in den vhosts.
   
4. Apache öffnet die Logfiles gemäss Konfiguration in den vhosts.
   
5. Apache wechselt ins chroot.
   
6. Apache öffnet die Sockets.
   
7. Apache wechselt zu einem unpriviliegierten User.
   
8. Apache ist bereit. Sämtliche Anfragen werden nun im chroot bearbeitet. Die Ausführung von PHP-Skripten findet nun im chroot statt.

Folglich muss von den DocumentRoot-Verzeichnissen eine Schatteninstallation und eine Life-Installation vorgenommen werden. Wird in der Apache-Konfiguration z.B. die Direktive

DocumentRoot /var/www/htdocs/myhost

eingetragen, müssen folgende Verzeichnisse erstellt werden:

mkdir -p /var/www/htdocs/myhost
mkdir -p /var/www/var/www/htdocs/myhost

Effektiv arbeiten wird Apache dann mit dem Verzeichnis /var/www/var/www/htdocs/myhost, dorthin gehören folglich alle HTML-Dateien.

Apache starten, stoppen, neu laden

Jetzt kann man mal die ganze Sache testen und Apache starten. Ich habe festgestellt, dass mod_chroot leider die reload- und restart-Befehle zerschiesst. Folglich bleiben nur noch start und stop übrig. Um eine geänderte Konfiguration einzulesen, bleibt folglich leider keine andere Möglichkeit, als Apache erst zu stoppen und dann wieder zu starten. Bei stärker frequentierten Seiten freuen sich da vermutlich nicht alle User darüber. Sorry, aber dafür gibt's wohl keine Lösung.

/etc/init.d/apache2 start
/etc/init.d/apache2 stop

Nach einem Telefonat mit dem Support haben wir das USV geöffnet. Ein Feld der Zerstörung hat sich uns präsentiert:

Soll	Ist

Die Ursache liegt vermutlich an dauerhaft zu hoher Temperatur. Offensichtlich reicht die Klimaanlage in unserem Serverraum doch nicht aus.