Kategorien
Blog

Mein Speed-Setup, Teil1: https

Vor einiger Zeit hatte ich mal mit der Beschleunigung dieses Blogs (und der anderen wazong-Seiten) beschäftigt. Dabei hatte ich mit Varnish schnell mittelgute Ergebnisse bekommen, es waren aber einige Fragen offengeblieben. Für einen Teil habe ich inzwischen Lösungen gefunden, bei anderen bastle ich noch.

Da war zuerst das access.log, in dem nur noch Zugriffe von 127.0.0.1 verzeichnet wurden. Dafür gibt es ein Apache-Modul, das den verbindenden Client durch den Inhalt des „X-Forwarded-For:“-Headers ersetzt (wo der herkommt, dazu später mehr). Debian hat’s praktischerweise als fertiges Paket herumliegen, so dass man das Problem mit:

apt-get install libapache2-mod-rpaf
cd /etc/apache2/mods-enabled
ln -s ../mods-available/rpaf.* .

erledigt hat.

Das https-Caching ist mit WordPress als Backend komplizierter; da WordPress viel mit vollständigen (auch selbst erzeugten) URLs arbeitet, wird man beim einfachen Ansatz (also einen TLS-Offloader vor den Proxy-Cache setzen) ständig auf die unsichere Verbindung umgeleitet. Die eine Seite wird also wirklich über die verschlüsselte Verbindung geladen, alle Bilder und StyleSheets aber schon wieder unverschlüsselt, und die Links auf des Seite führen auch alle zur unverschlüsselten Version.

Mein erster Ansatz war, nginx die TLS-Verarbeitung durchführen zu lassen (das ging gut damit) , und Links auf http://dentaku.wazong.de/ automatisch zu https://dentaku.wazong.de/ umschreiben zu lassen. Leider ist das nicht die einzige Domain, die auf diesem Server wohnt, und das zuerst geeignet erscheinende HttpSubModule kann leider keine regulären Ausdrücke verarbeiten und ist auch auf eine Ersetzungs pro Virtual Host beschränkt. Ich ließ also nginx wieder nginx sein (wer will schon einen kompletten Webserver vor einem anderen Webserver haben?) und kehrte zu einem zweiten Versuch mit Pound zurück.

In den folgenden Artikeln erkläre ich also ein Setup, das etwa so aussieht:

Kategorien
Blog

Firnis (oder: Das muss schneller gehen!)

Vor einiger Zeit (oh, ist ja auch schon wieder ein Jahr her) hat mich bei Martin Thielecke ein Artikel aufgeschreckt. Seitdem steht Webserver-Tuning auf meiner ToDo-Liste (die ist geduldig). Nachdem auch Google sagt, dass meine Webseite langsam ist:

(ok, die scheinen das auch nur mal im letzten Mai gemessen zu haben), musste da jetzt echt mal was passieren. Das soll hier also alles ein wenig schneller (und belastbarer) werden. Als ersten Schritt habe ich nach etwas Einleserei vor meinen Apache jetzt einen Varnish-Cache gestellt. Der läuft im Moment noch mit Standardeinstellungen, was ein paar Nachteile hat:

  1. Die Cache-Hit-Rate ist eigentlich miserabel: WordPress liefert seine Seiten mit minimaler Lebenszeit aus und setzt auch sehr gern Cookies. Beides verhindert bei normaler Konfiguration eine Zwischenspeicherung im Cache. Varnish lässt sich aber sehr fein einstellen, da sollte sich noch einiges machen lassen.
  2. Die Apache-Accesslogs sehen eher eigenartig aus: alle Anfragen kommen im Moment von 127.0.0.1, aber auch das sollte mit Konfiguration wieder in den Griff zu bekommen sein.
  3. https ist noch nicht beschleunigt, weil Varnish kein TLS spricht. Da habe ich schon ein wenig herumexperimentiert mit Pound, aber damit kommt die Information, dass über https zugegriffen wird, nicht bei WordPress an, so dass alle ausgegebenen Links (auch die zu StyleSheets und Bildern des Themes) wieder auf die unverschlüsselte Variante zeigen. Da weder Varnish noch Pound die Links im Vorübergehen umschreiben können, muss ich mir da was anderes einfallen lassen (ich lese gerade ein wenig über nginx, damit könnte das gehen).

Wenn ich eine gangbare Konfiguration gebastelt habe, dann schreibe ich mal eine Anleitung (wenn Euch hier umgekehrt irgendwas auffällt, das nicht richtig funktioniert, dann beschwert Euch).

Kategorien
Blog

Linux-Server im Windowsnetz (Teil 1,5: OpenVPN)

Die in Teil 1 schon erwähnte Sicherheitsrichtlinie schreibt auch vor, dass VPN-Zugänge logisch nicht an Maschinen sondern nur an Personen gebunden sein dürfen. Bisher hatten wir OpenVPN mit X.509-Zertifikaten zur Zugangsbeschränkung benutzt. Die Zertifikate lassen sich zwar mit einem Passwort verschlüsseln, das kann aber vom Besitzer des Zertifikats leicht geändert werden. Eine echte Zweifaktorauthentifizierung geht anders.

Da trifft es sich gut, dass OpenVPN auch nach Benutzername und Passwort fragen kann. Die können direkt hinterlegt sein, mit einem entsprechenden Plugin kann man aber PAM mitbenutzen:

plugin /usr/lib/openvpn/openvpn-auth-pam.so login

Auf client-Seite muss die bestehende Konfigurationsdatei durch eine Zeile ergänzt werden, damit der Benutzer nach dem übermittelnden Passwort gefragt wird:

auth-user-pass

PAM hatten wir ja in Teil 1 schon an Active Directory angebunden, was wir hier jetzt problemlos mitbenutzen können. Fertig.

Einschränkung: da der OpenVPN-Endpunkt oft ein Rechner ist, auf dem sich die so „entstandenen“ Benutzer gar nicht interaktiv anmelden sollen, empfiehlt sich die Einrichtung einer restricted Shell und die entsprechende Anpassung der smb.conf:

template shell = /bin/rbash
template homedir = /home/restricted

(und wenn man schon dabei ist, dann sollte man dort auch alle Services entfernen).

Kategorien
Microblog Photoblog

Experimentalküche. Heute: wir…

Experimentalküche. Heute: wir basteln uns ein Curry http://flic.kr/p/9g5irK #

Kategorien
Blog

Einrichtung eines SVN-Spiegelservers

Der Subversion-Server des Kunden ist der langsamste seiner Art. Das sorgt für Frust; nicht nur blickt man in Eclipse oft minutenlang auf „Pending…“, wenn man Teilbäume aufklappen möchte, es schlagen auch Hudson-Builds fehl, weil svn update nicht durchgelaufen ist.

Für Hudson könnte man sich behelfen, indem man mit svnsync eine lokale (readonly-)Kopie des Repositories einrichtete, aber in der Entwicklungsumgebung hilft das nicht weiter. Seit Subversion 1.5 ist es zum Glück möglich, das dav_svn-Modul im Apache so zu konfigurieren, dass schreibende Zugriffe direkt auf ein zentrales Repository (den Master) umgeleitet werden während lesende Operationen auf einer lokalen Kopie ausgeführt werden.

Die im Netz zu diesem Thema zu findenden Anleitungen gehen größtenteils davon aus, dass man Master- und Slaveserver unter seiner eigenen Kontrolle hat. Wir können aber am Master nichts konfigurieren und werden deshalb eine etwas sparsamere Variante einrichten müssen.

Voraussetzungen:

  • Apache (min. 2.2)
  • svn (min. 1.5)
  • Apache mod_dav_svn und mod_proxy (sowie Module, von denen die jeweils abhängen)
  • Apache mod_ssl (wenn das Master-Repository per https erreichbar ist)

Schritt 0:

Benutzer anlegen (nennen wir ihn mal svnsync), mit dessen Account später die Synchronisation laufen wird. Weil der sich den Zugriff auf das Repository mit dem Webserver teilen wird, habe ich ihn in einer gemeinsamen Gruppe angelegt.

Schritt 1:

