Cyrus IMAP unter Opensuse auf die Schnelle

Mein Freund Michael fragte mich mal, was ich tue, um alle meine gesammelten (alten) Mails auf Reisen einsehen zu können, wenn ich keine Verbindung zum Internet habe.

Ich denke, dass die Voraussetzung mit dem Internet gar nicht so entscheidend ist, denn nicht jeder möchte alle seinen Firmenmails oder auch seinen privaten Mails dauerhaft bei einem Provider vorrätig halten. Und nicht jeder hat einen eigenen Root-Server mit IMAP-Komponente im Internet.

In unserer kleinen Firma laden wir z.B. alle Mails von unseren verschiedenen Internet-Providern per "fetchmail" herunter und transferieren sie über Postfix auf einen lokalen, eigenen IMAP-Server (Cyrus) im Hausnetz. Dort werden Sie nach Kunden vorgefiltert.

Schon aus Sicherheitsgründen lassen wir unsere Mails nicht im Internet herumstehen. Wenn wir dann mal länger verreisen müssen, gibt es für uns zwei Methoden, unsere bisherigen Mails, die z.T. mehrere Gigabyte umfassen, unter Linux auf einem Laptop einzusehen:

  1. Disconnected IMAP-Account unter Kmail:
    Ich lege unter Kmail einen sog. "Disconnected-IMAP-Account" an und synchronisiere den vor unserer Abreise mit den Inhalten der mir zugänglichen Mailverzeichnisse auf unserem IMAP-Server. Das funktioniert in der Regel recht gut und ist sicher die einfachste Methode, seine IMAP-Mails vom hauseigenen Server auf Reisen mitzunehmen.

    Mit folgenden nicht unwesentlichen Einschränkungen: Solange man sich auf seine KDE-Installation verlassen kann, diese nicht grundlegend ändert oder updated, und keine versehentliche Synchronization des Disconnected-Imap-Accounts mit dem Nirwana anstößt .... Ein weiterer Nachteil ist natürlich der lokal auf dem Laptop benötigte Plattenplatz - in unserem Fall doch einige Gigabyte.

  2. Zugriff auf ein IMAP-Backup unter einem lokalen IMAP-Server:
    Ich kopiere zur Sicherheit den kompletten Inhalt des Verzeichnisses "/var/spoool/imap" von unserem SLES auf ein geschütztes Verzeichnis meines Laptops (mit cp -dpRv) oder eine kryptierte externe USB-Harddisk. Das ist ein sehr nützlicher Backup. Zur Not implementiere ich mir nämlich auf die Schnelle einen lokalen Cyrus-Server auf meinem Laptop und rekonstruiere mir dann die Mailverzeichnisse, die mich interessieren. Dann kann ich mit KMail auf dem Laptop auf den lokalen Cyrus-Server zugreifen und die benötigten Mails einsehen.

    Ein Vorteil dieser Lösung ist u.a. der, dass man nicht immer gleich alle Mailverzeichnisse zur Verfügung stellen muss, sondern evtl. nur die gerade interessanten, z.B. kundenbezogene. (Voraussetzung ist eine hinreichende Gliederung der Mailverzeichnis-Hierarchie)

Die Variante 2) ist auch dann ein schöner Rettungsanker, wenn man sich bei einem KDE-Upgrade in der Fremde (z.B. von KDE 4.5 auf 4.7) seine Akonadi- und Kmail-Installation auf einem Opensuse 11.4 praktisch zwangsweise zerschießen muss. Denn der Sprung vom Kmail 1.x zu Kmail2 und die entsprechend notwendigen Migrationen von IMAP-Resourcen funktionieren schlicht nicht fehlerfrei.

Oft genug muss der KDE-Nutzer seit der Akonadi-Einführung feststellen, dass Kmail sich nach fehlgeschlagenen Migrationsversuchen nicht mehr starten läßt. Dann bleibt einem nur mehr der Neuaufbau der Akonadi-Ressourcen und von Kmail durch Löschen der Inhalte entsprechender Akonadi- und Kmail-Konfigurationsdateien. Leider können dabei auch die "Disconnected-IMAP-Verzeichnisse" vom alten Kmail verloren. Das passierte mir neulich in Norwegen. Hat man dann seine IMAP-Dateien in Form eines Backups dabei, ist das kein Weltuntergang.

Wie kommt man also auf die Schnelle unter Opensuse zu einem lokalen Cyrus IMAP-Server, mit dem man die Mails eines IMAP-Backups einsehen kann? Das ist gar nicht so schwer, wenn man bei der Sicherheit Abstriche macht und auf eine Open-SSL-Umgebung für den lokalen IMAP-Server verzichtet. Den IMAP-Port des Cyrus-Servers kann man durch eine Firewall ja nach außen gezielt sperren, wenn man sich mit seinem Laptop während einer Reise ins Internet begibt.

Die nachfolgende Installation ist allerdings so simpel, dass sie kaum für mehr als das Lesen alter Mails aus einem Backup geeignet ist. Sie kann nicht für einen produktiven Betrieb - z.B. zusammen mit Postfix - eingesetzt werden. Aber das ist in diesem Artikel auch gar nicht die Zielsetzung.

Wer sich genauer mit CYRUS IMAP und SASL befassen will, sei auf dir Dokumentation unter

/usr/share/doc/packages/cyrus-imapd/doc/

und

/usr/share/doc/packages/cyrus-sasl/doc/

hingewiesen. (Hierzu muss man sich unter Opensuse natürlich die RPMs für die Paket-Dokumentation installiert haben.)

Schritt 1: Notwendige Pakete der Opensuse Repositories

Eine Voraussetzung der Cyrus-Installation ist , dass man sich bereits die RPM-Pakete von Opensuse für den lokalen Cyrus-Imap-Server und den SASL-Authentifizierungsmechanismus installiert hat. Folgende Pakte stellen nach meiner Erfahrung das notwendige Minimum dar:

  • cyrus-imapd
  • cyrus-sasl
  • cyrus-sasl-plain
  • cyrus-sasl-saslauthd
  • perl-Cyrus-IMAP
  • perl-Athen-SASL

Will man neben "Plain" andere sicherere SASL-Mechanismen wie z.B. "digest-MD5" (für die Passwortverschlüsselung) benutzen, so muss man sich die entsprechenden Pakte zusätzlich installieren. Ich gehe auf solche Varianten aber nachfolgend nicht ein.

Schritt 2: Starten der Dämonen

Bevor man administrativ tätig werden kann, müssen die Cyrus- und SASL-Dienste laufen. Man prüft den Status der Dienste mit

#   rccyrus status
#   rcsaslauthd status

Nötigenfalls startet man die Dienste unter Opensuse explizit per

#   rccyrus start
#   rcsaslauthd start

Für ein dauerhaften Start beim Hochfahren trägt man die Dienste über "Yast >> Systemdienste (Runlevel)" für die gewünschten Runlevels [ z.B. 3 und 5 ] ein.

Schritt 3: User "cyrus" als Mitglied der Gruppe "mail" überprüfen

Wir prüfen dann, dass es einen User "cyrus" im System gibt. Dieser wird unter Suse normalerweise bei der RPM-Installation automatisch angelegt und ist Mitglied der Gruppe "mail". Sein Homeverzeichnis ist "/var/lib/imap". Er sollte ferner Owner des Verzeichnisses "var/spool/imap" sein.

laplux:~ # ls -l /var/spool
.....
drwxr-x--- 3 cyrus mail 4096 Nov 17 17:26 imap
....

Schritt 4: SASL für imap als Authentifikations-Mechanismus festlegen

Der Cyrus-SASL-Mechanismus muss in der Datei "/etc/imapd.conf" als Auth-Verfahren für den Cyrus IMAP-Server festgelegt werden. Siehe hierzu die rot markierten Einträge im nachfolgenden Listing der "imapd.conf"-Datei. Diese sehr einfache Datei wurde mit der Installation der RPM-Pakete angelegt (bis auf einen Eintrag "allowplaintext", den wir weiter unten erläutern):

configdirectory: /var/lib/imap
partition-default: /var/spool/imap
sievedir: /var/lib/sieve
admins: cyrus
allowanonymouslogin: no
autocreatequota: 10000
reject8bit: no
quotawarn: 90
timeout: 30
poptimeout: 10
dracinterval: 0
drachost: localhost
sasl_pwcheck_method: saslauthd
lmtp_overquota_perm_failure: no
lmtp_downcase_rcpt: yes
 
# Changed by cyrus for an installation of intern backup server
allowplaintext:yes
 
#
# if you want TLS, you have to generate certificates and keys
#
#tls_cert_file: /usr/ssl/certs/cert.pem
#tls_key_file: /usr/ssl/certs/skey.pem
#tls_ca_file: /usr/ssl/CA/CAcert.pem
#tls_ca_path: /usr/ssl/CA

Danach starten wir den IMAP-Server per

#   rccyrus restart

neu.

Hinweis 1: Die Konfigurationsvielfalt für einen ausgewachsenen IMAP-Server kann man nach einem Blick in die Manpage erahnen:

#  man 5 imapd.conf

Für unsere einfachen Zwecke genügen die obigen Einträge aber vollkommen.

Schritt 5: SASL-Passwort für den User "cyrus" setzen und die Datei "sasldb2" lesbar machen

Auch der User "cyrus" muss sich natürlich gegenüber dem IMAP-Server authentifizieren. Als User "root" legen wir nun das SASL-Passwort für cyradm fest. Hierzu benutzten wir das Programm "/usr/sbin/saslpasswd2":

laplux:~ # saslpasswd2 -c cyrus
Password:
Again (for verification):

Dabei geben wir das gewünschte Passwort (nachfolgend mit "CYRUS_PWD" bezeichnet) zweimal ein.

Zudem müssen wir dafür sorgen, dass der User "cyrus" die Datei "/etc/sasldb2" lesen kann. Am einfachsten geschieht dies in unserem Fall, indem man "cyrus" zum Owner macht:

laplux:~ # chown cyrus /etc/sasldb2*

Bei komplexeren Konfigurationen, in denen mehrere Programme SASL nutzen, muss hier bei Bedarf geeignete Gruppen aufbauen, die noch andere User mit aufnehmen.

Schritt 6: Mailverzeichnis für einen neuen Mailuser "rmx" anlegen

Unser Mailuser, unter dessen ID wir auf die Mails zugreifen wollen, habe die UID "rmx". Wir legen nun einen Mailordner (Eingangskorb) für den User "rmx" an. Dazu wechseln wir zum User "cyrus" und führen dann das Kommando "cyradm" aus, das uns in eine eigene Kommandoumgebung für den Cyrus-Server führt:

lap3lux64:~ #   su - cyrus
cyrus@lap3lux64:~> cyradm
cyradm> connect localhost
Password:
localhost.localdomain> lm
user.rau (\HasChildren)

user.rau.Gesendete Objekte (\HasNoChildren)
user.rau.alpha_inbox (\HasNoChildren)

localhost.localdomain> cm user.rmx
localhost.localdomain> lm
user.rau (\HasChildren)

user.rau.Gesendete Objekte (\HasNoChildren)
user.rau.alpha_inbox (\HasNoChildren)

