[Kroupware] Web interface frontend

[Lutz Badenheuer]

Hi Tassilo, 

Am Sonntag, 29. September 2002 17:40 schrieb Tassilo Erlewein:
> Am Sonntag, 29. September 2002 16:20 schrieb konold@erfrakon.de:
> > > no business card contains a userpassword to my knowledge.
> > >
> > > an object might be both: a contact/person/... and an account
> > > (or an whatwasthenameoftheitemthatallowestohaveauserpassword),
> > > but a contact per se has no userpassword.
> >
> > Tassilo: Do you want to comment on this?
>
> About the LDAP stuff - let me clearify that point a little bit:
>
> for authentication purposes (Cyrus IMAP and Postfix via saslauthd
> with experimental ldap enabled, Apache2 with experimental
> mod_auth_ldap) one needs the ldap object referring to a user to
> have exactly this two attributes: 
> 1. uid (easily configurable)
> 2. userPassword

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)... :-) 

> And yes you're right this should be discussed.  We can discuss
> whether inetOrgPerson is good enough, or how we extend it, etc.
> etc. etc. Tobias has made an interesting suggestion in another
> mail; this could be a good direction to go :-) I like to hear
> contributions about this.

> We just have to find a very flexible admin web interface frontend
> then and still be somewhat understandable by the folks who happen
> to not be ldap addicts and don't wish to become it.

I'm working on a simple object encapsulation of such a thing, using 
oo-Perl. Possibly I'll be able to post a link in the next three or 
four days -- the simple framework is mostly done, I'm working on a 
plugin idea I had in conjunction with Text::Template. 

Kind regards, 
Lutz 
-- 
Lutz Badenheuer     | IT--Consulting, Development, Networksolutions
luke@the-web-ac.com | C/C++, OO-Perl, sh | Linux, SCO UNIX, Solaris