Repository anlegen (als root):

svnadmin create /var/www/svn/projekt

Die einzelnen Benutzer müssen wir nicht anlegen, weil das Benutzermanagement und die Commitrechte weiterhin vom Masterserver verwaltet werden.

Schritt 2:

Schreibenden Zugriff aufs Repository für alle Benutzer außer svnsync verbieten. Das geht mit einem „pre-revprop-change“-hook:

#!/bin/sh
USER="$3"

if [ "$USER" != "svnsync" ]; then
    echo >&2 "Only the svnsync user can change revprops"
    exit 1
fi

exit 0

Schritt 3:

Synchronisation starten:

Als Benutzer svnsync muss man die Synchronisationsverbindung erst erstellen (init) und dann die erste Synchronisation durchführen (sync). Je nachdem, wieviele Revisionen es im Master-Repository schon gibt kann das seine Zeit dauern.

 svnsync init file:///var/www/svn/projekt https://subversion.kunde.de/svn/projekt
 svnsync sync file:///var/www/svn/projekt

Passwörter für das Master-Repository müssen in dieser Phase eventuell eingegeben werden und werden dann im Home-Verzeichnis des Synchronisationsbenutzers im .svn-Verzeichnis gespeichert — das ist also mit der notwendigen Vorsicht/Sicherheit zu behandeln.Ständige Synchronisation einrichten:

Da uns, wie gesagt, das Master-Repository nicht gehört, können wir es nicht dazu bringen, uns von Änderungen zu unterrichten. Den sync-Befehl lassen wir deshalb von cron einmal pro Minute ausführen:

* * * * * svnsync sync file:///var/www/svn/projekt > /dev/null 2>&1

Schritt 4:

Zugriff über Apache einrichten:

In schmerzhaften Versuchen musste ich feststellen, dass der Zugriff über den Spiegel nur dann zuverlässig funktioniert, wenn sich die beiden Server möglichst ähnlich sind. Mit verschiedenen Repository-URLs (also wenn der „Verzeichnisname“ des Spiegels sich vom Original unterschied) hatte ich z.T. seltsame Fehlermeldungen („405 Unsupported Operation“,…). Auch der Wechsel von https (auf dem Kundenserver) auf http sorgt für unerklärliches Verhalten bei Verschiebe- und Umbenennoperationen. Wenn das Master-Repository über https erreichbar ist, benötigt man aber ohnehin mod_ssl (und muss den Parameter „SSLProxyEngine“ auf „on“ stellen).

Module laden (dies ist der Mindestumfang, und die Syntax unterscheidet sich je nach Linux/Apache-Distribution):

LoadModule dav_svn_module mod_dav_svn.so
LoadModule proxy_module mod_proxy.so
LoadModule proxy_http_module mod_proxy_http.so
LoadModule ssl_module mod_ssl.so

Konfiguration (Schnipsel an für diesen Apache geeignete Stelle einfügen):

SSLProxyEngine on

<Location /svn/projekt>
    DAV svn
    SVNPath /var/www/svn/projekt
    SVNMasterURI https://subversion.kunde.de/svn/projekt
</Location>

Jetzt kann man mit dem schnellen lokalen Server statt mit der weit entfernten lahmen Ente arbeiten (aber Achtung: nur per http(s) zugreifen, sonst entsteht Chaos!).

Kategorien
Microblog Photoblog

… und ein Designersofa brauc…

… und ein Designersofa braucht der Bär von Welt. http://flic.kr/p/8Rc5wU #

Kategorien
Blog

Die Linux-Server im Windowsnetz (Teil 1)

Als wir noch nicht Microsoft-Gold-Partner waren, und uns die Windowslizenzen noch nicht nachgeworfen wurden, wurden hier ein paar Linux-Server als Fileserver aufgebaut. Mit Linux kann man (über NIS und den Automounter) sehr einfach die Benutzerverzeichnisse und -dateien über mehrere Rechner verteilen. Die Windows-Arbeitsplatzrechner hatten zu der Zeit noch keine Anbindung an eine zentrale Benutzerverwaltung sondern lokale Benutzerkonten.

Mit der Einführung von Exchange (statt Lotus Domino) wurde später eine Active Directory-Domäne eingerichtet, so dass Benutzernamen und Passwörter jetzt auf allen Windowsrechnern einheitlich funktionieren. Die Linux-Rechner blieben bisher außen vor (weil wir aber auf dem Fileserver einige Unix-Eigenheiten nutzen, weil es dort eine sehr gute vollautomatische Backupsoftware gibt, und weil außerdem inzwischen auch einige andere Dienste auf den Maschinen laufen kommt eine Umstellung auf Windows nicht ohne weiteres in Betracht).

Diese Gesamtkonstruktion sorgt dafür, dass für jeden Benutzer (mindestens) drei Passwörter existieren (AD, Unix/NIS, Samba). Wenn ein Benutzer nur eins davon ändert, dann wird er an (für ihn) unvorhersehbaren Stellen plötzlich nach einem (welchem?) Passwort gefragt. Die Lösung dafür war bisher einfach: die Benutzer änderten ihre Passwörter nicht (gibt es eigentlich Untersuchungen darüber, ob häufiger Passwortwechsel die Sicherheit eher erhöht oder verringert?). Jetzt sind wir aber seit kurzem mittelbares Tochterunternehmen einer Bank, und die hat einen Katalog an IT-Sicherheitsrichtlinien, zu dem auch eine Mindestkomplexität (8 Zeichen, große und kleine Buchstaben, Zahlen und Sonderzeichen) und eine Höchstgültigkeitsdauer (90 Tage) für Passwörter gehören.

Zeit also für eine Anbindung zwischen Linux und Active Directory:

Kategorien
Photoblog

Salzteigfiguren anmalen

Kategorien
Blog

Frohe Ostern!

Schönes Fest mit Hasen und Eiern! Diese komplizierte Geschichte mit dem Kreuz und dem Grab lassen wir jetzt mal weg, schließlich feiern wir den ersten Sonntag nach dem ersten Vollmond nach dem Frühjahrsäquinoktium. Viel heidnischer geht es nicht.

(Pssst: wer seine Kinder kurz mal beschäftigt haben möchte, der kann bei Susanne eine Ausmalvorlage herunterladen…)

Kategorien
Blog

Guck mal da, eine Kuh!

Meine Frau bastelt Sachen macht Kunst. Das geht vom Ölgemälde über selbst entworfene und genähte Stofftiere bis hin zur Zinnfigur, für die sie die Gussform im Negativ schnitzt. Das fand bisher, von wenigen verschenkten Exemplaren abgesehen, weitgehend unter Ausschluss der Öffentlichkeit statt.

Gleichzeitig existierte unter susannerenger.de eine komplett leere Webseite.

Jetzt hat sie (gerade vor kurzem erst) damit angefangen, dort Artikel über die Kunstwerke, die sie erschafft, zu verfassen. Das Werk ist Umfangreich, drum wartet da noch einiges auf seine Veröffentlichung. Willkommen also als Neu-Bloggerin…

Kategorien
Blog

MU!

Ich spiele gerade mit WordPress MU, denn ich möchte dieses Blog gern mit dem und dem und dem (da läuft gerad der MU-Test) auf eine gemeinsame Platform setzen, außerdem möchte ich den Wazong-Benutzern ermöglichen, eigene Blogs aufzusetzen.

Damit das funktioniert, müssen natürlich erstmal alle Plugins, die ich hier jetzt im Moment benutze, mit der Multiblogversion zusammenarbeiten (oder ich muss einen Ersatz für sie finden). Zwei Sorgenkinder konnte ich schon ausmachen:

  • YAPB findet die Bilddateien nicht wieder
  • OpenID kann seine Einstellungen nicht speichern, funktioniert sogar möglicherweise garnicht (ohne Einstellungen schwer zu testen).

Ein paar andere Kandidaten funktionieren problemlos. Am Wochenende werde ich mal mit dem vim aufs PHP losgehen, und dann kann ich mehr dazu sagen, eventuell mit Patches für ein paar Problemfälle.

