Kolab 3.4: Wheezy / Dovecot 2.2.15 -> generelle Fragen

Di Mär 10 14:05:37 CET 2015

Guten Morgen,

ich habe mir in einer KVM VM ein Wheezy und ein "nahezu" komplettes Setup vom aktuellen Kolab 3.4 aufgesetzt. "Nahezu" deshalb, weil ich statt dem Cyrus auf Dovecot setze. Vom grundlegenden her scheint das auch zu klappen, allerdings habe ich das Konzept von "Shared folder" noch nicht so recht verstanden.
Auf meinem derzeit produktiven Systemen nutze ich "public folders" im Dovecot und habe dazu die passenden Ordner und ACLs von Hand (doveadm + vi) angelegt. Im Kolab Admin Interface habe ich versucht das gleiche über "Shared folders" zu erreichen. In Dovecot sind auch die passenden Parameter eingetragen, wie laut (1) angegeben, aber in z.B. Roundcube sehe ich nichts von diesen Ordnern.

Dann habe ich z.B. noch in den Logs Meldungen wie:

imap-login: Disconnected (auth failed, 1 attempts in 8 secs): user=<cyrus-admin>, method=PLAIN, rip=::1, lip=::1,

Irgendein Prozess möchte sich da einloggen, um vermutlich nach den passenden Mailboxen zu schauen. testsaslauth und auch ein Test per telnet foobar*dovecot-cyrus-admin-passsword auf Port 110 (leichter als das IMAP Prozedere ... zum testen), klappt ebenfalls.
In die gleiche Kerbe schlägt natürlich "kolab lm"

[...]
    self.__doraise( function.upper(), msg )
  File "/usr/lib/python2.7/dist-packages/cyruslib.py", line 367, in __doraise
    raise CYRUSError( idError[0], mode, msg )
cyruslib.CYRUSError: (10, 'LOGIN', '[AUTHENTICATIONFAILED] Authentication failed.')

Ich finde da leider auch nicht die Quelle. Ich vermute nur, dass Dovecot einfach noch einen regulären User mit auf dem Weg bekommen möchte.

(1) http://kolab.org/blog/grote/2013/03/19/using-kolab-dovecot-imap-server

Dann wäre da noch eher so konzeptionelles Zeug :-)

Wir bereits im Dezember auf der Liste einige geschrieben haben, trenne auch ich meine Dienste, also Web, Mail - und normalerweise auch LDAP und SQL. Für meinen privaten Server würde ich LDAP und SQL auch auf dem MX Host laufen lassen, unabhängig davon, dass auf Web bereits ebenfalls schon MySQL läuft.

Jetzt interessieren mich da noch insb. die Domain Konzepte.

Ich habe z.B. Domains, die ich primär für Mails verwende. In der bisherigen Installation ist nur eine Mailbox pro Benutzer vorgesehen. Das ist nicht sehr praktisch, wenn man die Mailboxen getrennt haben möchte. Der erste Ansatz ist da natürlich einfach mehrere "User" anzulegen ... Vor/Nachname etc. muss man ja nicht ausfüllen.
Würde man dazu einfach eine weitere Domain zur primären hinzufügen und dann den passenden User darunter anlegen?
Wie ich gerade im LDAP sehe, hat die neue Domain natürlich auch eine neue Base, was wiederum bedeutet, dass diese überhaupt so nicht genutzt werden kann, da Dovecot/Postfix und Co nur auf die Base DN der Hauptdomain schauen...
Was würde wohl bedeuten, dass ich ein Multidomain Konstrukt bauen müsste. Sehe ich das richtig?

Da ich vieles, was ich privat für "gut" erachtet habe, auch zumeist auch in der Firma verwende, stelle sich da ebenfalls Fragen:

1. Ich nutze dort ein Master-Master OpenLDAP Konstrukt, aus dem nicht nur die rund ~5.000 Studenten und Mitarbeiter fallen, sondern auch noch diverse Dienste wie Postfix, Dovecot, ISC-DHCP(-ldap) Puppet, Sympa und Co ihre Daten beziehen. Kurz, ich würde auf jeden Fall diese LDAP Server für Kolab verwenden wollen.
Meine DNs sind da nach folgendem Schema aufgebaut:

Base-DN dc=informatik,dc=tu-darmstadt,dc=de

Darunter fallen dann für die einzelnen Fachgebiete, die Orgas:

ou=fachgebiet1, dc=informatik,dc=tu-darmstadt,dc=de
ou=people,ou=fachgebiet1, dc=informatik,dc=tu-darmstadt,dc=de
ou=groups,ou=fachgebiet1, dc=informatik,dc=tu-darmstadt,dc=de
ou=services,ou=fachgebiet1, dc=informatik,dc=tu-darmstadt,dc=de
out=dhcp,ou=services,ou=fachgebiet1, dc=informatik,dc=tu-darmstadt,dc=de
out=mail,ou=services,ou=fachgebiet1, dc=informatik,dc=tu-darmstadt,dc=de
dc=informatik.tu-darmstadt.de,out=mail,ou=services,ou=fachgebiet1, dc=informatik,dc=tu-darmstadt,dc=de
ou=aliases,dc=informatik.tu-darmstadt.de,out=mail,ou=services,ou=fachgebiet1, dc=informatik,dc=tu-darmstadt,dc=de
cn=foobar,ou=aliases,dc=informatik.tu-darmstadt.de,out=mail,ou=services,ou=fachgebiet1, dc=informatik,dc=tu-darmstadt,dc=de
...
ou=fachgebiet2, dc=informatik,dc=tu-darmstadt,dc=de
ou=people,ou=fachgebiet2, dc=informatik,dc=tu-darmstadt,dc=de
...
ou=fachgebiet3, dc=informatik,dc=tu-darmstadt,dc=de

Ein weiterer wichtiger Punkt ist es auch zu wissen, dass unsere Konten mittels einer eigenen (Web-)Anwendung gepflegt werden. Sie sorgt dafür, dass Leute einen (POSIX) Account bei uns anlegen können und das Passwort zurücksetzen etc. pp. Des Weiteren sorgt die Anwendung auch dafür, dass nicht mehr benötige User automatisch aus dem System (LDAP/NFS..) gelöscht werden.

Ich hätte also ein gesteigertes Interesse da Kolab in diese Prozesse zu integrieren.
Ein Benutzer der über unsere Anwendung gelöscht wird, müsste also auch aus den Datenbanken (Kolab/Roundcube..) etc. verschwinden und auch die Postfächer müssten gelöscht werden.
Bisher sind mir aber generell keine Scripte begegnet, die dafür sorgen, dass gelöschte Benutzer/Accounts entsorgt werden.

Wären also der Punkt der Integration in das vorhandene Schema von OpenLDAP und auch die Pflege der Daten.

Dann habe ich z.B. noch einmal die Domain Frage:

Einige Domains werden extern befüllt, da sie täglich durch die Verwaltung generiert werden. Das würde in dem konkreten Fall die BaseDN betreffen. Hätte Kolab ein Problem damit? Also werden diese E-Mail Aliase auch noch irgendwie in der MySQL Datenbank referenziert, oder werden sie einfach nur Ad-Hoc aus dem LDAP ausgelesen.

Es wäre schon, wenn jemand zu dem einen oder anderen ein paar Worte schreiben könnte :-)

cu denny
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 163 bytes
Beschreibung: Message signed with OpenPGP using GPGMail
URL         : <http://lists.kolab.org/pipermail/users-de/attachments/20150310/b2b16d6f/attachment.sig>