Skip to content

Gentoo + manitu = Webhosting

Endlich! Wir haben heute damit begonnen, unsere Webhosting-Server zu Gentoo Linux zu migrieren.

Für unsere Kunden ganz sanft und im Hintergrund. Nur ein kurzer Pieks (Reboot) und alles wird gut (tm).

Es war ein hartes Stück Arbeit in den letzten Wochen und Monaten, v.a. da wir unser Administrations-Interface selbst programmieren und derzeit - zumindest in Teilen - "doppelt" (eher mit vielen Fall-Unterscheidungen) pflegen müssen. git sei Dank geht das ganz wunderbar.

Wir freuen uns, wenn die Migration aller Server durch sein wird. Das wird noch ein paar Wochen dauern. Aber die erste Flasche werden wir sicherlich noch diese Woche öffnen.

Als Ausblick für die Zukunft kann ich jetzt bereits verraten, dass wir stetig neue Features nachlegen werden. Die Wunschliste unserer Kunden ist umfangreich, und wir arbeiten bereits an kleinen Wundern ;-)

Sehr seltsames Verhalten einiger MTAs

In den letzten Tagen hat einer der Slave des iX-Blacklist nicht geantwortet.

Eigentlich nichts Schlimmes - hätten nicht einige MTAs (oder deren DNS-Resolver) gemeint, das in "jede IP-Adresse ist gelistet" zu übersetzen. :hmpf:

Wir haben den Slave natürlich deaktiviert.

PHP 7.3 verfügbar

Seit $gerade ist PHP 7.3 bei uns im Webhosting verfügbar. Standardmäßig ist allerdings 7.2 aktiv (abgesehen von Servern, auf denen relativ viele langjährige Bestandskunden liegen).

Daneben haben wir in einem Aufwasch 5.6, 7.1 und 7.2 aktualisiert.

IPv6 für alle Webhosting-Pakete

Der ein oder andere hat es vielleicht gemerkt: Seit einigen Tagen haben alle unsere Webhosting-Pakete IPv6. Alle bisherigen und alle neuen Pakte, alle Domains.

Wir haben das Feature bewusst sukzessive, ohne Tam-Tam und in Ruhe ausgerollt, so dass es genau so ablief, wir wir uns das vorgestellt haben: Unbemerkt.

Wer sich jetzt fragt, ob wir auch dedizierte IPv6-Adressen anbieten: Nein. Wir haben das zwar für Ende 2019 / Anfang 2020 in der Pipeline, aber es hat keinerlei hohe Priorität ;-)

Kernel für Server und Root-Server etc. (insbesondere Gentoo)

In der (längeren) Vergangenheit hatte ich ja immer wieder, allerdings gegen Ende unregelmäßg, über neue, binär von uns compilierte Kernel gebloggt.

Die wenigsten von Euch werden vermutlich jemals einen dieser Kernel genutzt haben. Nur wer Distributionen wie Gentoo nutzt, wird vermutlich beim Compilieren hin und wieder geflucht und sich einen aktuellen, binären Kernel zurückgewünscht haben :-)

Da wir für uns intern die Kernel in einem eigenen Overlay binär bauen, haben wir uns dazu entschlossen, diese Kernel für Euch (allerdings nicht als Repository / Overlay) zur Verfügung zu stellen. Ihr findet diese in

https://download.manitu.de/root-server/kernel/

und dort im Verzeichnis des jeweiligen Zweigs, also 4.14 für den aktuellen LTS-Kernel. Derzeit bieten wir 4.9 und 4.14 mit einer analogen Konfiguration an. Die Nomenklatur der Dateien sollte klar sein, weitere Releases eines Kernels derselben Version nennen wir gemäß dem Gentoo-Schema -r1, -r2, ...

Die Kernel sind quasi-monolitisch, keine Module. Es ist alles drin, was man so für einen Server-Betrieb braucht, quasi nichts, was man dafür nicht braucht, abgesehen von ein paar Kleinigkeiten, die wir selbst intern benötigen. Man könnte hier sicher über Optimierungen sprechen, allerdings sind all diese Dinge unseren internen Anforderungen geschuldet.

Exemplarisch hier der Auszug der im Archiv des aktuellen 4.14.74 enthaltenen Dateien und Verzeichnisse (gekürzt):

