Datenbank aus Gesamt-Dump extrahieren

Auf manchen meiner Maschinen erstelle ich Datenbank-Sicherungen gerne zum Beispiel mit einem

mysqldump --all-databases > all.sql

Das hat den Vorteil, dass auch später angelegte Datenbanken automatisch gesichert werden und keine Anpassung von Skripten notwendig ist. Natürlich ist das nur für kleinere Datenbanken gangbar und hat den Nachteil, dass man beim Restore entweder den kompletten Datenbank-Server (also alle Datenbanken) einspielen muss oder aber per Hand (oder sed, awk, …) eine Datenbank oder Tabelle aus dem Gesamt-Dump rausfummeln muss.

Einfacher geht es mit dem, mir gerade vor der Füße gefallenen, mysqldumpsplitter.

MySQL Dump splitter to split / extract databases, tables, list from mysqldump with plenty of more funtionality.

mysqldumpsplitter-Repository

Mehr macht das Skript wirklich nicht: es extrahiert einzelne Datenbanken oder Tabellen aus einer Gesamtsicherung und speichert die am gewünschten Ort. mysqldumpsplitter kann auch mit gepackten Dumps umgehen und extrahierte Daten auch direkt wieder packen. Ein Beispielaufruf sieht also z.B. so aus:

./mysqldumpsplitter.sh --source /mnt/backup/all.sql --extract DB --match_str $DBNAME --decompression none --output_dir /mnt/backup/$DBNAME.sql.gz

Zack, hat man nur die gewünschte Datenbank extrahiert und kann auch nur diese wieder einspielen.

Achtung!

MySQL hat auch die Optionen -D oder –one-database. Das klingt ja erstmal nach einem Verhalten, dass ich mir oben gewünscht habe – ist es aber nicht!

Ein Dump mit der Option –all-databases enthält für jede Datenbank die Statements

DROP DATABASE IF EXISTS dbname; 
CREATE DATABASE dbname; 
USE dbname;

Sofern ihr also z.B. die alphabetisch dritte Datenbank (nennen wir sie C) mit der Option –one-database wieder einspielt, werden die Datenbanken A und B geleert und nicht wieder befüllt. Das muss nicht, kann aber stark nach hinten losgehen – deshalb: wir bleiben beim mysqldumpsplitter.

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, sondern in die Datei /Users/$USERNAME/.ssh/config – diese wird bei Updates nicht angefasst und die dort hinterlegten Änderungen sind dauerhaft.

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!