Dokumentation der Konzeption und Entwicklung eines Prototypen zur Emulation von Layer 2 Verbindungen unter QoS Aspekten auf Basis von “dummynet”. Die gewonnenen Erkenntnisse werden präsentiert und mit der bereits existierenden Implementierung im Linux-Kernel tc/NetEm verglichen.

Download

In Fällen wo diese Datei nicht (mehr) existiert oder man mehr als ein Kommando rückgängig machen will (z.B. lvremove -f /dev/vg/vServerA-disk; lvremove -f /dev/vg/vServerA-swap aber eigentlich sollte vServerB gelöscht werden, vServerA wird noch benötigt) hat man trotzdem noch eine Chance. LVM speichert am Anfang der physical Volumes mehre Kopien der Konfiguration. Diese kann man (wie auch hier beschrieben) mittels dd if=/dev/md0 bs=512 count=255 skip=1 of=/tmp/vg.txt auslesen (/dev/md0 ist natürlich durch ein passendes physical Volume zu ersetzen). Die Datei kann man dann in einen Texteditor öffnen, und findet (hoffentlich) noch die gewünschte Version der Konfiguration. Am Ende jeder dort gesicherten Konfiguration steht ein Zeitstempel mit Versionsangabe der Tools, auf welchen Host es erstellt wurde. So lässt sich die gewünschte Konfiguration leichter finden. Die wiederherzustellende Version kopiert man dann in eine neue Datei (z.B. /tmp/recover.txt) und nachdem man wieder die Volume Group offline genommen hat (oder LVM komplett mit /etc/init.d/lvm stop) stellt man die gewünschte Version mit vgcfgrestore -f /tmp/recover.txt VolumeGroupName wieder her. Nach einem online nehmen (oder /etc/init.d/lvm start) ist der gewünschte Zustand wieder hergestellt.

ACHTUNG: Das funktioniert natürlich nur dann fehlerfrei, wenn die Blöcke in der Zwischenzeit nicht anderweitig überschrieben wurden (nach einem vgcreate, vgresize und Nutzung des logical Volumes u.Ä.).

Update: Der Mailserver spricht nun auch IPv6

Kurze Inhaltszusammenfassung: Beschreibung eines Konzepts zur Nutzung von virtuellen Servern als Container für verteiltes Rechnen und Dokumentation der Erfahrungen bei der Entwicklung eines Prototypen. Die Ergebnisse werden unter dem Aspekt des Overheads bewertet..

Download

Varnish cacht (sinnvollerweise) per Default keine Dokumente, bei denen bei der Anfrage ein Cookie mitgesendet wurde. Um aber auch bekannt statische Inhalte für alle Nutzer zu cachen, kann man bei Varnisch in der Konfigurationsdatei auch Regeln erstellen, die für bestimmte Pfade oder Dateiendungen die Cookies aus der Anfrage entfernen, und damit cachbar machen.

Anders als im Wiki dokumentiert, muss man bei der in Debian Lenny vorhandenen Varnishversion “remove” statt “unset” als Aktion angeben, so das bei mir nun in der Konfiguration u.A. das folgende steht:

sub vcl_recv {
    if (req.url ~ ".(png|gif|jpg|swf|css|js|ico|pdf)$") {
            lookup;
    }
}

sub vcl_fetch {
    if (req.url ~ ".(png|gif|jpg|swf|css|js|ico|pdf)$") {
        remove obj.http.set-cookie;
    }
}

Kurze Inhaltszusammenfassung: Darstellung der Grundlagen zum Thema virtuelle Server und Entwicklung eines Prototypen der das Reliable Server Pooling Framework (beinhaltet Failover Mechanismen und Lastverteilung) zur Verwaltung von virtuellen Server nutzt.

Download

Es wird nun hier verwendet:

• WordPress 3.0
• Das WordPress-Plugin Super Cache
• Apache2 in einer Konfiguration mit PHP als FCGI
• APC als PHP Cache
• varnish als reverse Caching Proxy
• modifizierte .htaccess die Expires-Header setzt

Damit dürfte auch ein größerer Besucheransturm den Webserver nicht an die Grenzen bringen. Der Beweis steht mangels entsprechenden Content allerdings noch aus

#!/bin/sh

set -u
set -e

IP=10.11.12.13
User=sa-update

# SPAM
for datei in $( find Maildir/.Spam/cur/ -mindepth 1 ) ; do
    cat $datei | ssh $User@$IP "sa-learn --no-sync --spam" > /dev/null
    rm $datei
done

# HAM, nur der neue seit dem letzten Update
for datei in $( find Maildir/cur/ -mindepth 1 -mmin -65 -name "*S" ) ; do
    cat $datei | ssh $User@$IP "sa-learn --no-sync --ham" > /dev/null
done

ssh $User@$IP "sa-learn --sync" > /dev/null

Das kann für jeden User einmal die Stunde aufgerufen werden, und trainiert dann die Bayes-Datenbank mit den aktuellen Spam, und mit den neuen HAM.

SSH-Login ohne Passworteingabe ist dafür natürlich notwendig. (SSH-Keys nutzen)

Die benötigte RAM-Menge teilt sich in zwei Teile auf, die Menge die direkt vom XEN-Hypervisor genutzt wird, und den Teil, den die Verwaltung benötigt.

Da man in der Regel aus Sicherheits- und Performancegründen in der Domain-0 nur die Verwaltung laufen lässt, ist der RAM-Bedarf für die Domain-0 der Verwaltung zuzurechnen.
64 MB RAM gelten als “sichere Minimalausstattung” für die Domain-0.

Der Hypervisor benötigt auch etwas RAM, die Menge hängt vom Systemtyp (i386 oder x86/64) ab, und von der Menge an installierten RAM

Um den gesamten Bedarf auszurechnen, muss man die Werte nun addieren.

Als Beispiel ein i386 System mit 1 GB RAM:
12 MB + 1*7 MB = 19 MB für XEN + 64 MB für die Verwaltung = 83 MB

Als weiteres Beispiel ein i386 System mit 3 GB RAM:
12 MB + 3*7 MB = 33 MB für XEN + 64 MB für die Verwaltung = 97 MB

Als weiteres Beispiel, das letzte System, aber als x86/64:
16 MB + 3*12 MB = 48 MB für XEN + 64 MB für die Verwaltung = 112 MB

Es basiert auf den Java-Framework jameica, und beherrscht neben den klassischen HBCI auch das PIN/TAN Verfahren.