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

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

 

[harvey]

Gibt es eigentlich irgendwelche Infos zur manuellen Installation von ISPconfig 3 auf ein laufendes Produktionssystem, sprich installieren, aber configfiles manuell einspielen/anpassen? Ich möchte gerne einen Mail- und Webserver in einen ISPconfig Verbund aufnehmen. Ich kann aber die configfiles nicht einfach überschreiben lassen, weil dann alle betroffenen Dienste crashen würden (speziell das Mailsystem). Zur Zeit wird der Server, wie schon im ersten Posting beschrieben, mittels syscp verwaltet.

Die Webdomains könnten eventuell schon vor der Umstellung auf einen anderen Server im ISPconfig Verbund umziehen, aber der zu integrierende Server soll dann als dedizierter Mailserver im Verbund arbeiten, das bedeutet, dass das Mailsystem auf dem Server umkonfiguriert werden muss.

Gruß, harvey

 

[Till]

Hi,

also ich denke nicht, dass es gehen wird. Und zwar aus folgenden Gründen:

1) das mail setup von syscp zu ispconfig ist inkompatibel.
2) Die Datenbankstrukturen sind inkompatibel.
3) Die Dateistrukturen sind inkompatibel.

Aus diesen Gründen würde auch ein manuelles Umkonfigurieren keinerlei Sinn machen, da Du entweder exakt das gleiche machen musst, was der ISPConfig installer eh macht, damit es funktioniert. Oder es wird halt nicht funktionieren, wenn Du nicht das gleiche machst wie der Installer selbst. Ich kann Dir also nur davon abraten zu versuchen das Controlpanel eines laufendes Mailsystem umzustellen, das wird nicht funktionieren. Unabhängig davon ob es um syscp, plesk, ispconfig, ispcp etc. geht.

 

[harvey]

Hallo Till,

also dass die Strukturen generell unterschiedlich sind, ist, denke ich, schon klar. Das es keinen Migrationspfad von syscp zu ISPconfig gibt, auch.

Was ich möchte, ist eigentlich, die Mail Konfiguration parallel zum laufenden System für ISPconfig vorzubereiten, das heisst, alle configfiles in einem separaten Bereich (z.B. /etc/postfix.new, /etc/courier.new ...) anzupassen auf das neue Szenario, die Filesystem-Strukturen für ISPconfig anzulegen bzw. anzupassen, die Datenbank anzulegen (was kein Problem sein dürfte), Maildomains und Mailuser zu migrieren (mittels eines noch zu schreibenden Konverter-Progrämmchens) und dann in einem Moment des geringsten Mailaufkommens das System anzuhalten, die configfiles und Benutzerdaten umzukopieren (zum Glück beides Courier) und das System neu zu starten.

Und dann... Logfiles beobachten

Alternativ wäre auch denkbar: Alle relevanten configs zu sichern (s.o., /etc/postfix -> /etc/postfix.running etc.), Mailsystem anhalten, ISPconfig installieren und konfigurieren, jetzt alle ISPconfig configs zu sichern, die alten (running) zurückzukopieren und das System wieder starten. Dann in Ruhe das Mailsystem zu migrieren und wie oben beschrieben scharf schalten.

Und dann... Logfiles beobachten

Meine Frage war halt nur: hat schon jemand so etwas mal angedacht oder durchgezogen?

 

[Till]

Ich denke nicht, dass das Vorgehen so erfolgreich sein wird. An Deiner Stelle würde ich folgendes machen:

Zieh Dir eine Kopie des Servers in eine virtuelle Maschine (vmware, virtualbox etc.) und versuche es dort mit der Migration. Das uaf nem live System zu machen ist tödlich. Du kannst Dir dann auche infach eine 2. vm mit ispconfig erstellen und dann von dort die postfix Konfigurationsdateien nehmen, die der ispconfig Installer erstellt hat.

Ich würde dir zur Migration des Mailservers aber definitiv zu einem 2. Server raten und nicht versuchen den einen Server im laufenden Betrieb umzustellen. Dann kannst Du bei Fehlern auch im schlimmsten falle zurückschalten.

 

[harvey]

So, der erste Teil ist geschafft. 2 MX-Server übernehmen jetzt den Mailempfang inkl. Spam- und Virenprüfung für alle Maildomains in meiner Verwaltung. Ich habe zwar nun, wie schon oben beschrieben, für jede Domain und jeden MX-Server einen Eintrag im Email Routing, aber damit kann ich erst mal leben. Auf jeden Fall kann ich diesen Part jetzt zentral verwalten.

Der Mailserver selbst, also Postfix und Courier, laufen momentan noch mit der syscp-Datenbank, aber die ISPconfig-Datenbank läuft schon parallel und kann jetzt komplett - ZENTRAL - vorbereitet werden. Auch die fertigen Configfiles für Postfix und Courier liegen schon bereit. Ein Script fährt dann zur Umstellung die Postfix- und Courierserver herunter, fertigt eine Sicherung an, kopiert anhand einer Liste die configfiles und mittels eines SQL-Scripts die Mailboxen an die richtigen Stellen, passt die Rechte an und startet die Server wieder.

@Till: Kann es sein, dass ein Cronjob die main.cf der Postfix-Konfiguration zyklisch ändert (speziell den Eintrag message_size_limit auf 0 setzt)? Wenn ja, warum? Ich meinte, gelesen zu haben, dass nach der Installation keine Konfigurationsdateien mehr angefasst werden...

Grüße, harvey

 

[Till]

Die Werte für message_size_limit und mailbox_size_limit kannst Du in den Servereinstellunegn von ispconfig setzen.

Ansonsten werden nur die Variablen für den relayhost und dazugehörige sasl auth noch in der main.cf überschrieben.

 

[harvey]

Hallo Zusammen.

Erst einmal allen ein frohes, gesundes und erfolgreiches neues Jahr.

So, nachdem ich arbeitstechnisch erst einmal lange anderweitig beschäftigt war und nur wenig an der Umstellung arbeiten konnte, nun die Erfolgsmeldung. Der Rechnerverbund läuft mit momentan vier Rechnern stabil und kann zentral verwaltet werden.

Nachdem ich das System nun im Produktionsbetrieb beobachten konnte, kann mein Fazit nur lauten: der Umstieg auf ISPconfig 3 hat sich gelohnt. Zwar sind noch ein paar Ungereimtheiten aufgetaucht, speziell mit dem Webserver-Betrieb und der vhost-Verwaltung (hier speziell mit Subdomains) sowie mit dem Spam-Handling, aber das mag auch mit meiner Herangehensweise an die Administration liegen.

An die Forenadmins: Kann es sein, dass es ungebetene Besucher gibt? Ich habe eine PM von einer natali7 bekommen mit folgendem Inhalt:
"Hello friend, i found you http : //effectmeds.com/harvey " (den Link hab ich unschädlich gemacht).

Grüße, harvey

 

[planet_fox]

An die Forenadmins: Kann es sein, dass es ungebetene Besucher gibt? Ich habe eine PM von einer natali7 bekommen mit folgendem Inhalt:
"Hello friend, i found you http : //effectmeds.com/harvey " (den Link hab ich unschädlich gemacht).

Ich werde das prüfen und mit natali7 sprechen

 

[Till]

Habe den User Natali7 gelöscht.