postfix: IP-Adresse des Absenders verbergen

Nach langer Zeit gibt es heute mal wieder einen kleinen Post aus der Sysadmin-Ecke.

Die Ausgangslage

Ein Benutzer liefert seine Emails mit Authentifizierung bei einem durch mich betriebenen Mailserver ein, der für die entsprechende Domain zuständig ist.

In den Headern dieser Mail wird nun die IP-Adresse auftauchen, von der aus die Email eingeliefert wurde. Dies kann die IP zu Hause sein, die von einem Bekannten oder die von einer Institution. Postet derjenige häufiger auf Mailinglisten kann man so schon ein Profil erstellen und bekommt auf jeden Fall heraus, dass er z.B. Emails von der Uni aus sendet, etc.

Dies möchte man nun verhindern - und das funktioniert mit postfix Bordmitteln sogar relativ einfach.

Mehr Information ist am Ende doch weniger

Zunächt müssen wir die entsprechenden Header erkennen können. Da bei allen nicht-authentifizierten Emails die IP-Adresse des einliefernden MTA im Header unverändert erhalten bleiben soll, schon um Spammer identifizieren zu können ohne extra in die Logs schauen zu müssen, brauchen wir einen Weg, die passenden Received:-Header zu erkennen. Dies erreichen wir, indem wir dem postfix sagen, dass er den Benutzernamen des Absenders auf dem Mailserver in den Header einfügen soll. Dies geschieht über die Anweisung smtpd_sasl_authenticated_header = yes in der Datei main.cf des postfix.

Unser header sieht nun ungefähr so aus:

Received: from [192.168.101.150] (guest123.guest.example.org [192.0.43.10])
  (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
 (No client certificate requested)
 (Authenticated sender: username)
 by mail.somedomain.tld (Postfix) with ESMTPSA id 32A59B1C032
 for ; Thu, 30 Jun 2011 12:36:07 +0200 (CEST)

Die hervorgehobene Zeile ist neu hinzugekommen und ermöglicht es uns im zweiten Schritt nach genau diesen Headern zu suchen.

pcre ftw!

postfix bietet dafür die Möglichkeit der header_checks. Damit kann man mittels (perl) regular expressions auf den Headern der Email arbeiten und Zeilen einfügen, Zeilen ändern und eigentlich vor allem Aktionen auslösen wie das Aufhalten einer Email, Abweisen, Weiterleiten, etc.

Wir benutzen diese Möglichkeiten, um auf der oben gezeigten Received:-Zeile ein paar Ersetzungen vorzunehmen.

Dazu stellen wir zunächst sicher, dass die main.cf des Postfix auch header checks aktiviert hat:

 smtpd_sasl_authenticated_header = yes
 ...
 header_checks      =  pcre:/etc/postfix/header_checks
 mime_header_checks =  pcre:/etc/postfix/header_checks

Nun koennen wir in der angegebenen Datei header_checks mit folgender Zeile das Umschreiben aktivieren:

/^Received:\ from (.*)\(.*\)(.*)\(Authenticated\ sender:\ .*\)(.*by mail\.somedomain\.tld.*)$/U  REPLACE Received: from $1 (Remote IP hidden) $2(Sender was authenticated on somedomain.tld) $3

Hinweis: Die Zeile ist relativ lang, beim Kopieren aufpassen sie komplett zu erwischen. Wichtig ist die Option U an der Regex, diese schaltet sie auf ungreedy. Siehe man pcre_table.

Der Name des Mailservers taucht hier nochmal auf, damit ich die Original-IP bei extern eingelieferten Emails nicht verwerfe - das kann zum Identifizieren von Spammern helfen, auch wenn die Header oft gefälscht sind.

Im Ergebnis sieht der Header der Email nun aus wie folgt:

Received: from [192.168.101.150]  (Remote IP hidden) 
 (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
 (No client certificate requested)
 (Sender was authenticated at somedomain.tld) 
 by mail.somedomain.tld (Postfix) with ESMTPSA id A36241184685
 for ; Fri, 29 Jul 2011 20:23:31 +0200 (CEST)

Wenn man die private IP auch noch entfernen möchte, kann man sich jetzt natürlich einen weiteren Header-check überlegen, der auf '\[.*\].*Remote IP hidden' triggert und diese ersetzt. Das kann im Einzelfall notwendig werden, wenn kaputte Antispam-Maßnahmen anderer Empfänger solche Emails ablehnen.

Wenn man misstrauisch ist fügt man ausserdem noch eine Zeile hinzu, die jedes Vorkommen von '(Authenticated sender: ...)' mit etwas belanglosem ersetzt, falls man unter allen Umständen die internen Nutzernamen geheim halten will.

Effizienter Desktop mit fluxbox

Nach langer Zeit mal wieder ein kleines Posting von mir. Diesmal zum Thema Organisation des Desktops bzw. Windowmanagers

Vor zwei Tagen bin ich auf der Suche nach einem neuen Windowmanager auf Anregung von Seba auf fluxbox umgestiegen. Flott, schlank, stark konfigurierbar. Auch wenn ich nach wie vor ein paar Gimmicks vermisse, habe ich Features entdeckt, die ich glaube ich nicht mehr missen will.

Dinge die ich vermisse

Der System-Monitor von Gnome war doch ganz praktisch. Man konnte in einem Panel die CPU-Auslastung sehen und den Speicherverbrauch. Aktuell habe ich nur die CPU-Auslastung beider CPUs ohne Unterscheidung in Nice, System und IO-Wait. Die wmaker-Docks sind mir zu groß und außerdem nicht im Panel. Ein 'swallow' wie damals beim fvwm2 wäre toll, um Anwendungen in das Panel einzubinden.

Die Arbeitsflächen lassen sich nicht zweidimensional anordnen, d.h. ich kann immer nur nach links und rechts, nicht nach oben und unten wechseln. Das war aber relativ effizient, um schnell zwischen Anwendungen zu wechseln. Eine Sache der Gewöhnung, hoffe ich.

Das Killer-Feature

Eines der Killer-Features schlechthin ist aber die Möglichkeit, beliebige Aktionen, per MacroCommand auch mehrere, auf Tastaturshortcuts zu legen.

Nicht nur, dass man damit Dinge wie das Maximieren oder Umschalten der Arbeitsflächen anpassen kann, man kann auch neue Funktionalität schaffen, zum Beispiel einer Anwendung eine Tastenkombination zuordnen und sie nur dann starten wenn sie noch nicht läuft.

Aktuell ist mein fluxbox nun so konfiguriert, dass Programme wie Firefox, Thunderbird, etc. eine Tastenkombination haben, die entweder auf die Arbeitsfläche mit der Anwendung umschaltet und sie anzeigt oder aber eine Dialogbox aufpoppt mit der Frage, ob sie gestartet werden soll. Zusätzlich ist den Anwendungen eine Arbeitsfläche und Größe fest zugeordnet, auf der sie starten sollen.

Läuft die Anwendung also noch nicht, startet sie unsichtbar auf ihrer Arbeitsfläche und ich kann dann später dorthin umschalten, sobald sie bereit ist.

Gerade das Umschalten zum Instant-Messenger oder Mediaplayer und wieder zurück zum Browser oder der IDE ist damit sehr schnell möglich.

Hinweis: Eventuell klappt das nur mit der aktuellen git-Version von fluxbox, da NextWindow unter Umständen nicht alle Workspaces durchsucht.

Hier die relevanten Auszüge:

~/.fluxbox/keys:

Mod4 C :Reconfigure
Mod4 F :If {Some Matches (class=Iceweasel)} {NextWindow (class=Iceweasel)}  {Exec ~/.fluxbox/bin/fbexec.sh iceweasel}
Mod4 G :If {Some Matches (class=Gmpc)     } {NextWindow (name=gmpc) (class=Gmpc)} {Exec ~/.fluxbox/bin/fbexec.sh gmpc }
Mod4 M :If {Some Matches (class=Icedove)  } {NextWindow (class=Icedove) } {Exec ~/.fluxbox/bin/fbexec.sh icedove}
Mod4 P :If {Some Matches (class=Pidgin)   } {NextWindow (class=Pidgin)  } {Exec ~/.fluxbox/bin/fbexec.sh pidgin }
Mod4 R :If {Some Matches (class=RSSOwl)   } {NextWindow (class=RSSOwl)  } {Exec ~/.fluxbox/bin/fbexec.sh ~/bin/RSSOwl.sh}

Anm: Mod4 ist die 'Windows'-Taste. Die Werte für class habe ich der apps-Datei entnommen, die fluxbox automatisch erweitert, wenn man mit der rechten Maustaste auf eine Titelleiste klickt und 'Remember' anklickt um Attribute wie den Workspace der Anwendung zu speichern. Alternativ geht auch xprop oder wmctl -l ~/.fluxbox/apps:

...
[app] (name=Navigator) (class=Iceweasel) (role=browser)
  [Workspace]   {5}
  [Dimensions]  {1198 682}
  [Position]    (UPPERLEFT)     {0 80}
[end]
...

~/.fluxbox/bin/fbexec.sh:

#!/bin/sh

#timeout returnes 0 (success) thus we have to use || here:
xmessage -center -buttons 'yes:1,no:0'  -timeout 5 "about to exec $@" || exec "$@"

Vorlesungsverzeichnis der TU-Berlin (Backup)

Die Freitagsrunde hat sich wieder die Freiheit genommen, eine Kopie des Vorlesungsverzeichnisses der TU-Berlin anzulegen, falls die Server überlastet sein sollten. Bitte weitersagen.

Das Vorlesungsverzeichnis für das Wintersemester 2010/2011 findet sich nun auch hier: offizielles Vorlesungsverzeichnis der TU-Berlin (Kopie).

In den Ordnern sind jeweils die pdf-Versionen der Fakultäten abgelegt. Auf oberster Ebene auch nochmal ein Archiv als zip und tarfile.

Update: Ja, das Backup des Vorlesungsverzeichnis ist in den letzten Jahren rege genutzt worden, weil der Typo3 doch ab und zu ausfällt und das lsf-web einfach überlastet ist. Und ich hoffe dass dieser Eintrag jetzt auch genügend Stichworte für die Google-Trefferliste hat ;o). Die billigen Tricks wie finden sie HIER mehr über TU-Berlin Vorlesungsverzeichnis oder Backup Vorlesungsverzeichnis TU Berlin lasse ich mal weg...öhm - wait... mist ;)

md-raids aus USB-Platten und automatische Checks...

Falls ihr externe USB-Platten als Raid einsetzt, werdet ihr wissen, dass es mitunter Tage dauern kann, bis ein Rebuild oder Check des Raids komplett ist:

md4 : active raid5 sdc[0] sdf[3] sde[2] sdd[1]
      2930287488 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
      [>....................]  check =  0.9% (8861912/976762496) finish=1374.5min speed=11735K/sec

Falls ihr euch nun wundert, warum das Raid an einem Sonntag Abend auf einem Debian System sehr träge reagiert und 50% der CPU durch einen Thread mit dem Namen md4_raid5 belegt sind, empfehle ich euch mal den Cronjob des mdadm anzusehen.

Dieser läuft am ersten Sonntag jedes Monats und prüft das Raid auf Konsistenz. Einerseits recht nützlich kann es aber auch störend sein - dauert es doch wie gesagt relativ lange. Zudem gibt es unter Debian bei manchen Installationen einen Bug, so dass der Cronjob jeden Sonntag läuft.

Um einen laufenden Check abzubrechen genügt ein:

/usr/share/mdadm/checkarray -x --all

Der Cronjob ist in der /etc/cron.d/mdadm definiert.

Komplett deaktivieren ist aber auch unschön, weil es das Erkennen von Fehlern auf dem Raid verhindert. Bei Mirror-Raids ist das Fatal, beim Ausfall einer Platte in einem Raid5 ebenfalls, weil dann unter Umständen keine reduntenten Informationen zum Wiederherstellen vorhanden sind.

How to disable AAAA queries for IPv6 / configure your resolver

Today I stumbled upon a very nasty behaviour of glibc - again.

On a host which has no access to IPv6 at all and no module-support in the kernel, it seems the connect() call fails when there is a AAAA record in place for a remote server.

This means I cannot wget a webpage if an AAAA record exists for the page, etc.

You will find many solutions on how to 'disable IPv6' - but they all miss the resolver in glibc, the part that is behind the 'gethostbyname' call.

I like to disable AAAA DNS-queries for IPv6 completely - and the solution is easy:

#cat /etc/resolv.conf 
options no-inet6
nameserver ...
nameserver ...

Just documenting it here, because the manpage does not document the 'no'-Feature and searching for this on google was not helpful at all.

Scrollen mit dem Touchpad...

Kleiner Tipp am Rande: Wer sich wie ich darüber ärgert, dass nach einem Update des X-Servers bzw. des synaptic Touchpad-Treibers das scrollen per Touchpad nur noch an der rechten Seite des touchpads funktioniert und nicht mehr, wenn man zwei Finger auf das Touchpad legt, kann das alte Verhalten schnell durch Aufruf des 'synclient' wiederherstellen.

Die Konfiguration erfolgt bei aktuellen xorg-Versionen ja nicht mehr in der xorg.conf...

Bei der Gelegenheit habe ich auch gleich das vertikale Scrollen aktiviert und Klicks und Doppelklicks eingeschaltet:

   #Scrollen in alle Richtungen gleichzeitig:
   synclient VertTwoFingerScroll=1
   synclient HorizTwoFingerScroll=1
   #Klicken mit linker Taste:
   synclient TapButton1=1
   #Meine default-Werte:
   synclient MaxTapTime=180
   synclient MaxDoubleTapTime=180

Das obige snippet habe ich jetzt einfach in meine .xinitrc eingebaut, fertig.

1. Nachtrag: Die Freude hält sich in Grenzen - nach einem Suspend to RAM muss man das kleine Script nochmal ausführen, damit das Touchpad konfiguriert ist. Offenbar sichert der synaptics-Treiber den Status nicht korrekt bzw. stellt ihn nach dem Aufwachen nicht wieder korrekt her. *grr*

Präsentationen mit LaTeX und... pdfPres!

Wer so wie ich Fan von LaTeX ist, wird sich über dieses Programm freuen:

pdfPres zeigt die aktuelle Folie, die letzte und die folgende sowie Notizen an. Die Folien sind als pdf Datei vorhanden, die Notizen werden in einer xml-Datei gehalten. Der Clou ist aber, dass ein zweites Fenster nur die aktuelle Folie anzeigt, so dass man dieses auf den zweiten Desktop schieben kann und so per Beamer dem Publikum zeigt.

Außerdem kann man in seiner Vorschau blättern ohne das Publikum durch Folienwechsel zu verwirren.

Download per git von http://github.com/vain/pdfPres/

Presenter-Keyodes mappen

Was tun, wenn die Software zum Blättern die Cursortasten 'Links' und 'Rechts' verlangt, der Presenter aber nur die Bild auf und Bild ab Tasten als Keycodes sendet?

Die Frage wurde mir vorhin in einem telefonischen Notruf 5 Minuten vor Beginn einer Präsentation gestellt... Damit es beim nächsten Mal schneller geht hier die Doku.

Nun, zunächst sucht man per xev die Keycodes der betreffenden Tasten und xmodmap -pr die Namen der Zieltasten.

Man erhält dann sowas:

Taste	Keycode	Name in X
Bild auf	112	Prior
Bild ab	117	Next
Links	113	Left
Rechts	114	Right

Und nun mappen wir fröhlich die Tasten um:
Bild auf soll Cursor links werden:
xmodmap -e "keycode 112 = Left"
Bild ab soll Cursor rechts werden:
xmodmap -e "keycode 117 = Right"

Und wenn man Ersatz für die Cursortasten will:
Links soll Bild auf werden:
xmodmap -e "keycode 113 = Prior"
Rechts soll Bild ab werden:
xmodmap -e "keycode 114 = Next"

Unter OpenWRT per DHCP den NTP announcen

Wer sich wundert, warum die Rechner zu Hause den NTP-Server des eigenen Routers einfach nicht benutzen wollen, sollte mal per tcpdump nachsehen, ob die DHCP-Option 42 auch gesendet wird... Wenn nicht muss man auf dem Router in der /etc/config/dhcp das Schlüsselwort dhcp_option benutzen:

config dhcp lan
        option interface        lan
        option start            100        
        option limit            150
        option leasetime        1h
        list dhcp_option '42,10.1.1.1'

Hier wird den Clients im LAN mitgeteilt, dass man 10.1.1.1 als NTP-Server nutzen will...

IO-Durchsatz und kernel neuer 2.6.28

Kurze Notiz: Wer auch wie ich das Problem hatte, dass manche Anwendungen wie liferea das gesamte System einfrieren lassen, wenn sie ein bischen IO machen (eine sqlite-db nutzen z.B.) kann ich ein downgrade auf Kernel 2.6.28, z.B. 2.6.28-gentoo-r5, empfehlen. Seitdem ich von 2.6.33 umgestiegen bin, kann ich wieder Multitasking machen und liferea benötigt keine 20-30 Sekunden pro Artikel(!) zum Darstellen, wenn mal ein Bild enthalten ist. Auch insgesamt ist das System wesentlich responsibler geworden und damit wieder benutzbar. Das Problem als solches stellte sich durch 80-90% iowait dar - so dass ich trotz Dualcores nicht mehr arbeiten konnte, weil der IO Scheduler das System schlicht und einfach komplett lahmgelegt hat. Ich hoffe das wird mal wieder besser *seufz*

Heute ist Bundestagswahl: Geh Wählen!

Ein kurzer Reminder an alle: Heute, am 27.09.2009, ist Bundestagswahl Wer nicht wählen geht, darf sich hinterher nicht beschweren! Ansonsten gilt (nach GBO) für die Wahl dasselbe wie für den Zahnarzt: Geht man zu lange nicht hin, wird's braun. In diesem Sinn: Beweg Dich und geh zur Bundestagswahl! ... damit sie sich noch wünschen wir wären nur politikverdrossen!

Webseiten automatisch vor Überlast schützen am Beispiel einer MediaWiki-Seite

