Debian Buster: SSH „Connection refused“

Nach einer Neuinstallation oder dem Upgrade auf Debian Buster konnte ich mich nicht mehr per SSH an meinem Server anmelden. Mich begrüßte ständig nur die Meldung Connection refused.

Interessanterweise konnte ich das Problem immer „lösen“, indem ich mich per Konsole direkt an der Maschine angemeldet hatte (geht dank Proxmox ja ganz einfach). Nach nur einem Login funktionierte die SSH-Verbindung wieder problemlos.

Nach einiger Recherche bin ich dann auf diesen Bug gestoßen. Um es kurz zu machen benötigt die Generierung von zufälliger Entropie mehr Zeit als zuvor unter Debian Stretch – der Start des OpenSSH-Servers benötigt allerdings ebendiese Entropie und dauert daher sehr viel länger als zuvor.

Eine einfache Lösung des Problems ist die Installation des Pakets haveged. Direkt nach der Installation dieses Pakets und einem erneuten Neustart ist das Problem behoben.

Was ist haveged? Kurz umrissen haben es die Kollegen des Linux Magazin:

Das Verfahren macht sich den Umstand zunutze, dass moderne Prozessoren Elemente zur Verzweigungsvorhersage (Branch Prediction), Caches, Pipelines und vieles mehr besitzen. Das normale Benutzen der CPU löst ein Trommelfeuer an Statusänderungen bei Tausenden dieser Elemente aus, und genau daraus produziert das Havege-Verfahren viel und hochwertigen Zufall.

Linux Magazin

Das erklärt auch, wieso der Start nun sehr viel schneller von statten geht. Vielleicht hilft es ja dem ein oder anderen verzweifelten Buster-User…

Proxmox: ungenutzte Kernel entfernen

Heute nur ein Kurztipp zum Sonntag!

Jeder Admin kennt das: man nutzt seinen Proxmox-Server schon ein paar Monate und es sammeln sich immer mehr ungenutzte Kernelversionen an… möchte man diese nun entfernen, kann man das natürlich händisch mit dpkg, apt oder aptitude machen – einfacher ist es aber mit pvekclean!

pvekclean ist ein kleines Skript von Jordan Hillis, das man gratis bei Github bekommt. Die Installation ist sehr simpel:

git clone https://github.com/jordanhillis/pvekclean.git
cd pvekclean
chmod +x pvekclean.sh

Fertig!

Beim ersten Start fragt das Skript, ob es sich zum einfacheren Aufruf in den Ordner /usr/local/sbin kopieren darf; kann man halten wie man möchte, ich finde es ganz angenehm. Hat man die Nachfrage bestätigt, kann man das Script ganz einfach via

pvekclean

aufrufen. Die Ausgabe bei mir sah so aus:

█▀▀█ ▀█ █▀ █▀▀   █ █ █▀▀ █▀▀█ █▀▀▄ █▀▀ █
█  █  █▄█  █▀▀   █▀▄ █▀▀ █▄▄▀ █  █ █▀▀ █
█▀▀▀   ▀   ▀▀▀   ▀ ▀ ▀▀▀ ▀ ▀▀ ▀  ▀ ▀▀▀ ▀▀▀

█▀▀ █   █▀▀ █▀▀█ █▀▀▄ █▀▀ █▀▀█
█   █   █▀▀ █▄▄█ █  █ █▀▀ █▄▄▀   ⎦˚◡˚⎣ v1.2
▀▀▀ ▀▀▀ ▀▀▀ ▀  ▀ ▀  ▀ ▀▀▀ ▀ ▀▀
By Jordan Hillis [contact@jordanhillis.com]
___________________________________________

Usage: pvekclean [OPTION]

  -f,   --force         Remove all old PVE kernels without confirm prompts
  -s    --scheduler     Have old PVE kernels removed on a scheduled basis
  -v,   --version       Shows current version of pvekclean
  -r    --remove        Uninstall pvekclean from the system
___________________________________________

OS: Debian GNU/Linux 9 (stretch)
Boot Disk: 74% full [342M/488M used, 121M free]
Current Kernel: pve-kernel-4.15.18-16-pve
___________________________________________

