https://bugzilla.novell.com/show_bug.cgi?id=686477

Problembeschreibung

Deaktiviert man nach einer Installation von Opensuse 11.4/12.1 im Zuge der Netzwerkeinrichtung mittels Yast IPV6, so funktioniert danach von einem Remote-PC aus zwar noch der ssh-Login und das Arbeiten im ASCII-Terminal auf dem Opensuse 11.4/12.1-System. Das Starten von X- oder KDE-Applikationen wird aber verweigert.

Bei KDE-Applikationen taucht die Warnung auf, dass kein Zugang zum X-Server möglich sei. Dies obwohl man ggf. auf dem Zielsystem mit “xhost + RemotePCAdresse” den Zugriff explizit zugelassen oder aber entsprechende Auth-Mechanismen und Schlüssel korrekt eingerichtet hat.

Bei Standard-X-Applikationen wie “xterm” erhält man eine Nachricht, dass die Umgebungsvariable DISPLAY nicht gesetzt sei. Ein “echo $DISPLAY” zeigt, dass dies auch stimmt. Eigentlich sollte hier ein “localhost:10.0″ als Wert auftauchen.

Problembehebung

Lösung 1: Aktiviert man IPV6 mittel YAST wieder und rebootet man, so läuft danach alles wieder wie man es erwartet.

Lösung 2: Bei diesem Ansatz geht man an die Wurzel des Problems. Diese Lösung ist allerdings nur dann sinnvoll, wenn man IPV6 wirklich nicht verwenden will. Der Grund des Problems liegt in der Konfiguration des SSH-Daemons “sshd”. Die entsprechende Konfigurationsdatei liegt unter

/etc/ssh/sshd_config

Hier gelten weitgehend die Defaulteinstellungen, die man (zumindest bei SuSE) auch in den kommentierten Zeilen der Datei findet. Von Interesse ist die Vorgabe

#AddressFamily any

Auf Basis dieser Einstellungen sucht der ssh-Daemon nach beiden Protokollen gleichzeitig. Obwohl bei deaktiviertem IPV6 nur IPV4 gefunden werden muss. Für reines IPV4 hilft nun statt “any” die Einstellung “inet”, also :

# changed by rmo - because of IPV6 - IPV4 bug (see https://bugzilla.novell.com/show_bug.cgi?id=686477)
AddressFamily inet

Konfigurationsdatei speichern, mittels Yast IPV6 deaktivieren, rebooten und testen. “ssh -X” funktioniert dann von einem Remote-PC aus wie erwartet - obwohl IPV6 auf dem Opensuse 11-4/12.1-Host deaktiviert ist. X-Anwendungen lassen sich nun starten.

Bleibt nur die Frage, wer sich darum kümmern wird, dass bei künftigen Releases das “any” in der sshd-Konfiguration alternativ als IPV6 oder IPV4 interpretiert wird.

Nachtrag 05.12.2012: Zusätzliches sshd-Problem unter Opensuse 12.1 - Fehlermeldung zu DSA-Keys

Bei Upgrades zu und bei einer Neuinstallation von Opensuse 12.1 bin ich darüber gestolpert, dass das Starten des “sshd”-Dämons mit der Meldung:

Generating /etc/ssh/ssh-host-dsa-key
DSA keys must be 1024 bits
Startig SSH daemon
Could not load host key:
/etc/ssh/ssh-host-dsa-key

quittiert wird. Die letzte Meldung ist korrekt: der Key wird zumindest nicht am erwarteten Bestimmungsort erzeugt. Ohne die genaue Fehlerursache in den entsprechenden Skripts analysiert zu haben, möchte ich darauf hinweisen, dass man das Problem über einen mutigen händischen Versuch zur Schlüsselgenerierung

ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key

umgehen kann.

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.

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.

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

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.

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

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.

Meine Antwort:

Ja, schon - wenn man denn viel Zeit zum Testen und Spass am Basteln hat - und man immer eine Rückversicherung in Form älterer KDE-Versionen auf anderen Linuxinstallationen im Arbeitsumfeld vorrätig hält.

Ich möchte in diesem Beitrag auf ein aktuelles Beispiel eingehen - nämlich Veränderungen an KJots. An diesem Beispiel kann man, glaube ich, sehr deutlich festmachen, wo die Probleme liegen.

Zuvor aber ein kleiner Exkurs zu einer der wichtigsten Voraussetzungen für einen professionell einsetzbaren Desktop:

Exkurs: Stabilität der Desktop-Umgebung und ihrer Standard-Anwendungen - gibt es das unter einem sich rasend schnell entwickelnden KDE?

Die obige Antwort deutet das Nein fast schon an. Dann wäre der professionelle Einsatz eines KDE4-Desktops aber wirklich ein Problem. Denn in einer professionellen Arbeitsumgebung gibt es wenig oder gar keine Zeit für Basteleien.

Nun könnte man sagen, dass sich Fehler und zugehörige Basteleien durch eine konservative Upgrade-Politik für den Desktop vermeiden ließen. Damit ist gemeint, dass man halt nur Releases einführt, die man als durch und durch stabil verifiziert hat.

Aus meiner Erfahrung muss ich aber leider sagen: Das kann man bei der enormen Frequenz an Änderungen und der Vielfalt an Applikationen als Administrator nicht wirklich durchhalten. Soviel testen und zurechtbiegen kann man gar nicht - das ist bei dem Umfang und der Vielzahl allein an KDE-Applikationen und der Wechselwirkung mit vielen anderen Open Source Applikationen (Browser, Office-Pakete, etc.) viel zu zeit- und personalaufwändig. Zudem gleicht das Fehlerverhalten unter KDE eher einer Hydra - man muss zum Beleg dieser These nur mal regelmäßig in die KDE-Bugliste reinschauen. Interessant wäre in diesem Zusammenhang eine Statistik von Regressionsfehlern …

Fehler gibt es in der IT immer wieder. An was mache ich die Frage nach dem professionellen Einsatz also fest?

Letztlich an vielen Beispielen, bei denen “Verbesserungen” der Desktopbasis oder aber bestimmter Applikationen immer wieder zu Defiziten im Vergleich zum bisherigen Leistungsumfang des KDE-Desktops oder bestimmter Applikationen führten.

Es geht also eigentlich nicht um “Fehler” sondern um immer wieder auftretende Probleme in Bezug auf die Funktionalität des Desktops oder seiner Applikationen. Solche Probleme können ja auch durch andere Faktoren als durch echte Programm-Fehler induziert sein - z.B. technischen Innovationsdrang, der zum Einsatz neuer zentraler Komponenten führt, die langfristig echte Vorteile versprechen, aber kurzfristig ganze Applikationen an den Rand der Unbrauchbarkeit führen können, weil die Anpassung zu komplex ist. Als Beispiel verweise ich auf die Akonadi-Einführung als zentrales Element der KDE-Umgebung ….

Leider und oft genug bedeuten “Modernisierungen” deshalb für den Anwender plötzlich (mit einem Releasewechsel) auftretende Einschränkungen der Funktionalität und damit der täglichen Arbeit. In einer professionellen Arbeitsumgebung muss man sich jedoch auf die Stabilität seiner Tools verlassen können.

Liebe KDE-Entwickler und/oder Distributoren:

Stabilität bedeutet wesentlich mehr als keine Fehler im Code-Ablauf. Stabilität bedeutet u.a. auch, dass ich mich als Anwender in der täglichen Arbeit auf ein Basis-Set an Applikationen und deren Funktionalitäten verlassen können muss. Das schließt Innovation und Modernisierung nicht aus. Aber es schließt u.a. aus, dass wichtige Funktionalitäten plötzlich ersatzlos verschwinden. Sprich:

Führe substanziell geänderte Applikationen erst dann in ein Release ein, wenn neben der Fehlerfreiheit auch der alte Funktionsumfang der Applikationen sichergestellt ist oder es einen adäquaten Ersatz gibt.

Nun ist aber eine wiederkehrende Standardsituation bei KDE-Updates folgende:

Release 4.x.y weist endlich einen Fortschritt oder eine Fehlerbehebung in der Applikation A auf, auf die man schon lange gewartet hat. Mit dem gleichen Release wurden aber andere Applikationen B oder der Desktop selbst so stark modifiziert, dass sich die angeblichen “Verbesserungen oder Modernisierungen” dort zunächst eher als substanzielle “Verschlechterungen” erweisen.

Ein kleines Beispiel aus der jüngeren Vergangenheit von Kmail:

Ab einem bestimmten Qt-Upgrade war es über 1,5 Jahre hinweg nicht mehr möglich, unter aktuellen Kmail-Versionen ein “Drag und Drop” von Mails in Richtung Folderhierarchie so durchzuführen, dass sich die Sub-Folderhierarchie beim Überfahren eines Mailordners mit der Maus automatisch öffnete. Alle Umwege, die man als User nutzen konnte, waren unpraktisch und kosteten in der täglichen Arbeit erheblich Zeit. Dabei ging das alles schon mal ganz wunderbar unter KDE 3.x und den ersten KDE 4-Versionen. Unter KDE 4.7 ist dieses Problem dann endlich behoben worden.

Nun lässt sich dafür aber die Reihenfolge von Mailordnern in der Folderhierarchie nicht mehr einstellen. Man hat also in einem Release endlich eine funktionale Einschränkung beseitigt - aber über die Hintertür an anderer Stelle eine neue Funktionalitätseinschränkung eingeführt. Das neu Problem wird nun möglicherweise zur Version KDE 4.7.4 behoben. Frage: Was geht dann nicht mehr ? Und das war nur die Situation innerhalb einer Applikation.

Noch viel öfter tritt der Fall der Verbesserung an einer Stelle und der gleichzeitigen Verschlimmbesserung oder gar Funktionalitätsverlust an einer anderen Stelle auf, wenn man sich KDE applikationsübergreifend von Release zu Release ansieht.

Was sollst du als Admin mit dieser Situation vernünftig umgehen? Eine Umfrage unter den Usern durchführen, ob sie lieber den Teufel in Applikation A oder Beelzebub in Applikation B wollen? Oder eben unter erheblichem Testaufwand auf den eher immer unwahrscheinlicheren Zustand warten, dass mal alle wichtigen Applikationen des Desktops gleichzeitig hinreichend gut funktionieren? Oder sich gleich eine eigene Desktopdistribution zusammencompilieren?

Man versucht halt sein Bestes - bastelt, so gut es geht - und schließt auch als User manchmal erhebliche Kompromisse.

Eine Schlussfolgerung wäre :

Die Planung für KDE-Änderungen oder KDE-Applikationsänderungen muss viel stärker user- und funktions-orientiert erfolgen als bisher und nicht allein technik-orientiert. Und: Es muss eine Qualitätssicherungsinstanz eingeführt (und bezahlt) werden, die die Autorität hat, manche Verschlimmbesserung aus Releases trotz allem berechtigten Innovationsdruck der Entwickler schlicht und einfach fern zu halten.

Aber wem soll man das in einer “Community”, in der der Spaß am Experimentieren und der Innovation der stärkste Motivationsfaktor ist, als Aufgabe mit auf den Weg geben? Müssen die Distributoren hier besser werden? Bei der Effizienzoptimierung, die auch dort unter Kostendruck betrieben wird?

Ich weiss es nicht - am besten wäre aus meiner Sicht eine von der Community selbst organisierte und anwender- und nicht entwickler-dominierte Qualitätssicherung und Release-Politik. Wahrscheinlich gibt es so was schon - ich kenne mich da ehrlich gesagt viel zu wenig aus ….. ich kann nur sagen, es funktioniert irgendwie nicht hinreichend …. man muss in diesem Bereich vielleicht ein paar Aspekte von Open Source neu überdenken - besser die Offenheit und den bisherigen Innovations- und Qualitätsicherungsprozess neu überdenken und um ein paar Komponenten ergänzen.

Die Distributoren haben ja versucht, eine Qualitätsverbesserung über die kostenpflichtigen “Enterprise Desktops” zu erreichen. Ich hatte eine solche Desktopversion mal ein Jahr von Suse - es bringt ehrlich gesagt nicht viel.

Und es erscheint mir eher eine grundsätzliche Frage zu sein:

Soll oder muss die “Qualität” für den professionellen Einsatz eines Open Source Desktops erst durch kostenpflichtige und z.T. intransparente Leistungen von Distributoren gewährleistet werden? Ist das nicht vielleicht die falsche Stelle in der “Produktionskette”? Das würde ja letztlich eine Drei-Klassen-Gesellschaft” an Anwendern bedeuten:

• die Kaste an superfitten Freaks, die sich in jeder Situation selbst zu helfen wissen.
• Otto-Normal-Anwender, der gerne von Microsoft, Apple, etc. unabhängig werden möchte, dabei aber leider zum laufenden Beta-Tester mutiert, wenn er denn nicht irgendwann entnervt aufgibt?
• Den Besserverdienenden oder Unternehmen, die sich die Gebühren für einen Enterprise-Desktop leisten können?

Irgendwie kann es das doch nicht sein!

Was gar nicht geht - das aktuelle Beispiel KJots

Ich habe mich vor ca. einem halben Jahr mal intensiv nach einem Tool umgesehen, mit dem ich schnell und einfach Notizen und Einfälle strukturiert und formatiert festhalten und sie danach in “Büchern” und “Kapiteln” organisieren konnte. Zudem wollte ich die Möglichkeit für einen Backup sowie einen Export in XHTML-Dateien haben.

Nach einigen Tests von etwa 5 Open Source Produkten bin ich bei KJots hängen geblieben. U.a. auch wegen der Integration in Kontact. Besonders gefallen haben mir aber die Möglichkeiten zur Strukturierung in Büchern, die Formatierungsmöglichkeiten und die Exportmöglichkeiten.

Also habe ich angefangen, das Tool in einer kreativen Phase im Juni und Juli dieses Jahres wirklich intensiv zu nutzen. Damals lief bei mir irgendeine KDE 4.5.x-Version. Vorgestern - also nur 3 Monate später - und mit einem KDE 4.7.2 ausgestattet, wollte ich mich mit den Ergebnissen meiner früheren Arbeit, die ich in Form von “*.book”-Dateien abgelegt und gesichert hatte, mal wieder befassen. Genauer gesagt: ich brauchte die alten Kjots-Dateien dringend als Ausgangspunt für eine Auftragsarbeit.

Man muss dazu sagen, dass ich mir wegen vieler Änderungen auf dem Weg von KDE 4.6 zu KDE 4.7 und der schon gewohnten Probleme mit Akonadi-Ressourcen und Kontakt etliche Teil des Desktops neu aufgebaut hatte. Dabei ging auch die frühere Verzeichnissstruktur (der KDE 4.5-Installation) für KJots unter .kde4 bzw. unter anderen Dateien des Desktops den Weg alles Irdischen.

Na und, denkt der Leser sicher - was solls - daür hattest du ja deine Kjots Dateien ordentlich exportiert und gesichert - importier sie halt einfach. Tja, dachte ich auch … .

Nur hat sich halt inzwischen KJots bzgl. der Datenhaltung und -organisation - vielleicht auch aus sehr guten Gründen - neu aufgestellt. Dummerweise haben die Entwickler dabei offenbar nicht die Zeit gefunden, eine geeignete Importfunktionalität für die alten Kjots-Export-Formate bereitzustellen - nicht einmal für das frühere “native” “.book”-Format.

Nein, nicht nur das - im aktuellen Kjots gibt es gleich gar keine Import-Funktionalität mehr! Siehe

https://bugs.kde.org/show_bug.cgi?id=277378

http://forum.kde.org/viewtopic.php?f=22&t=97304
http://forum.kde.org/viewtopic.php?f=20&t=95898
http://chakra-project.org/bbs/viewtopic.php?pid=37139
http://forums.gentoo.org/viewtopic-t-880151-start-0-postdays-0-postorder-asc-highlight-.html?sid=6e53049575aa553e582f6a2f24bcdd86

und weitere mehr ….

Nun waren die Ergebnisse meiner früheren Arbeit aber wirklich wichtig und Geld wert, und ich brauchte sie dringend. Der erste Ansatz zu einer Problemlösung führte ins Internet - aber dort fand ich im Laufe einer Stunde auch nur arme, ebenfalls ratlose Betroffene und leider keine für mich brauchbare Lösung - zumindest nicht innerhalb eines Zeitraums von einer weiteren Stunde. Dann habe ich - wenig optimistisch - versucht herauszufinden, ob sich nicht eine ältere Version von Kjots installieren lassen würde. Nein ging nicht, die Änderungen an den KDE-Basisbibliotheken auf dem Weg zu KDE 4.7.2 waren einfach zu massiv. Unter Zeitdruck und bei hinreichendem Wert der alten Kjots-Dateien bleibt als nächste Option für einen normalen Benutzer nun nur der Weg zurück zu einer alten KDE-Version.

