Skip to content

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.

Mengenrabatt auf IPv4-Adressen?

Wir diskutieren hier intern gerade, ob ein "Mengenrabatt" auf IPv4-Adressen sinnvoll ist. Unsere aktuelle Aufpreis-Struktur (egal ob bei Root-Servern oder DSL) ist derart, dass es bei größeren Bereichen je IPv4-Adresse günstiger wird.

Einerseits entspricht das dem gängigen kaufmännischen Verhalten: Beziehe ich mehr, zahle ich umgerechnet weniger je Einheit.

Andererseits widerspricht es dem technischen Gedanken, eine gewisse Sparsamkeit bei IPv4-Adressen walten zu lassen. Es verleitet dazu, mehr zu "brauchen" als es wirklich nötig ist. Natürlich prüfen wir den Bedarf gemäß RIPE-Richtlinien, aber sind wir mal ehrlich: Es gibt viele Buzz-Words, die sind schlagkräftig genug für eine Zuteilung, aber kaum nachprüfbar.

Wie seht Ihr das?

DSA-Key für OpenSSH wieder aktivieren

Wer übrigens nach einem Upgrade von OpenSSH (auf Version 7.0) auch mit seinem DSA-Key nicht mehr "reinkommt", dem könnte ein
PubkeyAcceptedKeyTypes=+ssh-dss
in der /etc/ssh/sshd_config bzw. ~/.ssh/config helfen!

:-)

Ersatz für ntpdate

Wer übrigens mal "Ersatz" für ntpdate sucht:
timeout -k 10 ntpd -s -d
Hässlich, aber funktioniert ;-)

Indifferenzen bei Antworten von BIND

Wenn jemand auch mal am verzweifeln ist, warum zwei theoretisch identische Abfragen an denselben BIND-DNS-Server unterschiedliche Antworten liefern, könnte es daran liegen, dass der eine via UDP und der andere (sehr ungewöhnlich, aber dennoch möglich) via TCP abfragt, und der BIND nicht sauber neu gestartet ist.

:grrr: