Wir haben unter erschwerten Bedingungen auf einem Strato-Rootserver Ubuntu installiert. Da das Rettungssystem 32bittig war, — was einen chroot in ein installiertes Linux verhinderte — bereiteten wir das Basissystem zuhause vor und kopierten das Ergebnis mit rsync zum Server. Das macht die Anleitung auf praktisch alle Provider übertragbar.

Als Arbeitsumgebung zuhause ist eine 64bittige Ubuntu-Installation ideal, es geht aber auch eine Kanotix-CD (Bitte 64 Bit!). Temporär wird etwa ein Gigabyte Platz auf einer Linux-Partition benötigt.

Vorbereiten des Basissystems zuhause

• Den Anfang macht eine Arbeitsverzeichnis /tmp/bootstrapped oder /usr/local/tmp/bootstrapped, die Spracheinstellungen setze ich temporär auf C:

  mkdir -p /tmp/bootstrapped
export LC_ALL=C
export LANG=C

• Die Installation von Ubuntu in einem Verzeichnis nimmt das Tool debootstrap vor. Wenn Sie einen Rechner mit der gleichen Architektur wie der Rootserver zuhause unter Ubuntu 6-06 betreiben, genügt

  apt-get update
apt-get install debootstrap

  für die Installation. Nutzer von Knoppix oder Kanotix müssen das aktuellste DEB-Paket vom Ubuntu-Server herunterladen und mit dpkg installieren:

  dpkg -i debootstrap-xyz.deb

  Mit debootstrap installieren Sie Dapper im vorbereiteten Verzeichnis:

  debootstrap --arch amd64 dapper /tmp/bootstrapped http://archive.ubuntu.com/ubuntu

• Um dieses Minimal-Ubuntu anpassen zu können, wechseln Sie mit chroot in das Installationsverzeichnis. Sie bewegen sich dann im neuen System, als wäre es nicht in einem Verzeichnis, sondern direkt in der Wurzel eines installierten Systems. Damit chroot funktioniert, müssen /proc und /dev/pts gemountet sein:

  mount -t proc none /tmp/bootstrapped/proc
mount -t devpts none /tmp/bootstrapped/dev/pts

  Ab in den chroot-Käfig:

  LANG=C chroot /tmp/bootstrapped /bin/bash

• Zuerst wird ein Rootpasswort gesetzt. Ich bin konservativ und vergebe eines, zur Absicherung des Servers später mehr. Ubuntu schreibt den Passworthash in die /etc/passwd, wo er seit etwa 10 Jahren nicht mehr hingehört, aktivieren Sie deshalb unbedingt Shadow-Passwörter!

  passwd
shadowconfig on

• Nun ist die Netzwerkkonfiguration des frisch installieren Ubuntu an der Reihe. Zuerst der Hostname:

  echo 'rootie.meinedomain.xyz' > /etc/hostname

  Dann die /etc/hosts:

  echo '127.0.0.1 localhost' > /etc/hosts

  Die Datei /etc/resolv.conf für die Namensauflösung bekommt als zweite Zeile den Nameserver des lokalen Netzes! Dieser Eintrag wird benötigt, damit später apt-get funktioniert. Löschen Sie diese Zeile wieder, bevor Sie das System zum Rootserver kopieren.

  search meinedomain.xyz
nameserver 192.168.1.1
nameserver 81.169.163.104
nameserver 81.169.163.106

  In der Datei /etc/network/interfaces stehen die Netzwerkeinstellungen wie IP-Adressen, DHCP-Client zur Konfiguration etc. Am sichersten ist es, Sie ermitteln mit den Befehlen ifconfig und route die aktuelle Konfiguration. Beim Strato-Rootserver ergab sich (address, netmask, broadcast und gateway bitte einrücken):

  auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 85.214.xx.221
netmask 255.255.255.255
broadcast 85.214.xx.221
gateway 85.214.xx.221


  Bei Stratos Konfiguration mit 32er-Netzmasken muss der Gateway auf die eigene Adresse zeigen. Bei vielen anderen Providern dürfte die DHCP-Konfiguration problemlos funktionieren:

  auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp

• Für den Fall, dass beim Start das Netzwerk nicht aktiviert werden kann, ist es wichtig, eine serielle Konsole verwenden zu können. Achten Sie darauf, dass die Datei /etc/inittab die folgende Zeile enthält:

  S0:12345:respawn:/sbin/getty -L ttyS0 57600 vt102

  Diese Konsole sollte zudem als sicher gekennzeichnet sein, wozu der Eintrag in der Datei /etc/securettys dient:

  ttyS0

