Da ich in letzter Zeit mit Mails diesbezüglich geflutet werde, hier mal der Link zur Firma => www.smart-cluster.com

Dazu kommt noch dass der Aufwand die Mailserver dort aus deren RBL zu delisten bei einem Cluster mit vielen Mailservern enorm steigen kann. Man muss sich ja immer durch irgendwelche Forms mit Captchas durchhangeln – auf ein Feedback seitens Baracuda Central wartet man wohl vergeblich.

Ich kann nicht nachvollziehen, warum einige Mailserver-Admins der Meinung sind, dieses perverse System unterstützen zu müssen. Der Ärger mit Kunden die keine Mails zustellen können und der Aufwand whitelists zu Pflegen stehen doch in diesem Falle in keinem Verhältnis mehr. Dazu kommt noch, dass sich SPAM auch sehr effizient mit den üblichen Opensource-Lösungen wie dspam, spamassassin, diversen Filterlisten wie SpamCop und Spamhaus, amavisd, Greylisting etc filtern lässt.

Aber eine gute Geschäftsidee wäre es schon, einfach mal eine Blacklist aufzubauen, alles erst mal zu Blacklisten, für das Whitelisting Geld zu verlangen und dann irgendwelche Marketingmenschen in größeren Unternehmen dieses System als innovativ zu verkaufen und nochmals die Hand aufzuhalten. Dieser Gedanke könnte einem zumindest in den Sinn kommen, liest man sich diverse Foren im Netz durch.

Einfach nur frustrierend…

UPDATE:

http://packetstormsecurity.org/papers/evaluation/Barracuda_Evil.txt bestätigt meinen Verdacht, dass das Barracuda Zeug einfach nur Müll ist…

Mit etwas Konfigurationsarbeit und dem Linux VServer Patch (auf welchem auch die Vserver bei vlinux.biz laufen) lässt sich das Setup dennoch mit nur 2 Servern durchführen wobei auch ein Server komplett ausfallen kann, ohne dass der mysql cluster down ist oder crashed.

Man installiere ein Debian Lenny oder neuer, wähle entweder den bei Debian mitgelieferten VServer Kernel (linux-image-vserver-bigmem) oder baue seinen eigenen (z.B. 2.6.31.7-vs2.3.0.36.27 ) auf jeweils beiden Systemen.

Dann legt man auf den Servern vier virtuelle Server an:

vserver sql0[1-4] build –context 700[0-3] –hostname sql0[1-4]-n sql0[1-4] –interface sql0[1-4]=eth0:192.168.0.10-14 -m debootstrap — -d lenny

Danach wie gehabt mysql ndb herunterladen und installieren (z.B. mysql-cluster-gpl-7.0.9-linux-i686-glibc23) in /usr/local/ entpacken, und einen symlink auf /usr/local/mysql setzen.

Dann die Konfiguration (config.ini) wie folgt aufsetzen:

[NDBD DEFAULT]
NoOfReplicas: 2

DataDir: /var/lib/mysql-cluster
FileSystemPath: /var/lib/mysql-cluster

# Data Memory, Index Memory, and String Memory

DataMemory: 900M
IndexMemory: 300M
BackupMemory: 128M

MaxNoOfConcurrentOperations=100000

StringMemory=25
MaxNoOfTables=4096
MaxNoOfOrderedIndexes=2048
MaxNoOfUniqueHashIndexes=512
MaxNoOfAttributes=24576

TimeBetweenLocalCheckpoints=20
TimeBetweenGlobalCheckpoints=1000
TimeBetweenEpochs=100

MemReportFrequency=30
BackupReportFrequency=10

### Params for setting logging
LogLevelStartup=15
LogLevelShutdown=15
LogLevelCheckpoint=8
LogLevelNodeRestart=15

### Params for increasing Disk throughput
BackupMaxWriteSize=1M
BackupDataBufferSize=16M
BackupLogBufferSize=4M

[MGM DEFAULT]
PortNumber: 1186
DataDir: /var/lib/mysql-cluster

[NDB_MGMD]
Id:1
HostName: sql01

[NDB_MGMD]
Id:2
HostName: sql02

[NDB_MGMD]
Id:3
HostName: sql03

[NDB_MGMD]
Id:4
HostName: sql04

[NDBD]
Id:5
HostName: sql01

[NDBD]
Id:6
HostName: sql02

[NDBD]
Id:7
HostName: sql03

[NDBD]
Id:8
HostName: sql04

[API]
Id:9
HostName: sql01

[API]
Id:10
HostName: sql02

Nun die Management-Knoten auf allen vier VServern starten / initialisieren. Dazu in /usr/local/mysql

ndb_mgmd –initial -f config.ini

ausführen, anschliessend die 4 ndb Knoten starten (ndbd –initial)

Für die API Nodes natürlich noch mit ./scripts/mysql_install_db die mysql Datenbanken anlegen und anschliessend mit chmod mysql.mysql data -R die Rechte passend setzen.

