planetknauer.net

Da mein krüppliger Koala immer noch nach dem Booten etwas gar schweigsam ist und die Entwickler bislang kein Update zur Verfügung gestellt haben, hab ich halt einen Würgaround gebastelt:

Erstelle ein Skript /usr/local/bin/unmute.sh mit Berechtigung +x mit folgenden Inhalt und füge es zum Gnome-Session-Management als Autostart-Programm hinzu

#!/bin/sh
pactl set-sink-mute 1 0
pactl set-sink-volume 1 35000
pactl set-sink-mute 0 0
pactl set-sink-volume 0 35000

Das setzt die Ausgabelautstärke auf beiden Soundkarten auf 53%. Keine Ahnung, wieso 35000 53% entspricht.

...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.

Oh wie geil! Microsoft sponsert Windows 7 Parties. Lade ein paar Kumpels an, sauf dir Mut an und installier Windows. Will man so eine Party veranstalten, gibt's so eine komische Sonderedition zu gewinnen.

Da die Party zwischen dem 22. und 29. Oktober stattfinden soll, hab ich auch schon eine Idee. Da Ubuntu 9.10 am 29. Oktober veröffentlicht werden soll, werd ich an dem Tag Windows-Release-Party machen. Erst gibt's einen Linux-Install-Event, bei dem jedem Gast ein Ubuntu 9.10 installiert wird. Anschliessend wird als grosses Highlight die Windows 7 CD geshreddert und die Handbücher feierlich verbrannt (Pyroshow!!!).

Folglich: Gleich mal bewerben

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!

Seit kurzem hab ich den Bedarf, gewissen Netzwerkverkehr über ein VPN zu tunneln. Da die direkte Anbindung aber wesentlich schneller ist als die Anbindung des VPN-Servers, wäre es eine eher mässig produktive Massnahme, einfach allen Verkehr übers VPN laufen zu lassen. Aber unter Linux sind auch anspruchsvolle Routinglösungen genial einfach. Alles, was man so benötigt, hat man in der Regel standardmässig dabei, nämlich die Tools iptables und ip. Mittels iptables werden die umzuroutenden Pakete identifiziert und markiert, mittels ip wird eine Routing-Regel und ein Routing-Tabelleneintrag erstellt. Wirklich total simpel:

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
TCP_PORTS="993 5222"
for PORT in $TCP_PORTS; do
iptables -t mangle -A OUTPUT -p tcp --dport $PORT -j MARK --set-mark 1
done

In diesem Fall werden einfach alle Pakete markiert, welche an einen bestimmten TCP-Port gesendet werden. Bei Bedarf können natürlich problemlos weitere Regeln (auch für UDP, ICMP oder bestimmte Zieladressen) gesetzt werden. Iptables setzt der Kreativität eigentlich keine Grenzen. Damit auch die Antworten eintreffen, müssen die Pakete geNATet werden. Nun benötigt man noch eine passende Routenkonfiguration:

ip rule add fwmark 1 table 1
ip route add default dev tun0 table 1
ip route flush cache

Sollte der VPN-Tunnel mal zusammenbrechen, muss einfachh nach dem Wiederaufbau der VPN-Verbindung die Route nochmals neu gesetzt und der Puffer nochmals geleert werden. Das war's.

Ich hab mir ein neues Spielzeug besorgt. Nachdem endlich der eeepc 901 in schwarz und ohne Microsoft-Steuer nicht nur "anderswo" sondern tatsächlich auch im IT-Drittweltland Schweiz verfügbar ist, habe ich natürlich sofort zugegriffen. Danach musste als erstes das Xandros-Verräterlinux runter. Stattdessen läuft nun ein Debian Sid mit nur freier Software.

Die 16GB SSD habe ich komplett verschlüsselt. Die Installation war drum etwas knifflig da der Debian EEE Installer das nicht von Haus aus beherrscht und ich drum eine normale Installation mit Ergänzungen gemäss Anleitung vornehmen musste.

Die Hardware ist ganz OK. Die SSD überzeugt mit ihrer Geschwindigkeit. Um sie zu schonen habe ich sämtliche Tricks von meiner Xubuntu-Stick-Installation vorgenommen, das Debian-Wiki hält auch noch ein paar Tricks parat. Zum Surfen ist die CPU passabel schnell. Der Akku hält auch lange genug. Einzig das kleine Display ist etwas gewöhnungsbedürftig. Die Tastatur ist aber definitiv zu klein für mich, da werd ich längere Gewöhnungszeit brauchen. Vor allem tipp ich gerne auf "Cursor hoch" statt der rechten Shift-Taste.

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

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...

Derzeit geht's rund! Ärger mit Servern, Ärger mit dem Militär und Freude über meinen Internetprovider!

Nachdem seit letztem Samstag mein Server wieder frisch läuft, hab ich ja Zeit, mich um anderes zu kümmern. MÖÖÖP, nix da! Am Dienstag stelle ich fest, dass in diesen Server hier eingebrochen wurde und das Ding nun frisch-fröhlich Spam versendet! Na toll. Vermutlich hat da einer der Domain-Mieter ein faules Skript in seinem Webroot liegen gehabt. An sich war der Server ja gut gewartet, aber wenn die Sicherheitsvorkehrungen unterwandert werden, nützt das auch nicht viel. Wie auch immer: Seit Donnerstag wurde die Sache neu gemacht und maximal gehärtet: Virtualisierung, exzessives chroot, verstärkte Firewallregeln, Rechteeinschränkungen, verstärkte Überwachung etc pp. Und wir sind noch lange nicht fertig!

Ganz überraschend lag am Donnerstag ein Päckchen in meinem Briefkasten. Siehe da. Fast 3 Monate nach Vertragsabschluss erhalte ich mein ADSL-Modem. Das nenne ich doch eine prompte Erledigung. Zum Glück bin ich als Informatiker sowieso mehrfach mit sowas ausgestattet. Heute habe ich trotzdem das neue installiert. Gemäss Leistungsaufschrift auf dem Netzteil sollte es wohl so 25% weniger Strom verbrauchen.

Am Freitag bekam ich ein nettes Briefchen von Väterchen Staat, worin stand, dass man von mir noch keine Meldung wegen obligatorischem Schiessen erhalten hätte. Na Ihr seid ja so toll, meine lieben! Ich kann absolut nicht verstehen, wieso ein Prozess, der seit 100 Jahren jedes Jahr 400'000 Mal ausgeführt wird, nach wie vor nicht reibungslos verläuft! Es kann doch nicht sein, dass ich jeden Scheiss selbst machen muss? Na gut, geh ich halt mein Schiessbüchlein hervorsuchen und schicke es euch. Bleibt zu hoffen, dass die Post das Ding nicht verschlampt. grrrrmpf!!!

Am Sonntag Morgen hatte ich ein unschönes Erwachen. Über Nacht hatte auch noch eine der beiden brandneuen Platten im Homeserver verabschiedet. Dank RAID-1 ist da zum Glück nichts passiert. Da es sich um HotPlug-taugliche SATA-Platten handelt, wurde die defekte Platte einfach im Kernel abgemeldet und das System lief mit der funktionsfähigen Disk weiter. Mühsamer und Zeitaufwändiger als die Reparatur des RAID-Arrays war aber der Umtausch der Platte. Da die Angaben auf der Homepage meines Lieferanten wieder alles andere als korrekt waren, musste ich zweimal in dessen Laden, um Ersatz zu erhalten.

Langsam normalisiert sich die Lage wieder. Bleibt zu hoffen, dass sie auch normal bleibt.

Neben Ubuntu habe ich mich auch wieder mit Gentoo befasst, wenn auch eher zwangsweise. Mein Server hat kürzlich angefangen, beim Booten lustige Fehlermeldungen auszuspucken und sich geweigert, die verschlüsselten Partition zu entschlüsseln. Manuell liess es sich hingegen problemlos bewerkstelligen.

Die Gentoo-Installation war aber sowieso schon ein Bisschen in die Jahre gekommen und entsprechend mit vielen unnötigen Paketen zugekleistert. Gleichzeitig haben die Festplatten keinen freien Platz mehr geboten. Folglich war es also an der Zeit, wieder von vorne anzufangen. Und wenn man das schon macht, können ja grad noch ein paar Verbesserungen reingebracht werden.

Als erstes wurde die untertaktete Radeon9000 gegen eine uralte Mach64 ersetzt, was wohl den Stromverbrauch weiter senken dürfte.

Als zweites habe ich von drei auf zwei Platten reduziert und von leisen Platten mit 5400rpm auf 7200rpm-Scheiben umgestellt. Die sind wesentlich schneller und dennoch kaum lauter. Statt RAID-5 läuft jetzt alles als RAID-1, was auch die CPU freut. Der neue Array packt 80MB/s Übertragungsrate auch über längere Zeit. Sehr schön. Die Partitionierung wurde beibehalten, je eine LVM-Partition für /, /var und /home, auf RAID-1 sowie eigene Partitionen für den portage-Tree und /tmp bzw /var/tmp auf RAID-0.

Als drittes habe ich von "normalem" Gentoo auf Hardened Gentoo umgestellt. Da ich auch noch SELinux implementieren möchte, sind jetzt alle Partitionen bis auf die Portage-Partition mit ext3 statt reiserfs formatiert. Reiserfs unterstützt nicht alle Sicherheitslabel, die SELinux benötigt. Zuvor hatte ich übrigens noch Debian Lenny evaluiert, allerdings hatte ich da massive Probleme mit SELinux, so dass ich doch bei Gentoo geblieben bin.

