macOS: SSH-Config dauerhaft speichern

Photo by Kaitlyn Baker on Unsplash

Ich arbeite ja berufsbedingt oft auf Linux-Servern und nutze dafür den in macOS vorhandenen SSH-Client (in Verbindung mit iTerm 2, was aber hierfür nichts zur Sache tut).

Um bequemer zu arbeiten, habe ich mir mit der Zeit eine eigene SSH-Konfiguration zusammengewürfelt, um z.B. automatisch den Login-User, den SSH-Port oder einen Alias für bestimmte Hosts zu setzen.

Daraus folgt, dass ich mich zum Beispiel einfach ohne Angabe des Users, des SSH-Ports oder des vollen Hostname mit einem simplen

ssh management

an meinem Management-Server anmelden kann.

Leider hat macOS seit einigen Versionen eine unschöne Angewohnheit: bei Updates verschiebt es individuell angepasste Konfigurationen in einen Ordner „Neu zugewiesene Objekte“ auf dem Desktop (mehr dazu hier).

Die Lösung für dieses Problem ist allerdings denkbar einfach: die Änderungen an der SSH-Konfiguration einfach nicht in /etc/ssh/ssh_config eintragen, son

Eigene Skripte jetzt öffentlich

Immer mal wieder schreibe ich kleinere oder größere (Bash-)Skripte, die ich schon seit einiger Zeit veröffentlichen möchte. Vielleicht sind sie ja auch für andere nützlich und man muss ja auch nicht immer das Rad neu erfinden…

Ich veröffentliche meine Skripte jetzt bei Github. Hier meine Repositories.

Die Skripte sind sicher nicht immer 100% sauber geschrieben und für den ein oder anderen sind sie sicher auch völlig nutzlos – falls aber doch jemand sich darüber freut, habe ich mein Ziel ja erreicht.

In diesem Sinne: frohe Weihnachten an euch und eure Familien – habt ein besinnliches, ruhiges Weihnachtsfest und lasst es euch gut gehen.

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@nulljordanhillis.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.