Anschliessend sollte man mit ndb_mgm => show folgenden Output erhalten:

Cluster Configuration
———————
[ndbd(NDB)]     4 node(s)
id=5    @192.168.0.10  (mysql-5.1.39 ndb-7.0.9, Nodegroup: 0)
id=6    @192.168.0.12  (mysql-5.1.39 ndb-7.0.9, Nodegroup: 0, Master)
id=7    @192.168.0.11  (mysql-5.1.39 ndb-7.0.9, Nodegroup: 1)
id=8    @192.168.0.13  (mysql-5.1.39 ndb-7.0.9, Nodegroup: 1)

[ndb_mgmd(MGM)] 4 node(s)
id=1    @192.168.0.10  (mysql-5.1.39 ndb-7.0.9)
id=2    @192.168.0.12  (mysql-5.1.39 ndb-7.0.9)
id=3    @192.168.0.11  (mysql-5.1.39 ndb-7.0.9)
id=4    @192.168.0.13  (mysql-5.1.39 ndb-7.0.9)

[mysqld(API)]   2 node(s)
id=9    @192.168.0.10  (mysql-5.1.39 ndb-7.0.9)
id=10   @192.168.0.12  (mysql-5.1.39 ndb-7.0.9)

Nun sollte jeweils ein ndbd einer Nodegroup (0 und 1) auf einem physikalschen Server liegen, d.h. fällt ein Server aus, so sind immer noch mind. ein ndbd aus der jeweiligen Nodegroup verfügbar und der Cluster läuft weiterhin problemfrei.

Natürlich habe ich vorrausgesetzt, dass die Installation soweit fertig gestellt ist, d.h. mysql user angelegt, Datenverzeichnis angelegt (/var/lib/mysql-cluster – kann auch anders sein..) wurde etc. und in der my.cnf die Einträge für ndb gemacht wurden:

[mysql_cluster]
ndb-connectstring=sql01

[ndb_mgmd]
config-file=/usr/local/mysql/config.ini

Ein Test mit Namebench bestätigt, dass lokale Nameserver nicht langsamer sind als die von Google angepriesenen Services. Vereinzelt ist Google schneller, da Google natürlich sämtliche Anfragen von Usern cachen kann, während man lokal jedoch meist nicht so viele Seiten besucht und die Wahrscheinlichkeit eines Cachelookups dadurch natürlich sinkt.

Aus Datenschutzgründen sollte man die Nameserver von Google meiner Meinung nach nicht verwenden, selbst wenn ein Lookup 20ms schneller erfolgen sollte, als mit einem vom ISP zugewiesen Nameserver – diese 20ms fallen beim Surfen meist sowieso nicht auf.

Hier nochmal die Auswertung von Namebench für meinen lokalen Nameserver, meinen Nameserver in unserem RZ in Nürnberg sowie als Vergleich Googles Nameserver:

http://www.netz-guru.de/downloads/namebench_2009-12-05_2018.html

Es erscheint auch logisch, warum der lokale Nameserver schneller Antworten kann als ein Nameserver aus einem entfernten Netz – das liegt einfach an den Latenzen der Paketlaufzeiten zu den einezelnen Servern. Lokal hat man hier meist unter 0,1ms, während es bei DSL mindestens 10-20ms dauert, vorrausgesetzt das ist der Nameserver des ISP. Zu Googles Nameserver habe ich schon mal allein 110ms Latenz – da ist der eigentliche Request und die Zeit die das dauert bis ich eine Response bekomme noch nicht mitgerechnet.

Fazit: Finger weg von Googles DNS Services!

$ipv6 = “2001:4860:a005::68″;
function ip2long6($ipv6) {
$ip_n = inet_pton($ipv6);
$bits = 15; // 16 x 8 bit = 128bit
while ($bits >= 0) {
$bin = sprintf(“%08b”,(ord($ip_n[$bits])));
$ipv6long = $bin.$ipv6long;
$bits–;
}
return gmp_strval(gmp_init($ipv6long,2),10);
}

function long2ip6($ipv6long) {

$bin = gmp_strval(gmp_init($ipv6long,10),2);
if (strlen($bin) < 128) {
$pad = 128 – strlen($bin);
for ($i = 1; $i <= $pad; $i++) {
$bin = “0″.$bin;
}
}
$bits = 0;
while ($bits <= 7) {
$bin_part = substr($bin,($bits*16),16);
$ipv6 .= dechex(bindec($bin_part)).”:”;
$bits++;
}
// compress

return inet_ntop(inet_pton(substr($ipv6,0,-1)));
}

print $ipv6long =  ip2long6($ipv6).”\n”;
print $ipv6 = long2ip6($ipv6long).”\n”;

Ergebnis:

42541956150894553250710573749450571880
2001:4860:a005::68

Deshalb hier ein kleiner Patch, der den aktuellen source von debian lenny (postfix-policyd-1.80) patched, damit postfix-policyd keine delayed inserts mehr macht und einwandfrei mit Mysql-NDB-Cluster funktioniert.

