To ignore hostkey checking for a subnet (i.e. when hosts got changed/provisioned/scaled often) use the following snippet:
# ~/.ssh/config Host 172.18.* StrictHostKeyChecking no UserKnownHostsFile=/dev/null
But use with care, in general hostkey checking is a good idea!
Since macOS sierra the system don’t adds ssh-keys to the agent automatically anymore. Add the following ssh-config file to restore the previous behaviour:
# ~/.ssh/config
Host *
UseKeychain yes
AddKeysToAgent yes
after connecting to a remote shell and typing the passphrase once the key/passphrase will be remembered in the macOS keychain.
Libvirt unterstützt leider noch nicht das Migrieren von VM-Images auf andere Speicherformen – z.B. von NAS auf eine lokale Partition. Dieses muss man dann halt selber machen ;).
Folgendes Kommando holt sich vom entfernten Rechner den Inhalt des dort gemounteten iSCSI Targets und packt ihn in ein lokales Volume (in diesem Fall LVM):
ssh root@cloudnode \
"dd if=/dev/disk/by-path/ip-10.10.199.4:3260-iscsi-cloud1-11-lun-0" \
| buffer -S 10m -s 64k | dd of=/dev/vmdata/vm02
Das Tool “buffer” hat noch den Nebeneffekt, dass es Statistiken zum laufenden Transport ausgibt. Ein ähnliches Tool in dem Zusammenhang ist Pipe-Viewer (pv), welches ich auch immer schon mal erwähnen wollte.
Möchte man die Daten von Cluster-Nodes auf einem gemeinsamen Stand halten gibt es viele Möglichkeiten. Handelt es sich um eine Read-Only Anwendung werden die zugehörigen Dateien meist über einen Master gepflegt und von dort verteilt. Dafür kann man z.B. rsync nehmen – periodisch ausgeführt synchronisiert es zuverlässig die Nodes mit dem Master. Das Problem mit rsync: Die Synchronisation findet nur periodisch statt und nicht live. Außerdem ist bei größeren Datenmengen die Last während der Synchronisation recht hoch.
Warum also nicht nur das synchronisieren was auch synchronisiert werden muss? Genau dafür gibt die inotify-Schnittstelle am Linux-Kernel. Mit entsprechenden Tools überwacht es ganze Dateibäume auf Änderungen und führt bei Bedarf Aktionen aus.
Also habe ich mir ein Script gebastelt welches 1. ein bestimmtes Verzeichnis überwacht und 2. nur die geänderten Dateien/Verzeichnisse unmittelbar mittels ssh verteilt. Voraussetzungen: ssh, scp und inotifywait (enthalten bei den meisten Distributionen im Paket “inotify-tools”). SSH sollte über public keys authentifizieren. Im Kopf von inotifysync.sh müssen die Ziel-Nodes eingetragen werden (diese ändern sich wohl nicht so häufig). Alternativ kann auch eine Datei mit den Ziel-Nodes verwendet werden.
Download: inotifysync.sh
Folgendes Beispiel überwacht das Verzeichnis /home/cluster/htdocs auf Änderungen und synchronisiert diese in das Verzeichnis /var/www/cluster/htdocs auf dem jeweiligen Node:
./inotifysync.sh /home/cluster/htdocs /var/www/cluster/htdocs \
>> /home/cluster/log &
Die Logausgaben werden in die Datei /home/cluster/log geschrieben und das ganze mittels “&” in den Hintergrund geschickt.
Hinweis: Etwas bash Erfahrung sollte man beim Einsatz dieses Scripts schon haben. Einsatz erfolgt natürlich auf eigene Gefahr ;)
Derzeit bin ich auf der Suche nach einem geeignetem Weg um meinen Homeserver ins Rechenzentrum zu sichern. Zunächst ist mir natürlich rsync over ssh eingefallen, aber ich hätte die Daten gerne auf der Remote-Seite verschlüsselt abgelegt… Mit TrueCrypt lokal einen Backup-Container anlegen und dann per rsync sichern? Zu unflexibel. Auf der Remote-Seite einen TrueCrypt Container anlegen? Toll, mindestens jeder root-user kommt ran ;)
Was sich als Ideal herausstellt ist das Tool “duplicity“. Mir ist es irgendwann schon mal aufgefallen da es bei der Synchronisation mit Amazon S3 auch auf librsync setzt. Das es auch verschlüsselt war mir irgendwie entfallen.
Um nur ein paar Features zu nennen: Verschlüsselung mittels gnuPG, Vollsicherung, Incrementelle Sicherung. Dabei setzt es wie gesagt auch die Trafficschonende rsync library ein.
Der Clou sind aber auch die unterstützten Backends/Transportwege. Neben ssh und ftp tauchen auch u.A. AmazonS3 und sogar IMAP in der Liste auf…
Das werde ich auf jeden Fall testen!
Kürzlich kam die Frage auf, ob man nicht nach einem Upload per scp automatisch ein Script auf dem entfernten Rechner anstoßen kann. Prinzipiell gibt es mehrere Ansätze. Bevor es jedoch zu Scripting-Orgien kam, ist Gerd glücklicherweise das Tool dnotify eingefallen (sollte in vielen Distributionen vorhanden sein).
dnotify überwacht Verzeichnisse auf Änderungen. Folgender Befehl überwacht das Verzeichnis /var/www/htdocs und führt bei einer Änderung (-M “Modify”) das angegebene Script aus. Sehr nützlich um z.B. Scripte nach dem hochladen auf einen Cluster zu verteilen.
dnotify -M /var/www/htdocs -e /opt/deploy_scripts.sh > /dev/null &
screen ist ein Programm zum öffnen von virtuellen Konsolen in einer Terminal-session. Ein Screen-Prozess wird mit der Eingabe von “screen” gestartet. Das Screen verlassen (es aber nicht beenden) geht per “CTRL-a d” (CTRL und “a” gleichzeitig, danach ein “d” drücken). Danach kann man sich per “screen -r” wieder zum Screen zurückverbinden. Sehr nützlich z.B. innerhalb von ssh-Sessions. Auch sollte man z.B. kritische Operationen immer im Screen ausführen, da es z.B. bei einer unerwarteten Unterbrechung einer ssh-Session zu problematischen Effekten kommen kann.
Leider vergesse ich (ausser CTRL+a d) immer wieder viele der Tastenkombinationen:
CTRL-a ? Hilfe
CTRL-a " Listet aktive Screens
CTRL-a c Erzeugt einen neuen Screen
CTRL-a d Beendet den aktuellen Screen (er läuft aber im Hintergrund weiter)
CTRL-a Wechselt zum nächsten Screen
Zuerst aktiviert man per “CTRL-a ESC” den Ausgabepuffer, dann kann man per CTRL+f und CTRL+b blättern.
Mittels “screen” kann man auch mit mehreren Personen in einem Screen arbeiten: Einer startet mit “screen” einen neuen Prozess, ein weiterer Benutzer kann sich dann mit “screen -x” zu einer gemeinsamen Konsole verbinden.