Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- konfigurationsbeispiele:anbindung_provisioning [2017/11/14 11:09] – [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 den Kunden-Mailboxen fest zugeordnet, wie dies in der Praxis häufig der Fall ist. In diesem Beispiel-Setup können E-Mail-Adressen und Aliase des Kunden daher 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