|
Saturday, 29. November 2008
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
Monday, 24. November 2008
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.
Sunday, 23. November 2008
Meine Pechsträhne mit Servern reisst nicht ab. Gestern ist eines der beiden USVs (unterbrechungsfreie Stromversorgung... quasi eine Batterie für Server) im Serverraum meines Arbeitgebers abgeraucht.
Was ich daraus lerne? Wenn der apcupsd meldet,
UPS needs battery replacement NOW
, dann ist damit nicht etwa in "sobald die Ersatzbatterie bestellt und geliefert wurde und danach keiner mehr den Server braucht[1]" gemeint, sondern GENAU JETZT SOFORT!
Rund eine Woche nach der ersten Meldung durfte ich nämlich feststellen, dass die Server nicht mehr ansprechbar waren. Da ich sowieso an diesem Tag (es war der gestrige Samstag) die Batterie ersetzen wollte, konnte ich mich grad drum kümmern. Die Feststellung im Serverraum: Das USV war aus, die Server waren aus, das USV liess sich nicht mehr einschalten und die Batterie kann nicht mehr entfernt werden, da sie aufgebläht ist! So viel zum Thema "unterbrechungsfrei". Na ist ja super... Das Gerät ist übrigens erst gut 2 Jahre alt und ein Profi-Teil eines renommierten, professionellen Herstellers. Wenigstens war das Timing des Ausfalls gut: Samstag, wenige Stunden bevor ich mich eh rangesetzt hätte. Nun ja, dann wird halt ein Fachmann bestellt, der sich darum kümmern soll. Garantie ist immerhin noch drauf.
ad [1]: Vor dem Ersetzen der Batterie fahr ich die Server runter, schalte das USV aus und trenne es vom Strom. Zwar müsste sich die Batterie auch im laufenden Betrieb ersetzen lasse. Aber bei Dingen, die so viel Strom führen, dass sie nicht nur töten können, sondern auch noch Schmerzen bereiten bis man tot ist, bin ich lieber doppelt und dreifach vorsichtig.
Sunday, 16. November 2008
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...
Saturday, 15. November 2008
 Ich halte nun fest, dass sämtliche Einträge und von mir erstellten Bilder in diesem Blog unter der Lizenz " Creative Commons Namensnennung-Weitergabe unter gleichen Bedingungen 2.5 Schweiz" (kurz: by-sa) stehen.
Die Lizenz besagt, dass bei Verwendung dieser Inhalte auf mich als Originalautor verwiesen werden muss. Dies geschieht, sofern nicht individuell vereinbart, durch einen Link auf diese Seite.
Saturday, 15. November 2008
Das hier ist nur interessant für Betreiber von DNS-Servern mit einem Hang zum Alternativen 
Nachdem bekannt wurde, dass ORSN auf Ende Jahr abgeschaltet würde, habe ich mich auf die Suche nach einem alternativen Rootserver-Netz gemacht. Bislang erscheint mir nur Cesidian Root ein halbwegs tauglicher Ersatz, obwohl die Betreiber sogar mir etwas freakig vorkommen. ORSN war richtig professionell, da kommen die anderen schlicht nicht mit.
Cesidian Root bietet jedoch kein Hint-File für die einfache Integration in seinen Nameserver an. Daher musste ich selbst Hand anlegen und selbst eins verfassen:
. 3600000 NS a-root.cesidio.net.
a-root.cesidio.net. 3600000 A 78.47.115.194
. 3600000 NS b-root.cesidio.net.
b-root.cesidio.net. 3600000 A 78.47.115.197
. 3600000 NS c-root.cesidio.net.
c-root.cesidio.net. 3600000 A 24.129.114.64
. 3600000 NS d-root.cesidio.net.
d-root.cesidio.net. 3600000 A 66.92.233.14
. 3600000 NS e-root.cesidio.net.
e-root.cesidio.net. 3600000 A 66.92.233.130
. 3600000 NS f-root.cesidio.net.
f-root.cesidio.net. 3600000 A 89.238.64.147
. 3600000 NS g-root.cesidio.net.
g-root.cesidio.net. 3600000 A 80.239.207.176
Ich empfehle jedoch, Cesidian Root nicht als alleiniges DNS-Root einzutragen. Es ist wohl besser, wenn man das Hint-File des ICANN-DNS-Netzwerks um mein Hint-File für Cesidian Root ergänzt.
Friday, 14. November 2008
Nachdem der Server wieder (fast) vollständig läuft und ich nun zwei Tage lang Doku (woraus ich das eine oder andere gelungene Howto veröffentlichen werde) geschrieben habe, fasse ich hier ein paar Gedanken zu Serversicherheit zusammen. Wir haben nun extrem viel Arbeit in die Sicherung des Systems gesteckt. Vermutlich haben wir einige Dinge richtig paranoid abgesichert. Aber irgendwie ging es zumindest mir mit der Zeit so, dass ich nur schon das theoretische Maximum an Möglichkeiten ausschöpfen wollte. Quasi eine akademische Suche nach Serversicherheit.
- Sicherheit ist ein Prozess, kein Zustand. Nur während Δt=0 ist es ein Zustand!
- Ein sicheres System verwenden. Dazu gehört, dass das System sicher designt wurde, dass Updates leicht einzuspielen sind und dass es vom Hersteller auf lange Frist unterstützt wird.
- Virtualisierung nutzen, dadurch können Dienste getrennt werden. Wird eine virtuelle Maschine befallen, kann sie einfach ersetzt werden. Virtuelle Maschinen lassen sich leicht backuppen. VMWare bietet ausserdem mit nonpersistenten virtuellen Festplatten eine Möglichkeit, sämtliche Änderungen an einem Dateisystem mit einem Neustart zurückzusetzen.
- chroot nutzen! Insbesondere besonders exponierte Dienste gehören in ein chroot. Natürlich nutzt ein chroot nur dann, wenn es sauber eingerichtet wird und der Dienst nicht mit root-Rechten läuft.
- Dienste nutzen, die sicher designt wurden. Dazu gehört insbesondere, dass das Programm standardmässig root-Privilegien abgibt, auch wenn es z.B. privilegierte Ports nutzen will (da kann es einfach mit root-Rechten den Port öffnen und danach die Rechte abtreten).
- Sicherheit aktiv prüfen. Dazu gehören automatisierte Tests wie rkhunter, logcheck oder auch Statusüberprüfung durch Nagios.
- Restriktive Firewall. Es darf weder schädliches hinein noch unnötiges heraus. Neue Verbindungen soll das System idealerweise nur zu seinen Update-Servern öffnen dürfen.
- Nur ein Minimum an Diensten betreiben. Und auch sonst möglichst wenig Software installieren.
- Ausführliche und vollständige Dokumentation schreiben! Dazu gehört auch, dass jede Änderung am System sofort in der Doku nachzutragen ist, damit auch die anderen Admins wissen, was Sache ist.
- Backups! Wenn denn doch etwas passiert, sind wenigstens die Anwenderdaten in Sicherheit.
- Kommunikation mit Co-Admins und Kunden. Wer Daten auf dem Server hat, ist automatisch in den Sicherheitsprozess involviert.
- Dass Passwörter lang und komplex sein müssen und nie im Klartext übertragen werden dürfen, brauch ich wohl kaum noch einmal zu wiederholen...
Tuesday, 11. November 2008
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.
Sunday, 2. November 2008
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.
Sunday, 2. November 2008
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
Saturday, 1. November 2008
Kürzlich hat sich schon Roman gefragt, wieso man eigentlich immer in der längsten Schlange steht. Nun, das lässt sich ganz klar mit Murphy's Law beantworten.
Mir ist allerdings noch eine weitergehende Variante davon aufgefallen:
1. Wieso bilden sich Schlangen immer erst dann, wenn ich auf eine Ressource zugreifen will?
Und 2. Wieso bleibe ich der letzte in der Schlange, ergo wieso stellt sich hinter mir niemand weiteres an?
Zum Beispiel neulich brauchte ich Geld, also ging ich zum Bankomaten. Der war völlig frei, ich nähere mich, schon macht's "Schwupps" und fünf Leute stellen sich vor mir hin. Nach 15 Minuten warten und geduldig zuschauen, wie die Leute ewig an dem Ding rumspielen, als ob sie am Bankomatenschirm Solitär spielen würden, darf ich dann auch. Und nach mir will irgendwie keiner mehr. Und das ist mir in letzter Zeit doch mehr als nur ein Mal passiert.
So langsam komme ich mir vor wie im Film "die Truman Show". Kaum nähere ich mich einer Ressource, schon wird durch die unsichtbare Regie eine Gruppe Schauspieler hingeschickt, damit ich möglichst lange anstehen muss: "Achtung er kommt. Nähert sich vermutlich Bankomat X. Timing ist jetzt ganz wichtig. Er schaut zufrieden aus, weil er keine Schlange sieht. Jetzt betritt er den kritischen Bereich. Bereithalten... noch warten... Jeeeeetzt, Schlange bilden! Sehr gut Leute, das Grinsen ist aus seinem Gesicht raus, jetzt haltet ihn einfach noch etwas hin."
|
arbeit 