Kategorien
Microblog Photoblog

Herbstbastelei (Pferd, Männch…

Herbstbastelei (Pferd, Männchen, Hund) #Kastanien http://flic.kr/p/6ZYWEL #

Kategorien
Microblog Photoblog

In der Figurenwerkstatt http:/…

In der Figurenwerkstatt http://flic.kr/p/6VmCzC #

Kategorien
Blog

Alles neu, alles schnell

5 Jahre, also mehrere Generationen oder eine halbe Ewigkeit war charon.wazong.de jetzt die Heimat dieser Webseite. Seit vorgestern nun läuft sie auf dem neuen Server; wieder bei Hetzner, wieder ein Rootserver, diesmal ein „EQ4“. Dass das neben mehr Platz (und der Möglichkeit, mehr Dinge auf einmal laufen zu lassen) auch der WordPress-Geschwindigkeit nutzt, das lässt sich sogar messen:

Testbeispiel: https://wazong.de/blog/2006/07/

  • charon: Laut Firebug: 98 (http-)Anfragen, 8.05s. — Laut WordPress: 76 (SQL-)queries. 1.463 seconds
  • nyx: Laut Firebug: 98 (http-)Anfragen, 4.1s — Laut WordPress: 76 (SQL-)queries. 0.342 seconds

Also: schneller surfen 🙂

Kategorien
Blog

ssh-Begrenzung – diesmal aber wirklich

Hier hatte ich schonmal versucht, mit iptables und dem recent-Modul, die lästigen ssh-Scanner vom tatsächlichen sshd fernzuhalten. Leider hat das nie wirklich toll geklappt (die „Angreifer“ wurden zwar ausgesperrt, es gelang aber nie, die Sperre automatisch aufzuheben).

Nach zwei bis drei erfolgreichen DoS-Attacken auf unser Firmennetz habe ich mir die Liste der iptables-Module nochmal genauer durchgesehen, ob da nicht was passendes dabei ist — und siehe da; das hashlimit-Modul kann eine Regel auf eine Höchstzahl von Treffern pro Zeiteinheit beschränken. Das liest sich dann so:

# 
# keep established connections open
# 
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# 
# enable ssh:
# 
# throttle to 2 (3) connections per minute for outsourcing and internet
iptables -N ssh
iptables -A ssh -m hashlimit --hashlimit 2/minute --hashlimit-burst 3 \
         --hashlimit-mode srcip --hashlimit-name ssh --j ACCEPT
iptables -A ssh -j LOG --log-level info --log-prefix "SSH scan blocked: "
iptables -A ssh -j REJECT
iptables -A INPUT -p tcp --destination-port 22 --syn -j ssh
iptables -A FORWARD -p tcp --destination-port 22 --syn -j ssh

Das syn-Paket (also der Verbindungsaufbau) wird höchstens zweimal pro Minute durchgelassen, bestehende Verbindungen sind erlaubt. So funktioniert es.

Kategorien
Blog

Blog Design 3: Lifestreaming hier

Ich bin nicht bei vielen Themen paranoid, aber den Verlust einmal angehäufter oder mühsam erzeugter Daten fürchte ich ständig. Dabei tippt man heutzutag ständig irgendwas in andererleute Server ein oder läd etwas auf andererleute Server hoch — fast immer auf kostenlosen Diensten, damit es von Freunden gelesen oder angesehen, weiterbenutzt oder kommentiert werden kann. Was passiert aber, wenn einer der Dienste plötzlich abgeschaltet wird (z.B. Pleite) oder Daten verliert (z.B. Datenbankcrash) oder Dinge löscht?

Außerdem ist all dieser „Content“ natürlich im ganzen Netz verstreut und somit schwer wiederzufinden. Dieses Problem lösen zwar Aggregatoren wie lifestream.fm oder friendfeed.com, aber das sind ja schon wieder externe Dienste (s.o.).

Es gibt dazu nur eine Lösung: alles muss hierher. Und weil ich nicht twitter und twitpic und flickr und del.icio.us (und was noch alles) nachbauen möchte (wer außer mir würde das dann auch benutzen?), drum kopiere ich die Daten von dort in Zukunft hierher (bei Tweets und Bookmarks klappt das schon, am Rest wird noch gebaut) und passe die Darstellung an den jeweiligen Inhaltstyp an (Tweets brauchen z.B. keine Überschrift, Fotos sind einfach nur Fotos). Dadurch kann plötzlich auch alles verschlagwortet und kommentiert werden; eine Fundgrube für meine vergangenen Gedanken, eine Hirnerweiterung.

Die übrige optische Gestaltung habe ich nur wenig angepasst: Dunkel auf Hell liest sich leichter, und ich zwinge jetzt alle Leser zu dem Hochformat, mit dem die Seite ursprünglich entworfen ist (Ich weiß, das ist jetzt nicht mehr modern, aber mein Browser hat normalerweise DIN-Hochkant-Format — und zwar seit XMosaic 1.0. Warum machen die anderen Leute ihre Browser so breit? So breite Zeilen kann man doch sowieso nicht lesen). Dazu kommt noch eine deutlichere Trennung zwischen Inhalt und Metadaten, fertig ist das neue Design. Hier nochmal zum Vergleich: links „Wazong 2“ und rechts „Wazong 3“ (erstellt mit dem großartigen Browsershots):

Ein paar noch frühere Designs der Seite — aber leider nicht alle — kann man übrigens hier und hier sehen, und demnächst erzähle ich nochmal mehr über die Technik.

Kategorien
Blog

Baubetrieb

Schon länger angekündigt: hier wird mal wieder umgebaut (und dann auch gleich mal von WordPress 2.3.3 auf WordPress 2.7.1 umgestellt). Bitte nicht wundern, wenn es vorübergehend seltsam aussieht…

Kategorien
Blog

Mehr! Platz!

Vorher:

19,34GB verfügbar

Nachher:

178,82GB verfügbar

Carbon Copy Cloner  ist ein überaus hilfreiches Programm. Aber wenn sowas schonmal (nur in der aktuellen Version) einen bekannten Bug hat, dann ist das natürlich völlig klar, dass ich den auf der Stelle treffe und die Klonaktion deshalb zweimal durchführen muss (an dieser Stelle Dank an die nützliche Fähigkeit des MacBooks, via USB von seiner vorherigen Festplatte zu starten, wenn inzwischen eine andere fest im Gerät eingebaut ist).

Kategorien
Blog

Bleep Dudidudidu Tititititi

Vor etwa einem Jahr hatte ich schon einmal einen Quittungston für das Projekt erzeugt. Der ist inzwischen leider nicht mehr im Einsatz, denn er war in der lauten Lagerhalle nie richtig zu hören. Er wurde deshalb später von diesem durchdringenden Ton abgelöst, den ich mit Audacity erzeugt habe:

Kein Flash? Bleep

Jetzt hat sich der Kunde wieder gemeldet und zwei neue zusätzliche Töne gewünscht. Die genaue Funktion (bzw. Bedeutung) zu erklären würde jetzt zu weit führen, aber ich präsentiere:

Kein Flash? Dudidudidu

und

Kein Flash? Tititititi

Kategorien
Blog

Feed-Abonnenten aufgepasst!

Ich bastle gerade am Umbau dieses Blogs in eine Art von Lifestream. Das Layout ist auf einem Testserver schon ziemlich weit fortgeschritten, und die twitter-Updates laufen hier im Hintergrund schon rein. Meine Fotos wohnen sowieso hier und für die Bookmarks habe ich in der Testumgebung auch schon was gebastelt.

Dadurch wird es im (Standard-)Feed bald voll werden. Für die Feed-Leser muss das nicht unbedingt schlecht sein, ich befürchte aber, dass manche Leute eher genervt sein werden, wenn sie plötzlich mit meinem kompletten Braindump überschüttet werden. Wer also auch in Zukunft nur die „echten“ Artikel haben möchte, der sollte seinen Feedreader von https://wazong.de/blog/feed/ auf https://wazong.de/blog/category/blog/feed/ umstellen. Sagt nicht, ich hätte Euch nicht gewarnt…