Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung |
konfigurationsbeispiele:anbindung_provisioning [2017/11/14 11:01] – [Backend System des Hosters] lwsystems | konfigurationsbeispiele:anbindung_provisioning [2019/01/08 15:45] (aktuell) – [Backend System] lwsystems |
---|
* [[#Authentisierung]] | * [[#Authentisierung]] |
| |
Die Beispiele erläutern mit einfach nachvollziehbaren Shell-Skripten und einfachen Textdateien als Ersatz für an dieser Stelle typischerweise eingesetzte Datenbanken (oder Directory-Systeme usw.) die Anbindung an die jeweiligen Backend-Systeme eines Hosters. | Die Beispiele erläutern mit einfach nachvollziehbaren Shell-Skripten und einfachen Textdateien als Ersatz für an dieser Stelle typischerweise eingesetzte Datenbanken die Anbindung an die jeweiligen Backend-Systeme eines Hosters. |
| |
Aus den hier dargelegten Skripten und "Beispiel-Datenbanken" kann eine Integration in die eigenen Hosting-Systeme schnell abgeleitet und in einer beliebigen Programmiersprache der eigenen Wahl implementiert werden. | Aus den hier dargelegten Skripten und "Beispiel-Datenbanken" kann eine Integration in die eigenen Hosting-Systeme schnell abgeleitet und in einer beliebigen Programmiersprache der Wahl implementiert werden. |
| |
===== Backend System des Hosters ===== | ===== Backend System ===== |
| |
| Das in diesem Proof of Concept (PoC) verwendete fiktive Backend-System speichert die Daten in einer SQLite-Datenbank [[konfigurationsbeispiele:Provisioning Datenbank|provisioning.sqlite]]. Die Datenbank ist hier exemplarisch mit vier Tabellen abgebildet. |
| |
| In diesem Szenario unseres fiktiven Hosters sind weder Login-Namen, Mailadressen noch Aliasadressen fix den Kunden-Mailboxen zugeordnet, wie dies in der Praxis häufig der Fall ist. In diesem Beispiel-Setup können E-Mail-Adressen und Aliase des Kunden jederzeit flexibel zwischen den Konten des Kunden hin und her geschoben werden. Das nachfolgende Datenbankschema ist daher etwas umfangreicher, als bei einem einfachen Setup, wo E-Mail-Adresse (+ Alias-Adressen) = Mailbox ist. |
| |
In dem in diesem Proof of Concept (PoC) verwendeten fiktiven Backend-System (Provisioning-Datenbank) unseres fiktiven Hosters werden die Daten (Benutzername, Mailadresse, usw.) exemplarisch in der SQLite-Datenbank [[konfigurationsbeispiele:Provisioning Datenbank|provisioning.sqlite]] gespeichert. Die Provisioning-Datenbank ist hier beispielhaft mit vier Tabellen abgebildet. | |
| |
In diesem Szenario unseres fiktiven Hosters sind weder Login-Namen, Mailadressen noch Aliasadressen fix den Kunden-Mailboxen zugeordnet, wie dies in der Praxis häufig der Fall ist. In diesem Beispiel-Setup können E-Mail-Adressen und Aliase des Kunden jederzeit flexibel zwischen den Konten des Kunden hin und her geschoben werden. Das nachfolgende Datenbankschema ist daher etwas umfangreicher, als bei einem einfachen Setup, wo E-Mail-Adresse (+ Alias-Adressen) = Mailbox ist. | |
| |
{{:konfigurationsbeispiele:konfig-beispiel_anbindung_provisioning_-_grafik_1.jpg?nolink&712|}} | {{:konfigurationsbeispiele:konfig-beispiel_anbindung_provisioning_-_grafik_1.jpg?nolink&712|}} |
Alle ein- und ausgehenden E-Mails werden über ein Mail-Gateway (MTA) geroutet. Auf diesem ist ein [[benno-milter]] konfiguriert, der von jeder E-Mail eine Kopie zwischenspeichert. | Alle ein- und ausgehenden E-Mails werden über ein Mail-Gateway (MTA) geroutet. Auf diesem ist ein [[benno-milter]] konfiguriert, der von jeder E-Mail eine Kopie zwischenspeichert. |
| |
Die zwischengespeicherten E-Mails werden per SMTP an den auf dem Benno MailArchiv-Server laufenden [[benno-smtp]] Daemon übermittelt. Die lokale Kopie der Mail auf dem MTA wird nach Übergabe an Benno MailArchiv gelöscht. | Die zwischengespeicherten E-Mails werden per SMTP an den auf dem Benno MailArchiv-Server laufenden [[benno-smtp]] Daemon übermittelt. Die lokale Kopie der Mail auf dem MTA wird anschließend gelöscht. |
| |
| |
====== Automatisches Provisioning ====== | ====== Automatisches Provisioning ====== |
| |
Falls ein Kunde das Produkt //Benno MailArchiv// im Online-Portal des Hosters bucht, wird die Option in der Datenbank des Provisioning-Systems des Hosters eingetragen und anschließend die Aktualisierung der Benno MailArchiv Konfiguration getriggert. | Falls ein Kunde das Produkt //Benno MailArchiv// im Online-Portal des Hosters bucht, wird die Option in der Datenbank des Provisioning-Systems eingetragen und anschließend die Aktualisierung der Benno MailArchiv Konfiguration getriggert. |
Die Konfigurationsdatei ''benno.xml'' wird dabei von ''benno-writeconfig.sh'' automatisch aus der Datenbank heraus erstellt (generiert). Anschließend wird die Konfiguration der Benno-Dienste neu geladen, so dass die um den neuen Kunden ergänzte Konfiguration aktiviert wird. | Die Konfigurationsdatei ''benno.xml'' wird dabei von ''benno-writeconfig.sh'' automatisch aus der Datenbank heraus erstellt (generiert). Anschließend wird die Konfiguration der Dienste neu geladen. |
| |
===== benno-writeconfig.sh ===== | ===== benno-writeconfig.sh ===== |
| |
sqlite provisioning.sqlite \ | sqlite provisioning.sqlite \ |
'SELECT c.displayname,m.maildomain FROM customer AS c, maildomain AS m | 'SELECT c.displayname,m.maildomain FROM customer AS c ,maildomain AS m |
WHERE c.customer_id=m.customer_id;' |\ | WHERE c.customer_id=m.customer_id;' |\ |
while read -d\| domain customer; do | while read -d\| domain customer; do |
</code> | </code> |
| |
Das obige Skript ''benno-writeconfig.sh'' generiert die Konfigurationsdatei ''benno.xml'', in der die zu archivierenden Mandanten konfiguriert sind, automatisch aus den Template-Dateien [[xml_header.tpl]], [[xml_container.tpl]], [[xml_footer.tpl]]. Im Container-Template wird der Name des Kunden sowie die Domain(s), die in diesem Container archiviert werden sollen, eingesetzt. | Das Script ''benno-writeconfig.sh'' erstellt die ''benno.xml'' aus den Template-Dateien [[xml_header.tpl]], [[xml_container.tpl]], [[xml_footer.tpl]]. Im Container-Template wird der Name des Kunden sowie die Domain(s), die in diesem Container archiviert werden sollen, eingesetzt. |
| |
Danach wird die Konfiguration der Dienste //benno-archive// und //benno-rest// neu geladen. Die neue Konfiguration ist damit in Benno MailArchiv aktiv. | Danach wird die Konfiguration der Dienste //benno-archive// und //benno-rest// neu geladen. |
| |
| |