iptables -t nat -I PREROUTING --src 0/0 --dst 127.0.0.1 -p tcp --dport 80 -j REDIRECT --to-ports 8080

Möchte man alle fünf Minuten einen Befehl ausführen lassen, bemüht man hierfür üblicherweise cron und schreibt ihm ein /5 in die crontab. Der Befehl wird dann in den Minuten 0, 5, 10, 15 … 55 ausgeführt. Möchte man den Aufruf aber beispielsweise in den Minuten 2, 7, 12, 17 … 57 ausführen, wird cron einem ein 2/5 als Syntaxfehler um die Ohren schlagen. /5 kann auch als 0-59/5 notiert werden. 2-59/5 erfüllt den Zweck, beginnend ab Minute 2, alle 5 Minuten den Befehl auszuführen.

Um häufig benutzte, komplizierte Shell-Kommandos abzukürzen, kann man ein kurzes alias definieren. Leider können so keine Parameter bzw. Variablen übergeben werden. Alternativ kann man in seiner .bashrc eine Funktion schreiben:

function sshlnxp () { 
    ssh -A user@lnxp-$*.srv.mediaways.net;
}

Soll nur eine Teilmenge einer Tabelle gesichert werden, kann auch dies mit mysqldump erledigt werden. Es bietet hierzu den Parameter --where an, mit dem man eine übliche where clause setzen kann.

mysqldump --where "column=1" dbname tablename

Der Flash Player versucht die Crossdomain-Policy erst vom Port 843/tcp zu laden. Bekommt er dort keine Antwort, versucht er es auf dem Service-Port, den es zu kontaktieren gilt. Bei unseren Anwendung im Amazon EC2 konnten wir dabei ein Problem auf Windows-Systemen beobachten (Mac und Linux hatten keine Schwierigkeiten). Der Flash Player fragte auf 843 an, mehrfach, aber erst viel zu spät auf dem Port des Dienstes, der die Policy ausliefert. Der Flash Player hatte bereits vorher die Verbindung gekappt.

Die Ursache ist nicht ganz klar, scheint aber im NATing zu liegen, dass Amazon für die öffentlichen IPs betreibt. Hierbei wird die Anfrage auf Port 843 ausgebremst. Als wir den Port in der Security Group freigegeben haben (ohne dafür einen Service anzubieten), ging die Anfrage durch, wurde vom Server zurückgewiesen und der Flash Player fragte unsere Anwendung auf dem Service-Port wie gewünscht nach der Policy.

Die Instanzen im Amazon EC2 bekommen dynamische Hostnamen und IP-Adressen. Zur dauerhaften Adressierung kann man Elastic IPs allocieren, die jedoch öffentliche Adressen sind. Will man auf eine andere Instanz in der Cloud zugreifen, möchte man selbstverständlich die lokale IP (RFC1918) nutzen und keine öffentliche (das ist ja auch eine Kostenfrage). Doch Amazon bietet hier eine Möglichkeit: Der Reverse-DNS-Hostname der IP-Adresse wird von den Amazon-Nameservern auf die private Adresse aufgelöst, während er sonst auf die Öffentliche zeigt.

root@domU-xx-xx-xx-xx-xx-xx:~# host 184.73.175.xxx
xxx.175.73.184.in-addr.arpa domain name pointer ec2-184-73-175-xxx.compute-1.amazonaws.com.
root@domU-xx-xx-xx-xx-xx-xx:~# host ec2-184-73-175-xxx.compute-1.amazonaws.com
ec2-184-73-175-xxx.compute-1.amazonaws.com has address 10.253.87.xxx
sw@external:~$ host ec2-184-73-175-xxx.compute-1.amazonaws.com
ec2-184-73-175-xxx.compute-1.amazonaws.com has address 184.73.175.xxx

Mit dem Reverse-DNS-Eintrag der Elastic IP hat man also auch eine statische Adresse für internen Traffic im EC2.

#!/bin/bash
# Reads username:password per line in plain text from stdin
# and feeds smbpasswd to add/update users, similiar to chpasswd
while read line
do
    username="$(echo ${line} | cut -d: -f1)"
    password="$(echo ${line} | cut -d: -f2)"
    (echo $password; echo $password) | smbpasswd -s -a $username
done

Habe Ubuntu 10.04 (Lucid Lynx) auf meinem Laptop installiert. Dabei habe ich den Aufbau der OpenVPN-Verbindungen vom Terminal mittels des Plugins NetworkManager-OpenVPN in den NetworkManager verschoben. Dummerweise überschreibt dieser die Default-Route und setzt stattdessen das VPN als Gateway. Etwas versteckt, ganz unten auf dem Reiter IPv4 Settings, kann hinter dem Button Routes das Routing geändert werden. Mit einem Haken in der Checkbox vor “Use this connection only for resources on its network” kann das Default-Verhalten von OpenVPN wieder hergestellt werden. Das sollte voreingestellt sein. Als ich einen Bugreport schreiben wollte, mußte ich feststellen, dass das Problem kein neues ist. Der Bug ist schon seit längerem bekannt.

Wer Tabellen in Excel oder Calc anhand einer Schlüsselspalte zusammenführen möchte, wird VLOOKUP nicht mehr missen wollen. In deutsch lokalisierten Versionen heißt es SVERWEIS.

Beispiel: SVERWEIS(B2; $K$1:$L$800; 2; 0) fügt anhand des Schlüssels in B2 den Wert aus Spalte Lx ein, wenn B2 und Kx identisch sind.

Weil das hier gerade aufkam, kurz zur Erklärung: Wenn eine Terminalsitzung “einfriert”, hat der Benutzer vermutlich vorher die Tastenkombination Ctrl-S gedrückt. Ctrl-S steht für XOFF, das für die Datenflusskontrolle von asynchronen seriellen Verbindungen benutzt wird. Das Gegenstück ist XON (Ctrl-Q). Ich kenne das noch von den alten Modem-Verbindungen. Also: Wenn das Terminal nicht mehr reagiert, mit Ctrl-Q XON auslösen und weiter geht’s!