Re: [Evolution] Remote Contacts/Calendar?

[Tony Earnshaw <tonye billy demon nl>]

ons, 17.12.2003 kl. 04.59 skrev Joseph Mocker:

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

O.k. this is for the archives. I'm CCing Joseph (I don't normally and
it's usually no good for people to try and CC me, eh, Guenther ? :), cos
this was a while ago.

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
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.
I can't possibly teach all of this, therefore the best forum is a
community and the best community is the Openldap mailing list. There are
an awful lot of power users there and the archives are worth pure gold -
there's almost no problem or solution that hasn't been covered again and
again.

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.

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

> I found OpenLDAP's administration guide to be a pretty good 
> start on getting the software set up. 

If one follows it methodically and uses one's head, it's sufficient to
start with. It lacks depth and detail.

> The hard part was really getting Evolution to correctly authenticate
> to OpenLDAP so I could add/modify entries. After struggling with
> ACLs for a few days, trying to decipher the cryptic debugging output,
> and many, many searches, I found this email to be probably the 
> most helpful.
>
> http://lists.ximian.com/archives/public/evolution/2002-October/022119.html
>
> But even following this email, I still couldn't get Evolution
> to correctly authenticate. Getting pretty frustrated, I decided 
> to see if the syslog output (which I hadn't initially enabled)
> helped at all. After adding the lines:
>
>       local4.debug            /var/log/local4.log
>       local4.notice           /var/log/local4.log
>       local4.err              /var/log/local4.log
>       local4.info             /var/log/local4.log
>
> to /etc/syslog.conf, I found another message to that might help:
>
>       [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.

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

That's part of the instability I mentioned above. You'll find what I
described above will hit you again and again - you'll have to keep
redefining your connection mechanism in Tools-> Settings -> Directory
servers -> Your DN -> Connection -> Use SSL/TLS (Always|When
possible|Never) - backward and forward, even though it might not be what
you want. And you should do this with Evo on some other map than your
directory server, otherwise even then it won't work.

> After some more fiddling, I not even quite sure how I fixed
> it, but it is finally working,

Probably how I describe, only you didn't realize ;)

>  and I have been able to drag
> and drop local contacts to LDAP, and modify them, and everything.
> I _think_ it was hitting the Clear button on the Contacts screen
> that finally did it. Or maybe it was just blindly trying to
> drag and drop a contact even though I knew I hadn't authenticated.

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.

> Who hoo! all that work makes the feature even more of a 
> gem to have!

It's one of the things I missed most during my 6 months enforced
Mozilla. You discovered the evolutionperson.schema, obviously.

Now you've discovered and half mastered Openldap. You can put that
knowledge to good use in an organization and do a lot with it.

Thanks for letting us know :)

--Tonni

-- 
mail: billy - at - billy.demon.nl
http://billy.demon.nl