user.rmx (\HasNoChildren)

localhost.localdomain>

Zu den Kommandos im Einzelnen:

Bevor wir ein Verzeichnis anlegen können, müssen wir uns mit unserem lokalen cyrus-Server verbinden. Dies geschieht über das cyradm-Kommando "connect" - hier "connect localhost". Das einzugebende Passwort ist nun genau das zuvor eingerichtete SASL-Passwort "CYRUS_PWD".

Nach der erfolgreichen Verbinung zum lokalen IMAP-Server sehen wir uns zunächst einmal um. Das oben dargestellte Kommando "lm" zeigt alle bereits vorhandenen Mailverzeichnisse an. Beginnt man von Scratch wird hier natürlich kein Verzeichnis angezeigt. Im obigen Beispiel sind bereits Verzeichnisse für einen User "rau" vorhanden.

IMAP arbeitet mit ganzen hierarchischen Mail-Verzeichnisbäumen. In der IMAP-Verzeichnishierarchie wird ein User-Zweig für den User mit der ID "uid" normalerweise durch Erzeugen des Verzeichnisses "user.uid" angelegt.

Der Schlüsselbefehl für das Anlegen eines Mailverzeichnisses ist "cm". Legt man keinen speziellen Posteingang an, so kann dieses Verzeichnis auch als Default-Posteingangskorb benutzt werden. Das abschließende "lm" zeigt an, dass das gewünschte Verzeichnis erstellt wurde.

Hinweis 2: Man kann alle Befehle, die einem unter der "cyradm"-Oberfläche zur Verfügung stehen, durch Eingabe von "help" einsehen. Die cyradm-Umgebung verläßt man mit "quit" oder "exit".

Hinweis 3: Hier lohnt es sich, als root einen vergleichenden Blick auf die Verzeichnisstruktur unter "/var/spool/imap/user/rmx" zu werfen.

laplux:/var/spool/imap/user/rmx # ls
cyrus.cache cyrus.header cyrus.index

Man erkennt, dass bereits Filestrukturen zur Indizierung und zum Cachen der Verzeichnisinhalte angelegt wurden. Diese sind zu füllen, sobald wir das Verzeichnis mit Inhalt versehen.

Hinweis 4: Die Hierarchie der Mailverzeichnisse wird in der "cyradm"-Umgebung durch eine einfach qualifizierende Punkt-Notation erfasst - z.B.: user.uid.suppliers.suse.

Schritt 7: SASL-Passwort für den Mail-User "rmx" setzen und dem User Rechte an seinem Mailverzeichnis geben

Dem Leser ist sicher aufgefallen, dass auch der User "rmx" natürlich noch SASL bekannt gemacht werden muss. Ferner kann man sich denken, dass ein IMAP-User hinreichende Rechte bekommen muss, um auf die ihm zugeordneten IMAP-Verzeichnisse auch zugreifen zu dürfen. Wir benutzen zunächst wieder "saslpasswd2" als root:

laplux:~ # saslpasswd2 rmx
Password:

Again (for verification):

Das Passwort für den User "rmx" sei "RMX_PWD". Nun gehen wir noch einmal in die "cyradm"-Umgebung und verbinden uns mit dem lokalen Server und schauen nach, wie wir Rechte abfragen und vergeben können :

ap3lux64:~ # su - cyrus
cyrus@lap3lux64:~> cyradm
cyradm> connect localhost
Password:
localhost.localdomain> help
 
authenticate, login, auth authenticate to server
chdir, cd change current directory
createmailbox, create, cm create mailbox
deleteaclmailbox, deleteacl, dam remove ACLs from mailbox
deletemailbox, delete, dm delete mailbox
disconnect, disc disconnect from current server
exit, quit exit cyradm
help, ? show commands
info display mailbox/server metadata
listacl, lam, listaclmailbox list ACLs on mailbox
listmailbox, lm list mailboxes
listquota, lq list quotas on specified root
listquotaroot, lqr, lqm show quota roots and quotas for mailbox
mboxcfg, mboxconfig configure mailbox
reconstruct reconstruct mailbox (if supported)
renamemailbox, rename, renm rename (and optionally relocate) mailbox
server, servername, connect show current server or connect to server
setaclmailbox, sam, setacl set ACLs on mailbox
setinfo set server metadata
setquota, sq set quota on mailbox or resource
subscribe, sub subscribe to a mailbox
unsubscribe, unsub unsubscribe from a mailbox
version, ver display version info of current server
xfermailbox, xfer transfer (relocate) a mailbox to a different server
 
localhost.localdomain> lam user.rmx
rmx lrswipkxtecda
 
localhost.localdomain> sam
usage: setaclmailbox mailbox id rights [id rights ...]
 
localhost.localdomain> sam user.rmx rmx all
localhost.localdomain> lam user.rmx
rmx lrswipkxtecda
 
localhost.localdomain> sam user.rmx rau all
localhost.localdomain> lam user.rmx
rmx lrswipkxtecda
rau lrswipkxtecda
 
localhost.localdomain> cm user.rmx.sent
localhost.localdomain> lam user.rmx.sent
rmx lrswipkxtecda
rau lrswipkxtecda
 
localhost.localdomain> sam user.rmx rau none
localhost.localdomain> lam user.rmx
rmx lrswipkxtecda
localhost.localdomain>

Das Help-Kommando führt uns zu den Kommandos "lam" für die Anzeige der Access-Rights und "sam" zum Setzen der Rechte. Die oben im Listing angezeigten Kommandos sind dann kaum erläuterungsbedürftig.

Wir erkennen, dass der User "rmx" bereits automatisch alle Rechte am Mail-Verzeichnis "uxer.rmx" zugeteilt bekommen hat. Diese Rechte werden auch auf weitere Subverzeichnisse "vererbt". Dies gilt übrigens auch für andere User - hier z.B., wenn man auch dem User "rau" sämtliche Rechte am Verzeichnis "user.rmx" einmal testweise zuordnet. Am Schluss nehmen wir dem User "rau" die zugewiesenen Rechte wieder weg.

Hinweis 5: Welche Rechte es in Bezug auf Mailverzeichnisse unter Cyrus IMAP gibt und was sie bedeuten, erfährt man durch Studium der folgenden Doku-Seite, die man in einem Browser betrachten kann:

file:///usr/share/doc/packages/cyrus-imapd/doc/overview.html#aclrt

Schritt 7: Mails aus dem Backup kopieren und Mailverzeichnis rekonstruieren

Nun wollen wir das Verzeichnis "user.rmx" mit Mailinhalt füllen. Dies geschieht einfach durch Umkopieren der Inhalte des korrespondierenden Verzeichnisses in unserem Backup von "/var/spool/imap", das wir von unserem richtigen IMAP-Server angelegt hatten.

Typischerweise haben wir unsere Sicherung auf einem USB-Stick oder einer USB-Platte dabei. Diese sei lokal am Laptop unter unter dem Verzeichnis "/backup" gemountet und die ursprüngliche Verzeichnisstruktur "/var/spool/imap" sei unter dem Verzeichnis "/bup_cyrus" abgelegt.

Dort - also am Ort des Backups - suchen wir unter den obigen Annahmen als "root" das Verzeichnis "/var/spool/imap/user/rmx". Unter den obigen Annahmen finden wir es unter:

/backup/bup_cyrus/var/spool/imap/user/rmx"

(Natürlich können wir ggf. auch ein anderes Verzeichnis wählen, welches uns interessiert und das wir anschließend im lokalen Cyrus gerne unter user.rmx öffnen möchten. Nur Mails aus unterschiedlichen Usprungs-Verzeichnissen sollte man nicht im selben Zielverzeichnis mixen.)

Wir kopieren dann vom Backup alle Files (Mails) vom gewünschten Verzeichnis - hier also aus "/backup/bup_cyrus/var/spool/imap/user/rmx" - in das korrespondierende Mailverzeichnis "/var/spool/imap/user/rmx" auf unserem lokalen IMAP-Server

Ausgenommen werden vom Kopiervorgang evtl. vorhandene Subverzeichnisse und Files, die mit "cyrus." beginnen (cyrus.cache, cyrus.header, cyrus.index).

Abschließend ändern wir mit

laplux:~ # cd /var/spool/imap/user/rmx
laplux:/var/spool/imap/user/rmx # chown cyrus.mail *

den Owner und die Gruppe der kopierten Dateien (= Mails) ab.

Nun gehen wir wieder in den "cyradm"-Bereich und "rekonstruieren" das Verzeichnis für den Gebrauch. Dies geschieht über den Befehl "reconstruct", der die Cyrus -Index- und Cyrus-Datenbankstrukturen gebrauchsfähig macht und auf den tatsächlichen aktuellen Inhalt des Verzeichnisses abstimmt:

lap3lux64:~ # su - cyrus
cyrus@lap3lux64:~> cyradm
cyradm> connect localhost
Password:
localhost.localdomain> reconstruct user.rmx
localhost.localdomain> quit
cyrus@lap3lux64:~>

Je nach Größe des Inhaltes der transferierten Dateien dauert das etwas - nach meinen Erfahrungen geht der "reconstruct"-Prozess aber auch bei größeren Mailverzeichnissen recht zügig vonstatten.

Schritt 9: LOGIN über PLAIN-Mechanismus zulassen und Test des Zugangs mit "imtest"

Uns fehlt noch ein wichtiger Eintrag, der sicherheitsrelevant ist und in der Datei "imapd.conf" vorgenommen werden muss. Da wir uns nur lokal einloggen wollen, ist keine SSL-Struktur mit Zertifikaten erforderlich - wenn wir auf unserem Laptop den potentiellen Zugriff von außen per Firewall dicht machen.

Ein Plain-Login muss für den Cyrus-Server aber explizit zugelassen werden! Sie finden den notwendigen Eintrag

# Changed by cyrus for installation of intern backup server
allowplaintext:yes

bereits im obigen Dateil-Listing. Wir hatten ihn dort nur noch nicht angesprochen.

Wir starten nach der obigen Änderung den Imap-Server per

#   rccyrus restart

zur Sicherheit nochmal.

Schritt 10: LOGIN mit imtest testen

Wir können nun den ordnungsgemäßen Zugang zum IMAP-Server mit dem Befehl "imtest" testen.

lap3lux64:~ #   imtest -v -a rmx -u rmx -m login localhost
 
S: * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID AUTH=GSSAPI AUTH=LOGIN AUTH=PLAIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5
SASL-IR COMPRESS=DEFLATE] laplux.mydomain.de Cyrus IMAP v2.3.16 server ready
Please enter your password:
C: L01 LOGIN rmx {7}
S: + go ahead
C:
S: L01 OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID LOGINDISABLED COMPRESS=DEFLATE ACL RIGHTS=kxte QUOTA MAILBOX-
REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ
THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE SCAN IDLE X-NETSCAPE URLAUTH]
 
User logged in
Authenticated.
Security strength factor: 0

Als Passwort muss man hier natürlich das "RMX_PWD" angeben. Wenn alles OK ist, sollte dann die Meldung "authenticated" erscheinen. Weitere Optionen zum "imtest"-Kommando liefert die zugehörige "man page".

Schritt 11: IMAP-Zugang in Kmail konfigurieren und testen

Nach diesem positiven Zwischenergebnis ist alles bereitet, um sich unter Kmail oder einem anderen E-Mail-Programm einen neuen, zusätzlichen Account für den lokalen IMAP-Server einzurichten. Man verfährt hierbei genauso wie mit jedem anderen IMAP-Account.

Bei der Einrichtung gilt: Der anzugebende IMAP-Server ist "localhost", die User-Id ist "rmx", das zugehörige Password in unserem Fall dasjenige, das wir mit "RMX-PWD" bezeichnet hatten.

Danach taucht der lokale Server mit dem bislang einzigen Verzeichnis und dessen Mail-Inhalt auf.

Sind wir an einer Einsicht in andere Verzeichnisse aus unserem Backup interessiert, so legen wir über "cyradm" einfach entsprechende weitere Verzeichnisse an, kopieren die Inhalte aus dem Backup hinein und führen jeweils ein "reconstruct" für das neue Verzeichnis der entstehenden Hierarchie durch.

Viel Spass nun beim Lesen der IMAP-Mails aus einem Backup in der Fremde.

Kontact 4.7 und OX 6 unter Opensuse 11.4 – Teil II

Einleitung und Inhalte dieses 2-ten Beitrags zu einer OX 6 Testinstallation

Im ersten Teil dieses Beitrages zu einer OX6-Testinstallation haben wir eine OX6-Grundinstallation auf einem "Opensuse 11.4"-Server vorgenommen. Siehe auch:
http://linux-blog.anracom.com/2011/08/21/kontact-47-und-ox-6-unter-opensuse-114-teil-i/ .

Es stand noch aus, einen ersten OX-Kontext und zugehörige OX6-User anzulegen.

Letztere sollen unter der OX-eigenen Web-Oberfläche auf den externen IMAP-Server zugreifen können. Der IMAP-Server, mit dem der OX6-Server kooperieren soll, läuft in unserer Testkonfiguration auf einem separaten Server. Wir werden uns nachfolgend daher damit auseinander müssen, wie sich diese Trennung der Serversysteme auf die Einrichtung von OX6-Usern auswirkt.

In einem nachfolgenden dritten Blog-Beitrag wollen wir abschließend testen, ob und wie der Zugriff von Kontact auf den OX6-Server funktioniert.

Anlegen eines Default-Kontextes

Im ersten Teil sind wir bereits auf Kontexte eingegangen. Wir legen nun als "oxadminmaster" den sog. Default-Kontext an und kreieren dabei gleichzeitig den zugehörigen Default-Kontext-Administrator, dem wir hier willkürlich den Usernamen "oxadmin" geben. Das Ganze geschieht wieder durch ein Skript:

#   /opt/open-xchange/sbin/createcontext  −oxadminmaster  −P MY_OX_MASTER_ADMIN_PWD  −c 1  −u oxadmin  −d "Context Admin"  −g Admin  −s User  −p MY_OX_CONTEXT_ADMIN_PWD  −L defaultcontext  −e oxadmin@mydomain.de  −q 1024  −−access-combination-name=all

Ein paar Hinweise zu den Optionen (s. auch die Befehlsbeschreibung im OX6-Manual "OX6-Provisioning.pdf"):

  • Das "-c 1" definiert die Kontext-Id,
  • das "-u" die User-ID,
  • das "-d" den Displaynamen für den Kontext-Admin,
  • das "-g" den "Given Name" (Vorname),
  • das "-s" den Nachnamen,
  • das "-L" das sog. Login-Mapping (hier eben auf den Defaultkontext),
  • das "-e" die E-Mail-Adresse des Kontext-Admins,
  • das "-q" den kontext-weiten Quota-Betrag in MByte (!),
  • ein "-N" einen Kontext-Namen.

Ein Kontext kann auch einen Namen erhalten - hierzu ist der Parameter "-N" einzusetzen. Dieser Name kann z.B. beim Login-Mapping verwendet werden (s.u.).

Als Email-Adresse sind wir von einem IMAP-Account "oxadmin@mydomain.de" ausgegangen, der über unseren IMAP-Server versorgt wird. Unser IMAP-Server ist dabei wie gesagt nicht identisch mit dem Server des OX6-Systems.

Obwohl die Kommandos für die spätere Anlage normaler OX6-Anwender ähnlich sind, ist die Anlage des "Kontext-Administrators" ein besonderer Akt, der initial die Berechtigung des OX6-Adminmasters erfordert.

Hinweis zu mehreren Kontexten und zum kontextspezifischen Login-Namen eines Users

Legt man später mehrere Kontexte an, so geschieht dies für den zweiten Kontext etwa über

#   /opt/open-xchange/sbin/createcontext  −A oxadminmaster  −P MY_OX_MASTER_ADMIN_PWD  −c 2  −u oxadmin  −d "Context Admin"  −g Admin  −s User  −p MY_OX_CONTEXT_ADMIN_PWD  −e oxadmin@mydomain.de  −q 1024  −−access-combination-name=all

Man beachte 2 Dinge:

  • Für das Anlegen des Kontextes und gleichzeitig des Kontext Admin ist die Autorisierung als "oxadminmaster" erforderlich. Die weitere Gestaltung des jeweiligen Kontextes und auch die Pflege der zugehörigen User obliegt danach aber dem jeweiligen Kontext-Admin!
  • Jeder User-Account ist kontextspezifisch. Auch der "oxadmin"-User für den Kontext 2 ist keineswegs identisch mit dem "oxadmin"-user für den Kontext 1 !
  • In der Praxis sollten die Kontext-Administratoren natürlich besser unterschiedliche Bezeichnungen bekommen.

Der Login in einen spezifischen Kontext durch Angabe der Kontextnummer nach dem Usernamen, also z.B. durch "oxadmin@1" für den Kontext mit der Nummer 1 oder "oxadmin@2" für den Kontext 2, falls - wie im obigen Beispiel - in jedem Kontext ein User "oxadmin" angelegt wurde. Möchte man statt mit Kontext-ID-Nummern lieber mit "Kontextnamen" operieren, so kann man ein entsprechendes "Login-Mapping" durch folgende "Kontextänderung" bewirken:

#   /opt/open-xchange/sbin/changecontext  −A oxadminmaster  −P MY_OX_MASTER_ADMIN_PWD  −c 2  −N verwaltung  −L 2,verwaltung

Dieser Befehl ordnet dem Kontext 2 den Namen "verwaltung" zu. Ein Login in diesen Kontext würde für den User "oxadmin" danach also auch mit der Eingabe der Userbezeichnung "oxadmin@verwaltung" in einer Login-Maske möglich sein.

Hinweis zu einem typischen Fehler aufgrund bestimmter anfänglich zu viel installierter OX6-Pakete

Bei mir schlug das Kommando zur Kontextanlage trotz Variationsversuchen zunächst zig-fach fehl, weil ich unvorsichtigerweise das Paket "open-xchange-admin-plugin-autocontextid" installiert hatte (s. hierzu auch die Warnung in Teil 1).

Ich wurde dann mit Fehlermeldungen der Art

Error: Unrecognized options on the command line: Unknown option ``-c'

oder

com.openexchange.admin.plugins.PluginException: com.openexchange.admin.rmi.exceptions.StorageException: Table 'configdb.sequence_context' doesn't exist

konfrontiert. Letzteres wenn ich testweise das "-c" weggelassen habe. Das Paket "open-xchange-admin-plugin-autocontextid" setzt nämlich Zusatztabellen voraus, die bei unserer Grundinstallation nicht implementiert wurden.

Siehe zu diesen Fehlern
https://forum.open-xchange.com/showthread.php?5935-Error-option-c-not-recognized-when-running-createcontext

Ich habe in meinem Fall dann eine Neuinstallation mit genau den Paketen durchgeführt, die in der Referenz-Installationsanleitung (s. Teil 1) aufgeführt sind. Danach lief das Kommando einwandfrei durch.

Unzureichende Default-Einträge für den IMAP-Mail-Account des Kontext-Administrators

An dieser Stelle lohnt sich nun ein Blick mit PhpMyAdmin in das lokale MySQL-RDBMS, Datenbank "oxdatabase_{ID}", Tabelle "user". Es zeigt sich, dass nun für den Kontext 1, der bislang auch unser Defaultkontext ist, ein Eintrag mit folgender Feldbelegung existiert:

  • cid = 1
  • id = 2
  • imapServer = imap://localhost:143
  • mail = oxadmin@anracona.de
  • smtpServer = smtp://localhost:25
  • etc.

Einen korrespondierenden Eintrag findet man in der Tabelle "user_mail_account". Man beachte dort auch das Feld "default-flag", das für diesen ersten Maileintrag zum User "oxadmin" auf "1" gesetzt ist. Für weitere Maileinträge, die man später über die Web-Oberfläche des OX6-Systems erzeugen kann, ist das nicht der Fall. Dort findet man dann eine "0".

Das obige Kommando für die Kontexterzeugung geht für den User "oxadmin" im jeweiligen Kontext also von der Existenz eines Default-Email-Accounts auf dem lokalen OX6-Server nach dem Muster "imap://localhost:143" aus.

Der würde in unserem Fall aber unglücklicherweise nicht funktionieren, da unser IMAP-System ja auf einem anderen Server vorausgesetzt wurde. Login-Versuche des eben angelegten Users "oxadmin" über die Web-Oberfläche des OX6 würden mit nachaltigen Fehlermeldungen und einer Abschaltung des E-Mail-Subsystems für diesen User quittiert werden. Also müssen wir die Angaben für den User ändern (s.u.).

Dabei gilt es zu beachten, dass dem Default-Email-Account eines OX6-Users eine besondere Bedeutung zukommt.

Behandlung des Default-Mail-Accounts für OX6-User auf einem separaten IMAP-Server

Durch etwas Lesen und Herumprobieren findet man folgenden, eigentlich logischen Punkt heraus:

Jeder User auf dem OX-Server erhält eine Default-Mail-Adresse zugeordnet. Die implizite Annahme ist dabei wohl die, dass dieser Default-Mailaccount ein fester Bestandteil der OX6-Einrichtung ist und auf dem gleichen Server wie das OX-System selbst eingerichtet sein sollte. Alle anderen IMAP-Accounts eines Users sind davon externe unabhängige Dinge. Aber der Anspruch einer OX6-Einrichtung ist der, dass das OX6-System jedem seiner User einen eigenen Mail-Account anbietet. Nun habe ich aber bereits einen separaten IMAP-Server im Netz. Und dort will ich natürlich auch die Default-Accounts des OX6-Systems betreiben!

Wichtig für das erfolgreiche Zusammenspiel des OX-Servers mit unserem separaten IMAP-Server im Netz ist nun, dass der User-Name z.B. des "oxadmin"-Users auf dem OX6-Server identisch mit dem Login-Namen des Useraccounts auf dem Linux-IMAP-Server ist - auf Betriebssystemebene wie auf IMAP-Ebene.

Auch das verwendete Passwort muss auf beiden Servern (zunächst) identisch sein ( - wiederum auf Betriebssystemebene wie auf IMAP-Ebene).

