Mehrere Debian Lenny Server zu Verbund zusammenlegen

[harvey]

Hallo Community,

ich betreue mehrere Server (eigene als auch Kundenserver), die ich momentan mit syscp verwalte. Jetzt möchte ich die Server zu einem Verbund zusammenlegen. Dazu soll als Adminsystem, wenn möglich, ISPconfig3 zum Einsatz kommen. Ziele sollen sein: einfache, da zentrale Benutzerverwaltung sowie Redundanz des Mailsystems (was die MXe angeht). Es soll hier nicht um ein Failover-Szenario gehen.

Das neue Konzept sieht grob vor, einen zentralen Server als Mail- und Adminserver einzurichten, und mehrere Server als Webserver und Mail-Exchanger (ich nenn sie hier mal Satellitenserver), zu konfigurieren. Auf den Satellitenservern soll der gesamte eingehende Mailverkehr auflaufen und Spam- und Virenbereinigt werden, bevor er den Mailserver erreicht. Ebenso soll der Mailserver die Satelliten zum Versand benutzen, da diese ja im DNS als Mailserver für die verwalteten Domains bekannt sind.

Meine Frage nun: Hat schon jemand eine solche oder ähnliche Lösung mit ISPconfig3 realisiert und gibt es schon Erfahrungen mit solch einem Serververbund unter ISPconfig3-Verwaltung.

Ich bin für jeden Hinweis, was ich nicht bedacht oder übersehen habe, dankbar. Auch Anregungen nehme ich gerne auf. Vielleicht kann ich ja für solch eine Konfiguration dann auch mal ein HowTo schreiben, wenn es jemanden interessiert.

Danke erst einmal fürs Lesen,

harvey

[F4RR3LL]

Servus Harvey,

dein Szenario geht noch ne Ecke weiter als ichs grade betreibe.
Ich betreibe derzeit ISPconfig 3 mit 3 Servern.
Server 1 sql/web/debian, Server 2 sql/mail/debian, Server3 nur sql/centos als sql server für weitere server die nur wenig sql für Andere aufgaben benötigen.

Bis dahin ist das kein Problem. Wie das jedoch in deinem Szenario ausschaut mit dem vorfiltern der Mails und anschließenden weiterleiten an den eigentlichen Server kann ich nicht sagen ob sich das mit ispconfig realisieren lässt. Da muss wohl Till was zu schreiben.

Gruß Sven

[harvey]

Hallo Sven,

danke erst einmal für Deine Antwort.

Es klingt ja schon mal sehr ermutigend, dass es prinzipiell mit einer mehrere Server umfassenden Lösung funktioniert.

Ich bin gerade dabei, meine Wunschlösung noch ein wenig weiter zu durchleuchten. Prinzipiell würde die Lösung Deiner Lösung gleichen bis auf das Mailsystem.

Bei dem Mailsystem müsste ich auf den Satelliten (mx1. - mxn) wahrscheinlich die zu relayenden Maildomains separat aus der Datenbank auslesen und Postfix über den virtual_relay_domains-Parameter bekannt machen. Das Relayziel, also den eigentlichen Mailserver, müsste ich dann in der Postfix-Konfiguration der MXe fest vorgeben. Ebenso müsste der Mailserver einen der MXe als 'Outgoing SMTP-Server' konfiguriert bekommen. Das wäre ja an sich noch kein Beinbruch, allerdings wäre dann wieder manuelle Konfiguration vonnöten, wenn ein neuer Server in den Verbund aufgenommen werden soll, wobei der Wegfall eines Servers in dem geplanten Szenario nicht weiter tragisch wäre, es sei denn, es wäre der letzte mx...

Ich werde mir als nächsten Schritt mal die Konfigurations-Templates anschauen. Vielleicht finde ich ja dort einen Ansatz.

Das einzige 'Problem', das ich bis hierher sehe, ist die Unterscheidung der Mailserver in MX-Server (Frontend-Server) und eigentlichen Mailserver (Backend-Server).

Aber prinzipiell bin ich der Meinung, das sich mit Hilfe von ISPconfig3 eine gangbare Lösung realisieren lässt.

Gruß, harvey

[Till]

ISPconfig kann das mit dem Relayen schon von sich aus, siehe transports in ispconfig.

[planet_fox]

Mal so in den raum gefragt, weshalb gibt es kein howto bis her dafür ?

[F4RR3LL]

Mal in den Raum sag... weil wohl noch keiner die Zeit dazu hatte

[harvey]

Hallo zusammen.

So, ich habe jetzt einmal eine neue Maschine komplett aufgesetzt und mittels ISPconfig 3 mit Hilfe des HowTos 'The Perfect Server - Debian Lenny 5.0' die Verwaltung eingerichtet. Das ganze funktioniert erst einmal sehr gut.

Dann habe ich eine Maildomain eingerichtet, die nur zu dem momentan bestehenden Mailserver relayen soll. Till sagte ja

Zitat von Till

ISPconfig kann das mit dem Relayen schon von sich aus, siehe transports in ispconfig.

Prinzipiell ist das wohl richtig und auch total in Ordnung, wenn man die Domain auf dem (dann MX-Server) deaktiviert und über das Email Routing einen neuen Transport anlegt.

