Mal wieder ein Rant. Da sich mein Geburtstag langsam nähert und ich eigentlich keine großen Wünsche habe, dachte ich mir, dass ich mir einen vernünftigen Testrechner aufbaue. Der Dell Optiplex 740, den ich hier rumstehen habe, ist in sämtlichen Kategorien durchgefallen, weswegen ich mir jetzt lieber einen eigenen zusammenstellen möchte. Mein Fokus liegt dabei auf bestmöglicher Unterstützung von Virtualisierung - speziell ESXi - und guter Aufrüstbarkeit. Ich dachte an ein Sockel 1155 Mainboard mit einem entsprechenden Intel-Prozessor, das bis zu 32GB RAM aufgerüstet werden kann. Und hier fängt das Problem an. Intel bietet zwei Technologien für Virtualisierung an, das allseits bekannte und fast überall unterstützte VT-x und das weniger bekannte und weniger genutzte VT-d. Um VT-d nutzen zu können, muss das Mainboard VT-d Unterstützung anbieten. Auch wenn ich vorerst nicht vorhabe, VT-d zu nutzen, würde ich mir diese Möglichkeit gerne offenhalten, also ein Mainboard einbauen, welches VT-d unterstützt. Aber das machen einem die Mainboardhersteller so schwer wie möglich. Bisher habe ich auf keiner Herstellerwebsite direkt Angaben gefunden, ob das Mainboard VT-d unterstützt oder nicht. Bei ASRock habe ich es im Handbuch finden können, aber auch nur, weil dort der UEFI-Eintrag dafür beschrieben wird.

Liebe Hardwarehersteller, warum macht ihr es uns so schwer, an solche "Randgruppeninformationen" zu kommen?

Als Fazit werde ich mich wohl für ein Mainboard von ASRock mit Z77-Chipsatz* entscheiden, diese unterstützen offenbar alle VT-d. Mein Favorit momentan ist das Z77 Pro 3.

*=Affiliatelink

...für eine Internetanbindung jenseits von DSL reicht es dann wohl doch nicht.

Hintergrund der Geschichte: Wir haben momentan einige Supportcalls bei VMware geöffnet. Essentieller Bestandteil davon ist die Übermittelung von Coredumps und Logbundles zu VMware, damit deren Techniker eine tiefergehende Analyse vornehmen können. Gerade die Coredumps können schnell ein paar Gigabyte groß werden. Das scheint die Firma VMware, deren Marktwert so um die 30 Milliarden US-Dollar beträgt und deren Umsatz jenseits von 3,5 Milliarden US-Dollar pro Jahr liegt, nicht davon abzuhalten, die Uploadgeschwindigkeit von FTP-Accounts zu begrenzen. Dass die Geschwindigkeit VMware seitig begrenzt wird, wurde uns von einem Supportmitarbeitet bestätigt. Es scheint, als wäre die Uploadgeschwindigkeit pro FTP-Account auf ca. 180 KB/s begrenzt. Und wie man sieht, kann die VMware-Leitung nichtmal diese "Geschwindigkeit" beibehalten.

Hier mal als Vergleich ein banaler Speedtest:

Das Problem liegt also sicher nicht bei uns.

Dass eine IT-Firma solche steinzeitlichen Begrenzungen bei Diensten konfiguriert, die man sowieso nur mit bezahltem Support nutzen wird, empfinde ich als ein ziemliches Armutszeugnis.

Eine der ersten Aktionen auf einem frisch installierten Linux Server ist sicherlich das Einrichten von NTP. Dass eine synchronisierte Systemzeit extrem wichtig ist, sollte den meisten Usern und Admins einleuchten. Jeder, der deswegen schonmal mit Datenbankinkonsistenzen zu kämpfen hatte, weiß wovon ich rede. Da ich die Schritte immer wieder vergesse, werde ich sie hier für die Nachwelt dokumentieren.

1. Falls gewünscht sollte die Zeitzone eingestellt werden. Das geht auf zwei Arten. Mit manueller Eingabe:

   dpkg-reconfigure tzdata

   oder indem man die entsprechende zonedate kopiert:

   cp /usr/share/zoneinfo/Europe/Berlin /etc/localtime

   Europe und Berlin solltet ihr dann natürlich durch eure entsprechenden Pendants ersetzen.

2. Den ntp-Dienst installieren, falls noch nicht vorhanden.

   aptitude -y install ntp

3. Anschließend ersetzen wir die Poolserver in der ntp.conf noch mit denen des jeweiligen regionalen ntp-Pools.

   sed -i 's/debian.pool.ntp.org/de.pool.ntp.org/g' /etc/ntp.conf

4. Dann noch den NTP-Dienst neustarten und alles ist fein.

   service ntp restart

Ein Oneliner für Copy & Paste oder Skripte würde dann so aussehen:

