[Kroupware] Web interface frontend

[Andreas Jellinghaus]

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

hmm. i know lots of people using databases and then dump configs,
so the running service does not need the database.
you seem to suggest this when you write:
> - provide a backend (perl) that reads stuff from ldap and
>   fills out config file templates 

but for ldap i like the direct access, as ldap can replicate
quite easy and thus provide a high available solution.

also i would like to question: then why a new project.
there are several projects with the webfrontend -> database -> perl ->
config file idea out there, for that approach it might be usefull to
adapt one of them. i personaly do not see the advantage of storing data
in ldap, when it is later processed to config files.

also i do not see an advantage in ldap, if the config is split into
several objects (i guess this is necessary, if you want to seperate
public items such as users and private data such as
maildrop/mailacceptinggeneralid).

my personal view of ldap is: its a store for public data.
if my data is not public, i better not put it into ldap.
userpassword is ok as an excemption.

> So I would propose the following: 
> - have the web interface only interact with ldap

small addon: you need also imap, so you can create mailboxes
and manage permissions on mailboxes. i don't know if it is
possible to store that data in ldap and then somehow phase out
to imap, but i suggest not to.

also you might want to speak the sieve protocol to set/delete vacation
notices or other filer rules.


as for the virtual domain discussion, i'd like to this:
there are cases where people have several domains, but these are simply
aliases for each other and not treated different. like
abc.de and AgreatBusinessCompany.de.

In that case i prefer a config that simply has these domains in
mydomains, and does not consider domain names in the rest of the config
at all, e.g. only maps local part to mailbox without looking at the
config.

i know one company with > 500 domains and this scheme.

then of course there are companies, where the domain name matters.
that will need a very different setup, with respect to the localpart
and domain name. however i think this is not the normal situation,
and i guess many companies can work without this complexity.

it is possible to use the first setup, and then add some exemtions
to the general rul of "do not care". e.g. treat all names as normal,
but have different info@ addresses. two implementations come to my mind:
a) rewrite rule
b) sieve script sorting it out (* only one sieve script can be active,
so this might conflict with web based vacation management)

still i think for most users the domain part is not important,
and pure view of the localpart is good enough (+/- some exemtions of
this rule with above methods).

thus i prefer a setup, where the domainname is not considered.

postfix itself is very flexible, both setups should work nicely.

regards, andreas