Episode 68/2017: Durcheinander scp, ssh und uwsgi

Wieder was gelernt. Genauer gesagt, drei Dinge. Fangen wir an:

  1. Caching mit nginx ist eine tolle Sache. Auf einem Server wollten wir die Auswirkung von „Microcaching“, bei dem die Ressourcen beispielsweise nur 1 Sekunde lang vorgehalten werden, prüfen. Caching-Parameter gibt es z.B. als proxy_cache_*, scgi_cache_* oder fastcgi_cache_* Direktiven. Wir brauchten die uwsgi_cache-Direktiven für eine Django-App.
    Alles da, wunderbar.
    Aber: Ausgerechnet das tolle uwsgi-Modul hat keinen Defaultwert beim uwsgi_cache_key. Der Key setzt sich normalerweise aus verschiedenen Parametern wie dem Schema, dem Host und dem Request-URI zusammen, darüber wird ein MD5-Hash gebildet und die Dateien darüber identifiziert.
    Bei leerem Cache-Key wird genau eine Datei zwischengespeichert (die erste, die angefragt wurde) und jeder weitere Request führt zur gleichen Datei. Nicht gut.
  2. Kopieren mit scp. Du sitzt auf Rechner A, willst etwas von Rechner B auf Rechner C kopieren? Von A aus hast Du Zugriff auf B, aber wenn dann von B nach C kopiert wird, fehlen C die entsprechenden Credentials – was tun?
    „scp -3“ kopiert die Datei von B nach A und dann von A nach B. Schön unauffällig, aber sehr praktisch.
  3. Du hast eine ~/.ssh/config Datei mit verschiedenen nützlichen und spezifischen Host-Angaben, insbesondere gibst Du via IdentityFile Deinen Key an? Wenn Du sicherstellen willst, dass wirklich genau nur dieser Key benutzt wird und keine anderen beim Verbindungsaufbau probiert werden, setze „IdentitiesOnly yes“ mit dazu.
    Sagt die Doku: „Specifies that ssh(1) should only use the authentication identity and certificate files explicitly configured in the ssh_config files or passed on the ssh(1) command-line […]“.

Das wars.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert