planetknauer.net

Komische Welt bei Microsoft. Einen kleinen russischen Softwaretester mit mutmasslichen Verbindungen zum Geheimdienst schafft man aus. Aber dann gibt man quasi im gleichen Atemzug mal den Sourcecode von Windows 7 an den FSB weiter? Das versteh mal einer.

Ob diese Code-Weitergabe wohl Einfluss auf das künftige nationale Betriebssystem von Russland haben wird? Bislang hatte ich ja eher das Gefühl, dass dies einfach eine weitere Linux-Distribution werden soll. Gut möglich, dass es nun ein "Lindows-Reloaded" wird.

Ich bin ja nun schon mehrfach wie ein Mondkalb angeglotzt worden, weil ich tatsächlich noch richtige CDs kaufe und diese in ein ach so platzverschwendendes Regal stelle. Die Lösung wär doch gemäss meiner Gesprächspartner so einfach: Bei einer der grossen amerikanischen Firmen, deren Namen mit einem A beginnt die Musik zu günstigen Preisen in virtueller Form kaufen.

Nun gut. Das angebissene Obst kommt nicht in Frage, weil man dazu eine Software braucht, die nur und ausschliesslich unter proprietären Betriebssystemen funktioniert. Ausserdem ist deren Format AAC, womit mein alter ogg/mp3-Player definitiv nicht umgehen kann und ich mein aktuelles Smartphone nicht getestet habe.
Aber es gibt ja noch diese weibliche Kriegerin, die ebenfalls ein Download-Angebot hat und dabei sogar (patentbehaftete) mp3s anbietet. Von ihr hab ich neulich ein Mail bekommen, worin ein kostenloser Sampler zum Download angeboten wird. Na in dem Fall probieren wir die Sache doch mal aus! Für Albumdownloads bieten sie eine proprietäre Software an, welche es praktischerweise auch für Linux gibt. Zu den unterstützten Distributionen gehört z.B. Ubuntu 8.10, dessen Name schon andeutet, dass es 2 Jahre alt ist. Na gut, schauen wir doch mal, das das .deb unter Ubuntu 10.04 so macht:
gdebi meint nach Doppelklick in fett rot: "Fehler: Falsche Systemarchitektur »i386«" Oh! Ich hab ja ein 64bit System. Tjaaa, mal die Suchmaschine meines geringsten Misstrauens bemüht und bin sogleich auf eine Anleitung gestossen. Alles klar, ich brauch nur ein dubioses Skript laufen lassen und manuell ein paar veraltete Pakete installieren.

Und siehe da, danach läuft die Sache. Zumindest vorerst. Ob die Software dann auch unter Ubuntu 10.10 oder Debian 6 oder einem aktuellen Gentoo laufen wird, steht in den Sternen. Abgesehen davon, dass so Binärmüll auf meinem System sowieso nur wenig erwünscht ist.

Wie auch immer. Meine CD-Regale hab ich schon vor langer Zeit gekauft. Die Regalwand bietet derzeit auch noch etwasPlatz und wär auch relativ einfach erweiterbar. Daher bleib ich lieber weiterhin dabei, die Musik auf realen Scheiben zu kaufen und danach händisch in Ogg/Vorbis umzuwandeln. Das dauert zwar etwas länger, dafür weiss ich dann auch, was ich hab.

Heute gibt's wieder eine gnadenlos geniale Aussage eines abgespaceten Goggifroschs aus den USA:

Demnach soll man von Regierungsseite Open Source Software wie Piraterie behandeln.

sowie

Länder wie Indonesien, Kuba, Brasilien, Indien und viele mehr müssten demnach auf einer speziellen Risikoliste landen, weil sich deren Behörden für den Einsatz von freier Software aussprechen. Eigentlich definiert die "Special 301 watchlist", welche Länder der Erde gegen den Kapitalismus eingestellt sind.

Und äh ja, in diesem Fall ist natürlich alle Software auf diesem Server raubmordkinderschändnaziterrorkopiert, ebenso auf all meinen Rechnern zuhause, bei uns auf Arbeit, kurzum überall wo ich halt so meine Finger an eine Tastatur lege. Ich bin dann wohl Triebtäter und ich stehe dazu!!! Und dass ich zusätzlich ein Kommunistenschwein bin, hab ich ja schon lange befürchtet. Jetzt hab ich das sogar amtlich und mit Siegel. Auf in den Kampf, Genossen! Nieder mit dem Kapitalismus!

