Misc question about LDAP and admin stuff

Per-Olov Sjöholm pos at incedo.org
Mon Jul 25 17:03:33 EDT 2005


On Saturday 23 July 2005 17.37, Igor Brezac wrote:
> On Fri, 22 Jul 2005, Per-Olov [iso-8859-1] Sjöholm wrote:
> > On Thursday 21 July 2005 16.17, Igor Brezac wrote:
> >> On Thu, 21 Jul 2005, Per-Olov [iso-8859-1] Sjöholm wrote:
> >>> Hi list
> >>>
> >>> Does anybody know if there are any work going on to implement the stuff
> >>> that the third party cyrusmaster requires to work and extend the LDAP
> >>> support in cyrus imapd? If not... Is there any work at all going on to
> >>> add good LDAP or MySQL support? I really love cyrus imapd but think it
> >>> lacks some stuff when it comes to LDAP or MySQL support.
> >>
> >> Can you be more specific?
> >
> > Your'e right...
> >
> > I am not just talking  about LDAP auth using any PAM stuff.
> > Cyrus imapd in not directly LDAP friendly.
>
> From the authentication/authorizaion stand point it is very friendly.
> Perhaps it is not easily configured.
>
> Take a look at ptloader/ldap and cyrus sasl documentation (there are
> several different ways to configure ldap based authentication).
>

I am *not* talking about LDAP auth. I know that this is easily configured... I 
have already used it *a lot*. Me and my colleague have actually extended 
Cyrus sasl with extra Oracle auth through SQL*Net for a large Telecom/ISP 
customer. So yes... I know Cyrus SASL...


> > Let's say you want to put quota
> > info in LDAP.
> > And in huge installations you maybe want to put as much info as
> > possible into a central repository using LDAP protocol. And not just
> > quota,
>
> It is fairly trivial to develop an ldap based cyrus db backend.  But in a
> 'huge' installation I do not believe you can achieve desired performance
> and reliability.  ldap just does not do well when you have to write to it
> often.
>
Yes it is fairly trivial for a person with the correct programming skills (not 
me)... But it is not in the product today. And that is why I ask... 

Hmmm. I do know understand your LDAP performance comment.... Why should you 
write often to LDAP in a scenario like this??? You configure the attributes 
rarely  and then read them often. I can only see writes during user password 
change or any other admin changes of user attributes. *One* of the golden 
rules to use LDAP is to have *many* more reads for each write (example 
1000:1). I work with LDAP in my daily work. But I maybe missunderstood you...


> > maybe alternate e-mail adresses and more.
>
> You can do this now.
>
Did not know that....Sorry. Thanks for telling me.

But what I meant by "more" above could for example be quota, acl , virtual 
domain stuff etc.

Between the lines I can read a try to defend cyrus as "it is good as it is" in 
the LDAP area. But there is definitely no need to do that, because I already 
think Cyrus imapd is the best OpenSource product in this area. And also 
better than many commercial ones. I have it in some customer installations, 
and it works really well.

The cyrusmaster project looks nice. It looks like the most powerful admin 
software for cyrus and great for big installations. If we start to use it, we 
have to wait for LDAP extension patches from the cyrusmaster project after 
each cyrus update. Simple LDAP extension patches for basic (well.. almost) 
ldap features that could already have been in the product. And believe me... 
I would have helped the Cyrus project extending the LDAP support if I was a 
real programmer.

But I am maybe the only person ansking for some more centralized "LDAPified" 
config stuff for Cyrus. If so. Let's skip the LDAP discussion. As said 
earlier, it's not important to me today. Just asked because of curiosity to 
see what is in the Cyrus developers pipe....


> > My question is just because I am
> > interested to know if there is any work going on to make is more LDAP
> > friendly. And the main reason for asking is because the cyrusmaster
> > project has extended cyrus to contain some of this stuff.



And the last... Excuse me if I totally missed something important here.


Regards
Per-Olov
-- 
GPG keyID: 4DB283CE
GPG fingerprint: 45E8 3D0E DE05 B714 D549 45BC CFB4 BBE9 4DB2 83CE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://lists.andrew.cmu.edu/mailman/private/info-cyrus/attachments/20050725/9910669f/attachment.bin


More information about the Info-cyrus mailing list