Debian? – Hat doch schon Marc Shuttleworth bewiesen, das taucht ja anscheinend nix, weswegen die Entwicklungspower in das ach so grandiose Ubuntu gesteckt werden muss. Aber mal ehrlich, wir wissen doch selber, Ubuntu … und so – da ist ‘n Fork schon absolut sinnlosvoll: Mint macht, wenn nicht alles besser, zumindest alles gleich, bis auf das schicke, andere Wallpaper.

Aber was wäre die schöne Welt des Software-Kommunismus, wenn man nicht von jedem Fork ‘n Fork machen könnte? Deswegen, man sehe und staune, das bessere “Mint” ist Peppermint. Noch Fragen? Ich hab keine mehr, denn das ist – bei aller Liebe zu OpenSource und freier Software – so ziemlich unnötig. Aber nun ja, ich freue mich schon jetzt auf den Fork von Peppermint, was dann neben einen noch leichtgewichtigeren Windowmanager (vielleicht als Anregung mal genannt: Framebuffer) ein noch schöneres Wallpaper mitbringt.

Aus dem Stau ist immerhin zähfließender Verkehr geworden. Die extreme Limitierung des Arbeitsspeichers bei Strato stellt mich doch vor größere Probleme. Mit apache, mysqld, postfix ist der Host anscheinend schon gut ausgelastet – dieses Verhalten kann ich bei vollmar.net nicht nachvollziehen. Zwar habe ich dort deutlich mehr zugesicherten Arbeitsspeicher, aber der Ressourcen-Verbrauch war doch überschaubar.

Für heute ist jedenfalls genug gefummelt und gefrickelt: Der apache kann wieder RewriteRules umsetzen, was wohl an der default-Konfiguration lag. Nachdem ich dort die gleichen Einstellungen wie bei den vHosts vorgenommen hab, konnte auch das Blog wieder Suchmaschinen-konforme URLs verarbeiten. postfix mit SASL, sowie fetchmail und courier-imap rennen auch. Aber es fehlt eben die Integration von amavisd um dem Spam Herr zu werden. Nur scheitert es an den verfügbaren Ressourcen.

Zum Wochenende hin werde ich die Datenbank auf den vServer bei vollmar auslagern, in der Hoffnung, daß dadurch etwas Arbeitsspeicher frei wird. Eine glückliche Lösung ist das allemal nicht. Im Zweifel muß ich den Mailserver wieder zu mir nach Hause auf den Fileserver holen und auf dem vServer lediglich ein Relay einrichten. So glücklich wäre ich damit auch nicht. So schön schnell das bei Strato auch alles ging, so schön schnell der KK-Antrag durch war und die Domain umgezogen wurde, so recht hilft mir das im Moment aber auch nicht weiter.

Denn mit Web-, Mail- und Datenbank-Server läuft vielleicht ein kleiner Teil dessen, was ich eigentlich gedenke auf einem vServer zu betreiben. Gewillt zwei vServer durch zu ziehen bin ich auch nicht, ebenso wenig, wie ich gewillt bin mehr zu bezahlen. So wie’s aussieht bin ich wohl noch weiter auf der Suche nach der eierlegenden Wollmilchsau zum fairen Preis von maximal ¤ 10,-/Monat. Oder es wird einfach wieder Zeit zurück zu rudern, damals™ tat’s ja auch der Heimserver.

Nun hab ich den ganzen Sonntag Nachmittag über meinem Mailserver gesessen und dabei einige eklatante Probleme zumindest beseitigen können. Netterweise hat mich Tormentor drauf hingewiesen, daß mein postfix eine ziemliche Spam-Schleuder sein könnte – der SMTPd war offenen wie ein Scheunentor. Wie das passieren konnte ist mir dabei aber etwas unklar, immerhin war er eigentlich mit SASL2 abgedichtet.

So richtig gefunden hab ich den Fehler letztlich auch nicht – zumindest tendiere ich dazu es nicht zu verstehen. Im Prinzip habe ich nach einem Haufen HowTos lediglich zwei Einträge in der /etc/postfix/main.cf ergänzt:

smtpd_sasl_path = smtpd
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, permit_mx_backup, reject_unauth_destination, check_relay_domains

Letzterer Eintrag war schon soweit vorhanden, jedoch wurd er um die letzten drei Optionen nur noch ergänzt. Jedenfalls verwirft postfix nun Mails von Usern, die sich nicht per erfolgreichem Abgleich mit der SASLDB am Server angemeldet haben.

Danach stand das Zusammenspiel zwischen AMaViS und postfix an. Auch da hab ich an der Konfiguration letzten Endes nicht viel verändert. Im Prinzip habe ich den AMaViS-Daemon nur auf die IP des vServers hören lassen. Nun jagt postfix eingehende Mails auch durch AMaVis, aber irgendwie ist da noch ein Port zu viel nach Außen offen.

Zu guter Letzt hab ich mich noch an einigen serverseitigen Sortierungen via procmail versucht, was soweit immerhin auch bisher erfolgreich erscheint. Nun müßte man wohl nur noch diese ominösen Bayes-Filter von AMaViS trainieren, wenn ich das System dahin zumindest richtig verstanden hab.

Mailserver sind und bleiben für mich einfach ein Buch mit sieben Siegeln. Das neben mir liegenden “Postfix-Buch” aus dem Open Source Press-Verlag ist ja immerhin auch vom Schwierigkeitsgrad des Themas her für “Gurus” (es gibt noch Novice und Wizard) eingestuft.

und ich kann in Ruhe die Migration des IMAP vom Gateway auf den vServer in Angriff nehmen. Vielleicht sogar schon morgen – obwohl es eher unrealistisch erscheint.

Aus einem Tag sind nun auch wieder zwei Wochen geworden und so richtig motiviert war ich nicht wirklich, als ich das Thema “vServer & IMAP” gestern angegangen bin. Jedoch brauchte es nicht zwingend eines besonderen Konfigurationsaufwandes. Immerhin lief hier schon der courier-pop3 Server und entsprechend dieser Konfiguration nimmt auch der IMAPd Verbindungen entgegen. Also für ein 1-Personen-System nichts großartiges mit MySQL-Tabellen und übermäßigem bearbeiten von Konfig-Dateien. Wie “sicher” das ist will ich aber grad in diesem Moment nicht wirklich wissen.

Naja, aber mal im Ernst – auch wenn POP3 über authpam(?) zumindest zufriedenstellend abgesichert ist und den lokalen User anspruchsvolle Passwörter zugewiesen wurden sollte das hoffentlich soweit reichen. Wichtiger ist da vermutlich, daß der postfix nicht als offene Spam-Maschine arbeitet. Nach der großen Hürde den IMAPd zu installieren brauchte ich also nur noch mein Maildir vom lokalen Server zum vServer kopieren. Performance ist – bei meinen paar Mails – durchaus akzeptabel.

Dann muß ich mich über meine eigene Ungeschicktheit hier mal auslassen: Seit mehreren Jahren läuft ein IMAP hier bei mir und ich bin die ganze Zeit zu blöd gewesen die Mail-Clients so zu konfigurieren, das ausgehende Mails im “Sent“-Ordner auf dem IMAP landen. Ich hätte einige ausgehende Mails mehr archivieren können.

Zu guter Letzt wollt ich mich noch an Filterwerkzeugen für Spam und Viren probieren, aber trotz des durchaus guten und umfangreichen HowTos von debianhowto.de zum Thema amavis kann ich in der Hinsicht keinen positiven Vollzug vermelden. postfix meldet in den Logfiles:

babytux postfix/qmgr[3806]: 06D25C4596: to=, relay=none, delay=1153, delays=1153/0/0/0, dsn=4.3.0, status=deferred (mail transport unavailable)
babytux postfix/qmgr[3806]: warning: connect to transport amavis : Connection refused

Wer gerne einen Blick in die Konfigurations-Dateien werfen mag, darf sich gerne melden. Irgendwie komm ich da zur Zeit nicht weiter. Vielleicht hilfts ja schon, wenn man einmal drüber schläft.

Es wurd langsam aber sicher mal Zeit, den vServer auf die aktuellste Stable-Version von Debian zu aktualisieren. Immerhin wurde Debian 4.0 aka Etch schon Anfang April veröffentlicht. Mit einem Backup der Daten im Rücken wurde die sources.list angepaßt und schon ratterterten die Status- und Erfolgsmeldungen durch’s Terminal. Bis auf – ja, bis auf … wieso sollte es auch mal direkt auf Anhieb glatt laufen?

Jedenfalls wollte sich proftpd mit dem MySQL-Modul nicht aktualisieren lassen. Ein paar --force-all und dem Überschreiben der alten Config-Datei später konnte dann proftpd erfolgreich ins System geprügelt werden. Lediglich meckerte nun der FTP-Client bei einem Verbindungsaufbau:

Protocol violation by server: blank line on control.
Remote host has closed the connection.

“Beheben” konnt ich den Fehler damit, daß ich in /etc/proftpd/modules.conf den Eintrag für das PostgreSQL-Modul (LoadModule mod_sql_postgres.c) auskommentiert habe. Jedenfalls läuft’s jetzt wieder und ich kann in Ruhe die Migration des IMAP vom Gateway auf den vServer in Angriff nehmen. Vielleicht sogar schon morgen – obwohl es eher unrealistisch erscheint.