postfix-policyd-1.80_mysqlndb.patch

Installiert wird das Ganze mit:

apt-get source postfix-policyd

wget http://www.netz-guru.de/wp-content/uploads/2009/08/postfix-policyd-1.80_mysqlndb.patch.txt

patch -p0 <postfix-policyd-1.80_mysqlndb.patch.txt

cd postfix-policyd-1.80

dpkg-buildpackage  -uc -b

Abgesehen davon, dass die Sperren an sich schon fraglich sind, da die Sperren gegen Artikel 5 GG verstossen, in dem es ausdrücklich heisst:

“(1) Jeder hat das Recht, seine Meinung in Wort, Schrift und Bild frei zu äußern und zu verbreiten und sich aus allgemein zugänglichen Quellen ungehindert zu unterrichten. Die Pressefreiheit und die Freiheit der Berichterstattung durch Rundfunk und Film werden gewährleistet. Eine Zensur findet nicht statt.“

haben die Sperren auch nicht die Wirkung, Kinderpornographie zu unterbinden, Kindesmisshandlungen oder Vergewaltigung zu verhindern, oder in sonst irgend einer Weise etwas auszurichten, außer dem BKA die Möglichkeit zu geben, willkürlich Seiten im Internet zu filtern. Willkürlich deshalb, weil diese Filterlisten “geheim” gehalten werden sollen, und weil es keine Möglichkeit der Kontrolle durch die Öffentlichkeit gibt. So können ebenfalls Webseiten unliebsamer Kritiker oder politischer Gegner gefiltert werden, ohne dass hierbei eine regulierende Instanz notfalls einschreiten könnte. Außerdem stellt sich die Frage, ob es nicht an sich schon strafbar ist, dass das BKA eine solche Liste weitergibt.

Was einem auch zu Denken geben sollte ist der Umstand, dass wenn eben eine solche Liste existiert auf der Webseiten erfasst sind, welche strafrechtlich relevantes Material verbreiten, warum denn dann die Strafverfolgungsbehörden nicht einfach die Provider anschreiben, in letzter Instanz die Server beschlagnahmen und den Geldfluss zu den eigentlichen Tätern zurückverfolgen.

Weiterhin ist es problematisch, über das DNS zu filtern, wenn man sich folgendes Szenario einmal vorstellt:

Angenommen, man möchte einen Konkurrenten im Internet ausschalten – man bräuchte nur einige anfällige Nameserver mittels DNS-Cache Poisoning mit IP-Adressen von Webseiten füttern, welche strafrechtlich relevantes Material anbieten und dann entweder abwarten, bis die Domain des Konkurrenten auf der Sperrliste des BKA landet, oder eben selbst nachhelfen, in dem man anonym die entsprechende Seite meldet.

Abgesehen davon ist es ein leichtes, die DNS Sperren der Provider zu umgehen:

• Man suche sich im Internet Nameserver, welcher keiner Zensur unterliegen, z.b. die Nameserver von OpenDNS (208.67.222.222 und 208.67.220.220)
• Man trage die Nameserver in die Netzwerkeinstellungen seines lokalen Rechners oder Router ein. (Bei Windows XP: Start -> Einstellungene -> Netzwerkverbindungen -> Lanverbindung -> rechtsklick Eigenschaften -> Internetprotokoll (TCP/IP) -> Folgende DNS Server verwenden)
• Alternativ dazu, VPNs oder Anonymizer wie the onio router (TOR),  JAP, oder eine Kombination von beidem.

Bei einem reinen DNS Filter reicht es aus, Nameserver zu verwenden, die eben nicht gefiltert werden und keiner Blacklist unterliegen. Gefilterte IPs aus dem Ausland kann man meist mittels einem VPN oder Anonymizern wie TOR erreichen, wenn der Endpunkt der Verbindung eben nicht mehr gefiltert wird.

Das war es schon – ich würde fast sagen, jeder halbwegs intelligente Mensch schafft es innerhalb von weniger als 10 Minuten die Nameserver zu ändern. Das Filtern an sich geht völlig am Problem des Kindsmissbrauchs vorbei und ist in meinen Augen einfach nur ein trojanisches Pferd um die Gesellschaft langsam an Internetfilter zu gewöhnen und kritisch Denkende oder der Politik Unliebsame aus dem Netz zu verbannen, damit diese keinen weiteren “Schaden” anrichten können. Weitere heiße Luft von diversen Politikern (und entsprechende Kommentare von denkenden Individuen) kann man hier finden:

• http://netzpolitik.org/2009/die-dreizehn-luegen-der-zensursula/
• http://blog.odem.org/2009/02/grundrechtseingriffe-wegzaubern.html
• http://www.bmfsfj.bund.de/bmfsfj/generator/BMFSFJ/Presse/pressemitteilungen,did=121758.html
• http://www.ccc.de/updates/2009/besucht-zensursula?language=de
• http://www.ccc.de/updates/2009/filter-mitschnitt?language=de

