[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kroupware
Subject:    Re: [Kroupware] Web interface frontend
From:       Tassilo Erlewein <tassilo.erlewein () erfrakon ! de>
Date:       2002-10-01 8:53:43
[Download RAW message or body]

Hi Lutz,

sorry for my late answer. I find your ldap postfix findings quite useful.
We think heavily about getting the whole server config into a special 
access-restricted LDAP object.

However I'm not so sure it's generally good to have the daemons
get their running config directly from LDAP (where possible)

So I would propose the following:

- have the web interface only interact with ldap
- provide a backend (perl) that reads stuff from ldap and
  fills out config file templates 

How do you think about that ?

Note that it's possible to arrange for special settings in the config file 
templates that don't get overwritten by the backend. So it would be possible 
for you to have postfix fetch whatever it supports directly from ldap.

My understanding is, that requires we stay postfix conformant with regard to 
the ldap config object. So what you point out here could be very useful. 
Please let me know further requirements like this, if you like.

Thanks

Tassilo


Am Montag, 30. September 2002 12:07 schrieb Lutz Badenheuer:
> Hi Tassilo,
>
> To have the postfix server properly lookup its virtual domains, you
> should possibly use
> 3. mailacceptinggeneralid (the email address) and
> 4. maildrop (where to put mail for this address to)
>
> The mailacceptinggeneralid attribute is used to lookup a mail user
> AND a virtual domain in Postfix: if you use
>
>   mailacceptinggeneralid: example.org
>   mailacceptinggeneralid: @example.org
>   maildrop: harald@100jahralt.net
>
> in your "virtual_maps = ldap:ldaptag" you tell postfix to process
> mail for example.org; by adding a @example.org, you specify a
> catchall account that maildrops to harald@100jahralt.net.
>
> There is IIRC a limitation due to Postfix' security features, that
> you can't use [PC]RE or local usernames in the maildrop attribute.
> So, this has to be mapped to local mailboxes, but you can't specify
> local users in that maildrop attribute. To work around this, you may
> move transport_maps into LDAP, telling it to use cyrus deliver
> program as MDA. IIRC, the documentation told someting about cyrus: in
> this lookup's result. So,
>
>   transport: cyrus:
>
> should be the LDAP result for the entire domain.
>
> With all this in mind, we need exactly two objectclasses: one that
> may be, possibly an extended version of inetOrgPerson, and one that
> is a special objectclass to represent a virtual mail domain. This
> entry provides virtual_maps and transport_maps to postfix.
>
> For the virtual domain, I propose
>
> --snip-----
> objectclass VirtualDomain
>   requires
>     objectclass
>     mailacceptinggeneralid
>     maildrop                 //is this really "required"?
>     transport                //always cyrus:
> --snap-----
>
> Ok, I hope I didn't forget something -- I started using Postfix only
> a week ago (before, I was addicted to qmail)... :-)
_______________________________________________
Kroupware mailing list
Kroupware@mail.kde.org
http://mail.kde.org/mailman/listinfo/kroupware
[prev in list] [next in list] [prev in thread] [next in thread]