Ich konnte glücklicherweise einen anderen Ausweg wählen:

Ich kenne den Entwicklungsverlauf und die Fallen von KDE nun schon so viele Jahre, dass ich weiss, wie gut man daran tut, immer auch ein KDE zur Verfügung zu haben, das mindestens ein halbes Jahr alt ist - entweder auf einem anderen PC/Laptop oder aber - wie bei uns - auf einer virtuellen Maschine. Die konnte ich hochfahren - und dort temporär unter KDE 4.5 im VMware-Fenster eines viel “moderneren” KDE 4.7 dann endlich meine alten Kjots-Dateien laden und bearbeiten, die ich vor gerade mal einem Vierteljahr erzeugt hatte - mit einem von mir selbst “evaluierten” KDE-Produkt.

Wie ich den bearbeiteten Stand meiner Kjots-Bücher jetzt in die KDE 4.7-Welt bringe, ist dabei nach wie vor unklar. Über eine anderes Produkt, das evtl. mit KJot-Dateien umgehen kann? Mit einem aktuellen “KBasket” klappte es jedenfalls nicht. Am einfachsten ist am Ende vielleicht wirklich der Export aller meiner Kjots-Bücher in eine umfassende HTML-Datei mit Hilfe der alten Kjots-Version, danach der Import nach Openoffice sowie das dortige zeitaufwändige Nachbearbeiten.

Und der künftige Verzicht auf Experimente bei wichtigen Dingen eines professionellen Umfeldes mit illustren KDE-Applikationen, auch wenn sie einen zunächst mit einem brauchbaren Funktionsumfang verführen mögen ??!

Professionelles Arbeiten?

Offenbar setzt das bei KDE eine Rückversicherung in Form virtueller oder physikalischer Maschinen mit älteren KDE-Versionen voraus, bei denen irgendein Tool oder eine Applikation noch den gewünschten Funktionsumfang hat.

Das alles für den offenbar wahrscheinlichen Fall, dass dieser für das Arbeiten notwendige Funktionsumfang in späteren KDE-Versionen mal wieder nebenbei der heiligen “Innovation” oder aber irgendeiner Verschlimmbesserung geopfert wird …. und man trotzdem upgraden muss, weil das Upgrade an anderer Ecke wirklich Verbesserungen bringt ….

Liebe KDE-Entwickler: Bei allem Respekt, den ihr wirklich verdient - das kann es einfach nicht sein! Das geht so nicht! Das ist zumindest Otto-Normalverbraucher nicht zumutbar.

• Sie brechen nach Wochen halbwegs angenehmen Arbeitens plötzlich aufgrund eines harmlos erscheinenden Updates einer Applikations-Sub-Version über einen herein und machen eine Schlüsselapplikation zumindest teilweise unbrauchbar.
• Sie sind spezifisch für eine Linux-Desktop-Variante (hier KDE 4.7.x) und treten unter einer anderen (KDE 4.6, Gnome) nicht auf.
• Die Entwickler und Distributoren haben die verschlimmbesserten Anwendungs-Programme offenbar nicht unter der betroffenen aktuellen Desktop-Versionen getestet.

In diese Kategorie fallen z.B. zwei aktuelle Fehler bzgl. der Integration von Libreoffice 3.4.x und KDE 4.7.x - zumindest unter Opensuse 11.4, wohl aber auch unter anderen Distributionen.

Libreoffice ist GTK-basiert. GTK-Applikationen laufen unter KDE vom Erscheinungsbild her leider nicht immer ganz optimal. Aber im vorliegenden Fall half kein Rumdoktern an Einstellungen oder der Austausch von Bibliotheken für die GTK-QT-Integration; es liegt wohl eher ein Bug vor.

Man betrachte folgendes Bild:

Man erkennt einerseits eine viel zu große ungeglättete Schriftart, die zur Beschriftung der Lineale herangezogen wird. Andererseits - und das ist schlimmer - liegt ein Teil der Dokumentdarstellung über dem horizontalen Scrollbar, der dadurch letztlich unbrauchbar wird.

Bzgl. der Linealbeschriftung gilt, dass offenbar nicht die KDE-Schriften gezogen werden, obwohl in der entsprechenden LibreOffice-Optionen-Seite

“Extras > Optionen > LibreOffice > Ansicht”

der Punkt

“Systemschriftart für die Benutzeroberfläche wählen”

aktiviert ist. Statt dessen wird auf eine Schrift zurückgegriffen, die auf dem Linuxdesktop nicht unterstützt ist. Zumindest auf meinem nicht - und da sind wirklich viele Schriften installiert …

Beim horizontalen Scrollbar klappt möglicherweise die Integration der gewählten GTK-Styles unter KDE 4.7 in Libreoffice nicht, obwohl ein ansprechender Style unter KDE4’s “Systemeinstellungen > GTK-Stile und Schriftarten” ausgewählt wurde - und bei anderen GTK-basierten Anwendungen auch gezogen wird. Oder es liegt halt ein anderer handfester Bug vor.

Ein Test unter Gnome und KDE 4.6 zeigt im Gegensatz zu KDE 4.7 interessanterweise eine einwandfreie Darstellung der Libreoffice-Oberfläche.

Workaround

Als Sündenbock entpuppt sich nach ein wenig Rumspielen schließlich das RPM-Paket “libreoffice-kde4″. Ein Workaround besteht entsprechend darin, dieses Paket durch “libreoffice-gnome” zu ersetzen und die Einstellungen für die Gnome-Oberfläche zu erzwingen, obwohl man unter KDE4 arbeitet.

Dies geschieht dadurch, dass man in die Datei “/usr/bin/soffice” folgende Zeile einfügt:

export OOO_FORCE_DESKTOP=gnome soffice

Danach kann man mit Libreoffice 4.4.x unter KDE 4.7.x wieder arbeiten. Sogar die KDE-Schriftarten werden für die Menüs gezogen, wenn man einen kompletten Neustart der KDE-Oberfläche vornimmt.

Dieser Umweg ist nicht auf meinem Mist gewachsen - gefunden habe ich den Vorschlag nach einer etwas mühsamen Suche im Internet unter

https://bbs.archlinux.org/viewtopic.php?pid=971669

Ich dachte, ich verweise an dieser Stelle mal auf diesen Workaround, denn in vielen Internet-Beiträgen zum Scrollbar-Problem gehen die verzweifelten Anwender entweder auf eine ältere Libreoffice Version oder gar auf eine ältere KDE-Version zurück. Das ist unnötig. Aber die Verzweiflung der Anwender verstehe ich gut, denn es handelt sich bei KDE 4.7 und Libreoffice 3.4 ja um fundamentale Bausteine eines Opensource-Desktops, die man zum produktiven Arbeiten benötigt.

Mangelnde Qualitätssicherung ?

Es bleibt wieder der ungute Eindruck, dass es vor der Veröffentlichung mancher “verbesserter”, neuer Versionen von Opensource-Programmen an der Qualitätssicherung hapert. Im aktuellen Fall haben sich die Entwickler wohl mehr um Gnome, ältere KDE-Versionen oder gar Windows als Zielplattform gekümmert. Einen Test für ein aktuelles KDE 4.7 kann wohl kaum jemand durchgeführt haben, denn sonst gäbe es nicht so viele Beiträge zu dem Scrollbar-Problem im Netz.

Was wieder mal meine Überzeugung verstärkt, dass der Opensource-Desktop unter Linux auf Dauer nicht zum Erfolg kommen wird, wenn bzgl. der Qualitätssicherung nicht ein deutlich höherer Standard erreicht wird. Das hier geschilderte Beispiel ließe sich ja um viele weitere Fälle aus der KDE-Geschichte ergänzen. Man denke nur an die Probleme bei der Einführung von Akonadi oder bestimmte Bugs in Kontact.

Ich meine, dass eine bessere Form der Qualitätssicherung wirklich notwendig ist, bevor laufend Verschlimmbesserungen von Opensoure-Programmen ihren Weg in die Repositories der Distributoren finden. Irgendwie scheint mir diesbezüglich ein wichtiges Glied zwischen der Entwicklungstätigkeit der Community und der Publikation der mit sehr hoher Frequenz entstehenden Opensource-Werke in den Repositories der Distributionen zu fehlen.