Das Szenario: Man ist stolzer Betreiber eines eigenen Servers auf dem ein Wiki läuft. Plötzlich berichtet Heise über das eigene Projekt oder man wird von einer anderen der großen Nachrichten-Portale verlinkt und plötzlich geht auf dem Server gar nichts mehr. Selbst der Zugriff per SSH um zu schauen was los ist funktioniert nicht mehr richtig und alle Nagios-Instanzen schlagen Alarm.

Damit es zu diesem Szenario nicht kommt, gibt es natürlich verschiedene Ansätze. Von redundant vorgehaltenen Servern, die per DNS Round-Robin angesprochen werden, über Loadbalancer auf Routingbasis, etc.

Viele dieser Maßnahmen sind aber entweder recht kostspielig oder haben den Nachteil nicht so gut mit soetwas wie einem Wiki zusammenzuarbeiten.

Es gibt aber eine weitere Möglichkeit, die den Dienst http://coralcdn.org benutzt.

Coral Content Distribution Network

Das Coral Content Distribution Network funktioniert transparent durch das Anhängen einer Domain des Dienstes an eine beliebige Webadresse. So wird aus www.google.de ganz schnell die gecachte Version, wenn man statt dessen www.google.de.nyud.net aufruft.

An dieser Stelle vielen Dank an rbu für den Hinweis auf Coral!

Doch wie kann man diesen Dienst benutzen, um ein Wiki bei Überlast des Servers noch einigermassen erreichbar zu halten?

Ein eigener Host für Coral

Zunächst habe ich zum Testen einen weiteren Virtual Host für das Wiki aufgesetzt, so dass ich dort Einstellungen machen kann, ohne das Wiki unbrauchbar zu machen.

Ausserdem hat das den Vorteil, dass ich https-Zugriffe verhindern bzw. umlenken kann, die über Coral natürlich nicht richtig funktionieren.

Und, noch etwas, dieser Virtual Host soll später vielleicht mal auf einen weiteren Rechner umziehen und kann so noch mehr Last abfedern, indem er statische Dateien wie Bilder direkt aus seinem Cache ausliefert.

Dieser VHost hört auf den originellen Namen cache.meinedomain.tld.

Folgende Parameter wurden (zusätzlich) gesetzt:

      #Dies soll ein Proxy werden, also Zugriff auf
      #folgende Seiten per proxy erlauben:

      <Proxy proxy:http://wiki.meinedomain.tld/ >
            Order deny,allow
            Allow from all
      </Proxy>

      ProxyVia On
      ProxyRequests Off

      #Diese Seite liefern wir auf / aus:
      ProxyPass / http://wiki.meinedomain.tld/
      ProxyPassReverse / http://wiki.meinedomain.tld/

      #Ausserdem Cachen wir auf der Festplatte
      CacheRoot /var/cache/apache2
      CacheDirLevels 2
      CacheDirLength 10
      CacheMinFileSize 10
      CacheMaxFileSize 2000000
      CacheEnable disk /
      CacheEnable disk http://wiki.meinedomain.tld/
      CacheEnable disk proxy:http://wiki.meinedomain.tld/

      #Die Cookies wollen wir nicht mit speichern...
      CacheDefaultExpire 3600
      CacheIgnoreHeaders Set-Cookie

      # Bis hier war das nur die (optionale) proxy-Konfiguration
      # kommen wir nun zum LoadBalancer

      RewriteEngine on
      RewriteCond %{HTTP_USER_AGENT} !^CoralWebPrx
      RewriteCond %{QUERY_STRING} !(^|&)coral-no-serve$
      RewriteMap    lb      prg:/var/www/loadbalance.sh
      RewriteCond   ${lb:%{REQUEST_URI}|NULL} !^NULL
      RewriteRule   ^(.*)$ ${lb:$1|%1}           [P,L]

Der zweite Block definiert ein shellscript als Entscheidungshilfe für das Ziel eines Redirects, wenn der Request nicht von dem coral-webproxy kam. Diese Ausnahme müssen wir konfigurieren, da wir sonst den Coral-Server auf sich selbst umlenken würden.

Und dieses Script ist auch schon das Geheimnis.

Das Redirect-Script

Das folgende Script wird vom apache sofort beim Start geforkt und erhält auf stdin fortan die angefragte URL und kann auf stdout dann ausgeben, wohin denn der Request umgelenkt werden soll.

Damit kann man nun nach eigenem Ermessen Paramter suchen, die für einen Redirect sorgen sollen.

Ich nehme hier das maximum von zweien der Load-Werte, so dass bei zuviel Ansturm die Besucher umgelenkt werden und mit Abflauen des Ansturms (die Besucher bleiben dann ja auf dem Proxy) auch wieder neue Besucherrequests angenommen werden.

Ein wenig zusammengehackt und sicherlich nicht die schnellste Implementierung, aber es erfüllt erstmal seinen Zweck, sollte aber durch ein C-Programm ersetzt werden, welches ein _wenig_ effizienter implementiert ist.

#!/bin/bash

loadbalancer="cache.meinedomain.tld.nyud.net";

while read LINE; do
 load="$(awk '{gsub("\\.",""); if ($1>$2){ print $1} else { print $2 }  }'< /proc/loadavg)"
 if [ "$load" -gt "$(cat /var/www/maxload.conf)" ]; then
   logger -t "loadbalance-cache" "redirecting due to load=$load. request: $LINE"
   printf "http://%s/%s\n" "${loadbalancer}" "${LINE}"
 else
   printf "NULL\n"
 fi
done

In der Datei /var/www/maxload.conf habe ich testweise einfach die Zahl 550 eingetragen, so dass ab einer Load größer 5.5 ein Redirect erfolgt.

Konfiguration des Wikis

Bei Zugriffen über den Proxy muss das Wiki read-only arbeiten. Dafür gibt es mehrere Gründe:

Zum Einen sollen nicht die privaten Previews eines Benutzers gecached werden, zum anderen redirecten wir ja wegen hoher Last - und ein Edit eines Artikels wird sicherlich nicht zum Senken der Last beitragen.

Dazu gibt es einen Codeblock in der LocalSettings.php des Wikis:

if ( preg_match( "/^CoralWebPrx/", $_SERVER['HTTP_USER_AGENT']) > 0
    || preg_match( "/coral-no-serve$/", $_SERVER['QUERY_STRING']) > 0) {

 $wgReadOnly="<span style=\"background-color:yellow;\">Das Wiki ist aus Lastgründen read-only. Du greifst daher gerade über ein Cache auf eine gespeicherte Version zu.</span>";
}

Dadurch verlieren wir zwar auch die PageHits-Zählung im Wiki, aber über einen Proxy werden diese ohnhin nicht mehr korrekt gezählt.

Konfiguration des Wiki-Hosts

Nachdem alles getestet ist und funktioniert, können wir bei Überlast alle Requests auf den Wikiserver direkt auf die cache-Variante von Coral lenken. Dies machen wir mit einigen Zeilen in der Definition des Virtual Hosts:

RewriteEngine on
RewriteMap    lbwiki      prg:/var/www/wiki.meinedomain.tld/loadbalance.sh

Folgende Regeln fügen wir nun an die .htaccess des Wikis an. Das muss geschehen, da wir dort noch andere Rewrite-Regeln definiert haben.

# Alle requests des coral-proxies auf den cache lenken,
# requests von unserem Cache nicht auf unser Cache umlenken.
RewriteCond %{REMOTE_ADDR} !^127.0.0.1$
RewriteCond %{REMOTE_ADDR} !^IP.DES.EIGENEN.PROXIES$
RewriteCond %{HTTP_USER_AGENT} ^CoralWebPrx
RewriteRule   ^(.*)$ http://cache.meinedomain.tld/$1           [R,L]

RewriteCond %{REMOTE_ADDR} !^127.0.0.1$
RewriteCond %{REMOTE_ADDR} !^IP_DES_CACHES$
RewriteCond %{QUERY_STRING} (^|&)coral-no-serve$
RewriteRule   ^(.*)$ http://cache.meinedomain.tld/$1           [R,L]


#Folgender Block prueft ob die load zu hoch ist und
#redirected dann auf den gecachten cache...
#RewriteMaps muessen global in der vhost konfig gemacht werden.
RewriteCond %{REMOTE_ADDR} !^127.0.0.1$
RewriteCond %{REMOTE_ADDR} !^IP_DES_CACHES$
RewriteCond %{HTTP_USER_AGENT} !^CoralWebPrx
RewriteCond %{QUERY_STRING} !(^|&)coral-no-serve$
RewriteCond   ${lbwiki:%{REQUEST_URI}|NULL} !^NULL
RewriteRule   ^(.*)$ ${lbwiki:$1|%1}           [R,L]

Wichtig ist hier, dem LoadBalancer einen anderen Namen zu geben.

Wir benutzen für diesen Artikel wieder dasselbe script, so dass direkt auf den Host cache.meinedomain.tld.nyud.net verwiesen wird.

Der erste Block ist eher 'Kosmetik' und verhindert, dass man auf wiki.meinedomain.tld über Coral zugreifen kann.

gpg: SHA1 durch SHA256 ersetzen

Es ist wieder einmal Zeit, einem alten Freund Lebewohl zu sagen.

Wir trauern um
SHA1
*1995       †2009

Viele Jahre hat SHA1 uns stets dabei unterstützt, unsere Nachrichten unverändert ans Ziel zu bringen. Als Nachfolger von SHA0, der viel zu früh von uns gegangen ist, gab uns SHA1 wieder Zuversicht. Doch letzlich mussten wir lernen, dass nichts von Dauer ist.

SHA1 - Du wirst stets unvergessen bleiben.

Die Beisetzung findet im engsten Kreise statt. Wir bitten von Beileidsbekundungen am Grab Abstand zu nehmen. Statt Blumen bitten wir um die Umstellung Ihrer Applikationen auf stärkere Hashverfahren.

In tiefer Trauer,
die Internetgemeinde.

Mehr Informationen gibts hier.

Aus diesem Artikel habe ich auch den Hinweis entnommen, wie man in GnuPG die Hash-Algorithmen 'umstellt':

Zunächst sollte man dafür sorgen, dass alle Nachrichten, die man selbst signiert, nicht mehr mir SHA1 signiert werden. Dazu fügt man an die Datei gpg.conf im .gnupg Verzeichnis zwei drei Zeilen an:

cat >>~/.gnupg/gpg.conf <<EOF
personal-digest-preferences SHA256
cert-digest-algo SHA256
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
EOF

Danach teilt man noch den Gesprächspartnern mit, dass man gerne mehr Sicherheit hätte, indem man die Vorgaben seines Schlüssels ändert:

$ gpg --edit-key $KEYID
[...]
> setpref SHA512 SHA384 SHA256 RIPEMD160 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
> save

und den geänderten Schlüssel wieder veröffentlicht:

$ gpg --keyserver keys.gnupg.net --send-key $KEYID

---