Das gilt nicht nur für den "oxadmin"-Account sondern auch für alle anderen OX6-User-Accounts, die problemfrei auf ihren jeweiligen Default-IMAP-Account zugreifen sollen. Man sollte also einen eigenen, im Netz vorhandenen IMAP-Server von vornherein als eine dem OX6-System fest zugeordnete Einheit begreifen.

Das halte ich nebenbei gesagt für einen kleinen Nachteil der OX 6 Grund-Installation. Denn dies setzt vorab eine aufgeräumte Netzwerkumgebung mit "Single Sign On"-Charakteristik voraus. Was ja keineswegs verkehrt ist, aber dennoch nicht überall gegeben ist. Das Dumme ist dann, dass der OX6-Anwender bei Problemen mit der Default-Mail-Account-Einrichtung spürbare Schwierigkeiten beim Öffnen seiner OX6-Weboberfläche bekommt. Er erhält dann regelmäßig Fehlermeldungen, die das Abschalten des Email-Moduls der Groupware-Oberfläche ankündigen. Und dann ist man als Admin gefordert.

Ich habe übrigens nicht explizit geprüft, ob die Linux UID-Nummern auf den unterschiedlichen Servern auch identisch sein müssen; ich gleiche die aus anderen Gründen aber sowieso immer ab. Hier hilft natürlich ein zentrales LDAP-System als universales Backend enorm, aber dessen Einrichtung würde hier wirklich zu weit führen.

Nebenbei:
Man kann durch Eingriffe jenseits der verfügbaren OX6-Verwaltungskommandos auch unterschiedliche Passwörter auf dem IMAP-Server und dem OX6-System verwenden. Dazu muss man das abweichende IMAP-Passwort direkt in die Tabelle "user_mail_account" eintragen. Natürlich ist das Passwort verschlüsselt - also ist die spezifische Hash-Methode Crypt in der Tabelle "user_mail_account" zu beachten! (In der Tabelle "users" wird für das OX6-Passwort dagegen SHA1 als Hashverfahren verwendet). Da mir dabei das von OX6 verwendete Salt zur Crypt-Hash-Generierung nicht bekannt ist, behelfe ich mir hier regelmäßig, indem ich gezielt Dummy-User mit dem von mir gewünschten Mail-Passwort anlege, den erzeugten Hash dann in den zu ändernden User-Record kopiere und danach den Dummy-User mit "deleteuser" wieder entferne.

Weitere IMAP-Accounts jenseits des Default-Accounts?

Nach diesen Hinweisen zum Default-Mail-Account eines OX6-Users stellt sich die Frage, wie es um weitere IMAP- oder POP-Accounts bestellt ist und ob man die in der OX6-Web-Oberfläche auch nutzen und die zugehörigen Mailordner einsehen kann.

Ja, das geht natürlich! Jeder User kann später auf beliebige weitere IMAP- oder POP-Accounts auf externen Mail-Servern zugreifen - selbst dann, wenn es mit dem Default-Account des OX6-Systems Probleme geben sollte. Für das Anlegen von Mail-Accounts gibt es in der OX6-Web-Oberfläche einen entsprechenden Menüpunkt unter

"Einstellungen >> E-Mail >> Accounts".

Nur seinen Default-Account kann der User dort weder löschen noch in seinen Grunddaten ändern. Dies kann nur der Kontext Administrator. Das unterstreicht die besondere Rolle des Default-Mail-Accounts als Teil der OX6-Services.

Beim Anlegen weiterer Accounts kann man die auf dem jeweiligen IMAP-Server gültigen Login-Daten anstandslos verwenden - und die müssen dann natürlich auch nicht identisch mit den Account-Daten auf dem OX-Server sein. Die zusätzlichen Mail-Accounts werden nahtlos in die Struktur der Web-Oberfläche integriert; man kann auf die entsprechenden Mail-Ordner-Inhalte zugreifen sowie eigene Mails mit spezifischen SMTP-Einstellungen versenden. Siehe hierzu auch die Abbildungen weiter unten.

Anpassen der Einträge auf dem OX6-Server für einen Default-Email-Account auf einem separaten IMAP-Server

Nehmen wir an, der von uns betriebene IMAP-Server habe die IP-Adresse "192.168.0.10". Gehen wir weiter davon aus, dass es auf dem IMAP-Server 192.168.0.10 in unserem Netz einen Account und Postfach für den User "oxadmin" gibt. Dieser soll per E-Mail unter der Adresse "oxadmin@mydomain.de" erreichbar sei. Dann können wir unseren OX6 "oxadmin"-Account für den Kontext 1 wie folgt abändern, damit er mit diesem Postfach verbunden wird:

#   /opt/open-xchange/sbin/changeuser  −A oxadmin  −P MY_OX_CONTEXT_ADMIN_PWD  −u oxadmin  −e oxadmin@mydomain.de  −−imaplogin oxadmin  −−imapserver 192.168.0.10  −−smtpserver 192.168.0.10

Man beachte, dass wir uns hier bzgl. der Authorisierung auf den "Kontext Administrator" und nicht auf den OX6-Admin-Master "oxadminmaster" beziehen !!! Innerhalb eines Kontextes ist es - wie gesagt - der Kontext Administrator, der die Useraccounts ändert - auch seinen eigenen! Wir überprüfen das Ergebnis der Maildatenänderung wieder durch einen Blick in die Datenbank.

Hinweis: Der Zugriff auf den Default-Email-Account per OX6-GUI muss für Kontext Administratoren explizit freigeben werden !

Theoretisch könnten wir uns als User "oxadmin" nun über einen Browser bereits auf unserem OX6-Server einloggen. Das würde aber immer noch zu Fehlermeldungen führen, denn aus Sicherheitsgründen ist der Zugriff der Kontextadministratoren auf ihre IMAP-Default-Postfächer per OX6-Browser-Oberfläche defaultmäßig abgeschaltet. Diesen Umstand kann man aber durch Änderung eines Eintrags in den Konfigurationsdateien unter "/opt/open-xchange" ändern:

In der Datei "/opt/open-xchange/etc/groupware/mail.properties" muss man dazu den Wert des Parameters "com.openexchange.mail.adminMailLoginEnabled=true" auf true statt false setzen.

Man sollte das Flag in der Konfigurationsdatei wirklich kennen. Sonst wundert man sich - wie ich - evtl. stundenlang, warum die E-Mail-Anzeige in der OX6-Oberfläche für alle normalen User auf Anhieb funktioniert, nur nicht für den Kontext-Administrator - und das obwohl man über Kmail auf den E-Mail-Account des Kontextadmin ebenfalls problemlos zugreifen kann. Noch verwirrender wird die Angelegenheit, wenn man für den "oxadmin" über den Default-Mailaccount hinaus testweise weitere IMAP-Mailaccounts anlegt und sich mit denen auch sofort verbinden kann! Die Ursache für evtl. Probleme mit dem Default-Mail-Account des Kontext-Administrators liegt nur in besagtem Konfigurations-Flag!

Nebenbei:

Als Admin (root) des OX 6 Servers wird man sich neben dem Zugang zu seinem ureigenen Mail-Account ggf. auch einen Zugang zu dem "oxadmin"-IMAP-Account z.B. unter Kontact/Kmail/Akonadi anlegen, falls man die Groupware-Verwaltung nicht deligieren kann. Hierbei sollte man wie immer natürlich wegen des serverseitigen Abonnements von weiteren Ordnern als den Account-Standardordnern des IMAP-Servers aufpassen. Man will ja als Admin nicht alle möglichen Ordner des IMAP-Servers doppelt und dreifach synchronisiert bekommen.

Anlegen eines ersten normalen Users im Kontext 1

Wir legen nun einen ersten "normalen" User im Kontext 1 an. Dieser User muss natürlich bereits einen passenden E-Mail-Account auf dem IMAP-Server besitzen - mit auf beiden Servern gleicher UID und Passwort. Das Passwort heiße USER_PWD. Auf meinem Cyrus-Server sind die IMAP-User-Namen identisch mit den Linux-User-Namen - unser erster User habe den Login-Namen "rlu" (Ralf Lustig). Sein Mailaccount sei "rlu@mydomain.de".

#   /opt/open-xchange/sbin/createuser c 1  −A oxadmin  −P MY_OX_CONTEXT_ADMIN_PWD  −u rlu  −d "RLU"  −g Ralf  −s Lustig  −p USER_PWD  −e rlu@mydomain.de  −−imaplogin rlu  −−imapserver 192.168.0.10  −−smtpserver 192.168.0.10

Änderungen an diesen Daten führt man im nachinein wieder mit Hilfe des Scripts "changeuser" durch, wie wir das bereits weiter oben für den "oxadmin" vorgeführt haben. Will man dem User z.B. den Zugriff auf das Adressbuch des OX6-Systems gestatten ( in dem die User des OX6-Systems aufgeführt sind), so erreicht man dies durch :

#   /opt/open-xchange/sbin/changeuser  −c 1  −A oxadmin  −P MY_OX_CONTEXT_ADMIN_PWD  −u rlu  −−access-global-address-book-disabled true

Spätestens jetzt sollte man sich als Admin für weitere Optionen und Einstellungen mit dem Dokument OX6-Manual "OX6-Provisioning.pdf"
http://linux-blog.anracom.com/category/open-xchange/ox6/(http://software.open-xchange.com/OX6/doc/OX6-Provisioning.pdf]
vertraut machen.

Login in die Web-Oberfläche des OX6-Servers

Hat man den OX6-Server wie im ersten Teil dieser Serie beschrieben angelegt, so wäre er jetzt im eigenen Netz unter der Adresse "http://oxs3" erreichbar. Wir probieren dies zum Abschluss unserer Anstrenugungen nun abschließend für den User "oxadmin" aus.

OX6 Login-Maske

Danach erhalten wir - wenn wir alles richtig gemacht haben - die aufgeräumte Web-Anwender-Oberfläche für das OX6-System:

OX6 Benutzer Oberflaeche

Man erkennt hier - etwas mühsam - dass neben dem geöffneten Default-Email-Account noch ein zweiter IMAP-Account auf einem IMAP-Server "oxs2" eingerichtet worden ist. Man kann einen solchen Account einrichten, indem man auf das Zahnradsysmbol in der Icon-Leiste oben links klickt. Man erreicht dann das Menü "Einstellungen" und seine Unterpunkte. Hiermit sollte man sich auch als Admin vertraut machen.

ox6 Menue Einstellungen

Die Einstellung eines zusätzlichen Email-Accounts erfolgt dann über den Menüpunkt "Einstellungen >> E-Mail >> Accounts":

Ox6 zusaetzlicher Mail Account

Nach diesem ersten Erfolg wünsche ich viel Spass beim Einrichten weiterer User und beim Vertrautmachen mit den Möglichkeiten der OX6 GUI! Man lese hierzu auch das User-Manual

http://software.open-xchange.com/OX6/doc/OX6-User-Guide-German.pdf

Im nächsten Beitrag zum OX6 sehen wir uns dann den Zugriff auf den OX6-Server von KDE Kontact aus an.