Re: [Evolution] Remote Contacts/Calendar?

[Adam Williams <awilliam whitemice org>]

> > Thanks for the ideas on using OpenLDAP to store addresses. Being
> > somewhat of a novice to LDAP, it is a little daunting to dive into.
> > It's a shame that although you say this topic has been discussed
> > quite a bit on the opendlap aliases, there is no single document
> > that easily describes how to integrate Evolution and OpenLDAP.
> Setting up Openldap is the worst part, and Joseph seems to have done it.
> That has to happen long before one can begin to think of Evo, since a
> single Openldap directory database can form the basis of all user
> authentication within a whole organization, smtp, POP3 and IMAP AUTH,
> contacts, machines in a network, allowed workstations, buildings in an
> organization, through Samba v3 Windows PDC authorization - and much
> more. Therefore it's important firstly to have a plan for what is

I've published a good portion of Morrison Industries internal
"Enterprise Directory Manual" at - 
ftp://ftp.kalamazoolinux.org/pub/pdf/EDManual.pdf
- which might help if you need a example of what a working Dit might
look like, etc...  It isn't complete, but it might help;  in addition to
my other LDAP document.

Also McGraw Hills "Designing and Implementing Directory Enabled
Networks" (big huge tan book with a suspension bridge on it) is really a
good, albiet old, guide on basic LDAP issues.  And the LDAP issues seem
to really get people more than the OpenLDAP specific ones.

> intended with the database, and secondly how it is to be designed. This
> takes an awful lot of practice, swatting and *time* - and there's no
> single book or doc on it. Moreover, the more up-to-date one's Openldap
> and backend database software is, the more reliable and powerful it is.

Althougth anything relatively recent should work just fine.  We've used
OpenLDAP in production since 2.0.21 and while it has gotten faster and
more featureful it has always been stable and worked well once properly
configured.

> Once this has been done and one has discovered what lies behind LDAP,
> tools like GQ and directory_administrator and others, coupling Evo in is
> easy. Though Evo presents its own problems - even 1.4.5 is by no means
> stable yet and needs constant revision as to what connection mechanism
> is needed at a given moment - and if the LDAP server is restarted during
> an Evo session, the connection mechanism has to be redefined. If one
> doesn't know or realize this at first, it comes as a shock ("it worked
> yesterday, why doesn't it work today?"). More about this below.

This is true;  Evo is not really a very well behaved LDAP client.  Test
with things like ldapsearch and GQ, and when you think it works, then
fire up Evo and try it.  Don't initial-test with Evo, you'll end up bald
'cause you ripped all your hair out.

> > I read Adam's document, alot of good LDAP info, but not much 
> > specific to Evolution.
> No, one has to do this parallel to Evo - first get it working, get used
> to it and then couple the two.

Other than the evolution schemas and enabling v2 binds there really
(honest, I mean it) isn't anything evolution specific.

> >     [ID 217296 local4.debug] conn=1 op=0 RESULT tag=97 err=2
> >      text=requested protocol version not allowed
> > Googling once again, I found that I had to enable a specific
> > LDAP protocol version, that apparently Evolution uses. This is
> > done by adding the line:
> >     allow bind_v2
> > to slapd.conf.
> Figures. Mozilla needs this too.

I'm pretty sure thats in my ldapv3.pdf document.

Most clients at this point don't support v3.

> > But that wasn't the end of my troubles. Apparently all the
> > attempts I made to authenticate with Evolution had caused 
> > evolution to cache some sort of credential or something, 
> > because even though it was prompting me to enter a password,
> > watching the openldap log files, and snoop, I didn't see
> > Evolution even try to talk to openldap.

We see that same kind of behaviour.  Hoping very much that it is better
in 2.0.  It is on my TODO list to document this misbehaviour in ldapv3
but other project have my time currently.

> When you get a bit more advanced with your ACLs, you'll find you can set
> up different directory subtrees for, say, Unix users and contacts, and
> be able to give privileges to power users to modify users, contacts
> whatever and others just to read - or not even see different directory
> trees. The best thing is, that you can make this available across an
> entire organization.

And from virtually any client - thats the best part: Mozilla, Evolution,
Pine, Outlook, Eudora.... everybody can utilize LDAP (at least to some
degree).