kolab webadmin multi domain

[Jeroen van Meeuwen]

On Wednesday, August 29, 2012 02:47:37 PM Gondec Remus wrote:
> Hello,
> 
> I've instaled kolab 3.0 alpha on centos 6.3 with success but I have some
> problems in configure it.
> In web admin, I add a new domain but when I create a new user there is no
> posibility to chose another organizational unit. That textbox is disabled
> and is showed just the primary domain.
> How can I configure Kolab to work with multiple domains?
> 
> Any help will be appreciated...
> 

First of all, 'multi-domain' works different in Kolab 3.0 then it used to in 
Kolab 2.3 or earlier.

- The list of domains in the domains view are actually separate LDAP 
information trees, rather then domains part of the same organization. We'll 
call these domains "parent domains" for lack of a better term.

- Domain aliases (i.e. "Example, Inc." has domains "example.org" and 
"example.de") are added to an existing domain (a domain that is listed in the 
domains list).

That said, when you say "I add a new domain", could you please specify which 
type of a "new domain" you add?

Since you mention you subsequently attempted to add a new user, I suppose I 
can assume you added a "parent domain". There's more actions required for a 
new parent domain to become a completely functional domain though. I'm aware 
of the fact that this is somewhat counter-intuitive, and documentation on the 
subject is virtually non-existent.

For the webadmin to pick up on the new domain, you need to add a [$new_domain] 
section to /etc/kolab/kolab.conf, where "$new_domain" is the name of the new 
parent domain you added. At the very least, you have to specify the base_dn 
setting for this new domain (but there may be additional settings you want for 
this new domain, your references are the [ldap] section and the existing 
[$domain] section).

Additional changes to Postfix are required as well; you can copy and adjust 
the contents of /etc/postfix/ldap/*.cf to match your new domain (don't forget 
to adjust the "domains =" parameters), and include them in the various 
/etc/postfix/main.cf settings where these ldap lookup tables are being 
referred to already.

Alternatively, if your domains are in a $2.$1 pattern ("example.org" but not 
"demo.example.org"), you can not copy any files and not adjust main.cf, and 
replace the setting(s) that refer to a base dn to become dc=%2,dc=%1.

Additional changes to Cyrus IMAP are required as well - now that you have a 
multi-domain deployment, the one IMAP server you have running (configured in 
/etc/imapd.conf, started in the SERVICES block in /etc/cyrus.conf) can no 
longer canonify the login usernames and group/role authorizations for the new 
domain - as it searches the original parent domain root dn, not the new parent 
domain root dn.

To preserve canonification, copy /etc/imapd.conf to /etc/imapd.
$new_domain.conf and add an imap/imaps/ptloader/etc. line adding -C 
/etc/imapd.$new_domain.conf to the "cmd". Make sure the "listen" directive is 
unique as well. For example:

SERVICES {
 # The following lines enable the frontend server to proxy connections
 # to the appropriate backend server.
 #
 imap cmd="imapd -C /etc/imap/$domain1.conf" listen="$ip1:imap" prefork=5
 imap cmd="imapd -C /etc/imap/$domain2.conf" listen="$ip2:imap" prefork=5

 imaps cmd="imapd -C /etc/imap/$domain1.conf -s" listen="$ip1:imaps" prefork=5
 imaps cmd="imapd -C /etc/imap/$domain2.conf -s" listen="$ip2:imaps" prefork=5

 (...etc...)

Take a look at [1] for a full configuration file. Additionally, look at [2] 
and [3] for the Cyrus IMAP "/etc/imapd.conf" configuration files for each 
separate parent domain.

Alternatively, you can drop user canonification and require users that use 
desktop clients to login with their primary recipient email address. Roundcube 
is able to canonify the user login name *before* a login is attempted, so your 
users should be able to continue to be able to login with uid/mail/alias both 
qualified and unqualified.

I hope this helps, and clarifies why configuration management is rather 
difficult to achieve.

Kind regards,

Jeroen van Meeuwen

[1] http://git.klab.cc/klab.cc/tree/files/cyrus/cyrus.conf.hosted03
[2] http://git.klab.cc/klab.cc/tree/files/cyrus/imap.klab.cc.conf
[3] http://git.klab.cc/klab.cc/tree/files/cyrus/imap.mykolab.ch.conf

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/users/attachments/20120830/ee86e6fa/attachment.sig>