Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- konfigurationsbeispiele:anbindung_provisioning [2017/11/14 11:05] – [Backend System des Hosters (Provisioning-Datenbank)] lwsystems
+++ konfigurationsbeispiele:anbindung_provisioning [2019/01/08 15:45] (aktuell) – [Backend System] lwsystems
@@ Zeile 10: / Zeile 10: @@
   * [[#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 (Provisioning-Datenbank) =====
+===== 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, Passwort, Mailadresse(n), usw.) exemplarisch in der SQLite-Datenbank [[konfigurationsbeispiele:Provisioning Datenbank|provisioning.sqlite]] gespeichert. Die Provisioning-Datenbank ist hier beispielhaft mit vier Tabellen abgebildet.
-Weder Login-Namen, Mailadressen noch Aliasadressen sind in diesem fiktiven Szenario 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 verschoben 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|}}
@@ Zeile 26: / Zeile 28: @@
 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 ======
-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 =====
@@ Zeile 44: / Zeile 46: @@
   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;' |\
   while read -d\| domain customer; do
@@ Zeile 56: / Zeile 58: @@
 </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.

Das Benno MailArchiv Wiki

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge