Re: Hosting multiple domains
Timotheus Pokorra <[email protected]>
| Newsgroups | gmane.comp.kde.devel.kolab,gmane.comp.kde.kolab.devel |
|---|---|
| Message-ID | <CAJ0=nQejNDz+XwdHQj+2zi=d20SH_GvfjZcQoY-J4GJ=6UZhAw@mail.gmail.com> |
Hello Jeroen, I am sorry it took me a while to respond. I have to admit, I am still learning more and more about LDAP and the inner things of Kolab. Your email has helped, but I needed to learn more before I could understand it better :) I have worked now on allowing one Domain admin to manage several domains. Through this I have learnt more about LDAP. I will post a separate email on the mailing list about that later this morning. > Code *should* use a search against cn=kolab,cn=config to retrieve the domain > name space details, which *should* either; > > - contain an inetdomainbasedn value, or > > - lead to the attribute value used as the RDN, the "primary domain name > space"^1, from which the "standard" root dn can therefore be derived^2. I think I will experiment more over the adding of new domains, and try to make them fully functional without needing to modify kolab.conf. From what you have written, I will try to calculate the base_dn as you described, and there is no need for using kolab.conf. >> I am wondering that we still need the entries in kolab.conf for each >> domain, eg. for the autocreate_folders and primary email address etc, >> not just for the base_dn. > > Since these are domain name space specific settings, you would want them to > exist. > > We could possibly work on making sure there is a section for global defaults > as well. A global defaults section would probably work for us, since the domains of the customers should not be that different. > The goal with Kolab 3 is to not require configuration files to be written out > upon adding a domain name space (or upon editing, moving or deleting it, for > that matter). > > I suppose this means adaptive code, for which of course I cannot be completely > certain I've covered all use-cases. I think at the core, all of it is there. [...] > I suppose for (semi-)automated domain name space configuration like this is to > really take of, we have to consider doing the following (alternative outlined > below); > > - Allow the specification of some sort of a domain_include_dir in [kolab] in > kolab.conf(5). Let's say this will be /etc/kolab/domains.d/, or possibly > /var/lib/kolab/domains.d/. I am a little bit confused. I can understand your sentence above of not wanting to write to config files when a domain is added. I think it is good. But your suggestion is still about working with config files, even if it is a separate config file for each domain. Or could that information which is currently in kolab.conf (autocreate_folders, primary_mail) even be added to the information about the domain in "cn=kolab,cn=config"? Thank you also for explaining what kolabd does, that was helpful! All the best, Timotheus