Hinzu kommt natürlich auch eine für meinen Geschmack zu hohe Frequenz, mit der regelmäßig an fundamentalen Bausteinen der Desktops selbst - speziell von KDE - gerüttelt wird. Der Desktop wird so möglicherweise zu einer unberechenbaren Größe für die Entwickler von Anwendungen. Das hatte ja zuletzt auch Miguel de Icaza zu Recht im Linux-Magazin kritisiert. Vielleicht ist der obige Fall ja auch ein Beleg für dieses Problem.

Ein Desktop lebt schließlich nicht allein von intrinsischer Innovation, sondern in gleichem Maße von den Applikationen, die darauf laufen müssen. Und deren Entwickler brauchen Zeit, um sich auf grundlegende Veränderungen der Desktop-Plattform einzustellen ….

Ein supermoderner Desktop ist nämlich wirklich wenig wert, wenn Applikationen, die vor einem halben Jahr veröffentlicht wurden, nicht mehr auf der neuen Desktopversion laufen.

Ergebnis: 1,5 Stunden ging erstmal gar gar nichts. Zwar werden die Shares in “smbtree” und “smbclient” angezeigt, aber ein Versuch, die Inhalte der Share-Verzeichnisse in “smbclient” aufzulisten, endete jedesmal mit

NT_STATUS_ACCESS_DENIED listing \*.

Ebenso schlug das Browsing in Dolphin oder von anderen Rechnern aus fehl.

Natürlich habe ich dann meine Konfiguration geprüft, Passwörter und Rechte gecheckt, meine Zugriffsdaten mehrfach über “smbpasswd” und “pdbedit” upgedated, die Fehlerfreiheit von smb.conf mit “testparm” gecheckt und Zeit in das Studium von Samba-logs investiert. Mein Problem war auch nicht das, dass “/etc/init.d/smb” oder “/etc/init.d/nmbd” nicht gelaufen wären, wie das lt. Internet bei anderen Opensuse 11.4-Usern schon vorgekommen sein muss. Siehe etwa:

http://www.hardwarecrash.de/index.php/faq/software/linux/opensuse/215-opensuse-114-nmbd-startet-nicht
http://forums.opensuse.org/english/get-technical-help-here/network-internet/456049-11-4-samba-wont-run.html
http://www.linux-club.de/viewtopic.php?f=6&t=112904
http://forums.opensuse.org/english/get-technical-help-here/network-internet/455677-mount-cifs-issue-opensuse-11-4-a-2.html

Mein Opensuse 11.4 ist zudem auf dem neuesten Stand. Ich war wirklich ratlos.

Dann habe ich meine SMB-Konfiguration auf einem anderen, nicht vollständig aktualisierten Opensuse 11.4-System nachgestellt. Dort lief die Sache anstandslos. Also mussten irgendwelche Paket-Updates bei mir etwas “verschlimmbessert” haben.

Über weitere Hinweise im Internet bin ich dann auf Apparmor als Ursache vieler Samba-Probleme unter Opensuse 11.4 gestoßen. Ich habe dann zunächst geprüft, ob Apparmor bei mir über das Kontrollpanel unter Yast deaktiviert war. Ja, das war es. Dennoch lag der Fehler im Apparmor-Bereich und zwar in irgendeiner perversen Weise, die man als Endverbraucher nicht mehr verstehen kann und will :

Es half nämlich auch nichts, SMB-bezogene Profile aus Apparmor per Yast zu löschen. Einzig und allein

• ein (zweifaches) Anwenden des “Assistenten zum Aktualisieren von Profilen” unter Yast im Bereich Apparmor
• und ein “Zulassen” bei den hochkommenden SMB-relatierten Profilfragen

brachte die Lösung.

Liebe Leute von Novell:

Solche Bugs sind so dermaßen kontraproduktiv und so dermaßen desillusionierend, das man nur noch müde abwinken kann. (Ich habe meiner Frau versprochen, mich über sowas nicht mehr aufzuregen.) So gewinnt man keine Freunde für Linux in Form der Opensuse Distribution und schon gar nicht für Apparmor. Es führt eher zu dem Reflex, dieses Tool gar nicht mehr zu installieren.

Es trägt übrigens wenig zu meiner Beruhigung bei, dass es unter Fedora mit SELinux mal ein ähnliches Problem gab. Siehe etwa die Diskussion und nachfolgenden Beiträge zu http://lists.samba.org/archive/samba/2007-April/130900.html

Ursache für diese Misere ist aus meiner Sicht mal wieder das aktuelle Kernproblem von Opensource: die mangelnde Qualitätssicherung. Man ist als User - und vor allem als Enduser - halt doch immer Beta-Tester. Nun halt mal in puncto Sicherheit. Na toll …..

Links:
http://www.linux-club.de/viewtopic.php?f=6&t=113044
http://forums.opensuse.org/deutsch-german/hilfe-und-helfen/installation-administration/458037-opensuse-11-4-samba-probleme-wegen-apparmor.html
http://web.archiveorange.com/archive/v/TDuKzixdvQtYbQQ6CLRH
http://www.linux-club.de/viewtopic.php?f=6&t=113221

KDE 4.7 ist da. Damit erfolgte auch im KDE Factory Repository von Opensuse der Umstieg auf das akonadi-abhängige Kmail 2 - jetzt unter der Bzeichnung Kmail 4.7. Das aktuelle Gespann “Kontact 4.7/Kmail 4.7/Akonadi” hat aber ein Manko:

Es bietet keine Konnektoren mehr zum OpenXchange Server der Version 5 an. Siehe KDE-Bug https://bugs.kde.org/show_bug.cgi?id=258711.

Natürlich funktioniert der Zugriff von Kontact/Kmail 4.7 auf einen externen IMAP-Server - aber der ist eben unabhängig von spezifischen OX-Diensten wie der Pflege von Kontakt- und Adressdaten, von Kalender-Daten oder aber von Dokumenten.

D.h., die neueste KDE PIM Suite lässt sich z.Z. nur mehr mit dem Open-Xchange Server in der Version 6 (OX 6) betreiben. Für mich ist somit der Tag gekommen, an dem ich ernsthaft den schon seit längerem geplanten Umstieg von OX 5 auf OX 6 vorbereiten muss.

Kennt man Open-Xchange 6 gar nicht, so ist ein vernünftiger erster Schritt sicher der, den OX 6 zunächst einmal auf einem Testsystem auszuprobieren. In einem fehlertoleranten Umfeld mit (sehr) wenigen Usern reicht die Open-Xchange Community Edition [OX CE] auf einem Server, den man sich z.B. mit Opensuse 11.4 konfiguriert hat, für eine Testphase vollkommen aus. Bei uns läuft der OX 6 in diesem Sinne gerade testweise auf einem virtuellen, Opensuse 11.4 basierten Server unter XEN. Eine Diskussion der Gründe, warum ich als Basis für den OX-Server nicht unseren SLES 11 nehmen werde, würde hier zu weit führen.

Nachfolgend beschreibe ich in drei Blog-Beiträgen eine einfache Testinstallation auf einem Opensuse 11.4-System. (Ob dieses dabei XEN-basiert ist, ist bzgl. der OX-Funktionalität irrelevant.) Bei der Beschreibung gehe ich kurz auch auf Fallstricke, die z.B. bzgl. der Anbindung eines externe IMAP-Servers auftreten, ein.

Vor allem will ich aber testen, ob der KDE/Kontact 4.7 Zugriff auf den OX 6 funktioniert.
Mein Testszenario sieht daher etwa wie folgt aus:

D.h., ich nutze einen bereits vorhanden Cyrus-IMAP-Server in unserem Netz. Ist ein solcher nicht vorhanden, kann man sein “OX 6″-Versuchssystem aber auch gegen einen externen IMAP-Server im Internet testen, bei dem man ggf. einen E-Mail-Account hat. Der Zugriff auf den OX6-Server soll über 2 Varianten möglich sein:

• Einerseits möchte ich per Browser auf das OX6-Web-Frontend zugreifen. Dabei soll mir das Frontend nicht nur die Verwaltung von Kalendereinträgen, Tasks, Ressourcen unterstützen, sondern auch die Mails auf dem IMAP-Server anzeigen.
• Andererseits wünsche ich mir natürlich den Zugriff auf Kalender-, Task- und Addressbuchfunktionalitäten des OX6 per KDE’s Kontact. Natürlich will ich per Kmail auch die Mails sehen - aber dass Kmail mit IMAP-Servern umgehen kann, ist bei unserem Test weniger von Belang, weil von Haus aus klar.

