Re: [Evolution] Evolution, LDAP, etc. - rehashed



man, 2002-12-30 kl. 09:56 skrev Chris Toshok:

Categories used to be possible in 1.0.x, but they were entered wrongly
by Evo. Categories is a multi-value attribute that should have dollar
sign ($) separators (most clients would actually use newlines) and Evo
was entering the categories with a comma separator, i.e. single-value.

Multivalued attributes are already handled by ldap, and so there's no
need for a field separator within the value at all - *that* was the
problem with the original implementation.  It worked just fine in 1.0.x,
you could read/write them (using the deprecated "categories" ldap
attribute), but you couldn't search using them.

The 1.0.x version would store it like:

categories:  Business,Birthday,...

so any ldap search over categories would have necessarily been lossy.. 
we'd have to use "*Business*" as the filter, which is clearly broken.

The new way is:

category:  Business
category:  Birthday
which is much better.

Yeah. That's what I was saying. Or trying to, expressing myself badly,
sorry. That's a multi-value attribute. 

One of the Openldap list people implemented a calendar/task URI schema
that works correctly with Evo, otherwise that wouldn't be possible,
either.

I'm confused by this - does the calCalURI/calFBURL stuff not work the
way evo uses it?  There's not a bug (to my knowledge) filed against it.

I could be wrong here, sorry. I compared the rfc2739 schema with
evolutionperson.schema and the attribute names, OIDs syntax are
completely different. The two exist side by side, as the rfc2739 schema
is auxiliary. Evo 1.2 isn't looking for it.

B.t.w., have you modified evolutionperson.schema? I had to remove some
EQUALITYs for Openldap 2.1.8, as the new Openldaps have become very
picky.

I use ldap for absolutely all authentication and user/contact info on my
systems. That means that users and contacts only have to be entered once
for every possible service to be able to make use of them (the only
exception is Horde, because that doesn't implement ldap correctly except
for the Turba module). I'd love to see ldap implemented correctly on
Evo, meaning SSL/TLS, correct adherence to directory trees, categories
and mailing lists.

But ... :-(

o SSL/TLS:  works

I use Openldap 2.1.8 with a CA signed public key and there's no way I
can get encrypted ldap binds with Evo 1.2. It will only bind on port
389, "never use SSL/TLS". All other clients I use have no problem. SMTP
connections work encrypted (that's not ldap though :)

o correct adherence to directory trees:  you'll need to define that
better, not sure what more we can be doing given the the contact
editor/manager scope we have to operate in.

Entries are not divided into DIT subtrees.

Basically, I'd like to let authorized users to make new users in or drag
and drop to DIT subtrees to which they're authorized. At the moment
there is no way to specify a subtree.

           billy.demon.nl
     _________|__________
     |                   |
Contacts             People
May not write        May write

Trying to make a new entry under people (only way is right click,
there's no button any more), the whole Evo contact dialogue freezes and
the user has to 'killev'.

A wish: I can make modified Laser-Lachmann mailing lists and my smtp
server can use them. This is what I can make using standard schemas
delivered with Openldap 2.1.8, and it works perfectly. Any chance of
implementing this in Evo?:

dn: cn=norwlist,ou=contacts,dc=billy,dc=demon,dc=nl
objectClass: top
objectClass: nisMailAlias
structuralObjectClass: nisMailAlias
cn: norwlist billy demon nl
rfc822MailMember: marit domain1 no
rfc822MailMember: gaute domain com
rfc822MailMember: bjornst domain2 no
rfc822MailMember: unnicat domain3 no

Best,

Tony

-- 

Tony Earnshaw

When all's said and done ...
there's nothing left to say or do.

e-post:         tonni billy demon nl
www:            http://www.billy.demon.nl







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]