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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.