Skip to content

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: