Hi Paul,
Thanx for your reply.
Interest in Ldap support appears to be gaining momentum at the moment.
Last week I got sent some code from a company called Divine.com. This week
(after I've checked in some changes to the Mail classes) I'll start spending
more time on/in the Ldap code. If you guys can help and/or share knowledge
on this front that would be great.
Frank is a colleague of mine who is also subscribed to the list, so any
questions/suggestions you have concerning the initial schema that he
proposed should/can be sent to the listserver. I'll nudge him now and again
if he takes too long to answer :-)) (Just kidding Frank!)
/Colin
Colin,
I would love to be involved with progressing Turbine on LDAP. My
background is more on the schema end of things, but we have some
developers here who have already been working on the LDAP code. They
started with the code that was checked in, and got some basic
authentication integrated.
As for the schema is Frank available to discuss it. I have some
questions about the approach. For example the creation of custom
objects and attributes for the storage of TurbineUser. I know he had a
caveat that he knew the standard attributes existed, but he picked the
creation of a custom schema to get the ball rolling. I just wanted to
get more of the pro's and con's of this approach.
Before seeing his schema I was leaning towards using the existing
standard objects and attributes and just extending those objects with
any additional turbine specific ones. This way the schema could reside
in existing LDAP directories without duplicating data. After seeing his
approach, I looked into modifying the Standard schema with his attribute
names as aliases to the standard attributes. This seemed to have worked
on Netscape, but this approach may not be portable to other LDAP
vendors. This also required the modification of the slapd.at.conf file,
which is probably a hack that is not supported by Netscape.
For example the changes in the file were similar to:
attribute sn turbineUserLastName surName 2.5.4.4
cis
So now the Tubine code could reference the users last name as
turbineUserLastName, while the existing code still uses the standard
attribute sn.
Hopefully this will spur more discussion on the schema topic, please
feel free to contact me about any help or involvement you may need.
Paul Esposito
-----Original Message-----
From: Colin Chalmers [mailto:[EMAIL PROTECTED]]
Sent: Saturday, July 14, 2001 6:58 AM
To: [EMAIL PROTECTED]
Subject: Re: Turbine stored in LDAP
Hi Paul,
Ldap support is also something I would like to see and am willing to
work
on. I've mentioned this a couple of times in the group but due to time
restraints have not been able to do much (I should really either shut my
mouth or do it!!)
Code for Ldap was donated but has not been fully integrated yet. I
patched
the NamingService to return contexts which we could use for Ldap and a
colleague of mine (Frank Nolden) did some initial work on a schema which
we
could use for Turbine but has not yet been fully tested.
I hope to start working on the Ldap part *soon*. I think it would be
great
to have Ldap fully integrated for the next release which I think Jason
wants
to present at ApacheCon in October. Specifically because I want to be
there
also :-)
If you want to help and join "forces" great!
/Colin
I was wondering if there was more information on Turbine and LDAP. I
searched the backchat on the mailing lists and I did not find too much
information. I did find a document in CVS on the LDAP-HowTo. The HowTo
document describes the additional attributes and object classes
required, but doesn't talk too much about the implementation. Can
anyone point me to additional information, or has anyone implemented
Turbine into LDAP and have any tips or LDIF dumps of sample turbine data
they can provide.
Thanks,
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
