Im Prinzip ist die Konfiguration von Postfix als Backup-MX sehr einfach. Sofern im DNS ein zweiter MX-Record eingetragen ist, hat man die Konfiguration mit ein paar Zeilen in der main.cf erledigt. Man sollte darauf achten, dass keine Domain, für die man Backup-MX spielt, unter mydestionation gelistet sind.

mydestination = $myhostname, localhost

Andernfalls würde der Backup-MX glauben, er wäre das endgültige Ziel der Reise und die Mails frecherweise nicht weiterleiten. Sofern man mehrere Domain hat, macht es Sinn, die Domain einzeln (pro Zeile eine Domain) in einer Textdatei aufzulisten, und diese in der relay_domains Direktive zu übergeben. Ich "missbrauche" dafür meine /etc/postfix/virtual_mailbox_domains.

relay_domains=/etc/postfix/virtual_mailbox_domains

Sofern man nun Empfänger einschränken möchte, kann man das über die relay_recipient_maps machen, ich mache das aber nicht. Ich schränke das auf dem Primary-MX ein. Sonst müsste man Primary- und Backup-MX synchron halten. Dafür bin ich aber zu faul... Also bleibt der Eintrag leer.

relay_recipient_maps=

Abschließend muss man Postfix in der transport mitteilen, wohin der Backup-MX die Mails leiten soll. Pro Domain ist das eine Zeile.

example.de relay:[primary-mx.example.de]

Bitte nicht vergessen mittels

backup-mx:/etc/postfix# postmap transport

die Datei ins Hash-Format zu übertragen. Danach ist die Konfiguration abgeschlossen. Man sollte aber, dem Spam wegen, auch auf dem Backup-MX nicht zu lax mit der Konfiguration umgehen. Greylisting hat sich dort bewährt, daher setze ich es auf Primary- und Backup-MX ein. Ein Abgleich der Datenbanken ist eigentlich nicht notwendig, die Whitelist kann man einfach übertragen. Testen natürlich nicht vergessen. Sofern die Änderungen im DNS sich herumgesprochen haben, reicht es, auf dem Primary-MX den MTA zu stoppen. Im Log sollte man dann Meldungen in dieser Art sehen:

backup-mx postfix/smtpd[7447]: 811A11B48004: client=smtp.domain.de[212.202.xxx.xxx]
backup-mx postfix/cleanup[7504]: 811A11B48004: message-id=<75D70173AA1@relay.domain.local>
backup-mx postfix/smtpd[7447]: disconnect from smtp.domain.de[212.202.xxx.xxx]
backup-mx postfix/qmgr[10316]: 811A11B48004: from=<patrick@domain.de>, size=8035, nrcpt=1 (queue active)
backup-mx postfix/smtp[7530]: connect to mail.example.de[78.46.xxx.xxx]:25: Connection refused
backup-mx postfix/smtp[7530]: 811A11B48004: to=<patrick@example.de>, relay=none, delay=0.55, 
delays=0.49/0.01/0.05/0, dsn=4.4.1, status=deferred (connect to mail.example.de[78.46.xxx.xxx]:25: Connection refused)

Sobald der Primary-MX wieder da ist, werden die Mails nach kurzer Zeit zugestellt. Alternativ ein beherztes postqueue -f. Damit hat man noch ein Stückchen mehr Sicherheit beim Serverausfall. :)

Angeregt durch diesen Beitrag, habe ich MHVTL mal mit HP Data Protector getestet. Ergebnis: Läuft. Leerzeichen in VTL Namen findet MHVTL aber doof. Es lassen sich also keine MSLs simulieren. grmpf Ich empfinde IBM LTOs ja als Beleidigung einer jeden DP Cell, aber gut... Fakt ist: Läuft und fühlt sich ziemlich echt an. :) Da mein Urlaub aber nun zu Ende ist, muss die bebilderte Anleitung noch ein wenig warten.

v2238xxxxx:~# ps ax

bash: fork: Nicht genügend Hauptspeicher verfügbar

Mar 24 16:31:32 v2238xxxxx master[17489]: can't fork process to run service imaps: Cannot allocate memory

Mar 24 13:48:31 v2238xxxxx master[17442]: can't fork process to run service imap: Cannot allocate memory

Mar 24 16:31:33 v2238xxxxx cyrus/imaps[26366]: IOERROR: mapping cache file for user.xx.xx: Cannot allocate memory

Mar 24 16:31:33 v2238xxxxx cyrus/imaps[26366]: Fatal error: failed to mmap cache file

Mar 24 13:47:45 v223850901 postfix/master[12972]: warning: master_spawn: fork: Cannot allocate memory -- throttling

Inspiriert durch einen Artikel in der aktuellen iX, habe ich ein wenig mit stunnel unter Debian experimentiert. Es ist schon echt fies, was man da alles durchtunneln kann... Viel interessanter ist es aber, solche Tunnel zu finden. Dafür muss man sein Netz natürlich kennen, bzw. Komponenten wie Firewalls und/ oder IDS müssen entsprechend konfiguriert sein, bzw. überhaupt darauf ausgelegt sein, sowas zu finden. Ein entsprechend fähiger Admin sollte aber allein durch die lange Verbindungsdauer und die Datenmengen, die über eine einzige Verbindung gehen, hellhörig werden. Interessierten kann ich den Artikel "SSL/TLS für den unbeschränkten Netzzugang nutzen" in der aktuellen iX 03/2010 nur wärmstens empfehlen. Da wird u.a. auch gezeigt, wie man das ganze noch etwas unauffälliger machen kann. ;)

Ich habe mich Donnerstag ganz todesmutig das Exam zum Novell CLP 11 angemeldet, allerdings für Ende 2010. ;) Den CLA habe ich ja so bekommen, den CLP 11 brauche ich aber dann für den Novell Certified Linux Engineer. Den habe ich mir für 2011 vorgenommen. Ich habe halt die Wahl 2011 - LPIC 2 oder was Neues. Also nehme ich wahrscheinlich was Neues. ;) Ziele braucht der Mensch.

Nagios ist mir nicht ganz unbekannt. Ich war maßgeblich an der Entwicklung einer Managementappliance beteiligt. Das war aber noch zu Zeiten von Nagios 2.x. Nun habe ich für die interne IT meines Brötchengebers ein Nagios aufgesetzt, was unsere Server, Switches und Router überwacht. Endlich eine Sorge weniger. ;) Jetzt gibt es Mails, wenn etwas stirbt. Kommt zwar sehr selten vor, aber es ist immer doof, wenn die Kollegen ankommen und fragen, ob es gerade Probleme gibt. :D

Um ein Haar hätte ich die Mail vom LPI überlesen. Novell rechnet LPIC Zertifizierungen an. Damit komme ich, ohne noch was zu tun, in den Genuss nun als Novell CLA zertifiziert zu sein. Netter Zug von Novell. :)Trotzdem muss ich 2011 meine LPIC-2 in Angriff nehmen, da im November 2011 meine LPIC-1 ausläuft. Dann ist das auch schon wieder fünf Jahre her... wie die Zeit vergeht...

Man erlebt einen lustigen Effekt, wenn man versucht sich mit Firefox aus allen Newslettern auszutragen: Es geht nicht. Ein Klick auf "submit" bleibt ohne Ergebnis. Mit einem IE8 geht es... Toll, RedHat. ;)

EDIT: Mea maxima culpa. Es war der böse Adblock Plus in meinem Firefox. Sorry für das Layer-8 Problem.

Ich habe mich oft gewundert warum mein Mailserver oft Mails ablehnt, die ich über UMTS via O2 verschicke. Und das trotz AUthentifizierung. Irgendwann Nachts hatte ich eine Eingebung und habe es am Morgen danach direkt geändert. Siehe da, Fehler behoben. Hab ich mir schön selber in den Fuß geschossen...

Fehler:

smtpd_sender_restrictions = permit_mynetworks permit_sasl_authenticated  hash:/etc/postfix/access, reject_unknown_sender_domain

Funktioniert:

smtpd_sender_restrictions = permit_mynetworks permit_sasl_authenticated  hash:/etc/postfix/access

O2 hat teilweise keine PTRs für ihre Adressen, die an UMTS Clients rausgegeben wird. Das nimmt mir mein Postfix übel. Zurecht, immerhin habe ich ihn so konfiguriert. Typer Fall von "zu sicher gemacht".

Ich will mich ja nicht lumpen lassen. Hier die Erweiterung für den Artikel "poor man's cluster" um eine "poor man's XP" zu bauen... na ja, vielleicht nicht ganz eine XP... eine kleine XP. ;) Zu Beginn brauchen brauchen wir das iSCSI Enterprise Target.

root@lin01:~# apt-get install iscsitarget

root@lin01:~# update-rc.d -f iscsitarget remove

Target iqn.2007-02.de.blazilla:iscsi-cluster
    Lun 0 Path=/dev/drbd0,Type=blockio
    InitialR2T               Yes
    ImmediateData            No
    MaxRecvDataSegmentLength 8192
    MaxXmitDataSegmentLength 8192
    MaxBurstLength           262144
    FirstBurstLength         65536
    DefaultTime2Wait         2
    DefaultTime2Retain       20
    MaxOutstandingR2T        8
    DataPDUInOrder           Yes
    DataSequenceInOrder      Yes
    ErrorRecoveryLevel       0
    HeaderDigest             CRC32C,None
    DataDigest               CRC32C,None

Damit es aber auch richtig funktioniert, muss die /etc/default/iscsitarget auch noch angepasst werden. Immerhin soll der ietd nur auf der Cluster-IP lauschen:

ISCSITARGET_ENABLE=true
DAEMON_OPTS="--address=192.168.118.100"

Zum Schluss noch die passende haresources für Heartbeat:

lin01  192.168.118.100 drbddisk iscsitarget

Damit ist nun alles erledigt. Die Konfigurationsarbeiten müssen natürlich auf beiden Nodes durchgeführt werden. Nach einem abschließenden Neustart von Heartbeat auf beiden Nodes ist unser iSCSI Storage fertig. Am einfachsten lässt sich das mit dem Microsoft iSCSI Initiator testen. Tests zeigen übrigens, dass die Übernahme wirklich funktioniert. Bis auf einen kurzen Hänger ist nichts zu beanstanden, Windows meldet im Eventlog ein paar Fehler und dann, dass es geschafft hat die Verbindung wieder aufzubauen. Keine Lösung für das Enterpriseumfeld, aber eine sehr nette Spielwiese. :)