• Nächster Schritt ist die /etc/fstab mit den Dateisystemen des Rootservers. Sie nimmt die Partitionierung der Festplatte vorweg (wenn Sie Extlinux als Bootloader verwenden, s.u., dann muss die Bootpartition zwingend ext2/ext3 sein!). Für unser Testsystem habe ich neben der Wurzelpartition und Swap eine kleine Bootpartition am Anfang der Festplatte und eine Partition für /var vorgesehen.

  /dev/hda5 / ext3 defaults 0 1
/dev/hda1 /boot ext2 defaults 0 0
/dev/hda3 /var ext3 defaults 0 0
/dev/hda2 none swap sw 0 0

• Nun ist das Debian-Paketmanagement an der Reihe. Die /etc/apt/sources.list habe ich von einem gewöhnlichen Ubuntu-System übernommen. Vermutlich werden Sie Kleinigkeiten ändern wollen:

  deb http://de.archive.ubuntu.com/ubuntu/ dapper main restricted
deb-src http://de.archive.ubuntu.com/ubuntu/ dapper main restricted

  deb http://de.archive.ubuntu.com/ubuntu/ dapper-updates main restricted
deb-src http://de.archive.ubuntu.com/ubuntu/ dapper-updates main restricted

  deb http://de.archive.ubuntu.com/ubuntu/ dapper universe
deb-src http://de.archive.ubuntu.com/ubuntu/ dapper universe

  deb http://security.ubuntu.com/ubuntu dapper-security main restricted
deb-src http://security.ubuntu.com/ubuntu dapper-security main restricted

• Es folgt das erste Sicherheitsupdate und die Installation für den späteren Bau des Kernels benötigter Pakete, sowie des SSH-Servers:

  apt-get update
apt-get upgrade
apt-get install build-essential zlib1g-dev libncurses-dev wget

  apt-get install ssh

  Wenn Sie in der /etc/ssh/sshd_config den Port des Daemons auf einen anderen als 22 legen, so dass kein vom Host belegter Port beansprucht wird, können Sie sich nach einem Neustart des Daemons per SSH im chroot anmelden.

• Für das Testsystem habe ich einen Vanilla-Kernel von kernel.org vorgesehen und im chroot heruntergeladen und dort entpackt:

  cd /usr/local/src
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.16.27.tar.bz2
tar xvjf linux-2.6.17.7.tar.bz2
cd linux-2.6.17.7 Das Ncurses-Interface für die Kernelkonfiguration ist schlank und einfach zu bedienen. Vergewissern Sie sich, dass Treiber für die Netzwerkkarte, das Dateisystem der Rootpartition und den IDE- oder SATA-Controller fest einkompiliert sind. Alternativ können Sie natürlich Module bauen und sicvh mit der Syntax von mkinitramfs vertraut machen:

  make menuconfig
make
make install

  Der Befehl make install wird mit einem Fehler abbrechen, weil kein Bootloader installiert ist. Kein Problem, denn der Kernel liegt bereits in /boot, es folgen die (wenigen) Module:

  make modules_install

• Aufgeräumt ist schnell in erster Linie müssen nicht mehr benötigte DEB-Archive und der Tarball mit den Kernelquellen dran glauben:

  rm -f /var/cache/apt/archives/*.deb
rm /usr/local/src/linux*.tar.bz2

• Die Vorbereitung des Debiansystems ist nun abgeschlossen. Verlassen Sie die chroot-Umgebung mit exit und hängen Sie /proc und /dev/pts aus:

  umount /tmp/bootstrapped/proc
umount /tmp/bootstrapped/dev/pts

Vorbereiten des Rootservers

Jetzt steht die Vorbereitung des Rootservers und das Kopieren des vorbereiteten Systems zum Server an. Aktivieren Sie hierfür die serielle Konsole (falls Ihr Provider eine anbietet) und starten Sie das Rettungssystem. Dort führen Sie die folgenden Schritte durch:

• Mit fdisk löschen Sie die vorhandenen Partitionen und legen Sie diese entsprechend Ihrer /etc/fstab an. Setzen Sie die Bootpartition (falls Sie eine haben oder alternativ die Wurzelpartition) aktiv oder bootfähig. Verzichten Sie nicht auf die Swap-Partition, da ausgelagerte Speicherseiten den Cache der Dateisysteme beschleunigen können.
• Formatieren Sie die eben angelegten Partitionen, für die Bootpartition habe ich ext2 gewählt, weil diese den Bootloader extlinux aufnehmen soll:

  mkfs.ext2 /dev/hda1
mkfs.ext3 /dev/hda3
mkfs.ext3 /dev/hda5
mkswap /dev/hda2

  Erstellen Sie Mountpoints und binden Sie die frisch formatierten Partitionen ein:

  mkdir /tmp/ubuinstall
mkdir /tmp/ubuinstall/boot
mkdir /tmp/ubuinstall/var

  mount /dev/hda5 /tmp/ubuinstall
mount /dev/hda3 /tmp/ubuinstall/var
mount /dev/hda1 /tmp/ubuinstall/var

• Der Große Moment! Von Ihrem Rechner zuhause starten Sie den Transfer des vorbereiteten Ubuntu-Systems zum Rootserver:

  rsync -avzHP /tmp/bootstrapped/ root@85.214.xx.221:/tmp/ubuinstall/

  Rsync arbeitet mit Komprimierung und überträgt nur geänderte Dateien. Wenn die Übertragung abbrechen sollte, starten Sie diese einfach neu — rsync wird nach einer kurzen Prüfung dort weitermachen, wo es aufgehört hat. Rechnen Sie mit netto 200 bis 300 MB übertragenen Daten, bei DSL1000 kann dies einige Stunden dauern…

• Es folgt die Installation des Bootloaders. Da der Grub des Rettungssystems auf unserem Testserver nicht funktionierte, entschieden wir uns für Extlinux, einen schlanken Bootloader, der die Installation auf einer aktiven Partition voraussetzt und einen DOS-MBR verwendet:

  cd /tmp
wget http://www.kernel.org/pub/linux/utils/boot/syslinux/syslinux-3.11.tar.bz2
tar xvjf syslinux-3.11.tar.bz2
cd syslinux-3.11

  Zuerst wird der MBR der ersten Festplatte überschrieben, dann folgt der eigentliche Bootloader:

  cat mbr.bin > /dev/hda
./extlinux/extlinux /tmp/ubuinstall/boot/

  Extlinux nutzt eine Konfigurationsdatei extlinux.conf, die ebenfalls im Boot-Verzeichnis liegen muss:

  SERIAL 0 57600

  DEFAULT vmlinuz-2.6.16.27
  APPEND root=/dev/hda5 ro console=ttyS0,57600
  TIMEOUT 150
PROMPT 1

  Da Extlinux die serielle Konsole des Servers verwenden kann, aktivieren wir diese. Im Gegensatz zu LILO kann Extlinux das ext2/ext3-Dateisystem lesen, auf dem der Bootloader residiert. Das erlaubt das Booten von Kerneln, die nicht in der extlinux.conf eingetragen sind.

Das war es schon! Wenn Sie sich nun an der seriellen Konsolle einloggen, alle Partitionen (sowie /proc und /dev/pts) aushängen und den Rootserver rebooten, können Sie an der seriellen Konsole die Bootmeldungen des Systems verfolgen. Ein Login sollte als root sowohl auf der seriellen Konsole als auch per SSH möglich sein.

Deaktivieren Sie anschließend das Root-Login per SSH, legen Sie einen Nutzer an, der su oder sudo verwenden darf und installieren Sie die benötigten Serverapplikationen. Zudem sollten Sie mit dpkg-reconfigure locales und tzconfig Zeichensatz und Zeitzone einstellen.

http://ftp.gwdg.de/pub/opensuse/distribution/SL-10.1/

Installationskernel und Ramdisk sind so ausgelegt, dass sie von jedem Datenträger gestartet und werden können und so eine Remote-Installation zulassen. Dabei ist es egal, ob unter einer regulären Suse 9.1 ein Grub-Eintrag eingelegt und zum Standard erklärt oder auf einem “gesemmelten Rechner” temporär aus dem Rettungssystem heraus eine kleine Bootpartition erstellt und mit GRUB versehen wird.

Dank des neuen Software-Verwaltungstools “rug” wird Suse erstmals auch für Admins interessant, die viel automatisieren müssen. Ich gebe zu: unsympathisch ist mir “rug” nicht…

Die Installation per HTTP auf einem Rootserver beschreibe ich im Hetzner-Wiki, eine ausführlichere Erklärung werde ich wahrscheinlich demnächst in einem Print-Medium bringen:

http://wiki.hetzner.de/index.php/Suse_Update_auf_10.1_(Remote)

PS: Damit niemand denkt, ich wäre von Hetzner und Suse gekauft wird in den nächsten Tagen auf unserem Strato-Testsystem das Suse 9.3 gegen FreeBSD 6.1 ersetzt.

Nicht so im Falle der Serverschleuder. Thomas Hölscher hat seinen Unmut über die seiner Ansicht nach nicht zufriedenstellende Vertragserfüllung durch Serverschleuder im Web geäußert und fand prompt Drohungen eines der mutmaßlichen Geschäftsführer in seinem Blog wieder.

Selbst wenn man Thomas Hölscher in dem derzeit nicht erreichbaren Blog-Beitrag einen weit schnoddrigeren Ton als im Rest seines Weblogs unterstellt, fällt es schwer zu glauben, dass er die Grenze zur Schmähkritik überschritten hat.

Auffallend ist dagegen das unprofessionelle Auftreten des (vermeintlichen?) Geschäftsführers von Serverschleuder, Michael Heizmann. Dieser droht offen im Blog und per Mail mit Abmahnung und Strafanzeige, wenn der Blog-Beitrag nicht bis zum 28. Januar verschwunden ist. Offenbar soll der Streitwert bei dieser Aktion bei 500.000 Euro liegen.

Selbst wenn es der Firma Serverschleuder gelingen sollte, Thomas Hölscher zur Abgabe einer Unterlassenserklärung zu bewegen oder eine einstweilige Verfügung zu erwirken, ist der angerichtete Schaden für Serverschleuder mittlerweile enorm: die gesamte Bloggosphäre (unter anderem das Lawblog) zerreisst sich das Maul über den unprofessionellen Umgang der Serverschleuder mit ihren (Ex-) Kunden und potentielle Neukunden schauen so aufgescheucht zurecht bei Webhostlist nach der Kundenbeurteilung von Serverschleuder.

Wer günstiges Hosting sucht sollte selbst die Kalkulationen der Provider hinterfragen. Viele der extrem günstigen Angebote funktionieren nur durch Skaleneffekte oder sind sogar bewußt unter den eigenen Kosten kalkuliert, denn ein einmal gewonnener Kunde, der mehr möchte, wechselt lieber in ein teureres Angebot seines Providers als mittels KK-Antrag in ein neues digitales Heim umzuziehen. Provider, die fast ausschließlich extrem billige Hostingpakete anbieten, sollte man sehr kritisch betrachten.

Update:

Michael Heizmann scheint die Bloggosphäre aufmerksam zu beobachten. Er rief mich gegen 14:30 an und bat mich, seine Version der Geschichte anzuhören, was ich auch gerne tat. Offenbar hat man bei Serverschleuder die Notbremse in Sachen schlechter PR gezogen und entschuldigt sich nun für böse Emails und drohende Weblog-Einträge, so schreibt mir Heizmann (Hervorhebungen von mir):

Sehr geehrter Herr Schlenker,

Erst einmal danke für das mit Ihnen geführte Telefonat von eben! Leider ist es nicht gerade mein Stärke große Gegendarstellung zu schreiben und ich hoffe Sie verzeihen mir.

Ich möchte mich bei Herrn Hölscher für die etwas verunglückten Mails etc von mir und meines Kollegen entschuldigen. Es war nicht meine Absicht, diese Diskussion so hoch zu puschen! Ich weiß, dass ich auch Fehler gemacht habe, die man so nicht einfach Rückgängig machen kann aber ich würde Herrn Hölscher gerne um die Entfernung meines Textes auf seiner HP bitten.

Was die Androhung von rechtlichen Schritten angeht so ist dies eher eine Kurzschlussreaktion gewesen die nicht so gemeint war. Leider reagiere ich in manchen Situationen nicht gerade zu meinem Vorteil aber ich hoffe wir können diese Streitigkeiten bei Seite legen.

Das ist immerhin ein Schritt in die richtige Richtung, der allerdings — im Interesse beider Parteien — hätte viel früher erfolgen sollen. Denn selbst wenn Thomas Hölscher der Bitte um ein Edit des fraglichen Beitrages nachkommt, hat der fragliche Satz mit der Verbkreation “dolden” schon zu weite Kreise gezogen und ist praktisch nicht mehr zurückzuholen.

Bleibt zu hoffen, dass die Serverschleuder aus diesem PR-Debakel gelernt hat und fortan unzufriedene (Ex-) Kunden gelassener behandelt. Und selbst wenn mal ein Blog-Beitrag die Grenze zwischen Schnoddrigkeit und Schmähung überschreiten sollte, hilft ein souveräner Umgang damit, Professionalität zu beweisen.

2. Update (26. Januar 17:10):

Laut Thomas Hölscher schließt sich auch der zweite Geschäftsführer der Serverschleuder der Entschuldigung seines Kollegen an. Na also: geht doch! Dennoch wäre die in dieses Spektakel verschwendete Zeit sicher besser zur Betreuung der “aktiven” Kunden aufgewendet worden. Wie immer wenn es um “Recht und Internet” geht sind das Lawblog und das Webhostingblog mit von der Partie.

Ich hoffe, dass in den nächsten Tagen und Wochen noch ein oder zwei weitere Systeme folgen um die gesamte Bandbreite der gängigen Konfigurationen abzudecken.