Archiv für Februar 2009

WordPress: Doppelte Bindestriche gleich Gedankenstrich?

Beim Verfassen eines Artikels ist mir gestern aufgefallen, dass WordPress aus zwei hintereinander stehenden Bindestrichen einen Gedankenstrich macht. Insbesondere bei Codebeispielen kann das zu unerwünschten Effekten führen.

Im Internet kursieren zahlreiche Anleitungen, wie der in der Datei formatting.php versteckte Fehler behoben werden kann. Diejenigen, die WordPress nicht selbst hosten bzw. keinen Zugriff auf die formatting.php haben, können sich dagegen nur mittels direkter Angabe der entsprechenden numerischen Notation des Bindestrichs nach ISO 10646 behelfen.

Gibt man also statt zwei direkten Bindestrichen zweimal hintereinander die für den Bindestrich stehende Notation - ein, werden die doppelten Bindestriche korrekt dargestellt und nicht zum Gedankenstrich umgewandelt.

Advertisements

Debian Etch: Protokollbasiertes Routing mit iptables & Co

Im Rahmen eines Workarounds musste ich heute an einen bestimmten Webserver gerichteten HTTP Traffic am Standardgateway über ein alternatives Gateway zum Ziel leiten. Das Routing anderer Pakete sollte dagegen unverändert bleiben. Stichwort in diesem Fall ist das so genannte „Policy Based Routing“, mit dem Pakete anhand verschiedener Kriterien individuell weitergeleitet werden können. Ab Linux Kernel 2.6 lässt sich das relativ einfach mithilfe von iptables und unterschiedlichen Routingtabellen lösen.

Im folgenden Beispiel geht es um HTTP Verkehr, der vom Standardgateway (Debian Etch 2.6.18.dfsg.1-13etch2 mit iptables 1.3.6) über das alternative Gatway 192.168.1.2 ins Internet und damit zum Ziel http://www.heise.de aka 193.99.144.85 geroutet werden soll.

Bei Begriffen wie „Protokollbasiert“ oder „HTTP Traffic“ sei noch erwähnt, dass iptables den Verkehr ausschließlich auf Basis von Layer 3 und 4 inspiziert – eine Überprüfung oder Entscheidung anhand des tatsächlichen Application Layer Protokolls findet nicht statt.

Zunächst wird auf dem Standardgateway mit iptables eine Regel in der Mangle-Tabelle erstellt, die entsprechende Pakete in der PREROUTING Kette mit Nummer 15 markiert:

debian:~# iptables -t mangle -A PREROUTING -p tcp -d 193.99.144.85 \
                   --dport 80 -j MARK --set-mark 15

Nach Erstellen der Regel sollte sie in der Mangle-Tabelle aufgeführt werden:

debian:~# iptables -t mangle -nL
Chain PREROUTING (policy ACCEPT)
target  prot  opt  source     destination
MARK    tcp   --   0.0.0.0/0  193.99.144.85 tcp dpt:80 MARK set 0xf

Anschließend wird eine zusätzliche Routingtabelle mit der ID 15 erzeugt und eine weitere Regel angelegt, die alle Pakete mit Markierung 15 über diese Tabelle routet:

debian:~# ip route add table 15 default via 192.168.1.2 dev eth0
debian:~# ip rule add fwmark 15 table 15

Auch diese Einträge sollten anschließend in den entsprechenden Tabellen auffindbar sein:

debian:~# ip route show table 15
default via 192.168.1.2 dev eth0
debian:~# ip rule show
219: from all fwmark 0xf lookup 15

Sind die Regeln aktiv, werden alle Pakete => 193.99.144.85:80 über das neu definierte Gateway 192.168.1.2, alles andere dagegen weiterhin über das ursprüngliche Gateway in der Main Routing Table (ID 254) geroutet.

Achtung: Befinden sich der Host und das neue Gateway im selben Netzwerk, wird das Standardgateway möglicherweise ICMP Redirect Messages zum Host senden und ihm damit quasi „raten“, Pakete => 193.99.144.85 direkt über das neue Gateway zu senden. In solch einem Fall würde der Host eine Hostroute zur 193.99.144.85 über die 192.168.1.2 in seine Routingtabelle eintragen und damit alles in Richtung 193.99.144.85 über das neue Gateway senden. Treten derartige Phänomene auf, sollte das entsprechend kontrolliert und ICMP Redirect ggf. deaktiviert werden.