Na da haben unsere Volksvertreter (ihr wisst ja... Staugsaugervertreter, Versicherungsvertreter, Volksvertreter...) wieder einen schönen Bock geschossen. Betonung auf "geschossen". In Zukunft darf ich als angeblich mündiger Bürger also keine blutrünstigen Spiele mehr spielen. Aber dafür muss ich weiterhin einen echten Schiessprügel daheim im Schrank stehen haben? Na endlich mal Politkasper, die richtige Prioritäten bei der Sicherheit zu setzen wissen. Natürlich, gewalttätige Spiele gehören nicht in Kinderhände. Da ist genau dasselbe vorgehen wie bei Alkohol und Zigaretten angesagt. Aber Erwachsene zu bevormunden und Medien zensieren, das hat gar nichts mit der einst liberalen Grundgesinnung der Schweiz zu tun.

Eingebrockt hat uns diese Scheisse die angebliche Rechtskommission des Ständerats. Gut zu wissen, welche Clowns bei der nächsten Parlamentswahl bestimmt keine Stimme von mir bekommen werden. Schön finde ich ja auch, dass Killerspiele und Kinderfickerei grad in einem Satz genannt werden. Jaja, damit kann man dann mal gut Stimmenfang machen. Killerspieler sind Kinderficker! Wetten, dass das auch noch kommt?

A propos Ständerat: Das Parlament hat ja eine tolle Webseite. Man merkt da ganz deutlich, an welche Firma hier viel Kohle für nichts verpulvert wird. Der IIS kann scheinbar nicht mal saubere 302er-Statusmeldungen rausgeben. Da geb ich euch doch gerne einen Gutenrat: Setzt lieber auf Linux und nutzt die gewonnene Zeit um am Computer ein Bisschen zu spielen. Dann gewinnt Ihr vielleicht ein Minimum an Medienkompetenz. Und das durch wegfallende Lizenzkosten gesparte Geld könnt Ihr meinetwegen wieder irgend einer Bank hinten reinschieben oder ein paar reale Waffen für Ueli kaufen.

Nachdem ich mir mal wieder einen neuen Hirngrill besorgt hab, wollte ich dessen Daten natürlich bei Gelegenheit wieder auf den PC sichern. Programm der Wahl ist hierfür natürlich opensync. Als Übertragung würde sich zwar Bluetooth anbieten, was in einer theoretisch einfacheren Konfiguration von Opensync enden würde. Jedoch ist mir Bluetooth im Allgemeinen etwas zu fummelig. Daher bin ich ganz froh darüber, dass mein neues Gerät auch über USB synchronisiert werden kann. Das erfordert zwar eine etwas aufwändigere Konfiguration, dafür erhoffe ich mir davon längerfristig einfachere Ausführung des Synchronisationsvorgangs.

Eine ältere aber sehr gute Anleitung für ein anderes, vergleichbares Gerät habe ich ziemlich schnell gefunden. Daher an dieser Stelle nur ein kurzes Update für mein Modell:

Zur Programminstallation gilt eigentlich nur zu sagen, dass Ubuntu in der Geschmacksrichtung "Krüppliger Koala" schon alle Programme in den Standard-Repositories hat, ein einfaches

aptitude install multisync0.90 multisync-tools opensync-plugin-syncml opensyncutils opensync-plugin-file

reicht also schon (ggf noch weitere Plugins nach Bedarf hinzufügen).

Danach musste ich auch wieder eine handgefertige udev-Regel für den Zugriff als eingeschränkten Benutzer anlegen. Dies funktioniert analog zur verlinkten Anleitung, lediglich die Device-ID muss angepasst werden. lsusb meldet folgende Daten:

Bus 001 Device 006: ID 0421:0223 Nokia Mobile Phones

woraus sich folgende Regel ableiten lässt:

BUS=="usb", SYSFS{idVendor}=="0421",SYSFS{idProduct}=="0223",GROUP="plugdev",USER="lukas"

Das neue Upstart-System vom Koala erfordert einen etwas anderen Befehl zum Neustart von udev:

sudo service udev restart

anschliessend sollte das Gerät auch neu angestöpselt werden. Das Handy fragt dann auch nach dem Betriebsmodus, für die Synchronisation hab ich immer "PC Suite" angewählt. Damit funktioniert die Synchronisation problemlos, folglich habe ich auch keinen anderen Modus getestet. Der Befehl syncml-obex-client -u sollte nun genauere Geräteinformationen ausgeben. Nun lassen sich im multysync-GUI oder mit den opensync-Kommandozeilentools die Plugins konfigurieren. Diese sind relativ gut dokumentiert, wodurch sich auch die XML-Konfigurationsdateien sehr einfach den eigenen Bedürfnissen anpassen lassen.

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.

Mein Favorit unter den Bildbetrachtern ist geeqie, seines Zeichens selbsternannter lightweight Gtk+ based image viewer for Unix like operating systems. Nur: Wenn sich das Ding 200MB RAM krallt um ein 200kb Bild anzuzeigen, ist das nicht mehr unbedingt "lightweight" nach meiner Definition... Ein prima Programm bleibt's aber trotzdem. Na ja, wird wohl mal ein Bugreport fällig

...das Drecksvieh hat mir anscheinend automatisch ein rm /mnt -type f -exec rm -f '{};' ausgeführt... (für Leute ohne Shell-Kenntnis: Das löscht genau alle Dateien unterhalb des Verzeichnisses /mnt, lässt aber die Verzeichnisstruktur intakt). Dass Probleme mit ext4 und grossen Dateien bestehen, war bekannt. Nur: das waren je eine XFS und eine ext3 Partition. Woher das kommt? Keine Ahnung. Und nein, so doof, um solche Befehle auf meinem Rechner auszuführen, bin ich nun doch auch wieder nicht!

Ich hatte heut Morgen kurz ein System mit hoher Last und starker HD-Aktivität, wird wohl dann passiert sein. Ich hab gedacht, dass das wohl das Backup-Skript sei. Falsch gedacht, offensichtlich. Tatsächlich lief zu dem Zeitpunkt auch ein find-Prozess. Immerhin hab ich vor wenigen Wochen ein Backup auf externe HDs gezogen. Und was seither zur Musiksammlung dazugekommen ist, lässt sich wieder rippen.

Und was passiert mit dem Koala? So eine Scheisse krieg nicht mal Microsoft gebacken. Also einschläfern, würd ich meinen. Aber eiligst!

Sorry Canonical, aber Ubuntu 9.10 saugt wie ein Staubsauger. Seid Ihr von Microsoft unterwandert worden?

Probleme:

• Upgrades von der Vorversion sind immer noch ein Glücksspiel und Neuinstallation geht sowieso schneller.
• Pulseaudio vergisst nach dem Neustart die Lautstärke-Einstellungen, ausserdem gibt es standardmässig alles über mein Headset aus (trotz anderslautender Konfigurationsanweisung).
• Policykit bietet keine grafische Konfigurationsoberfläche mehr. Ist man z.B. noch in einer Konsole als root angemeldet, muss man erst sein Passwort eintippen, um runterzufahren. Als Alternative die Regeln über kaum dokumentierte Kommandozeilen-Tools zu hacken ist mir zu doof.
• Der Network-Manager muss erst von Hand neu gestartet werden, bevor OpenVPN-Verbindungen gestartet werden können.
• Statisch konfiguriertes Netzwerk über /etc/network/interfaces ist pöse geworden. Man muss dann z.B. mit leerer /etc/resolv.conf leben. Sehr witzig.
• Gnome-Shell ist ja ein total bescheuertes Konzept. Zum Glück ist das nur als "Preview" dabei und standardmässig nicht aktiviert. Aber wenn das je Standard werden sollte, wechsle ich sofort zu XFCE oder KDE
• Der USB-Startmendien-Ersteller ist ganz schön fummelig geworden. Unter 9.04 funktionierte der eindeutig besser.
• Grip ist verschwunden!!! Das ist ein richtiger Sargnagel! Einen besseren Ripper hab ich bislang nicht gefunden (ich kauf ja noch so antike Datenträger wie "Audio-CDs").

Alles andere lässt sich einigermassen gescheit hinbiegen. Ich bin trotzdem sehr unzufrieden. Da kann ich ja grad Windows Vista verwenden.

... denn das Spiel soll ja richtig gut gelungen sein.