cp /usr/share/zoneinfo/Europe/Berlin /etc/localtime && aptitude -y install ntp && sed -i 's/debian.pool.ntp.org/de.pool.ntp.org/g' /etc/ntp.conf && service ntp restart

Die ganze Chose kann man dann entweder testen, indem man mal ein

ntpq -p

eingibt, um die NTP-Server des Systems herauszubekommen oder - wenn man ein bisschen paranoid ist, so wie ich - indem man den NTP-Dienst beendet, die Zeit ändert und ihn dann mit dem -gq Parameter startet.

service ntp stop && date -s 12:00 && ntpd -gq && service ntp start && date

Wenn die Ausgabe dann etwa so aussieht:
und der Eintrag "ntpd: time set" erscheint, läuft alles korrekt.
Falls ihr auf eurem Server iptables einsetzt und standardmäßig alle ausgehenden Verbindungen dropt, solltet ihr noch zwei Regeln in euer iptables-Skript aufnehmen:

iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
iptables -A INPUT -p udp --sport 123 -j ACCEPT

Damit sollte dann wirklich alles laufen.

Notiz an mich:

Bevor du den Server rebootest, stelle sicher, dass alle iptables-Regeln auch in deiner Wiederherstellungsdatei gespeichert sind.

Hintergrund:

Ich habe gestern an einem meiner vServer gebastelt und die Maschine im Zuge dessen auch neugestartet. Alles lief hinterher wie gewollt, also beendete ich irgendwann meine Arbeiten daran und loggte mich aus. Heute morgen habe ich durch Zufall auf die Bewertungsskala meines seit Kurzem auf dieser Kiste laufenden NTP-Servers geschaut und war etwas überrascht.

Verdammt, da hatte ich doch glatt vergessen die Regel, die einkommende NTP-Verbindungen erlaubt, in die Datei zu übernehmen, die nach Systemstart die iptables-Regeln wieder automatisch einrichtet. Das gefiel dem NTP-Pool natürlich gar nicht. Jetzt wird es sicherlich einige Zeit dauern, bis meine Maschine wieder Anfragen zugeteilt bekommt. :-?

Ironie der Sache: Ich hatte den Server neugestartet, um die Funktion eines anderen Skripts nach dem Systemstart zu testen.

PS: Zu NTP-Clients und Servern werde ich demnächst mal zwei Beiträge schreiben.

Google hat gestern angekündigt, dass der Google Reader zum 1. Juli abgeschaltet werden soll. Das finde ich sehr schade, bisher war dieser Dienst einer der wenigen, die ich auch dauerhaft weiter bei Google belassen hätte. Während mein mittelfristiger Plan vorsieht, die meisten der jetzt genutzten Google Dienste wie GMail, GTasks, die Kontakte und noch ein paar weitere auf ein selbst gehostetes System umzuziehen, war das beim Google Reader eigentlich erst langfristig geplant. Nun bin ich aber alarmiert und mache mir entsprechende Gedanken. Deswegen habe ich mal angefangen eine Übersicht von RSS Readern zu erstellen, die man auf eigenem Webspace oder einem eigenen Server nutzen kann. Bisher habe ich noch keines dieser Angebote getestet, das wird sich aber mit Sicherheit in den nächsten Wochen ändern. Meine Anforderungen sind:

• Selbst hostbar: Logisch, darum geht es in diesem Beitrag. Die Software sollte auf einem eigenen Server hostbar sein. Wenn "nur" ein Webhosting benötigt wird, umso besser.
• LAMP: Die Anforderungen sollten möglichst mit einem typischen LAMP-System (Linux, Apache, MySQL, Php) abgedeckt sein.
• MultiUser: Da sowohl meine Spielerin #2 als auch ich darauf zugreifen werden, sollte irgendeine Art der Unterscheidung möglich sein. Ob es nun Ordner oder User sind, ist mir dabei gleich.
• Android-App: Eine kompatible Android-App möglichst mit Offline caching und ein Webinterface sollten vorhanden sein.
• Aktiv: Es sollte sich möglichst um ein aktives Projekt handeln, das nicht das letzte Mal vor 4 Jahren aktualisiert wurde
• OpenSource: OpenSource Software würde ich aus ideologischen Gründen bevorzugen. Ist allerdings nicht zwingend.

Weniger Wert lege ich auf:

• Aussehen: Ich mag Apple unter anderem deswegen nicht, weil sie nach dem FFF-Prinzip handeln ("function follows form"). Ich will Funktionalität, das Design ist für mich nicht mal zweitrangig.
• Einfache Installation: Beruflich bin ich in der IT zu Hause, deswegen sollte ich mit der Installation der meisten Applikationen klarkommen. Aber auf jeden Fall wichtiger, als das Aussehen.
• iOS-App: Apple-Produkte sind mir zuwider, dementsprechend ist mir die Unterstützung dieses Systems total egal.
• Windows/Linux/OSX-Client: Das Webinterface reicht mir am PC aus.

Dann schauen wir mal, was ich bisher finden konnte: