Hi Paul,
reading your email below I am willing to discuss anything regarding the schema. We set
up the schema as a completely new one because this would be the quickest for the
moment. I am aware of the fact that there are a number of attributes and object
classes in the standard schema that could be re-used, but that would have costed us
too much time at that moment.
When we were thinking over the schema for Turbine we were urged to donate it as soon
as possible since the next delivery was to contain the LDAP stuff. Unfortunately it
has been removed again (which leaves us some more time to think it over again).
Re-using the schema of standard LDAP servers is the best thing to do. The only problem
is when you want to connect with other LDAP servers not supporting that extended parts
of the schema. For example when we extend the standard schema inetOrgPerson object
class and add the TurbineLastLogon and want to replicate this entry to an other DSA
(LDAP Server; I am from the X.500 world ;-) ) this might fail because the other DSA
does not have our schema extensions. This means that nothing from that entry is
replicated and the entry will be missing in the other DSA. When we introduce a
separate schema for Turbine and replicate this information we will have the same
problem, but the "normal" entries (inetOrgPerson etc.) can flow to the other DSA,
because that is a standard object class with standard attributes.
This all was part of our decision to come up with a completely new schema for the
Turbine stuff. On the other hand I can understand your point of view. When you have an
LDAP server with information and want to reuse this for the Turbine environment (or
simply want to couple the Turbine stuff with information in an LDAP server) it is
easier to extend the already present object classes and attributes.
Your approach by creating aliases for the Turbine attributes is a general accepted
one. I think it will work in most LDAP servers, since you create an alias - only to be
used over LDAP - for already existing attributes.
We can reconsider the schema definition again and try to map all the Turbine stuff
onto already existing attributes and classes and define the missing ones ourselves. If
we use the already defined names it defintely won't mean problems for applications
using it already ;-)
We are open for any discussion and you definitely have a point.
Awaiting your comments to come to a great Turbine LDAP schema.......
Frank
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]