PS: Die 'Vorschau' von Blogger saugt :( PPS: SHA-1 wird immer ale eine der letzten enthalten sein, weil der RFC das verlangt, aber wichtig ist die Reihenfolge - es ist dann nur noch Fallback. Update: Wie das Update des Originalartikels habe ich "default-preference-list" hinzugefügt, damit neue keys gleich entsprechend erstellt werden.

'Kinderpornosperre' in 27 Sekunden 'umgehen'

Einfach um zu zeigen wie schwachsinnig die Pläne unserer Regierung sind hat jemand ein kleines Video gedreht. Es zeigt, wie man innerhalb von 27 Sekunden(!) die geforderten Sperren mit Stoppseiten etc. umgehen kann. Viel Spaß: Internetsperre in 27 Sekunden umgehen

Unter Linux geht es natürlich noch schneller:

  $ echo "nameserver 193.254.184.230" > /etc/resolv.conf

oder

  $ sudo bash -c 'echo "nameserver 193.254.184.230" > /etc/resolv.conf'

große pdf-Dateien mittels gimp und LaTeX verkleinern

Alles fing damit an, dass ich 10 Seiten Unterlagen von einer Bekannten kopiert haben wollte. Sie wohnt nicht in Berlin, also auf den Kopierer werfen ging nicht so einfach.

Sie hat aber einen Scanner und eine Software, die aus den Scans offenbar zusammenhängende pdf-Dateien erzeugen kann. Soweit so gut.

Als ich das pdf dann von ihrem Webspace gezogen habe, wurde ich ob der Größe der Datei schon einmal stutzig - war die Datei doch 38 Megabyte groß.

Ausserdem hatten die Scans schwarze Ränder - sowas mag ich beim Ausdruck nicht haben.

Erster Versuch

Man ist ja erfinderisch, also was tut man, richtig, man importiert das pdf erstmal in gimp und sagt, dass man keine einzelnen Ebenen pro Seite sondern eigene Bilder pro Seite haben will.

Mein Notebook knallte daraufhin seine 2GB Ram und 1GB SWAP zu und die CPU (Dualcore, 2,4 GHz) war auch beschäftigt. Gut, also war das keine gute Idee, alles auf einmal zu öffnen...

# killall gimp

Zweiter Versuch

Gut, versuchen wir es nur mit Seite 1 und 2. Klappt, wunderbar. Mist, 100 dpi sind zu wenig, da kann man nichts mehr lesen. Also nochmal mit 600 dpi.

krrrzzzsss Ah - er swappt. grummel...

Auch wenn wieder 1,2GB meines Arbeitsspeichers von gimp belegt waren, konnte ich die Bilder erfolgreich im Kontrast anpassen, gerade rotieren, schwarze Ränder abschneiden und die Palette von RGB auf schwarz-weiss ändern.

Das ganze als png gespeichert und aus gimp ausgedruckt. Die Druckjobs hatten alle unter 500kb.

Mein HP Laserjet 2200 (Postscriptfähig) brauchte dazu dann aber doch pro Seite 13(!) Minuten. *argh*

Das habe ich auch durchgezogen und 130 Minuten lang Seiten gewendet, weil doppelseitig drucken geht bei Einzelseiten nicht sooo gut.

Dritter Versuch

Heute morgen hatte ich dann eine hervorragende Idee: Latex kann doch Grafiken einbinden und ein pdf erzeugen!

Eine kurze Nachfrage im IRC channel #latex auf freenode ergab den Tipp, die png-Dateien nach pdf umzuwandeln und dann als einzelne Seiten einzubinden. Klappte via 'pdfpages' super!

Die Umwandlung habe ich dann sogar per Webinterface gemacht, es waren keine kritischen Unterlagen. Danke nochmal tlhiv ;) (URL: http://www.tlhiv.org/rast2vec/)

Die resultierende pdf-Datei hatte dann noch 2,2MB und war innerhalb von 3 Minuten gedruckt. Komplett, alle 10 Seiten. Und dafür hab ich die Nacht durchgemacht (unter Anderem) - aargh

Für alle, die es interessiert, hier ein Beispiel LaTeX-Schnipsel dazu:

\documentclass[a4paper,10pt]{report}
\usepackage[utf8]{inputenc}
    \usepackage[pdftex]{color}
    \usepackage[pdftex]{graphicx}
\pdfcompresslevel9
\newcommand{\checkpage}
{
\thispagestyle{empty}
} 
\usepackage[T1]{fontenc}
\usepackage{pdfpages}
\pagestyle{empty}
\begin{document}
\setlength{\topmargin}{-0.5cm}
\includepdf[pagecommand={\thispagestyle{empty}}]{p1.pdf}
\includepdf[pagecommand={\thispagestyle{empty}}]{p2.pdf}
\end{document}

HOWTO: eigener primärer DNS mit BIND und Schlund

Vergangenen Freitag ging durch die einschlägigen Medien die Meldung über eine DDOS-Attacke auf InternetX, die einen Ausfall bzw. die Nicht-Erreichbarkeit ihrer Nameserver zur Folge hatte.

Die Nameserver vonInternetX werden z.B. von Schlund genutzt um die Domains ihrer Kunden darauf 'abzulegen'.

Auch ich bin ein Kunde von Schlund, alle meine Domains habe ich über das Webinterface 'gekauft' und bisher auch darüber die Nameserver ns9.schlundtech.de und ns10.schlundtech.de 'konfiguriert', sprich meine RR's dort eingetragen.

Vergangenen Freitag konnte ich meine Domains dann allesamt nicht mehr auflösen. Etwas Recherche brachte zum Vorschein, dass die Nameserver von Schlund zwar wie DENIC vorschreibt in unterschiedlichen 'Class C-Netzen' liegen, aber in einem gemeinsamen AS.

Seit der Einführung von CIDR (im Jahr 1993!) existieren aber diese Netzklassen so nicht mehr. Wichtig ist spätestens seit dem, dass die Nameserver in unterschiedlichen autonomen Systemen (AS) liegen, da beim Ausfall des Routings zu einem AS dann immer noch der andere Nameserver erreichbar ist.

Nun gut, ich habe mich also am Samstag endlich daran gemacht, meinen eigenen BIND aufzusetzen. Alle Schritte, und die Einstellungen im Schlund-Interface, will ich beispielhaft im Folgenden dokumentieren. Ich konfiguriere einen primären und einen sekundären Nameserver und nutze den ns10 von Schlund als weiteren sekundären Nameserver.

Die 6 Schritte zum eigenen authoritativen Nameserver

• Namen und IP-Adressen der Nameserver in die Zone eintragen (nur die A-Records)
• sekundären BIND aufsetzen
• primären BIND aufsetzen
• Zonefiles schreiben
• Testen ob die Zone beim sekundären Nameserver ankommt
• Schlundtech konfigurieren

Das Szenario für dieses Beispiel

Es gibt zwei Server, 192.0.2.101 und 192.0.2.102, die als primärer und sekundärer Nameserver für die Domain example.org eingerichtet werden sollen. Für dieses Beispiel benutzen wir natürlich reservierte Namen und Adressen.

Namen und IP-Adressen in die Zone eintragen

DNS ist je nach Kofiguration ein recht träges System. Man weiss auch nie, welche Admins ihre Caches nicht im Griff haben, und auch nach Ablauf der TTL noch veraltete Daten ausliefern. Es ist daher immer gut, Änderungen die man später braucht, möglichst früh einzutragen und, wenn möglich, die TTL zu verringern. Auf das Verringern der TTL und ähnliches verzichten wir hier der Einfachheit aber mal, weil das Webinterface von Schlund da ein wenig unübersichtlich ist. Der von Schlund so genannte SOA-Level bleibt auf 'Empfohlene Einstellungen'.

Als erstes tragen wir die A-Records für unsere Nameserver ein.

ns01.example.org.   IN A 192.0.2.101
ns02.example.org.   IN A 192.0.2.102

Bitte bei Bind auf den Punkt am Ende der Namen achten oder die Domain und den Punkt weglassen. Bei Schlund: Entsprechend der vorhandenen Einträge machen - ich glaube ohne Punkt und ohne Domain ist korrekt.

Danach sollte man bei seinem Server-Hoster dafür sorgen, dass das Reverse-Lookup der IP-Adresse die oben angegebenen Namen liefert.

Jetzt können wir gemütlich einen Kaffee trinken gehen...nein, im Ernst, je nachdem wie paranoid man ist sollte man etwas warten, mindestens bis die Zeit für das negative Cachen abgelaufen ist. Da wir aber den ns10 weiter in Betrieb lassen kann es nur zu Verzögerungen beim Auflösen unserer Domain kommen, aber nicht zum Totalausfall, sofern ns10 noch zu erreichen ist.

Den sekundären BIND aufsetzen

Wir gehen davon aus, dass nach einem emerge -av net-dns/bind oder einem apt-get install bind9 der BIND installiert ist.

Die Konfiguration ist eigentlich ganz einfach - leider weichen bei Gentoo und Debian die Pfade ein wenig voneinander ab sowie das Konzept der Konfiguration.

Während bei Gentoo alles in einer Datei steht, teilt Debian die named.conf mittels include-Anweisungen in drei Dateien auf.

Wir gehen beim Sekundären mal von Debian aus...

In der Datei /etc/bind/named.conf müssen wir unter Debian nichts weiter für unser Beispiel einfügen, da diese zwei anderen Dateien inkludiert.

Man kann aber allerdings darüber nachdenken, den rootservern von .com und .net zu verbieten, nicht-registrierte Domains auf Suchseiten umzulenken:

 zone "com" { type delegation-only; };
 zone "net" { type delegation-only; };

In der Datei

named.conf.options

ändern wir am meisten, siehe Komentare in den Zeilen, es sollte selbsterklärend sein. Die folgende Datei ist 'komplett':

acl myown-servers  {        
        127.0.0.1;        
        # Hinweis: hier alle eigenen Server/Netze eintragen, 
        # die den Server als normalen DNS benutzen dürfen.
        # Kann auch leer sein.
};

acl secondaries {
        62.116.163.100; # InternetX/Schlund
        62.116.162.121; # InternetX/Schlund
        192.0.2.102;    # unser sekundärer (dieser host selbst)
        127.0.0.1;
};

options {
        directory "/var/cache/bind";;
        forwarders {
                             # wenn wir selber auflösen wollen:
                192.0.2.14;  # erster Nameserver des ISP
                192.0.2.15;  # zweiter Nameserver des ISP
        };

        listen-on-v6 { none; }; # wird hier IPv6 aktiviert, müssen
                                # in den ACLs die Adressen auch in der
                                # alternativen Schreibweise erscheinen.

        listen-on { 127.0.0.1; 192.0.2.102;}; # logisch...

        transfer-source 192.0.2.102; # von dieser Adresse 
                                     # machen wir Zonentransfers
        version "get lost";
        allow-transfer {"none";};
        allow-recursion {myown-servers;}; 
        notify no;
        auth-nxdomain no;    # conform to RFC1035
};

Nun folgen noch die Zonendefinitionen in der Datei named.conf.local:

zone "example.org" in{
  type slave;
  file "slv/example.org.slave";
  masters {192.0.2.101;};
};

Danach das slv-Verzeichnis verlinken und eine leere Datei anlegen, in die bind schreiben darf:

  # cd /etc/bind
  # ln -s /var/cache/bind/slv slv
  # touch slv/example.org.slave
  # chown bind:bind slv/example.org.slave

Das slv-Verzeichnis habe ich angelegt, um nicht immer überlegen zu müssen, ob ich auf meinem Debian oder meinem Gentoo-Server eingeloggt bin.

Damit ist der Sekundäre Nameserver Einsatzbereit und kann so bleiben. Wir laden die Zone nicht neu, das erledigt der Server nachher hoffentlich von alleine, wenn er das Notify von unserem primären Nameserver erhält.

Bei Hosts mit mehr als einer IP-Adresse sind die Quelladressen anzugeben, weil der primäre Nameserver sonst u.U. keine Zonentransfers erlaubt.

primären BIND aufsetzen

Mein primärer Nameserver läuft auf einem aktellen Gentoo, daher hier ein leicht anderer Ansatz, wir schreiben alles in eine Datei und müssen den Symlink für das slv-Verzeichnis nicht anlegen.

Nach einem emerge -av net-dns/bind editieren wir die /etc/bind/named.conf:

ACHTUNG: In der Originaldatei sind schon einige Zonen definiert, diese bleiben erhalten, ausserdem hat dieser Server nur eine IP-Adresse, daher müssen wir die Anaben zu den Quelladressen wie bei unserem Secondary oben nicht machen. In der folgenden Konfiguration sind nur Änderungen und Erweiterungen zur Originalversion der Datei aufgeführt:

acl myown-servers  {        
        127.0.0.1;
        ...;        #hier also wieder alle unseren server 
};
acl secondaries {
        62.116.163.100; # InternetX/Schlund
        62.116.162.121; # InternetX/Schlund
        192.0.2.102;    # unser sekundärer
        127.0.0.1;
};
options {
        directory "/var/bind";

        // uncomment the following lines to turn on DNS forwarding,
        // and change the forwarding ip address(es) :
        forward first;
        forwarders {
                DNS1;   # erster DNS unseres ISP
                DNS2;   # zweiter DNS unseres ISP
        };

        listen-on-v6 { none; };
        listen-on { 127.0.0.1; 192.0.2.101;};

        pid-file "/var/run/named/named.pid";
        max-journal-size 50k;
        version "get lost";
        allow-transfer {"none";};
        allow-recursion {myown-servers;};
};

zone "COM" { type delegation-only; };
zone "NET" { type delegation-only; };

zone "example.org" IN {
        type master;
        file "pri/example.org.zone";
        allow-transfer { secondaries; };
        notify yes;  #bei Änderungen die secundaries informieren
};

Wir haben die Konfiguration des Dienstes geschafft, nun müssen wir ihm noch die Daten geben, die er verteilen soll.

Zonefiles schreiben

Jetzt kommt der unangenehmste Teil der Arbeit, das manuelle Kopieren aller Einträge aus dem Schlund-Webinterface in eine Zonendatei.

Das wichtigste zuerst: Bei jeder Änderung der Zone muss die serial hochgezählt werden, sonst wird die Zone nicht auf die sekundären Server kopiert. Ausserdem muss das Retry-Interval größer als 30 Minuten sein, sonst nimmt Schlund die Zone nicht an. Und immer auf die Punkte am Ende der Hostnamen achten, ohne Punkt wird die Domain eingesetzt!

Wir legen nun im Unterverzeichnis pri das Zonenfile pri/example.org.zone an:

$ORIGIN example.org.
$TTL 2d    ; 172800 secs default TTL for zone
@             IN      SOA   ns01.example.org. hostmaster.example.org. (
                        2008112601 ; se = serial number
                        12h        ; ref = refresh
                        35m        ; ret = update retry
                        3w         ; ex = expiry
                        3h         ; min = minimum
                        )
              IN      NS      ns01.example.org.
              IN      NS      ns10.schlundtech.de.
              IN      NS      ns02.example.org.
              IN      TXT     "v=spf1 a mx ?all"
              IN      MX  10  mail1.example.org.
              IN      MX  20  mail2.example.org.
              IN      A       192.0.2.100
ns01          IN      A       192.0.2.101
ns02          IN      A       192.0.2.102
www           IN      CNAME   example.org.

Das ORIGIN der ersten Zeile definiert für den Rest der Datei, welche Domain wir da eigentlich vor uns haben. Ab der dritten Zeile findet sich der SOA-Eintrag, in dem der primäre Nameserver angegeben ist und eine Emailadresse des zuständigen Admins. Hier: hostmaster@example.org, das @ wird durch einen Punkt ersetzt. Es folgt die serial number, die bei jeder Änderung erhöht werden muß. Es empfiehlt sich das Datum und einen Zähler mit der Zahl der Änderung an diesem Tag zu nutzen. Die serial darf kein Zeichen länger sein, da sie sonst von Bind nicht angenommen wird.

Es folgen dann eine ganze Reihe von Timeouts und Intervallen, das Beispiel passt schon so...

Weiter unten in der Zone sind die Nameserver der Domain angegeben. Das ist wichtig. Bei uns stehen die Nameserver sogar noch in derselben Domain, für die sie auch zuständig sind. Daher müssen wir nachher in das Webinterface bei Schlund noch zusätzlich die IP-Adressen der Server angeben.

In dieser Zone sind auch gleich Beispiele für einen SPF-Record, Nameserver und einen CNAME für den WWW-Host, der auf den A-Record der Domain zeigt.

Wir können nun den bind auch beim Systemstart hochfahren lassen und starten:

 # rc-update add named default
 # /etc/init.d/named start

Damit sollte der primäre Nameserver fertig sein

Testen ob die Zone beim sekundären Nameserver ankommt

Wir loggen uns nun wieder bei unserem eben konfigurierten Sekundären Nameserver ein und schauen nach, ob die Zonendatei nun Daten enthält.

Wenn alles gut gegangen ist, hat der primäre Nameserver beim Starten unseren Secondaries ein Notify geschickt und sie zu einem Zonentransfer animiert. Der Server von Schlund ignoriert das Notify, da er unseren primären Nameserver ja noch nicht kennt.

Sollte die Zone noch leer sein, kann man vom sekundäen Server aus mit dem Utility dig mal einen Zonentransfer versuchen und dabei die Logausgaben des primären Nameservers anschauen.

  dig axfr example.org  @ns01.example.org

Hat man mehrere IP-Adressen hilft -b IP weiter.

Bei Änderungen an den Zonen muß der BIND nicht neu gestartet werden. Das Kommando rndc hilft weiter:

rndc reload

Schlundtech konfigurieren

Nachdem man die eigenen Server konfiguriert hat und alles funktioniert(!), kann man sich an das Webinterface von Schlund wagen.

Als Einrichtungsart unter 'DNS-Einstellungen und Weiterleitungen' wählt man 'nur zweiter Nameserver' und auf dem ersten Registerblatt 'Domain-Einstellungen' gibt man bei den Nameservern ein:

 ns01.example.org      192.0.2.101
 ns10.schlundtech.de
 ns02.example.org      192.0.2.102

Bei Nameservern, die in der Domain liegen, die sie auch verwalten, ist die Angabe der IP-Adresse essentiell!

Sobald man auf 'Domain aktualisieren' klickt, sollte ein Zonentransfer vom primären DNS starten...

Um Fehlermeldungen zu lesen, die beim Zonentransfer auftreten können, muss man sich vom Webinterface abmelden, neu anmelden und auf der Startseite in der History klicken.

Der ns10 von Schlund erlaubt übrigens wohl gar keine Transfers.

Wenn alles gut geganten ist, kann man im whois seine Nameserver bewundern und bei einem dig nach den Nameservern der Domain die Additional-Records sehen, welche die IP-Adressen enthalten. Man sollte beim dig natürlich einen Nameserver vom ISP nehmen, nicht seinen eigenen, der funktioniert ja ;)

$ dig ns example.org
[...]
;; ANSWER SECTION:
example.org.  34422 IN NS ns01.example.org.
example.org.  34422 IN NS ns02.example.org.
example.org.  34422 IN NS ns10.schlundtech.de.

;; ADDITIONAL SECTION:
ns01.example.org. 34265 IN A 192.0.2.101
ns02.example.org. 34265 IN A 192.0.2.102
ns10.schlundtech.de. 2167 IN A 62.116.163.100

Bei allem Debugging mit AS'en und Nameservern, etc, ist die Webseite von robtex sehr praktisch, da sie Graphen für AS-Zuordnungen und DNS-Einträge zeichnen kann.