Aber bei zur Zeit ca. 60 gewerblichen sowie noch einmal ca. 40 privaten Maildomains und geplanten 3 MX-Servern plus dem Mailserver müssten dann ja >= 100x4 Einträge gemacht werden. Des weiteren mus es auf dem Mailserver eine Möglichkeit geben, eigene Mailrouten vorzugeben, da einige Kunden Inhouse-Mailserver über Standleitung betreiben, und die wollen natürlich nicht per fetchmail o.ä. Ihre Mails abrufen sondern direkt eingeliefert bekommen. Dafür wäre dann das Email-Routing in ISPconfig zuständig. Und hier sehe ich einige meiner Probleme. Wenn sich dort ein Fehler einschleicht, dann kann das eine lustige Fehlersuche werden...

Ich will heute, so ich denn Zeit finde, mal eine SQL-Abfrage definieren und testen, die genau diese zwei Parameter für 'relay_domains' und 'transport_maps' aus der Datenbank herausliest und dort einträgt. Damit könnte man dann das Fehlerrisiko sowie die Pflege-Aufwände beträchtlich reduzieren. Zusätzlich kann man dann die automatische Empfänger-Validierung von Postfix mittels verify nutzen.

Auch die ganzen 'virtual_*' Parameter in der main.cf auf den MX-Servern könnte man weglassen, da dort nie eine Mailbox angelegt werden soll und kein Dovecot oder maildrop laufen muss/soll. Macht halt die Konfig-Dateien klein und übersichtlich.

Einzig der Mailserver muss über einen der MXe dann seinen SMTP-Verkehr abwickeln. Aber das kann man eventuell erst einmal mittels des relayhost oder relay_transport Parameters erledigen. Da muss ich mit dann noch einmal genau anschauen, was hier der beste Weg ist.

Aber so langsam klären sich die Nebel

Gruß, harvey

[harvey]

Hallo zusammen,

wie schon gesagt, so langsam klären sich die Nebel.

Ich habe jetzt mal 2 MX-Server aufgesetzt, die für einige (Test)Domains Mailtraffic annehmen und relayen sollen. Und jetzt fangen die Probleme an:

1) Eine Maildomain kann nur einem Server zugewiesen werden, ansonsten gibt es einen Fehler 'ERROR 1. Doppelte Domain'. Hier müsste also der Server mit den Mailboxen hin..

2) Einen Transport kann ich nur auf einem Server konfigurieren, ansonsten hier auch 'ERROR domain_error_unique'.

3) Eine Mail-Domain taucht nicht auf den MX-Servern in der Mail Domain Liste (Datenbank Tabelle mail_domain) auf, sondern nur auf dem eigentlichen Mailserver.

Ich kann natürlich jetzt hingehen und Postfix manuell auf den MX-Servern konfigurieren und $relay_domains und $transport_maps händisch eintragen. Aber das ist ja nicht ganz im Sinne eines zentralen Verwaltungstools.

An der Stelle wäre es natürlich super, wenn man einer Mail-Domain gleich die MX-Server mitgeben könnte. Wenn sich die MX-Server auch in der ISPconfig-Verwaltung befänden, wäre das ja nur ein auswählen und aktivieren des/der MX-Server.

Und die MX-Server könnten dann eine andere Postfix-Konfiguration bekommen, die komplett um die virtual_mailbox Parameter gestrippt ist.

Vielleicht finde ich ja in den Quellen einen Ansatz, um solch eine Erweiterung ohne große Umbauten umzusetzen.

Im übrigen kann ich so nach den ersten Erfahrungen mit ISPconfig 3 dem Entwicklerteam zu einer sehr guten Software gratulieren.

Gruß, harvey

[Till]

1+2) Die einfachste Lösung ist dass Du die unique checks in den form.php Dateien auskommentierst.

3) Mirroring von server Konfigurationen ist bereits im SVN und wird mit Version 3.0.2 veröffentlicht.

[harvey]

Hallo Till,

danke erst einmal für Deine Antwort.

Jetzt bin ich wieder ein Stück weiter.

Zu 1) So, wie ISPconfig eine Maildomain versteht, brauche/darf ich eine Maildomain nur einmal zuweisen, und zwar genau auf den Server, auf dem die Maildomain verwaltet wird, wo also die Mailboxen liegen. Hier ist also schon mal kein Eingriff nötig.

Zu 2) Sowohl 'relay_domains' als auch 'transport_maps' beziehen die Daten aus der Tabelle mail_transport. Dort liegen schon alle Infos, die man braucht, um einen MX sauber zu konfigurieren. Allerdings muss ich hier wirklich, wie Du beschrieben hast, den 'Unique check' auskommentieren, da ich sonst nur für einen MX den Transportweg definieren kann.

Zu 3) Hat sich ja mit 2) erledigt, da ich die Zieldomain in der mail_transport finde. Für dieses Szenario ist also kein Mirroring nötig.

Als nützliche Erweiterung könnte ich mir nach den jetzigen (wenigen) Erfahrungen mit ISPconfig 3 vorstellen, MX-Server separat anzulegen und zu verwalten und dann einer Maildomain genau so zuzuweisen wie den eigentlichen Mailserver. Das würde die Aufwände und Fehlerquellen deutlich minimieren und würde das Email-Routing für das lassen, für das es imho gedacht ist, nämlich für einzelne! Maildomains alternative Routen zu bestimmen.

Gruß, harvey