Nur hält mich die Aussicht darauf, dass ich erst ein mittleres Vermögen für die Spielkonsole eines entweder pestilenten oder choleraischen Herstellers ausgeben soll, doch stark vom Kaufrausch ab. Bis endlich eine unter Linux lauffähige Version veröffentlicht wird, bin ich wohl eh alt und grau und hör nur noch volkstümlichen Schlager.

Tja, wieder einmal zeigt sich, wieso freie und offene Standards genutzt werden sollten: ICQ hat mal wieder das Protokoll geändert und freie Clients bleiben ausgeschlossen. Zumindest Pidgin kommt derzeit nur in der allerneusten Version rein. Zum Glück wird die von Debian Sid schon ausgeliefert. Ubuntu weiss noch von nichts. Irgendwie peinlich.

Trotzdem zeigt das wieder, weshalb man freie und offene Standards wie z.B. XMPP nutzen sollte. Denn nur so kann der Datenaustausch garantiert werden. Ausserdem muss man sich nicht mit anwenderfeindlichen Nutzungsbedingungen rumschlagen. Bei proprietären Protokollen wie ICQ und Skype rufe ich daher per sofort ein Kontakte-Moratorium aus. Wer neu mit mir kommunizieren will, muss XMPP (Jabber, Google Talk, GMX Messenger, etc pp) haben. Punkt.

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

Ich weiss ja echt nicht, was die PHP-Entwickler geritten hat, als sie ihre Anbindung an LDAP zusammengefrickelt (oh ja!) haben:

Wenn Daten aus dem LDAP-Verzeichnis ausgelesen werden, erfolgt die Rückgabe als Array. Sämtliche Keys des Arrays sind in Kleinbuchstaben geschrieben. Möchte man aber Daten ins LDAP-Verzeichnis schreiben, müssen die Array-Keys Gross-/Kleinschreibung berücksichtigen. Und nur die wenigsten Keys sollten dann reine Kleinbuchstabenketten sein.

Die Fehlermeldungen sind absolut nichtssagend und teilweise falsch. Wenn PHP rumschreit "Value array must have consecutive indices 0, 1,", dann muss das mitnichten bedeuten, dass die Indices nicht konsekutiv sind. Es kann auch einfach heissen, dass die Array-Keys nicht die Gross-/Kleinschreibeordnung einhalten. Es kann aber auch sein, dass ein Array-Feld leer ist.

Oder ganz kurz gesagt: AAAAAAAAAAAAAAAARGH!!!

Teamspeak ist böse. Es ist proprietär, die letzte Version des Servers ist ein uralter RC und es ist komisch in der Konfiguration. Nun, was macht man mit sowas kriminellem? Na klar, einsperren! z.B. in einem chroot. Wie das bei mir funktioniert hat, erkläre ich hier:

Ein kurzes Suchen mit der Suchmaschine meines geringsten Misstrauens hat mich zu einer bereits sehr guten Anleitung geführt, welche ich mit leichten Modifikationen übernehmen konnte. Ich musste zum einen das Startskript etwas anpassen, zum anderen verwendet mein System standardmässig die TLS (Thread Local Storage) Bibliotheken der glibc. Für XEN-User ist dieser Hinweis insofern wichtig, als dass man diese Bibliotheken unter XEN aus Performancegründen nicht nutzen sollte. Auf einem XEN-System sind diese daher standardmässig nicht installiert. Da ist folglich ein Vorgehen gemäss der Originalanleitung zu empfehlen.

Ich bin so vorgegangen:
Erst werden die Verzeichnisse erstellt, ein Benutzer angelegt und Teamspeak entpackt. Danach werden die Berechtigungen angepasst. Leider konnte ich es Teamspeak nicht austreiben, in seinem Installationsverzeichnis Schreibrechte zu fordern (ein weiterer guter Grund für ein chroot).

mkdir /opt/teamspeak
cd /opt/teamspeak
tar -jxf ts2_server*.tar.bz2
useradd teamspeak -d /opt/teamspeak -s /bin/false
chown -R teamspeak:teamspeak tss2_rc2
chown root:root tss2_rc2/server_linux
chown root:root tss2_rc2/*.so

Nun werden die benötigten Bibliotheken ins chroot kopiert. Mittels ldd /opt/teamspeak/tss2_rc2/server_linux und ldd /opt/teamspeak/tss2_rc2/*.so lassen sich diese leicht bestimmen. Teamspeak fordert ebenfalls Zugriff auf /dev/null, was insofern blöd ist, dass man nun Teamspeak nicht auf einer Partition installieren kann, welche mit der Option "nodev" gemountet wurde:

mkdir etc dev lib tmp
mkdir -p usr/lib/gconv usr/lib/locale /lib/tls/i686/cmov var/run
grep teamspeak /etc/passwd > etc/passwd
grep teamspeak /etc/group > etc/group
cp /etc/localtime etc
cp /lib/ld-linux.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/libncurses.so.5 lib
cp /lib/libgcc_s.so.1 lib
cp /usr/lib/gconv/ISO8859-15.so usr/lib/gconv
cp /usr/lib/gconv/gconv-modules usr/lib/gconv
cp /usr/lib/locale/locale-archive usr/lib/locale/
mknod -m666 dev/null c 1 3

nano /etc/init.d/teamspeak

Der letzte Befehl startet einen Editor, mit welchem das Startskript erstellt wird. Im von mir verwendeten Editor nano lassen sich Dateien durch Eingabe von ctrl+o speichern und der Editor sich durch ctrl+w beenden. Meine grundlegende Änderung im Startskript gegenüber der Vorlage ist ein Wechsel ins Teamspeak-Verzeichnis. Dieser erwies sich als notwendig, damit Teamspeak überhaupt startet. Ausserdem habe ich nur die start und stop Parameter implementiert, den Rest brauche ich eigentlich nicht.

#! /bin/sh
CHROOT_DIR=/opt/teamspeak
EXECDIR=/tss2_rc2
USER=teamspeak
GROUP=teamspeak

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:${CHROOT_DIR}
EXEC=${EXECDIR}/server_linux
DAEMON=${EXEC}
NAME=tss2
DESC="TeamSpeak 2 Server"
PIDFILE=${EXECDIR}/server.pid
test -x ${CHROOT_DIR}${DAEMON} || exit 0

set -e

case "$1" in
start)
echo "Starting $DESC: $NAME"
start-stop-daemon --start --quiet --pidfile $PIDFILE \
--chuid $USER:$GROUP \
--chroot ${CHROOT_DIR} \
--startas $EXEC \
--chdir ${EXECDIR}
echo "."
;;
stop)
echo -n "Stopping $DESC: $NAME "
start-stop-daemon --stop --quiet --pidfile ${CHROOT_DIR}$PIDFILE \
--exec ${CHROOT_DIR}$DAEMON
echo "."
;;
esac

Das war's auch schon. Jetzt muss Teamspeak nur noch gestartet werden. Ausserdem kann man bei dieser Gelegenheit auch noch elegant die generierten Admin-Passwörter auslesen:

chmod a+x /etc/init.d/teamspeak
/etc/init.d/teamspeak start
update-rc.d teamspeak defaults 95
grep "admin account" tss2_rc2/server.log

So toll VMWare Server ist, manchmal ist er echt störrisch. In diesem Fall wollten die Uhren der Gastsysteme schlicht nicht synchron bleiben. Mal waren sie massiv zu langsam, dann wieder viel zu schnell. Und alle Gäste waren unterschiedlich schnell. Das Problem ist allerdings nicht selten, entsprechen ist das Internet voll mit Lösungsansätzen.

In meinem Fall war die Clock Drift aber so mühsam, dass ein ganzer Massnahmenkatalog nötig war, der als "Best Of The Web" durchgehen kann:

1. Installation der VMWare Tools
2. Deaktivieren des CPU Frequency Scaling beim Hostsystem
3. Übergabe von Bootparametern an die Kernel der Gastsysteme: clocksource=pit nosmp noapic. Ersterer bremst zu schnelle, die anderen beschleunigen zu langsame Uhren. Es gäbe noch nolapic, aber damit wollten meine Gäste nicht mehr starten.
4. Manipulation der .vmx-Dateien aller Gäste. Es mussten folgende Parameter angefügt werden:

tools.syncTime = "TRUE"
host.cpukHz = "2200000"
host.noTSC = "TRUE"
ptsc.noTSC = "TRUE"
hostinfo.noTSC = "TRUE"
timeTracker.periodicStats = "TRUE"
timeTracker.statsIntercal = "10"

Aber jetzt scheint die Sache endlich solide zu laufen. Hat ja nur 6h und 100 Reboots gedauert, das Problem zu lösen...