28 April – 2 May hailed in a new month with sys admin tips galore and a Request Tracker webinar slipped in.
Ronny began the week by sharing his trick to get Screen to work with SSH agent forwarding properly.
Markus then explained parameterized classes in Foreman as Michael showed how simple it is to configure Icinga 2 using the recent 0.0.10 release.
Last but not least, Christian and Marius held a successful webinar on Request Tracker after a technical hiccup.
NETWAYS Blog
SSH-Agent Forward und Screen
Ich glaube, dass wir Screen und SSH Agent Forwarding nicht weiter im Detail selbst besprechen müssen, aber mit diesem Post möchten wir auf ein Problem hinweisen, welches beim Einsatz von beidem zusammen aufkommt. Hintergrund ist folgender: SSH legt beim Connect mehrere ENV-Variablen an, welche auch den AUTH_SOCK enthalten. Dies ist ein Socket, der für die Kommunikation mit dem lokalen Agent verantwortlich ist und somit die Weiterleitung der Keys ermöglicht.
Unglücklicherweise werden diese EVN Informationen nur beim Start der Screen Session eingelesen, d.h. wenn man sich detached und dann mit einer neuen Verbindung wieder einhängt, enthält die Variable immer noch den alten Pfad, welche dann nicht mehr aktuell ist ( z.B. /tmp/ssh-hYQhk6Nrhq/agent.32462 ). Somit würde eine Verbindung innerhalb vom Screen zu einem Server dann keine Key Authentifizierung mehr durchführen und ein Passwort verlangen, was im ersten Moment dann sehr verwirrend ist.
Man kann sich aber mit einem kleinen Tricken helfen, welcher diesen Socket auf einen generischen Pfad legt. Dazu erstellt man sich eine SSH-RC Datei, die bei jeder Verbindung ausgeführt wird. ( SSH1 ~/.ssh/.rc | SSH2 ~/.ssh/rc )
#!/bin/bash
if test "$SSH_AUTH_SOCK" ; then
ln -sf $SSH_AUTH_SOCK ~/.ssh/ssh_auth_sock
fi
Somit wird ein Link zum jeweiligen Pfad des Socket erstellt, welcher bei jeder Anmeldung dann auch überschrieben wird. Schon haben wir einen festen Namen. Nun geht es nur noch darum, diesen Pfad auch im Screen mit anzuziehen. Dazu erstellt/ändert man nur die .screenrc im Home-Verzeichnis wie folgt:
setenv SSH_AUTH_SOCK $HOME/.ssh/ssh_auth_sock
Als letztes muss die Screen Sitzung nur noch einmal neu gestartet werden, damit die Einstellung greift. Und schon wird bei jeder Neueinwahl auf den Server und ins Screen die korrekte Verbindung zum lokalen SSH Agent hergestellt.
Terminal-Farben für SSH-Hosts vergeben
Wer öfter mit SSH arbeitet, läuft schnell Gefahr die Übersicht über die offenen Remote-Terminals zu verlieren. Damit man nicht versehentlich Befehle auf dem falschen Host ausführt, wäre es sinnvoll die Farben automatisch zu wechseln, sobald man sich mit SSH auf einem neuen Host einloggt. Wenn man ein bisschen sucht, findet man für das Problem gleich mehrere Lösungen, die aber alle einige Nachteile haben: Oft funktionieren diese Lösungen nur für einen bestimmten Terminal-Emulator oder die Farben verschwinden nach dem ersten clear gleich wieder.
Wer eine umfassende Lösung will, kann das Programm Colorize verwenden. Colorize führt ein beliebiges Programm in einem virtuellen Terminal aus und ändert dabei die verwendeten Farben, ohne dass ein neues Terminal-Fenster geöffnet werden muss.
Zuerst compilen wir das Programm und verschieben es nach /usr/local:
./make sudo cp ./colorize /usr/local/bin/colorize
Um die Farben für die einzelnen Hosts zu konfigurieren, wird die neue Datei ~/.ssh/host_colors erstellt. Jedem Host auf jeder Zeile kann im ersten Eintrag eine Hintergrundfarbe und im zweiten Eintrag eine Textfarbe zugewiesen werden. Bei den Farben muss eventuell ein bisschen probiert werden, da die Terminals oft nicht alle Farben unterstützen.
my.production.host 0x990000 0xffffff
Als nächstes muss in der ~/.bash_aliases noch eine Alias gesetzt werden, in dem ssh über colorize aufgerufen wird. Dabei wird die Konfiguration für den Host aus der eben erstellen host_colors geladen:
function colorssh() { if [ $# -gt 2 ] then # colorize only for simple ssh commands ssh "#@" return; fi host=$1; array=(`cat ~/.ssh/host_colors | egrep "^\s*$host\s+" | sed -e "s/^\s*//" | sed -e "s/\s\s*/ /"`) backg=${array[1]} foreg=${array[2]} if [ -z $backg ] then backg="0x111111"; fi if [ -z $foreg ] then foreg="0xffffff"; fi colorize -b $backg -f $foreg ssh "$@" } alias ssh=colorssh
Wenn man jetzt mit ssh den Host my.production.host öffnet, wird sich die die Farbe beim Start automatisch ändern.
Weekly Snap: Git Flow & GeoIP, Rsync & SCP
1 – 5 April kicked off the month with tips for flowing Git branches, SSH transmission speed, clean website code and request redirection.
Eva began by counting 16 days to the OSDC with Benedikt Stockebrand’s presentation “Like Rats on a Sinking Ship” on the end of IPv4.
Stefan then shared his trick to boost SSH transmission speed with SCP and Rsync parameters while Bernd gave us his to redirect requests from specific countries.
To end the week, Eric explained the right flow for Git branching, and Tobias reminded us that clean website code matters to Google page ranks.
SCP und Rsync Boost Parameter
Wer kennt es nicht: Es muss schnell etwas per scp oder rsync aus dem Backup oder einem LVM Snapshot auf einen anderen Server im internen Netz kopiert werden, weil gerade zur ungünstigsten Zeit z.B. eine Datenbank nicht korrigierbar ausgefallen ist.
Da die dabei anfallenden Datenvolumen heuzutage wohl eher beständig mehr als weniger werden, ist jedes bisschen Übertragungs-Speed, das man aus der Leitung kitzeln kann, sehr wichtig.
Was gerne übersehen wird: SSH bietet da zumindest einen Parameter an, mit dem man die Geschwindigkeit ordentlich nach oben schrauben kann durch die Wahl eines anderen Cypher Algorithmus, auch über rsync.
Das ganze bringt satte rund 30% mehr an Daten über die Leitung und spart dadurch natürlich auch entsprechend viel Zeit beim Kopieren.
Als Beispiel ein rsync Befehl, den ich in so einem Fall immer verwende:
rsync -aPHxz --delete -e 'ssh -c arcfour' root@:/foo/bar/* /foo/bar/
Wem das immer noch nicht reicht, der kann zusätzlich auch noch einen anderen ‚message authentication code‘ angeben über den Parameter: ‚-m hmac-md5-96″