[*] Boot disk space used is healthy at 74% capacity (121M free)
[-] Searching for old PVE kernels on your system...
[*] "pve-kernel-4.15.18-10-pve" has been added to the kernel remove list
[*] "pve-kernel-4.15.18-11-pve" has been added to the kernel remove list
[*] "pve-kernel-4.15.18-12-pve" has been added to the kernel remove list
[*] "pve-kernel-4.15.18-13-pve" has been added to the kernel remove list
[*] "pve-kernel-4.15.18-14-pve" has been added to the kernel remove list
[*] "pve-kernel-4.15.18-15-pve" has been added to the kernel remove list
[-] PVE kernel search complete!
[!] Would you like to remove the 6 selected PVE kernels listed above? [y/N]: Y
[*] Removing 6 old PVE kernels...DONE!
[*] Updating GRUB...DONE!
[-] Have a nice day ⎦˚◡˚⎣

Natürlich sollte man, bevor man die Abfrage zum endgültigen Löschen bestätigt, sicher sein, dass der aktuelle Kernel nicht entfernt wird. Führt man das Skript nun in regelmäßigen Abständen aus, bleibt die Kernelliste auf dem Server immer schön sauber!

Zabbix: Fehler nach Upgrade auf 4.2

Fehler im Zabbix-Frontend

„The frontend does not match Zabbix database. Current database version (mandatory/optional): 4010005/4010005. Required mandatory version: 40200000. Contact your system administrator.“

Diese nette Fehlermeldung hat mich heute nach dem Upgrade meines Zabbix Server auf Version 4.2 begrüßt.

Im Log des Servers habe ich dann den entscheidenden Hinweis gefunden, wieso das automatische Upgrade der Datenbank nicht funktioniert hatte:

[Z3005] query failed: [1071] Specified key was too long; max key length is 767 bytes [create unique index lld_macro_path_1 on lld_macro_path (itemid,lld_macro)]

Letzten Endes hatte ich offenbar beim damaligen Erstellen der Datenbank für Zabbix nicht gut genug aufgepasst und das Charset/die Kollation falsch gesetzt. Sollte euch das auch passiert sein: keine Panik!

Ihr könnt die Datenbank mit zwei einfachen Befehlen auf die empfohlenen Optionen utf8/utf8_bin umstellen, vorher sollte natürlich unbedingt ein Backup der Datenbank stattfinden!

# Herausfinden, ob das falsche Charset gewählt ist
SELECT default_character_set_name FROM information_schema.SCHEMATA S WHERE schema_name = "zabbix";

# Alle Tabellen der Datenbank "zabbix" umstellen
mysql --database=zabbix -B -N -e "SHOW TABLES" | awk '{print "SET foreign_key_checks = 0; ALTER TABLE", $1, "CONVERT TO CHARACTER SET utf8 COLLATE utf8_bin; SET foreign_key_checks = 1; "}' | mysql --database=zabbix

# Die eigentliche Datenbank "zabbix" umstellen
ALTER DATABASE zabbix CHARACTER SET utf8 COLLATE utf8_bin;

Wurden die Befehle korrekt ausgeführt, könnt ihr den Zabbix Server neugestartet werden und das Log sollte nun das korrekt gelaufene Datenbank-Upgrade ausspucken – und das Frontend wieder erreichbar sein.

PHP 7.2 unter Debian 9

PHP wurde Ende letzten Jahres in Version 7.2 veröffentlicht und hat damit einen weiteren Meilenstein hinter sich gebracht. Wer jetzt schon die neuen Funktionen nutzen oder einfach nur aktuell sein will, kann PHP 7.2 unter Debian Stretch ganz einfach nachinstallieren.

Ondřej Surý stellt die aktuellsten Pakete in einem Repository zur Verfügung – man muss also zum Glück nicht selbst kompilieren. Um die Pakete zu nutzen, reichen folgende Schritte aus:

wget -q -O- https://packages.sury.org/php/apt.gpg | apt-key add -
echo "deb https://packages.sury.org/php/ stretch main" | tee /etc/apt/sources.list.d/php.list
apt-get update

Vor dem eigentlichen Upgrade kann man sich kurz die aktuell installierten PHP-Pakete anschauen (z.B. mit dpkg -l | grep php) und die entsprechenden Pakete mit vorangestelltem php7.2 installieren. Beispiel gefällig?

apt install php7.2 php7.2-cli php7.2-common php7.2-curl php7.2-gd php7.2-json php7.2-mbstring \
php7.2-mysql php7.2-opcache php7.2-readline php7.2-xml libapache2-mod-php7.2

Diese Paketliste ist mit Sicherheit nicht für alle Systeme gültig, daher gilt wie immer: erst denken, dann abschreiben! Ich habe danach die alten php7.0-Pakete mit apt entfernt.