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
pgpQlyaIhlIWx.pgp
Description: PGP signature