./lib/modules/4.14.74/kernel/
./lib/modules/4.14.74/modules.order
./lib/modules/4.14.74/modules.builtin
./lib/modules/4.14.74/modules.dep
./lib/modules/4.14.74/modules.dep.bin
./lib/modules/4.14.74/modules.alias
./lib/modules/4.14.74/modules.alias.bin
./lib/modules/4.14.74/modules.softdep
./lib/modules/4.14.74/modules.symbols
./lib/modules/4.14.74/modules.symbols.bin
./lib/modules/4.14.74/modules.builtin.bin
./lib/modules/4.14.74/modules.devname
./boot/vmlinuz-4.14.74
./boot/System.map-4.14.74
./boot/config-4.14.74
./usr/share/doc/manitu-kernel-4.14.74/LICENSE.bz2
Ein Hinweis noch zu den Firmware-Dateien, die automatisch geladen werden (die aber nicht enthaltenen sind - siehe config-Datei). Wenn diese nicht vorhanden sind, gibt's nur einen Hinweis. Das tut nicht weh ;-)

Wichtig: Der Kernel steht unter der GNU GPL v2-Lizenz. Diese ist sowohl als Datei in den Verzeichnissen wie auch den tar-Archiven enthalten.

Praxis-Tipp: tar beschleunigen

Ein kleiner Tipp aus unserem Maschinenraum, da wir ja nicht selten mit großen Datenmengen zu tun haben: Wer tar beschleunigen will, kann neben einem anderen Verfahren als gz oder bzip2 oder xz ggf. auf die jeweils parallelen Varianten umstellen.

Dazu braucht man dann pigz (der Name ist in der Tat seltsam), pbzip2 oder pxz - die Varianten der drei o.g. Kompressionsprogramme als "Parallel"-Version.

Was bisher dann z.B.

tar -cJvf foo.tar.xz bar1 bar2 bar3
war, könnte nun z.B.

tar -I pxz -cvf foo.tar.xz bar1 bar2 bar3
sein, gleiches gilt dann für

tar -I pigz ...
oder

tar -I pbzip2...
oder

Der Geschwindigkeitszuwachs ist (auf aktuellen Systemen) enorm.

Prozess aus 2015

Einerseits sicherlich ein Kompliment für die Hardware, aber eigentlich will man sowas nicht auf einem Server sehen ;-)

root 3601 0.0 0.0 27244 576 ? S 2015 424:00 supervising syslog-ng

Für Windows-Samba-Geplagte: convmv

Für Windows-Samba-Geplagte ist das hier ein nützlicher Befehl:
convmv -f cp850 -t utf-8 --nosmart -r .
Wobei cp850 auch ggf. anders sein muss. Es erspart einem viel Sucherei :-D

Zeichen-Sparen

Man sollte es ja im Jahr 2016 nicht mehr meinen, aber manchmal muss man auch heute noch an einzelnen Zeichen sparen, z.B. bei automatisch erzeugten Monitoring-SMS :-)

WhatsApp hat immer noch keine offizielle API, oder?

Erfahrungsbericht eingeschränkte Webhosting-Passwörter

Eigentlich wollte ich das schon viel länger geschrieben haben...

Wir hatten vor längerer Zeit (ich weiß nicht mal mehr genau, wann) die Wahl der Passwörter im Bereich Webhosting, sprich für FTP und Postfächer, eingeschränkt. Nicht nur, dass wir die üblichen Längenbeschränkungen gemacht haben, wir haben uns auch nach langem Für und Wider dazu durchgerungen, eine Blacklist zu verwenden, sprich bestimmte Passwörter nicht (mehr) zu erlauben. Eigentlich nichts Unübliches, aber wir hatten mit Widerstand gerechnet.

Der Widerstand fiel jedoch erstaunlich gering aus. Ja, es gab den ein oder anderen Kunden, dessen Wunsch-Passwort künftig nicht mehr neu setzbar war (alte Passwörter haben wir unangetastet gelassen), aber mit ein oder zwei Antworten und Erklärungen aus dem Support war es meist in Ordnung.

Was wir seit der Umstellung gemerkt haben: Die erfolgreichen Versuche, Passwörter via brute force zu erreichen, sind praktisch auf null zurückgegangen. Kaum ein E-Mail-Konto wird noch zum Versand von Spam missbraucht (sofern der Rechner des Kunden nicht infiziert ist, aber das steht auf einem anderen Blatt). Auch gabe es praktisch keine erfolgreichen Versuche mehr, Webspace via erratenem FTP-Passwort zu defacen oder anderweitig zu missbrauchen.

Alles in allem also, trotz unserer anfänglichen Besorgnis, dass uns unsere Kunden die Blacklist übel nehmen würden, eine gute Entscheidung.