Alles in allem finde ich es mehr und mehr befremdlich, was in diesem Land so alles geschieht. Auf der einen Seite wird nach mehr Datenschutz und Datensicherheit gerufen (man denke an die zig Affairen Lidl, T-Com, Müller, etc..) – auf der anderen Seite werden Filterlisten etabliert um die User von angeblicher Kinderpornographie abzuhalten. Offensichtlich haben wir keine wichtigeren Probleme – die Umwelt, die Umverteilung von Ressourcen, Krankheiten, Energiegewinnung sind eben nicht so wichtig wie den Bürger unter Kontrolle zu halten…

vlinux.biz wurde in der aktuellen Ausgabe 02/2009 von Internet Intern getestet. Abgesehen davon, dass vlinux.biz vom Preis/Leistungsverhältnis gegenüber den anderen getesteten VServer-Anbietern gar nicht berücksichtig wurde, möchte ich hier doch mal meinen Unmut über die Testpraktiken von Internet Intern loswerden.

Testmethoden oder so was Ähnliches…

Webserver Stress Tool wurde als Last-Test für den vorinstallierten apache2 verwendet. Dabei hat Internet Intern festgestellt, dass von in etwa 18.000 Tests ca. 10.000 Fehler aufgetreten sind – dies ist nicht verwunderlich, hat der von Debian vorinstallierte apache2 als Standard nur 2 Serverprozesse gestartet, sowie ein Connection-Limit von 150 Maxclients gesetzt. Dass hierbei dann natürlich so viele Fehler auftreten, ist nicht verwunderlich – wurde aber von Internet Intern in keinster Weise erwähnt – wundert mich aber jetzt nicht wirklich, denn es hat nicht ein einziger Login via SSH von den Internet Intern Testern stattgefunden. Bei Max-Clients von 150 und 500 parallelen Test-Zugriffen bleiben eben einfach 350 davon unbeantwortet, dies entspricht exakt den von Internet Intern beobachteten Werten.

Konfigurationssoftware

Auch wurde bemängelt, dass vlinux.biz seinen Kunden keine Konfigurations-Software wie Plesk oder cPanel aufzwängen will – hier ist die Philosophie von vlinux.biz so, dass der Kunde selbst entscheiden soll und darf, welche und ob er überhaupt eine Konfigurationssoftware eingesetzt werden soll. Dies als Nachteil auszulegen und darauf rumzureiten, dass Plesk der Quasistandard für VServer-Management sei, ist einfach frei erfunden – schliesslich will nicht jeder VServer Kunde Massenwebhosting mit dem VServer betreiben. Viele Kunden installieren Gameserver oder Teamspeak-Server auf dem VServer, oder nutzen diesen als SVN-Server. Offensichtlich ist man aber bei Internet Intern in dieser Hinsicht nicht in der Lage, über den Tellerrand hinausszuschauen. Auch bietet vlinux.biz als einziger der getesten Anbieter mehr als 15 GB Space, nämlich stattliche 40GB RAID1 Space, und garantiert eine 100MBit Anbindung.

Fazit

Insgesamt kann man den Test von Internet Intern einfach nur als Zeitverschwendung betrachten – auf essentielle Dinge wie maximal verfügbares RAM, Anzahl der Kunden pro Host-System, etc. muss man in diesem Testbericht verzichten. Auch habe ich in den Logs des Test-Servers festgestellt, dass nicht ein einzier Login via SSH von Internet Intern erfolgt ist – vielleicht hatten die Tester auch überhaupt keine Lust, den Test wirklich aussagekräftig zu gestalten. Einfach nur enttäuschend. Ich kann die Internet Intern deshalb nicht empfehlen – kauft lieber die iX oder c’t, die wissen wenigstens wie man aussagekräftig testet…

Gänzlich unbekannt war mir bis heute jedoch GlusterFS, welches ebenfalls ein verteiltes Filesystem über das fuse-Modul bereitstellt. Hier hat man jedoch keine Limitierung auf max. 2 Nodes. GlusterFS bietet Automatic File Replication auch über mehr als 2 Nodes. Weiterhin kann man mit Unify mehrere RAID1-Knoten zu einem einzigen FS zusammenfassen. GlusterFS bietet noch mehr Möglichkeiten, hier mal ein Überblick:

• Standalone Storage (NFS Like)
• Distributed Storage

• Replicated Storage
• Distributed Replicated Storage

• Striped Storage

• Cloud/HPC Storage

• NFS Like Standalone Storage Server-2
• Aggregating Three Storage Servers with Unify

Mit einem Setup wie unter “Distributed Replicated Storage” beschrieben, lässt sich so ein gemeinsammes /var/spool für die Mailserver generieren. Die Konfiguration der Server kann man dann entweder in einer Datenbank oder LDAP ablegen, oder man verwendet die vom MTA vorgegebenen Konfig-Files, diese kann man auch auf einem verteiltem Filesystem speichern.