Zielsetzung Teil I / Ausblick auf Teil II

In diesem ersten Teil wollen wir auf einem Opensuse 11.4-Testsystem zunächst die Grundinstallation eines lokalen OX-Servers [ OX CE] ohne Installation eines IMAP-Servers durchführen. Letzteren setzen wir auf einem separaten Server im Netzwerk voraus. (Die Beschreibung einer Postfix/Imap-Installation würde hier zu weit führen. Erste grundsätzliche Hinweise zum Aufsetzen eines Postfix/Imap-Systems findet man hier “http://linux-blog.anracom.com/2009/01/29/kmail-kde-42-postfix-und-cyrus-imap-unter-ox/“).

Wir führen ferner keine Cluster-Installation mit Lastverteilung durch. Bis auf IMAP laufen alle erforderlichen Services lokal auf dem Testsystem ab.

Im zweiten Teil legen wir schließlich einen OX-Default-Kontext mit OX-Usern an und greifen über den OX6 auch auf den IMAP-Server zu. Testen werden wir das über die OX-eigene Web-Oberfläche für den Anwender. Danach - im dritten Beitrag - verbinden wir schließlich unsere Kontact/Kmail 4.7-Clients mit dem OX6- und dem IMAP-Server.

Zur Klarheit: Es geht um eine “OX CE”-Testinstallation, nicht um eine Produktivumgebung und nicht um die kommerziellen OX-Versionen. [ Open-Xchange rät vom Einsatz der nicht supporteten Community Edition in einem produktiven Umfeld ab, obwohl die CE im Kern keine funktionalen Einschränkungen aufweisen soll. Solche Einschränkungen gibt es aber bzgl. von Konnektoren und der Admin GUI. Die Community Edition kann nach meinem Verständnis auch nicht für das kommerzielle Hosting oder Verleihen von OX-Diensten eingesetzt werden. ]

Vorbemerkungen / Voraussetzungen der Installation / Referenzinstallationsanleitung für OX 6 unter Opensuse 11.4

Eine “Single Server”-Basisinstallation geht wesentlich schneller, als man das von früheren Experimenten mit dem SLOX oder OX5 unter SLES gewohnt sein mag. Im besonderen muss man sich nicht zwingend mit einer Anbindung an einen vorhandenen LDAP-Server. Eine Tomcat-Integration ist auch nicht erforderlich. OX6 ist hier schlanker als OX5.

Grundsätzlich sollte man für eine Testinstallation den entsprechenden Texten im OX Wiki [http://oxpedia.org/index.php?title=Main_Page_CE#quickinstall] folgen. Für Opensuse 11.4 und die OX Community Edition hält man sich an die Referenz-Installationsanleitung für Opensuse 11.0:

Referenzanleitung zur Installation: http://oxpedia.org/wiki/index.php?title=Open-Xchange_Installation_Guide_for_openSUSE_11.0

Sie führt mit ein wenig Geduld auch unter Opensuse 11.4 zum Erfolg. Der Text ist aus meiner Sicht knapp, aber ausreichend. Trotz der Komprimiertheit der Anweisungen umfasst der Text immerhin ca. 12 Seiten. Einiges davon sind aber Inhalte von Konfigurationsdateien. Man sollte sich durch den Umfang der Installationsanleitung also nicht abschrecken lassen.

Eine deutsche Übersetzung findet man hier:
http://www.pcwelt.de/ratgeber/Mailserver-Open-Xchange-Server-6-installieren-konfigurieren-355910.html und nachfolgende Webseiten.

Weiere Dokumentationen zur Administration und Nutzung des OX6 findet man hier: http://oxpedia.org/index.php?title=Main_Page_CE#documentation

Ich folge weiter unten im wesentlichen genau den Schritten der oben genannten Referenz-Installationsanleitung, werde aber bei einigen Punkten auf Schwierigkeiten eingehen, die auf meinem Test-System auftraten. Die Referenzanleitung sollte man auf jeden Fall elektronisch herunterladen, um Inhalte für Konfigurationsdateien per Copy/Paste übernehmen zu können.

Voraussetzungen der Installation

Voraussetzungen der Installation werden hier diskutiert:
http://www.pcwelt.de/ratgeber/Download-und-Installation-Mailserver-355914.html

Hier noch ein paar Anmerkungen von meiner Seite:

• Erforderl. Skill-Level: Die OX6-Installation ist aus meiner Sicht nichts für Linux-Anfänger. Man sollte schon einige Linux-Administrationskenntnisse haben, sein Opensuse gut kennen und natürlich schon mal einen Apache- und MySQL-Server aufgesetzt haben. Tiefgehende Spezialkenntnisse sind allerdings für eine Testinstallation nicht erforderlich. (Für eine professionelle, dauerhaft produktive Installation im Firmennetz ist natürlich ein breiteres Wissen erforderlich.)
• Natürlich muss auf dem Opensuse 11.4-Testsystem, das den OX 6 beherbergen soll, zuvor ein Apache Web-Server laufen. Für eine schnelle Test-Installation siehe http://linux-blog.anracom.com/2010/07/25/lokaler-apache-test-server-fur-php5/
• Auf dem OX6-Testsystem muss auch eine MySQL-Datenbank installiert sein. PhpMyAdmin zum Verwalten des RDBMS ist ferner von Vorteil, da wir in Teil II bei Bedarf Inhalte der OX6-Datenbank modifzieren werden. Zu einer einfachen MySQL-Testinstallation siehe http://linux-blog.anracom.com/2010/08/28/lokale-mysql-phpmyadmin-installation/
• Eine Java Runtime Umgebung (z.B. OpenJDK) muss laufen. Ich selbst habe OpenJDK und die Pakete von Sun installiert. Ich habe noch nicht ausprobiert, ob es reichen würde, OpenJDK einzusetzen. Vermutlich ja (obwohl es dazu bereits eine Fehlermeldung gibt: https://bugs.open-xchange.com/show_bug.cgi?id=15987). Zumindest zeigt die Paketverwaltung nach einem “rpm -q –requires open-xchange-server | grep java” an, dass “java-openjdk” benötigt wird.
• Die Namensauflösung zum externen IMAP-Server und zum lokalen System muss im hauseigenen Netzwerk funktionieren und änderbar sein. Gründe: Je nach Konfiguration des auf dem Testsystem vorhandenen Apache möchte man ggf. unterschiedliche Services des Web-Servers von Client-Systemen aus unter unterschiedlichen Namen ansprechen. Der OX 6 Dienst entspräche dann nur einer von mehreren virtuellen Web-Domainen. Ferner kann man den IMAP-Server dem OX6 auch über dessen Namen bekanntmachen, um von IP-Adressen unabhängig zu werden.
  Bei fehlendem DNS-Server muss man die Namensauflösung halt über die “/etc/hosts”-Files auf den betroffenen Systemen vornehmen.
• Wir unterlassen in diesem Test - wie oben angekündigt - eine Anbindung an einen LDAP-Server.
• Im Paketmanager unter YAST muss man auf dem Testsystem das Repository
  “http://download.opensuse.org/repositories/server:/OX:/ox6/openSUSE_11.4/”
  auf dem gewohnten opensuse-spezifischen Weg einbinden.
• Eine Admin GUI sucht man in der OX 6 Community Edition vergeblich. “Peters OX Server Admin GUI” (s. http://oxgui.wordpress.com/category/einfuhrung/) klammere ich in diesem Beitrag aus. Ohne eine GUI muss man die User-Verwaltung für die Tests händisch und über Scripts durchführen. Auch das sollte einen nicht abschrecken.

Installation der benötigten RPM-Pakete

Ist das OX-Repository “http://download.opensuse.org/repositories/server:/OX:/ox6/openSUSE_11.4/” in YASTs Paketmanager vorhanden, installiert man sich vor allen weiteren Schritten die notwendigen OX-Pakete für einen Betrieb auf einem einzigen Server.

Die Pakete sind im obigen Installationsleitfaden in einem umrandeten Kasten (Seite 4 im Abschnitt “Updating repositories and install packages” - zypper install mysql \ …” ) einzeln angegeben und werden hier aus Platzgründen nicht aufgelistet.

Die Installationsfiles für den OX-Server sowie zugehörige Admin-Skripts landen im Zuge der Paketinstallation dann im Verzeichnis “/opt/open-xchange” (mit “root” als Owner und ansonsten mit einem gewöhnlichen “755″-Rechtekamm).

Vorsicht und Zurückhaltung bei der Paketinstallation:

Bitte anfänglich ausschließlich nur die Pakete installieren, die in der oben genannten Installationsanleitung angegeben sind. Unter anderem nicht das Paket “open-xchange-admin-plugin-autocontextid” installieren. Das führt im Rahmen des im “Installation Guide” beschriebenen Installationsverlaufs unweigerlich zu Fehlern.

Ich selbst hatte auch mit entsprechenden Fehlern (s. Teil 2, Kontextanlage) zu kämpfen, weil ich mir aus Bequemlichkeit im ersten Anlauf einfach alle OX-Pakete installiert hatte. Das sollte man besser nicht tun.

Kontexte und einige wichtige Accounts im Zusammenhang mit OX6

Kontexte / Default-Kontext

Open-Xchange 6 kennt sog. “Kontexte”. Das sind logische Bereiche, die ihre spezifischen User, Gruppen und Ressourcen beinhalten. Daten eines Kontextes sind in anderen Kontexten nicht sichtbar oder zugänglich. Ein Kontext definiert damit für die User auch eine bestimmte Login- und Arbeitsumgebung.

Jeder Kontext hat eine eindeutige “context id”, und jedem Kontext ist auch ein eigener Kontext-Administrator zugeordnet, der z.B. die User und Gruppen des Kontextes kreiert und verwaltet. User, die in einem Kontext angelegt werden, erben von ihrem Kontext Rechte bzgl. des Zugangs zu bestimmten Arbeits-Modulen.

Ein Kontext kann nur über den sog. “oxadminmaster” (Hauptverwalter des OX 6-Systems) angelegt werden. Dieser definiert auch den zum Kontext zugehörigen Kontext-Administrator, der seinen Kontext verwaltet. Kontexte sind ferner mit sog. Kontext-”Domainen” des OX-Servers verbunden.

Im OX-System gibt es genau einen ausgezeichneten “Default Context”, der während des Installationsvorgangs definiert werden muss. Ein OX-User muss in anderen, normalen Kontexten neben seiner UID auch seine Kontextdomaine angeben, um sich einzuloggen. Beim Default-Kontext genügt für den Login die OX-UID.

Über Kontexte kann man u.U. Unternehmensbereiche abbilden, die getrennt voneinander operieren und separat verwaltet werden sollen. Pro Kontext können auch Quotas hinsichtlich des Speicherplatzes angelegt werden.

Genaueres zu “Kontexten” findet man im “OX6 Provisioning Guide” (http://software.open-xchange.com/OX6/doc/OX6-Provisioning.pdf. (Siehe etwa den Beginn des dortigen Chapter 1.)

Die Installationsanweisung sieht lediglich die Anlage eines einzigen Kontextes - nämlich des “Default Context” - vor. Für unseren Test - und für eine kleine Firma - ist das auch ausreichend.

Spezielle Accounts / Admin-Accounts

Folgende (Administrator-) Accounts spielen im Zusammenhang mit dem OX6-Server eine wichtige Rolle:

• Datenbankuser - “openexchange” : Dieser User erhält die notwendigen Rechte bzgl. der unter MySQL noch anzulegenden “openxchange”-Datenbank und ihrer Tabellen. Das wird ein administrativer MySQL-Account. Er erhält standardmäßig umfassende Rechte im RDBMS, u.a. auch das erforderliche Recht zum Anlegen von Datenbanken ! (Ich habe noch nicht ausprobiert, wie weit sich die Rechte an anderen Stellen beschneiden lassen).
• Administrator für den OX-Server - “oxadminmaster” : Dieser User nimmt Grundeinstellungen des Servers vor. U.a. kreiert er die oben erwähnten Kontexte und die Kontext-Admins.
• Context Administrator - “oxadmin” : Dieser User ist ein Beispiel für einen ersten Kontext-Administrator. Er legt später die ersten Accounts zu dem vom “oxadminmaster” kreierten “Default Context” an.
• Linux System-User und System-Gruppe - “open-xchange” : Auf der Linux-Systemebene wird während der Installation ein (System-) User “open-xchange” und eine (System-) Gruppe “open-xchange” angelegt. Unter der entsprechenden UID/GID erfolgt später der Zugriff auf bestimmte Dateien des OX6-Systems.

Die Namen der ersten drei Accounts können eigentlich frei vergeben werden. Wir halten uns hier aber an die Namen, die die Installationsanweisung vorschlägt.

Wir ordnen diesen Accounts Passwörter zu. Für diesen Text verwenden wir folgende Platzhalter, die jeder selbst mit den geeigneten Passwörtern füllen muss:

• openexchange - Password: MY_OX_MYSQL_PWD
• oxadminmaster - Password: MY_OX_MASTER_ADMIN_PWD
• oxadmin - Password: MY_OX_CONTEXT_ADMIN_PWD
• MySql Root Admin - Password: MY_MYSQL_ROOT_PWD

Für den System-User “open-xchange” ist keine Passwortvergabe erforderlich. Er erhält auch keine Login-Shell.

Serverbezeichnung

Der zu installierende OX6-Server muss im Rahmen der Installation eine Bezeichnung erhalten. Wir verwenden hierfür im Text den Platzhalter

MY_OX_SERVER_NAME

den jeder durch seinen eigenen Servernamen ersetzen muss.

Hinweis: Wir installieren hier nur genau einen Server, der gleichzeitig als Admin-, Application-, Web- und Datenbankserver fungiert. In einer verteilten Hochleistungs-Installation können die Aufgaben auf mehrere Server verteilt werden, die alle zu benennen und in der zentralen Konfigurationsdatenbank des OX-Systems zu registrieren sind. Sehen Sie hierzu die Administrationsdokumentation unter http://software.open-xchange.com/OX6/doc/OX6-Installation-and-Administration.pdf.

Die Installation von Open-Xchange 6 unter Opensuse 11.4 im Einzelnen

Vor Beginn der eigentlichen Installationsarbeiten prüfe ich, ob mein MySQL-Servers läuft. Unter Opensuse z.B. mit

#  rcmysql status

Alternativ mit der Mysql Workbench oder PhpMyAdmin. Zur Not muss der Service gestartet werden:

#  rcmysql start

oder auf anderen Systemen mittels “/etc/init.d/mysql start”. Für den künftigen Gebrauch sollte man den Dienst per “Runlevel”-Verwaltung (z.B. per Runlevel-Editor unter YAST) oder aber manuell in die Startscript-Directories für diejenigen “Runlevel” eintragen, auf denen man den Service benötigt. Typischerweise 3 und 5.

Schritt 1: Anlegen und Initialisierung der zentralen OX6 Konfigurations-Datenbank und ihrer Tabellen

Nun sollte man sich als root (gemeint ist hier natürlich der Linux “root”-Account und nicht der MySQL-”Root”-User) auf einem Terminal einloggen und versuchsweise folgendes Kommando absetzen :

#  /opt/open-xchange/sbin/initconfigdb  −−configdb-pass=MY_OX_MYSQL_PWD  −a

Die “-a”-Option dient zur Anlage des administrativen MySQL-Users “openxchange”.

Bei mir schlug das Kommando prompt fehl.

Ein Blick in das Script “initconfigdb” zeigt, dass zum Anlegen des neuen administrativen Accounts natürlich eine Authorisierung als “MySQL-Root”-Administrator erforderlich ist. Man kann das lt. Script durch einen zusätzlichen Übergabeparameter “−−mysql-root-passwd=….” lösen. Ich selbst habe mir das Leben für die Tests einfacher gemacht und

• die Lese- und Ausführungsrechte für die Script-Datei “/opt/open-xchange/sbin/initconfigdb” auf root begrenzt
• und in die Script-Datei im Bereich “#defaults” das MySQL-Root-Passwort in die zugehörige Zeile explizit eingetragen.

  #defaults
  …
  MYSQL_ROOT_PASSWD=MY_MYSQL_ROOT_PWD
  …….

So ausgestattet lief das Script dann per

#   /opt/open-xchange/sbin/initconfigdb  −−configdb-pass=MY_OX_MYSQL_PWD  −a

anstandslos durch. Ein Blick in die MySQL-Datenbank zeigt denn auch, dass eine Datenbank “configdb” und zugehörige Tabellen angelegt wurden. Ferner ist ein MySQL-User “openxchange” mit sehr umfassenden Rechten angelegt worden.

Hinweise:

• Will man ganz sicher gehen, so kann man beim letzten Kommando vermutlich auch ein zusätzliches “−i” als Option angeben. Dann wird eine evtl. doch schon vorhandene Datenbank “configdb” in dem MySQL-RDBMS zunächst wieder entfernt und dann die Datenbank neu angelegt.
• Ferner wird im OX6-System alles mögliche mit Index-Nummern versehen. Bei mir haben mehrere Anläufe im Zusammenhang mit dem initconfigdb-Script vermutlich zu einer “id=5″ in der Tabelle “configdb_sequence” geführt. Diese Sequenz-Nummer fließt dann später in den Namen der Datenbank ein, in der die eigentlichen Bewegungsdaten (Kontexte, user, Kontakte, Kalendereinträge, etc.) hinterlegt werden. Das hat offenbar nicht geschadet - für eine saubere Installation ist aber die erwähnte “-i”-Option hilfreich.
• Bzgl. des MySQL-Users “openxchange” kann man z.B. mit Hilfe von PhpMyAdmin prophylaktisch noch genauer festlegen, von welchen Systemen aus man einen Zugriff - außer von localhost aus - noch zulassen will.
• Hinweis: Nach erfolgreichem Abschluss der Tests entfernt man den Eintrag mit dem MySql-Root-Passwort aus Sicherheitsgründen natürlich wieder aus dem Script !

Schritt 2: Setup und Initialisieren von Konfigurationsfiles

Das Initialisieren und Konfigurieren der OX6-Systemkomponenten und der zugehörigen Konfigurationsdateien geschieht nun mit Hilfe eines weiteren Scripts - “oxinstaller”:

#  /opt/open-xchange/sbin/oxinstaller  −−no-license  −−servername=MY_OX_SERVER_NAME  −−configdb-pass=MY_OX_MYSQL_PWD  −−master-pass=MY_OX_MASTER_ADMIN_PWD  −−ajp-bind-port=localhost

Der Platzhalter “MY_OX_SERVER_NAME” steht - wie gesagt - für einen frei vergebbaren Namen des künftigen OX-Servers. Das “–no-license” bezieht sich offenbar auf die “Community Edition”.

Im System wird während der Installation übrigens auch ein User “open-xchange” und eine Gruppe “open-xchange” angelegt.

Im MySQL-RDBMS findet sich nun auch eine Datenbank

“oxdatabase_INDEX”,

wobei “INDEX” für die oben erwähnte id in der Tabelle “configdb_sequence” der Konfigurationsdatenbank steht. In meinem Fall also “oxdatabase_5″. Diese Datenbank nimmt später die eigentlichen Daten des OX-Systems und seiner Kontexte auf.

Schritt 3: “Registrieren” des Servers

Wir starten zunächst die OX 6 Administrations-Services

#  /etc/init.d/open-xchange-admin start

Der resultierende Prozess läuft übrigens unter der nichtssagenden Bezeichnung “java” unter dem User “root”. Dass er der korrekte OX6 Daemonprozess ist, erkennt man erst über einen pid-Eintrag unter

/var/run/open-xchange-admindaemon.pid

Ein “cat” für dieses File zeigt einem dann die PID des Prozesses.

Nun muss der installierte Server in der zentralen Konfigurationsdatenbank “configdb” registriert werden. Dies geschieht wieder durch ein Script:

#  /opt/open-xchange/sbin/registerserver  −n MY_OX_SERVER_NAME  −A oxadminmaster  −P MY_OX_MASTER_ADMIN_PWD

Als Ergebnis erhält man u.a. einen Eintrag in der Tabelle “server” der Bank “configdb”.

Schritt 4: Anlegen eines Verzeichnisses zum Speichern von Files und Dokumenten des “Infostore”

OX 6 kennt ein minimales Dokumenten-Management. Letzteres präsentiert sich als sog. “Infostore”. Der zugehörige “Filestore” - ein Verzeichnis auf der Festplatte - enthält später alle im Infostore verwalteten Dokumente, aber auch Anhänge an andere Groupware Objekte wie z.B. Tasks. Das “filestore”-Verzeichnis muss angelegt und in der Konfigurationsdatenbank registriert werden. Der Ort des Filestores ist im Grunde beliebig. Ein Verzeichnis unter “/var” bietet sich an. Ich habe folgende Kommandos benutzt:

#  mkdir /var/opt/filestore

#  chown open-xchange:open-xchange /var/opt/filestore/

#  /opt/open-xchange/sbin/registerfilestore −A oxadminmaster −P MY_OX_MASTER_ADMIN_PWD  −t file:/var/opt/filestore

Schritt 5: Registrieren der Groupware-Datenbank”

Die bereits angelegte Datenbank “oxdatabase_…” wird registriert:

#  /opt/open-xchange/sbin/registerdatabase  −A oxadminmaster  −P MY_OX_MASTER_ADMIN_PWD  −n oxdatabase  −p MY_OX_MYSQL_PWD  −m true

Schritt 6: Apache konfigurieren”

Module

Auf dem lokalen Apache-Server müssen mehrere Module laufen :

proxy, proxy_ajp, expires, deflate, headers, rewrite, proxy_balancer.

Mit

#  a2enmod  −l

verschafft man sich zunächst einen Überblick, über die bereits laufenden Module. Den fehlenden Rest aus der obigen Liste lädt man dann per “a2enmod” nach. In meinem Fall:

#  a2enmod proxy && a2enmod proxy_ajp && a2enmod deflate && a2enmod headers && a2enmod rewrite && a2enmod proxy_balancer

Eintrag in “/etc/sysconfig/apache2″

Danach legt man unter Opensuse über den “sysconfig”-Mechanismus fest, welche Module Apache2 laden soll. Die richtige Datei editiert man entweder über Yast und den dortigen “Editor für /etc/sysconfig”, oder man editiert mit einem Text-Editor direkt die Datei “/etc/sysconfig/apache2″ und dort die Zeile für die APACHE_MODULES:

APACHE_MODULES=”actions alias auth_basic authn_file authz_host authz_groupfile authz_default authz_user autoindex cgi dir env expires include log_config mime negotiation setenvif ssl suexec userdir php5 proxy proxy_ajp deflate headers rewrite proxy_balancer”

Ort der OX 6-Dateien auf dem Apache-Server

Die ausführbaren Dateien, auf die der Webserver zugreift, liegen auf einem Opensuse-System unter

/srv/www/htdocs/ox6

Auf diesen Ordner wird natürlich in der Domain-Konfiguration des Web-Servers Bezug genommen.

Konfigurationsfiles

Nun legt man als root zwei neue Konfigurationsfiles für den Apache-Server an:

• /etc/apache2/conf.d/proxy_ajp.conf
• /etc/apache2/vhosts.d/ox.conf

Die Inhalte dieser Dateien übernimmt man mit Hilfe eines Editors und Copy/Paste exakt der oben angegebenen Referenzinstallationsanleitung. Wir lassen das hier aus Platzgründen weg.

Das erste File regelt den Zugang zu Axis/Soap-Services und dient u.a. der Konfiguration eines Web-”Load-Balancers” für die OX6-Aufgaben, die in einer komplexen Installation ja auch auf mehrere (geclusterte) Web-Server verteilt werden könnten. In unserem Fall reduziert sich die Konfiguration auf genau ein System, nämlich localhost. Ein Blick in die Konfigurationsdatei ist ganz instruktiv.

Das zweite File konfiguriert den Apache-Server so, dass ein Zugriff auf den lokalen Apache immer (!) auf der Login-Seite für den OX endet! Hierfür wird der Zugriff auf das Verzeichnis “/srv/www/htdocs/ox6″ umgelenkt.

Abändern der Konfigurationsfiles für einen namensbasierten Aufruf der OX-Seiten auf dem Apache-Server

Für das Testsystem ist die vollständige Umstellung des Apache-Servers auf die OX-Seiten vielleicht OK. In der Realität - und gerade in kleinen Firmen - möchte man aber auf einem Web-Server unter einer IP-Adresse mehrere unterschiedlich benannte Web-Domainen zur Verfügung stellen. Deswegen ist der nachfolgende Text nicht ganz so “off topic” wie es zunächst erscheinen mag.

Ich z.B. möchte meine aktuelle Apache-Services unter der Adresse des Testsystems unverändert lassen und deshalb den OX-Service bei mir im internen Netz nur unter dem (verkürzten http-Domain-) Namen “oxs3″ erreichen. Bei einem lokalen Standardzugriff “http:/localhost” auf dem Testsystem selbst sollen andere Dateien erscheinen - nämlich die, die bisher schon im Verzeichnis “/srv/www/htdocs/” vorhanden waren. Auch von extern sollen die Dateien unter “/srv/www/htdocs/”, wenn der Server unter seinem Standardnamen “http:/mytestserver” aufgerufen wird.

Ich möchte also trotz evtl. gleicher IP-Adresse eine saubere Trennung der Web-Dienste haben, wenn ich den Server von innen und außen mit unterschiedlichen (”Domain”)-Namen und IP-Adressen aufrufe. Nehmen wir an, der Server des Testsystems habe im lokalen Netz die IP-Adresse 192.168.0.2 und sei DNS-seitig unter dem Namen mytestserver, ruxa, ruxb bekannt. Dann sollen folgende Aufrufe folgendes Ergebnis zeitigen :

• http://localhost >> Anzeige von Inhalten unter /srv/www/htdocs/
• http://127.0.0.1 (auf dem lokalen System) >> Anzeige von Inhalten unter /srv/www/htdocs/
• http://192.168.0.2 (von innen und von extern) >> Anzeige von Inhalten unter /srv/www/htdocs/
• http://mytestserver (von innen und von extern) >> Anzeige von Inhalten unter /srv/www/htdocs/
• http://oxs3 (von innen und von extern) >> Anzeige von Inhalten unter /srv/www/htdocs/ox6
• http://127.0.0.2 (auf dem lokalen System) >> Anzeige von Inhalten unter /srv/www/htdocs/ox6
• https://ruxa (von innen und von extern) >> TLS/SSL-gesicherte Anzeige von Inhalten unter /srv/www/htdocs/ruxa
• https://ruxb (von innen und von extern) >> TLS/SSL-gesicherte Anzeige von Inhalten unter /srv/www/htdocs/ruxb

Unter solchen Voraussetzungen muss man die Konfiguration natürlich etwas ändern. Ich kann das hier nur andeuten. In die Datei “/etc/apache2/listen.conf” des Testservers nehme ich folgende Zeilen für “NameVirtualHost” zu den involvierten IP-Adressen auf:

Die Datei /etc/apache2/vhosts.d/ox.conf ergänze ich wie folgt - es werden nur die wichtigsten Einträge gezeigt:

Für die SSL-Domainen habe ich eine eigene Datei “/etc/apache2vhosts.d/vhost-ssl.conf” mit ungefähr folgendem Inhalt

Hieraus sollte hervorgehen, wie man einen namensbasierten Zugriff erreicht. Die Zugriffsregeln - oben ist oft “allow from all” gesetzt muss man natürlich anpassen. Auf die Konfiguration eines SSL-Servers kann ich hier nicht eingehen. Siehe aber die Links in http://linux-blog.anracom.com/2010/07/25/lokaler-apache-test-server-fur-php5/.

Die diversen Namen (oxs3, mytestserver) unter denen der Web-Server erreichbar sein soll, muss man natürlich über seinen DNS-Server bekannt machen oder aber entsprechende Einträge in den “/etc/hosts”-Dateien vornehmen. In meinem Beispiel etwa sind folgende Daten auf dem Testsystem selbst relevant:

Hierbei bin ich von einer Zugehörigkeit der Server zu einer Domaine “anracona.de” ausgegangen, die auf dem DNS-Server des Netzes angelegt und konfiguriert sein muss.

Hat man seinen Apache konfiguriert, muss er erneut gestartet werden:

#  rcapache2 restart

Schritt 7: Groupware-Dienste starten / erster Test

Die Groupware-Dienste/Dämonen startet man unter Opensuse mit :

#  rcopen-xchange-groupware start

oder

#  /etc/init.d/open-xchange-groupware start

Erster Test
Nun sollte man bei einem Aufruf des Webservers über den Browser einen Login-Schirm sehen. Hat man die Apache-Konfiguration gegenüber der Standardinstallationsanleitung nicht geändert, so genügt zum Testen die Adresse “http://localhost”.

Ist man dagegen meinem Beispiel bzgl. eines namensbasierten Aufrufes gefolgt, so erreicht man den OX-Login-Schirm lokal auf dem Testsystem über die Eingabe der Adressen “http://oxs3″ oder “http://127.0.0.2″ - und gerade nicht über “http://localhost”.

Natürlich gibt es für einen echten Login-Vorgang noch keinen User. Diese legen wir in Teil II an.

Schritt 8: Benötigte Dienste den Runlevels zuordnen

Bevor wir den Default-Kontext erstellen und einen User anlegen, sollten wir die benötigten Serverdienste noch den gewünschten Runleveln zuordnen, damit sie beim nächsten System-Boot automatisch gestartet werden. Ich erledige das für die Dienste “mysql, apache2, open-xchange-groupware und open-xchange-admin” über “YAST > Systemdienste (Runlevel) > Expertenmodus”, da ich dort die Startlevel selber angeben kann. Nimmt man die vorgesehen Standardlevel, so genügt auch:

# insserv mysql; insserv apache2; insserv open-xchange-groupware; insserv open-xchange-admin

Damit ist die Grundinstallation des OX6-Servers [CE] erledigt. Im nächsten Beitrag zu diesem Thema legen wir den Default-Kontext und einige User an, die auch auf den IMAP-Server zugreifen sollen.

( SELECT …. ORDER BY …) UNION (SELECT ….. ORDER BY … )

Wir waren beide der Meinung, dass das zusammengesetzte Ergebnis pro Einzelresultset die jeweils gewünschte Sortierung aufweisen würde. Das war aber leider nicht der Fall !

Dabei hatten wir bereits früher ähnliche Statements verwendet, in denen die Sortierung funktionierte! Wir hatten jedoch eine bedeutsame Kleinigkeit übersehen. Unsere früheren Statements waren nämlich von der Art:

( SELECT …. ORDER BY … LIMIT .. ) UNION (SELECT ….. ORDER BY … LIMIT …. )

Der Unterschied liegt in der Vorgabe von LIMIT, also der Begrenzung der jeweiligen Teil-Resultsets im UNION-Statement. Wir haben dann ein wenig herumprobiert und herausgefunden, dass eine LIMIT-Vorgabe tatsächlich erforderlich ist, wenn beide (oder mehrere) Resultsets separat sortiert und danach zum Union-Resultset zusammengefügt werden sollen.

Offenbar ignoriert der MySQL-Optimizer die ORDER-Statements der Teil-Selects, wenn die einzelnen Resultsets nicht explizit begrenzt werden.

Somit stehen einem wohl zwei Arten zur Verfügung, wei man ein UNION-Resultset ordnen kann:

• Variante 1 - separate Sortierung der Einzel-Resultsets :

      ( SELECT …. ORDER BY … LIMIT … ) UNION (SELECT ….. ORDER BY … LIMIT … )

• Variante 2 - Sortierung des Gesamt-Resultsets :

      ( SELECT …. ) UNION (SELECT …. ) ORDER BY ….

Hinweise:
Die Klammerung ist mindestens im zweiten Beispiel von ausschlaggebender Bedeutung.
Klar auch, dass dabei die Felder der Einzel-Selects identisch sein sollten.

Links:
In einigen MySQL-Foren findet man tatsächlich auch entsprechende Hinweise. Man sollte da doch öfter mal reinschauen:

http://www.mysqlfaqs.net/mysql-faqs/Funtions-and-Operators/How-does-union-work-in-MySQL
http://forums.mysql.com/read.php?10,412000,412000

Ich empfehle

• als Basis: “Cascading Style Sheets”, Eric A. Meyer, O’Reilly (das
  Referenzwerk zum Einsteigen und Nachschlagen vom Guru)
• für das Erlernen grundlegender Design-Tricks: “CSS Mastery”, A. Budd, C.Moll, S. Collison,
  Addison-Wesley (ein sehr gutes Buch)
• zur Vertiefung: “Fortgeschrittene CSS-Techniken”, I. Chao, C. Rudel, Galileo
  Computing (ein sehr gutes Buch, teilweise Überlapp mit CSS Mastery, aber
  aktueller, mit vielen interessanten Details und nützlichen Hinweisen zu Browserunterschieden)
• ergänzend: “Eric Meyer on CSS”, E.A.Meyer, New Riders (Fallstudien von
  E.Meyer)

Ich habe die Bücher selbst und nutze Sie immer wieder gerne.