Re: [Kolab-devel] Kolab 3.x Extension to handle secondary domains internally (Multi-domain patched)

Rickard Osser <[email protected]>
Newsgroups gmane.comp.kde.devel.kolab
Message-ID <1396451461.32331.22.camel__403.215402229939$1396522238$gmane$org@dragon.home.osser.se>
Hi Ketil,

to add to this.

If your main domain is domain1.com and you send an e-mail to
[email protected] postmap -q [email protected]
ldap:/etc/postfix/ldap/<file.cf> will mapp domain1.com to
dc=domain1,dc=com which is fine.
If I want to use [email protected] which is a secondary domain it will
map to dc=domain2,dc=com which isn't present in LDAP, I wan't to ask
postfix if domain2.com is present in the server (mydestinations.cf used
with the domain line in the .cf file) and if so return the dn for where
it's present, which will then be used as the search_base.

That will solve all lookups in a multi-domain setup including
sub-domains and secondary domains in one main domain. Which will solve
both our problems. 

Best regards,
Rickard

On ons, 2014-04-02 at 16:48 +0200, Rickard Osser wrote:
> Hi Ketil,
> 
> On ons, 2014-04-02 at 16:18 +0200, Ketil Kvifte wrote: 
> > >  I would like to add the main domain dn to cn=kolab,cn=config for each
> > >  domain and thus be able to extract that to use as the search_base
> > > inside
> > >  postfix. That would help to have different users/lists/shared folders
> > >  using secondary mail-addresses to receive e-mail without mapping each
> > >  secondary domain to the main domain.
> > > 
> > >  I know this isn't possible as postfix looks today but that would be a
> > >  nice extension for all of us using multi-domain setups. In the case
> > > of
> > >  Kolab that would make it possible to handle all main as well as
> > >  secondary domains inside the kolab-webadmin and be a lot more
> > > flexible.
> > 
> > I am not really understanding what exactly you are trying to achieve, 
> > but I don't map my secondary domains to my primary domain, except maybe 
> > for mailman. I believe postfix already support most of what you want to 
> > do and that it's only a matter of easier and more flexible 
> > configuration. Please correct me if I am wrong.
> Yes, if you run kolab in single domain it does but not in multi-domain as it's implemented with separate dn's (dc=x,dc=y)
> for each organisation.
> I have several different domains which I run withing my business, some
> of them do more or less the same but under different names.
> If I want to use [email protected] and [email protected] I can't as I
> have to make a 1 to 1 mapping by hand. 
> Now, if I can really do a search for [email protected] inside ldap, get
> the dn which is dc=domain1,dc=com and use that as the search_base then
> that
> would make it easier to maintain, no hand-patching postfix as well as
> being very flexible.
> 
> 
> > I am running a server for different student organisations in my spare 
> > time. Each organisation has their own domain. Some are in the form 
> > my.domain.name and some in the form another.domain. I am describing what 
> > I did below because it might help figuring out a solution:
> > 
> > In my /etc/postfix/ldap/forward.cf file I have:
> > search_base = dc=%2,dc=%1
> > 
> > In my /etc/postfix/ldap/forward-subdomain.cf I have:
> > search_base = dc=%3,dc=%2,dc=%1
> > 
> > What I would like to do if anyone patch postfix is something like this 
> > because it would save me the work of duplicating my config files:
> > search_base = %dc .
> > 
> Which is exactly what I want to do... If you check what I wrote in the
> old mail as well as the description above then you see that
> is how I want it to be. I want to be able to extract the dn from ldap
> and use it as the search_base.
> 
> This also makes it unnecessary to have the "_3" files included as the
> information is in ldap and usable directly.
> 
> Best regards, 
> _______________________________________________
> devel mailing list
> [email protected]
> https://lists.kolab.org/mailman/listinfo/devel
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.