Den Source für GlusterFS kann man sich hier downloaden:

http://europe.gluster.org/glusterfs/2.0/LATEST/

Die Entwickler empfehlen ausserdem ein gepatchtes fuse-Kernel-Modul, welches GlusterFS erheblich beschleunigen soll:

http://europe.gluster.org/glusterfs/fuse/

Das Setup an sich ist relativ einfach. Unter Debian Etch fuse-Source entpacken, ./configure –enable-kernel-module –prefix=/usr  && make && make install && ldconfig

Dann glusterfs entpacken und ./configure –with-fuse=/usr/src/pfadzufuser &&  make && make install

Konfigurationsbeispiele gibt es unter www.gluster.org. Es sind auch kombinierte AFR,Stripe,Unify Filesysteme möglich, allerdings ist das Setup dann etwas komplizierter.

Weiterhin bietet GlusterFS neben normalem TCP/IP  auch direkte Verbindung über Infini-Band an. Auch redundante Verbindungen zur Storage werden unterstützt. Die Maximale Größe des Filesystems kann bis zu mehrere Petabytes betragen.

Möchte man viele kleine Dateien in glusterfs speichern, so kann glusterfs diese im DBD Berkeley DB Format speichern.

GlusterFS ist unter der GNU GPL v3 lizenziert.

Weitere Infos zu GlusterFS gibts auch bei der Wikipedia.

Wenn man Administrator eines produktiv genutzten Mailservers ist, macht man sich schon ab und zu mal Gedanken, wie man die Probleme, welche beim Betrieb des Servers auftreten oder auftreten könnten, mit möglichst wenig Aufwand – jetzt im Sinne von möglichst wenig Aufwand in der Zukunft – lösen kann. Ich betreibe einen kostenlosen E-Mail Dienst mit derzeit ca. 12.000 Usern. Seit 1998 hat sich das Setup des Mailservers eigentlich kaum geändert. Damals war sendmail noch das Nonplusultra, man war stolz dass SMTP-Auth und diverse Workarounds wie POP-Before-SMTP etc funktionierten, und im Allgemeinen gab es auch weniger SPAM. Zu dieser Zeit hatte quickemail.de ca. 500 User und die Welt der Flat-File Konfiguration war noch in Ordnung.

Irgendwann reicht das jedoch nicht mehr aus – Flat-Files werden schnell unübersichtlich und es musste eine Lösung her, um zumindest die E-Mail Accounts und User zu verwalten. Eine mySQL Datenbank war schnell aufgesetzt und mit ein paar Scripts und Cronjobs wuchs die Userbase dann immer weiter an. Da gingen dann aber auch die Probleme los.

SPAM von Botnets == DDOS?

Wenn man mehrere tausend User auf einer physikalischen Maschine hat, bringt das diverse Probleme mit sich. Zum einen braucht man ständig größere Festplatten, zum anderen natürlich auch mehr CPU und RAM. Das lässt sich eigentlich auf normaler Hardware noch relativ einfach erweitern. Problematisch wird das ganze dann, wenn man distributed SPAM von diversen Botnets abbekommt. Nicht nur der Mailserver an sich ist hier dann überfordert – bei jedem Connect wird ein nslookup durchgeführt, was sich auch wieder mit erhöhter Last auf den Nameservern auswirkt. Irgendwann ist dann jedoch Schluss – bei 200 gleichzeitigen Connects und einer Load von >100 kann es schon mal ein paar Minuten dauern, bis man diverse Services gestoppt hat um zumindest die Maschine wieder administrieren zu können.

SPOFs am laufenden Band

Eine einzelne Maschine zu verwenden ist natürlich auch nicht gerade von Vorteil. Fällt die Hardware aus, oder sind die Platten voll, steht die Maschine und nichts geht mehr. Klar kann man solche Ausfälle durch gutes Monitoring minimieren, spätestens jedoch beim nächsten Upgrade steht der Dienst erst mal wieder.

Wie man diese Probleme in den Griff bekommt?

Nun, wenn man nicht gerade im Lotto gewonnen hat, braucht man hier eine günstige Lösung die dennoch gut skaliert und fehlertolerant ist, also die Mails an sich redundant speichert, sowie mehrere Server zur Verfügung stellt um bei einem ausgefallenen System dennoch den Dienst aufrecht erhalten zu können. Das gestaltet sich jedoch gar nicht so einfach. Alleine dafür zu sorgen, dass die Daten auf allen Maschinen synchron sind, ist eine Herausforderung.

Es gibt diverse Lösungen mit NAS oder DRBD, proprietäre Lösungen von diversen Herstellern, Backup-Mailserver, etc – aber eine wirkliche günstige Alternative die mit normaler x86er Hardware auskommt, und bei der man nicht Tausende Euro Lizenzgebühren zahlen muss, hatte ich bisher noch nicht gefunden.

Deshalb habe ich mich mal eine Woche intensiv damit beschäftigt, das Mailproblem, zumindest für mich, ein für alle mal zu Lösen.

Daten redundant speichern…

kann man zum Beispiel mit mysql-ndb – Das war auch mein erster Versuch. Da man seit mySQL 5.1.6 bzw. der 6.2er NDB-Engine endlich Tables auch ondisk speichern kann, dachte ich das sei einen Versuch wert. Allerdings gibt es bei mySQL immer noch das Problem, dass die Indizes in-memory sein müssen. Bei einer Mailbase von sagen wir mal ca. 40GB kommt man so locker auf einen RAM-Bedarf von 8GB und mehr.

Dann gibt es noch die Möglichkeit dies einfach mit Master-Slave Replication zu lösen, hier ist jedoch das Problem, dass sobald der Master-Server ausgefallen ist, die User keine Daten mehr schreiben können und man nur noch Read-Only Access hat. Deshalb sind auch Lösungen wie PG-Pool oder Slony nicht wirklich praktikabel. Aber es gibt ja noch PGCluster. PG-Cluster ist im Vergleich zu mySQL-NDB wesentlich besser geeignet, um Daten redundant in einer Datenbank zu speichern. Hier müssen die Indizies nicht in-memory sein. Das derzeitige Release pgcluster1.9-rc5 basiert auf postgres 8.3 und funktioniert – sofern richtig konfiguriert – einwandfrei. Schade ist jedoch, dass auf der offiziellen Webseite von PG-Cluster immer noch die Version 1.3 als aktuell bezeichnet wird und das letzte Update der Seite irgendwann in 2005 war. Deshalb habe ich während der Evaluierungsphase erst PG-Cluster 1.3, dann den Fork cybercluster, und dann erst PG-Cluster 1.9 getestet. Mit PG-Cluster hat man zumindest schon mal das Problem ausgemerzt, dass man sich nicht mehr darum kümmern muss, was mit den Daten passiert. Die Master-Master oder auch Active-Active Replikation von PG-Cluster gewährleistet synchrone Daten über alle Cluster-Nodes hinweg.

Redundante Daten – und was machen wir nun damit?

Nach einiger Zeit googeln bin ich dann auf den dbmail gestossen – ein User aus dem IRC-Channel #linux.de hatte mich darauf hingewiesen, dass es soetwas bereits gibt. Bei dbmail werden alle E-Mails, Accounts, Forward etc. in der Datenbank gespeichert. In Verbindung mit PG-Cluster ergibt sich dann hier eben die Möglichkeit, Mailserver-Nodes zu betreiben die synchron sind. Die Last lässt sich dann via DNS-Roundrobin über die Mailserver und bei der Datenbank  mit dem PG-Loadbalancer verteilen. Mein aktuelles Setup sieht wie folgt aus:

Mit diesem Setup ist man dann in der Lage, solange zumindest ein Node online ist, die Mail-Services aufrecht zu erhalten. dbmail liefert ein Script mailbox2dbmail mit – damit lassen sich Mailboxen im mbox, maildir und mhdir Format leicht in dbmail einpflegen. Wie man so ein Setup bewerkstelligt, möchte ich hier nun kundtun. Ich selbst habe für mein aktuelles Setup ca. eine Woche gebraucht – das liegt aber auch daran, weil ich alles Mögliche getestet habe um herauszufinden, was am Besten funktioniert. Bei dbmail musste ich selbst einige Zeilen im Source-Code ändern. Auch Cyrus SASL muss man patchen, aber am Ende ist es das Alles wert.

Howto begin?

Als aller erstes benötigen wir mind. 2 Server. Wer möchte kann das auch zuerst innerhalb eines VServers oder VMware Session testen – ich rate dringend dazu, um sich mit der Sache etwas vertraut zu machen.

Die Server werden frisch mit Debian Etch installiert. Damit hier pgcluster allerdings kompiliert, müssen einige Pakete nachinstalliert werden – und nach dem ./configure muss man noch ein Makefile anpasssen. Benötigt wird build-essential libreadline5 libreadline5-dev asciidox flex bison libssl-dev rsync ssh. Sollte hier noch etwas fehlen, werde ich es zu gegebener Zeit ergänzen. Wichtig ist, dass das System eine utf8-Locale installiert hat und diese auch verwendet wird – sonst gibt es später Probleme mit PostgreSQL.

wget http://pgfoundry.org/frs/download.php/1705/pgcluster-1.9.0rc5.tar.gz
tar -xvzf pgcluster-1.9.0rc5.tar.gz
cd pgcluster-1.9.0rc5
./configure
make
make install

Postgres wird dann in /usr/local/pgsql installiert. Wer es woanders haben möchte, gibt einen Prefix beim configure mit an.

User anlegen, Rechte setzen:

cd /usr/local
useradd -d /usr/local/pgsql postgres
groupadd postgres
chown postgres.postgres pgsql -R

Hat man dies auf allen Nodes erledigt, wird mit initdb die Datenbank initialisiert:

su postgres
cd /usr/local/pgsql
./bin/initdb --locale=de_DE.utf8 data

Im Verzeichnis data legen wir dann auch entsprechend die Konfiguration für den Cluster an. Wichtig ist hierbei dass die Konfiguration bei allen Nodes identisch ist. Zuerst muss man die Datei pg_hba.conf im data Verzeichnis bearbeiten. Hier wird festgelegt, welcher Rechner sich zu der Datenbank verbinden darf. Das Ganze ist IP-basierend. Man sollte in jedem Fall für jeden Host einen eintrag in /etc/hosts machen, um DNS-Problemen innerhalb des Clusters aus dem Weg zu gehen – ich gehe hier bei diesem Howto mal davon aus, dass zuerst das ganze in einer Testumgebung installiert wird:

In pg_hba.conf unter der Zeile:

# IPv4 local connections:

muss für jeden Host des Clusters ein Eintrag gemacht sein:

host  all  all 192.168.0.10/32 trust # node01
host  all  all 192.168.0.20/32 trust # node02

Dies stellt sicher, dass die Nodes des Clusters gegenseitigen Zugriff auf sich selbst haben. Wichtig: man darf es nicht versäumen auch dem lokalen node Connections von sich selbst zu erlauben – daher ist auch bei node01 die IP für den node01 freizugeben.

Nun müssen wir die Datei cluster.conf im data Verzeichnis anlegen. Hier wird festgelegt, wohin repliziert werden soll:

<Replicate_Server_Info>
        <Host_Name> node01 </Host_Name>
        <Port>           5810 </Port>
        <Recovery_Port>  5811 </Recovery_Port>
</Replicate_Server_Info>
<Replicate_Server_Info>
        <Host_Name> node02 </Host_Name>
        <Port>           5810 </Port>
        <Recovery_Port>  5811 </Recovery_Port>
</Replicate_Server_Info>
</Replicate_Server_Info>
<Host_Name> node01 | node02 </Host_Name>
# Der Host_Name muss dem jeweiligen Node angepasst werden!
#
<Recovery_Port>         5611 </Recovery_Port>
<Rsync_Path> /usr/bin/rsync </Rsync_Path>
<Rsync_Option> ssh </Rsync_Option>
<Rsync_Compress> yes </Rsync_Compress>
<When_Stand_Alone> read_write  </When_Stand_Alone>
<Pg_Dump_Path> /usr/local/pgsql/bin/pg_dump</Pg_Dump_Path>
<Replication_Timeout> 1min</Replication_Timeout>
<LifeCheck_Timeout>3s</LifeCheck_Timeout>
<LifeCheck_Interval>15s</LifeCheck_Interval>

Nachdem die cluster.conf angelegt wurde, fehlt noch die pgreplicate.conf – hier wird festgelegt, von welchen Nodes gelauscht werden soll um die Queries zu replizieren:

<Cluster_Server_Info>
        <Host_Name> node01 </Host_Name>
        <Port>           5432 </Port>
        <Recovery_Port>  5611 </Recovery_Port>
</Cluster_Server_Info>
<Cluster_Server_Info>
        <Host_Name> node02 </Host_Name>
        <Port>           5432 </Port>
        <Recovery_Port>  5611 </Recovery_Port>
</Cluster_Server_Info>
<Host_Name> node01 | node02 </Host_Name>
# Der Host_Name muss dem jeweiligen Node angepasst werden!
#
<Replication_Port>    5810    </Replication_Port>
<Recovery_Port>       5811    </Recovery_Port>
<Response_Mode>       normal  </Response_Mode>
<Use_Replication_Log> yes     </Use_Replication_Log>
<RLOG_Port>           8301    </RLOG_Port>
<Replication_Timeout> 1min </Replication_Timeout>
<LifeCheck_Timeout> 3s </LifeCheck_Timeout>
<LifeCheck_Interval> 15s </LifeCheck_Interval>

Soweit so gut, PG-Cluster sollte jetzt lauffähig sein und Queries replizieren. Starten müssen wir das Ganze auf beiden Nodes noch:

su postgres
cd /usr/local/pgsql
./bin/pg_ctl -D data start
./bin/pgreplicate -D data

Man kann jetzt das ganze einmal testen indem man einfach eine Datenbank erzeugt, eine Tabelle anlegt, und von beiden Nodes Inserts durchführt:

./bin/createdb test
./bin/psql test
create table test ( test varchar(255));

# Dann jeweils auf beiden Nodes abwechselnd
#
insert into test (test) values (test1);
insert into test (test) values (test2);
select * from test;

Man kann jetzt beobachten, wie die Queries repliziert werden.

dbmail Setup

Auch hier müssen wir zuerst dbmail holen, entpacken und installieren:

cd /usr/src
wget http://www.dbmail.org/download/2.2/dbmail-2.2.11-rc3.tar.gz
tar -xvzf dbmail-2.2.11-rc3.tar.get
cd dbmail-2.2.11-rc3
./configure --with-pgsql=/usr/local/pgsql

Unter Debian Etch man/Makefile editieren, Zeile 547:
von:         asciidoc -b docbook -d manpage $<
zu:          asciidoc --unsafe -b docbook -d manpage $<

make
make install

dbmail ist jetzt in /usr/local/sbin installiert. Die Konfiguration dbmail.conf kann man nach /etc/ kopieren und anpassen. Wer pglb (Loadbalancer) verwenden will, muss vor dem kompilieren in modules/dbpgsql.c nach Zeile 110 Folgendes einfügen:

        g_string_append_printf(cs, " sslmode='disable'");

und der eigentliche MTA?

nun fehlt noch postfix. Postfix wird mit apt-get install postfix postfix-pgsql installiert. Wenn man sasl verwenden möchte, sei darauf hingewiesen, dass man hier ein gepatchtes sasl braucht, welches gecryptete Passwörter in der DB zulässt. Meine main.cf für Postfix sieht dann so aus:

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
append_dot_mydomain = no
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
myhostname = node01
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = $myhostname, mysql:/etc/postfix/sql-mydestination.cf
mynetworks = 127.0.0.0/8
mailbox_command = procmail
mailbox_size_limit = 0
recipient_delimiter = +
local_recipient_maps = pgsql:/etc/postfix/dbmail_rcpt.cf, pgsql:/etc/postfix/dbmail_rcpt_alias.cf
local_transport = dbmail-smtp:
broken_sasl_auth_clients = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_recipient_restrictions =
                           permit_mynetworks,
                           reject_invalid_hostname,
                           reject_non_fqdn_sender,
                           reject_non_fqdn_recipient,
                           reject_unknown_recipient_domain,
                           reject_unauth_pipelining,
                           reject_unknown_sender_domain,
                           permit_sasl_authenticated,
                           reject_unauth_destination
smtpd_sender_restrictions =
                           permit_mynetworks,
                           reject_authenticated_sender_login_mismatch,
                           permit_sasl_authenticated,
                           reject_sender_login_mismatch,
                           reject_unknown_sender_domain,
                           reject_unauth_destination,
                           reject_unknown_recipient_domain
check_sender_access = hash:/etc/postfix/sender_access
smtpd_sender_login_maps = pgsql:/etc/postfix/dbmail_sender_login.cf, pgsql:/etc/postfix/dbmail_sender_login_alias.cf
content_filter = smtp-amavis:[127.0.0.1]:10024

Dann hier noch die Files welche für sasl benötigt werden:

cat dbmail_rcpt.cf
user = dbmail
password = xxxxxxxxxxx
dbname = dbmail
hosts = node01
query = SELECT userid FROM dbmail_users WHERE userid='%s'

cat dbmail_rcpt_alias.cf
user = dbmail
password = xxxxxxxxxx
dbname = dbmail
hosts = node01
query = SELECT alias FROM dbmail_aliases WHERE alias='%s'

cat dbmail_sender_login.cf
user = dbmail
password = xxxxxxxxxx
dbname = dbmail
hosts = node01
query = SELECT userid FROM dbmail_users WHERE userid='%s'

cat dbmail_sender_login_alias.cf
# SMTP AUTH - check if the alias exists
user = dbmail
password = xxxxxxxxxx
dbname = dbmail
hosts = node01
query = SELECT userid FROM dbmail_users JOIN dbmail_aliases ON ( CAST (dbmail_aliases.deliver_to as bigint)=cast(dbmail_users.user_idnr as bigint)) WHERE dbmail_aliases.alias='%s';

cat sql-recipients.cf
user = dbmail
password = xxxxxxxxxxxxx
hosts = node01
dbname = dbmail
query =  SELECT alias FROM dbmail_aliases WHERE alias='%s' UNION SELECT userid FROM dbmail_users WHERE userid='%s';

Ich selbst habe meine relay-Domains noch in der mySQL Datenbank stehen, hier kann aber auch einfach nur das Hash-File verwendet werden. Jetzt steht die Postfix Konfiguration auch soweit. Wir müssen jetzt noch das DB-Layout in der Datenbank anlegen:

su postgres
cd /usr/local/pgsql
./bin/createdb dbmail
./bin/createuser dbmail
./bin/psql -U dbmail dbmail </usr/src/dbmail-2.2.11-rc3/sql/postgresql/create_tables.pgsql

Nun kann man postfix starten/restarten. Die pop3 und imap services startet man in /usr/local/sbin mit ./dbmail-imapd sowie ./dbmail-pop3d – Nützlich ist auch dbmail-users und dbmail-util.

Die amavis Konfiguration sowie das Anlegen und Verwalten von Usern möchte ich hier nicht weiter behandeln, da hier wohl jeder Admin seine eigenen Preferenzen hat. Dennoch hoffe ich hier etwas Wissen in PG-Cluster und dbmail vermittelt zu haben und wünsche viel Spass mit dem neuen Mailsetup. Die bisherigen Probleme sollten damit alle passé sein.