Als viertes habe ich längst nicht mehr benötigte Dienste gar nicht mehr installiert. Samba braucht mein Microsoft-freies Netz ja nun mal gar nicht.

Gerne hätte ich als fünfte Verbesserung noch Virtualisierung genutzt, da jedoch die CPU noch keine Hardware-Virtualisierung bietet, wird das etwas knifflig: Für XEN-Dom0 gibt es nur alte Kernel. Selbiges gilt für UserModeLinux, welches wohl eh tot ist. In beiden Fällen müsste ich auf viele gute Verbesserungen der neueren Kernel verzichten. VMWare ist proprietär. Und Qemu lässt sich nicht mit einem gehärteten GCC kompilieren (ausser mit manuellem Gefrickel). Nun muss also vorerst alles nativ laufen und ich warte vorerst auf neuere Implementierungen von XEN, welches mir für meine Zwecke der beste Ansatz zu sein scheint.

Seit letztem Donnerstag gibt es Ubuntu 8.10, seitdem läuft es auch auf meinen Arbeitsrechnern. Im Gegensatz zu früheren Versionen verlief das Update auf drei Maschinen problemlos, was schon fast zu bedauern ist. Denn so komme ich nach wie vor nicht dazu, im Rahmen einer Neuinstallation auf eine 64bit-Installation umzustellen Und grad da es so problemlos verlief, gibt es auch nicht viel dazu zu schreiben. Nur zwei, drei kleine Problemchen sind mir bislang aufgefallen:

• Pidgin poppt Gesprächsfenster automatisch auf, obwohl er das gemäss Einstellungen nicht sollte. Eventuell muss ich also ~/.libpurple löschen und das Profil zurücksetzen, damit das wieder geht. Hab ich aber nicht gross Lust dazu, also muss ich damit leben.


• VMWare Server funktioniert nach wie vor nicht mit Kernel 2.6.27. Dagegen hilft wohl nur auf die Gnade VMWare's zu warten (oder Patches aus mässig seriösen Quellen einzuspielen).


• Meine Logitec-Billigst-Webcam funktionierte unter 8.04 noch in Briefmarkengrösse, unter 8.10 geht gar nichts. Ist mir aber egal.


• Der Sound ist irgendwie basslastig geworden. Kann entweder an den alten Boxen liegen (wobei das ein extremer Zufall wäre, dass die grad beim Update defekt gehen), oder am Soundtreiber. Ich muss mal eine andere Soundquelle anhängen.
  

Auf neu funktionierenden Seite sind hingegen PulseAudio aufzuzählen, ebenso nvidia-settings, das nun endlich auch die config-Datei schreibt und nicht nur so tut.

Folglich ein ordentlicher Wurf, auch wenn mir unter Linux irgendwie der Pioniergeist früherer Jahre manchmal fehlt. Vermutlich muss ich doch auf FreeBSD umsteigen, damit mir nicht langweilig wird

und Linux so kompliziert. Denn unter Linux muss man alles in der Kommandozeile machen, während man unter Windows bequem alles per Mausklick einstellen kann.

OK.

Wirklich?

Aber klar doch!

Folgender Fall: Für einen Mitarbeiter wird ein Notebook mit Windows Vista und XP downgrade-Option angeliefert. Ich installiere also XP von der Recovery-CD. Danach habe ich zuerst die komische Systembremse alias "Virenscanner" mit dem gelben Logo entfernt und eine gescheite Alternative installiert. Dann wollte ich das Windowsupdate einspielen lassen. Das WGA-Prüftool liess sich problemlos installieren, aber Servicepack 3 hat rumgezickt mit einer Meldung über einen nicht gestarteten Kryptographiedienst (wobei der definitiv aktiv war). Lösung? Gemäss Microsofts Knowledgebase (Methode 4) muss man dazu ja nur die Kommandozeile öffnen (ah ja?), 10 Befehle eintippen, neustarten, Kommandozeile öffnen, weitere 10 Befehle eintippen, neustarten.

Na schön, immerhin scheint's jetzt wieder zu funktionieren.

Und bei meinem Ubuntu-Desktop warte ich einfach, bis er alle Woche einmal meint, dass neue Updates vorhanden seien, dann klicke ich aufs Trayicon, gebe mein Passwort ein und warte, bis alles fertig ist. Solche lustige Probleme hatte ich da noch nie (ausser bei einem Distributionsupgrade, aber das ist was anderes).

Übrigens, die Installation plus Konfiguration von Ubuntu auf einem baugleichen Gerät hat 2h gedauert. Bei Windows bin ich seit gestern dran und hab noch nicht mal das Basissystem fertig. Da könnte ich ja grad so gut Gentoo auf dem Desktop nehmen, das dauert inklusive kompilieren auch nicht länger bis es installiert ist.