You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@directory.apache.org by Damien Tougas <da...@tougas.net> on 2007/04/23 03:44:17 UTC
[ApacheDS] Having problems with schemas in 1.5
Hello,
I am in the process of checking out the directory server for the first
time. I am by no means an LDAP expert, but so far I like what I am
seeing here. My end goal for this testing is to create a shared address
book using the mozillaAbPersonAlpha schema:
http://wiki.mozilla.org/MailNews:Mozilla_LDAP_Address_Book_Schema
I was able to open the schema in LDAP Studio and export it to an LDIF.
The first problem I encountered was that the exported LDIF had a typo
which caused the import to fail. The typo was in this section (note the
spelling of "matchingRules" in the dn):
dn: ou=macthingRules, cn=moz, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: matchingrules
Once that was fixed, the import worked without any errors.
The next problem I encountered was the fact that the directory server
didn't know what to do with the syntax lengths. This problem did not
show up when I did the import, but it caused exceptions to get thrown
when re-starting the directory server.
To deal with that problem I simply removed the syntax length definitions
from the exported LDIF (i.e. removed {128} etc.) and did the import
again (I first had to delete the schemas partition directory in order to
be able to do this, I am not sure if there is a better way...).
After doing all of that, everything appears to be fine. I cannot,
however, see the mozillaAbPersonAlpha object class show up in the list
when trying to add a new entry using LDAP Studio. Is there anything else
I need to be doing in order to make this new schema active for a
particular partition?
Thanks for your help!
--
Damien Tougas
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Stefan Zoerner <st...@labeo.de>.
Hi Alex and Damien,
I tried to load the LDIF provided by Damien with raw LDAP tools and made
an observation which may help, (or may not, I am still a Schema
Subsystem rookie).
Loading this attribute type (as provided by the LDIF) fails with "The
attribute type syntax is invalid"
dn: m-oid=1.3.6.1.4.1.13769.3.7,ou=attributeTypes,cn=moz,ou=schema
objectClass: metaTop
objectClass: metaAttributeType
objectClass: top
m-equality: caseIgnoreMatch
m-name: mozillaHomeUrl
m-oid: 1.3.6.1.4.1.13769.3.7
m-singlevalue: true
m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
But this one works
dn: m-oid=1.3.6.1.4.1.13769.3.7,ou=attributeTypes,cn=moz,ou=schema
objectClass: metaTop
objectClass: metaAttributeType
objectClass: top
m-equality: caseIgnoreMatch
m-name: mozillaHomeUrl
m-oid: 1.3.6.1.4.1.13769.3.7
m-singlevalue: TRUE
m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
Please note the only difference: "true" vs. "TRUE".
Perhaps it has something to do with enabling syntax checking of
attribute types?
Greetings from Wiesbaden,
Stefan Zoerner (szoerner)
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi all,
The cause of this problem may also be the lack of the m-dependencies
attribute in the "cn=moz,ou=schema" entry.
We currently have an opened Jira for that :
https://issues.apache.org/jira/browse/DIRSTUDIO-83
This attribute is used to store the dependencies of the schema on other
schemas and the last release of LDAP Studio Schemas Editor doesn't support
it. I'm working on that right now. It should be fixed within the day.
Regards,
Pierre-Arnaud Marcelot
On 4/23/07, Stefan Zoerner <st...@labeo.de> wrote:
>
> Hi!
>
> Here is an addition to my last mail. I changed all "true" to "TRUE" in
> Damien's LDIF, was able to load it (via command line tool ldapmodify)
> and use it.
>
> Find a changed version of the LDIF file attached.
> Greetings,
> Stefan Zoerner (szoerner)
>
>
>
>
> dn: cn=moz,ou=schema
> objectClass: metaSchema
> objectClass: top
> cn: moz
>
> dn: ou=attributeTypes,cn=moz,ou=schema
> objectClass: organizationalUnit
> objectClass: top
> ou: attributeTypes
>
> dn: m-oid=1.3.6.1.4.1.13769.3.7,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: caseIgnoreMatch
> m-name: mozillaHomeUrl
> m-oid: 1.3.6.1.4.1.13769.3.7
> m-singlevalue: TRUE
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
>
> dn: m-oid=1.3.6.1.4.1.13769.2.1,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-name: mozillaNickname
> m-name: xmozillanickname
> m-oid: 1.3.6.1.4.1.13769.2.1
> m-supattributetype: name
>
> dn: m-oid=1.3.6.1.4.1.13769.3.4,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-name: mozillaHomeState
> m-oid: 1.3.6.1.4.1.13769.3.4
> m-singlevalue: TRUE
> m-supattributetype: name
>
> dn: m-oid=1.3.6.1.4.1.13769.3.8,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: caseIgnoreMatch
> m-name: mozillaWorkStreet2
> m-oid: 1.3.6.1.4.1.13769.3.8
> m-singlevalue: TRUE
> m-substr: caseIgnoreSubstringsMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
>
> dn: m-oid=1.3.6.1.4.1.13769.2.3,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-name: mozillaUseHtmlMail
> m-name: xmozillausehtmlmail
> m-oid: 1.3.6.1.4.1.13769.2.3
> m-singlevalue: TRUE
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.7
>
> dn: m-oid=1.3.6.1.4.1.13769.3.2,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: caseIgnoreMatch
> m-name: mozillaHomeStreet2
> m-oid: 1.3.6.1.4.1.13769.3.2
> m-singlevalue: TRUE
> m-substr: caseIgnoreSubstringsMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
>
> dn: m-oid=1.3.6.1.4.1.13769.4.4,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: caseIgnoreMatch
> m-name: mozillaCustom4
> m-oid: 1.3.6.1.4.1.13769.4.4
> m-singlevalue: TRUE
> m-substr: caseIgnoreSubstringsMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
>
> dn: m-oid=1.3.6.1.4.1.13769.3.3,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-name: mozillaHomeLocalityName
> m-oid: 1.3.6.1.4.1.13769.3.3
> m-singlevalue: TRUE
> m-supattributetype: name
>
> dn: m-oid=1.3.6.1.4.1.13769.4.3,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: caseIgnoreMatch
> m-name: mozillaCustom3
> m-oid: 1.3.6.1.4.1.13769.4.3
> m-singlevalue: TRUE
> m-substr: caseIgnoreSubstringsMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
>
> dn: m-oid=1.3.6.1.4.1.13769.3.5,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: caseIgnoreMatch
> m-name: mozillaHomePostalCode
> m-oid: 1.3.6.1.4.1.13769.3.5
> m-singlevalue: TRUE
> m-substr: caseIgnoreSubstringsMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
>
> dn: m-oid=1.3.6.1.4.1.13769.4.1,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: caseIgnoreMatch
> m-name: mozillaCustom1
> m-oid: 1.3.6.1.4.1.13769.4.1
> m-singlevalue: TRUE
> m-substr: caseIgnoreSubstringsMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
>
> dn: m-oid=1.3.6.1.4.1.13769.3.6,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-name: mozillaHomeCountryName
> m-oid: 1.3.6.1.4.1.13769.3.6
> m-singlevalue: TRUE
> m-supattributetype: name
>
> dn: m-oid=1.3.6.1.4.1.13769.3.9,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: caseIgnoreMatch
> m-name: mozillaWorkUrl
> m-oid: 1.3.6.1.4.1.13769.3.9
> m-singlevalue: TRUE
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
>
> dn: m-oid=1.3.6.1.4.1.13769.2.2,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: caseIgnoreIA5Match
> m-name: mozillaSecondEmail
> m-name: xmozillasecondemail
> m-oid: 1.3.6.1.4.1.13769.2.2
> m-singlevalue: TRUE
> m-substr: caseIgnoreIA5SubstringsMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.26
>
> dn: m-oid=1.3.6.1.4.1.13769.3.1,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: caseIgnoreMatch
> m-name: mozillaHomeStreet
> m-oid: 1.3.6.1.4.1.13769.3.1
> m-singlevalue: TRUE
> m-substr: caseIgnoreSubstringsMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
>
> dn: m-oid=1.3.6.1.4.1.13769.2.4,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: telephoneNumberMatch
> m-name: nsAIMid
> m-name: nscpaimscreenname
> m-oid: 1.3.6.1.4.1.13769.2.4
> m-substr: telephoneNumberSubstringsMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.50
>
> dn: m-oid=1.3.6.1.4.1.13769.4.2,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: caseIgnoreMatch
> m-name: mozillaCustom2
> m-oid: 1.3.6.1.4.1.13769.4.2
> m-singlevalue: TRUE
> m-substr: caseIgnoreSubstringsMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
>
> dn: ou=comparators,cn=moz,ou=schema
> objectClass: organizationalUnit
> objectClass: top
> ou: comparators
>
> dn: ou=ditContentRules,cn=moz,ou=schema
> objectClass: organizationalUnit
> objectClass: top
> ou: ditContentRules
>
> dn: ou=ditStructureRules,cn=moz,ou=schema
> objectClass: organizationalUnit
> objectClass: top
> ou: ditStructureRules
>
> dn: ou=matchingRules,cn=moz,ou=schema
> objectClass: organizationalUnit
> objectClass: top
> ou: matchingRules
>
> dn: ou=matchingRuleUse,cn=moz,ou=schema
> objectClass: organizationalUnit
> objectClass: top
> ou: matchingRuleUse
>
> dn: ou=nameForms,cn=moz,ou=schema
> objectClass: organizationalUnit
> objectClass: top
> ou: nameForms
>
> dn: ou=normalizers,cn=moz,ou=schema
> objectClass: organizationalUnit
> objectClass: top
> ou: normalizers
>
> dn: ou=objectClasses,cn=moz,ou=schema
> objectClass: organizationalUnit
> objectClass: top
> ou: objectClasses
>
> dn: m-oid=1.3.6.1.4.1.13769.9.1,ou=objectClasses,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaObjectclass
> objectClass: top
> m-may: c
> m-may: description
> m-may: displayName
> m-may: fax
> m-may: givenName
> m-may: homePhone
> m-may: l
> m-may: mail
> m-may: mobile
> m-may: mozillaCustom1
> m-may: mozillaCustom2
> m-may: mozillaCustom3
> m-may: mozillaCustom4
> m-may: mozillaHomeCountryName
> m-may: mozillaHomeLocalityName
> m-may: mozillaHomePostalCode
> m-may: mozillaHomeState
> m-may: mozillaHomeStreet
> m-may: mozillaHomeStreet2
> m-may: mozillaHomeUrl
> m-may: mozillaNickname
> m-may: mozillaSecondEmail
> m-may: mozillaUseHtmlMail
> m-may: mozillaWorkStreet2
> m-may: mozillaWorkUrl
> m-may: nsAIMid
> m-may: o
> m-may: ou
> m-may: pager
> m-may: postalCode
> m-may: postOfficeBox
> m-may: sn
> m-may: st
> m-may: street
> m-may: telephoneNumber
> m-may: title
> m-must: cn
> m-name: mozillaAbPersonAlpha
> m-oid: 1.3.6.1.4.1.13769.9.1
> m-supobjectclass: top
> m-typeobjectclass: AUXILIARY
>
> dn: ou=syntaxCheckers,cn=moz,ou=schema
> objectClass: organizationalUnit
> objectClass: top
> ou: syntaxCheckers
>
> dn: ou=syntaxes,cn=moz,ou=schema
> objectClass: organizationalUnit
> objectClass: top
> ou: syntaxes
>
>
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Emmanuel Lecharny <el...@gmail.com>.
Guys, don't loose time trying to fix LS, it's deep inside ADS that we have a
pb. Pam and me have found the cause, now we are trying to fix it.
The short story is that we don't have a OidLen syntaxChecker associated with
m-syntax.
Work in progress :)
On 4/24/07, Stefan Seelmann <ma...@stefan-seelmann.de> wrote:
>
> Hi Damien,
>
> Damien Tougas schrieb:
> >
> > No matter what I have tried, I have not been able to get LDAP Studio to
> > recognize the new schema. I have tried re-connecting to ApacheDS,
> > stopping/restarting the ApacheDS server, etc. LDAP Studio does not want
> > to recognize the schema.
> >
> > I then tested using LDAP Explorer. LDAP Explorer allowed me to see the
> > new schema elements and use them (the interface is really bad though!).
> > It looks like this is probably a problem with LDAP Studio, and not
> > ApacheDS.
> >
>
> Could you please try the following? Please open the schema browser
> (right-click to the connection, then select 'Open Schema Browser'). In
> the schema browser please press the 'Refresh' button. This forces LDAP
> Studio to reload the schema from the server.
>
> If this doesn't help you could try to delete the connection and create
> it again.
>
> LDAP Studio caches the schema and reloads it only if the schema has
> changes, this is done my comparing the modifyTimestamp of the schema.
> Perhaps there is problem with that, I will investigate on that.
>
> Best Regards,
> Stefan Seelmann
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Alex Karasulu <ak...@apache.org>.
Hi Stefan,
On 4/25/07, Stefan Seelmann <ma...@stefan-seelmann.de> wrote:
>
> Hi Alex,
>
> Alex Karasulu schrieb:
> > Hi Stefan,
> >
> > I specifically had worked a JIRA issue to make sure the modify timestamp
> on
> > the
> > schema subentry at cn=schema was modified when there were any changes to
> > schema entries made via cn=schema modifs or changes made directly on
> schema
> > entries under ou=schema. However I may have botched this. I'm very
> > interested
> > in finding out if the timestamp update is failing.
> >
> > Alex
> >
>
> The good news: timestamp update works fine.
Oh coolio!
However I found the reason why LS fails to detect if the schema was
> modified. When connecting to the directory LS requests the attributes
> modifyTimestamp and createTimestamp by its names from the server, but
> they aren't returned:
> --------------------------------------------------------------
> $ ldapsearch -x -h localhost -p 10389 -D "uid=admin,ou=system" -w
> "secret" -s base -b "cn=schema" "(objectClass=subschema)" modifyTimestamp
>
> # schema
> dn: 2.5.4.3=schema
> --------------------------------------------------------------
>
>
> However when requesting *all* operational attributes the timestamps are
> returned:
> --------------------------------------------------------------
> ldapsearch -x -h localhost -p 10389 -D "uid=admin,ou=system" -w "secret"
> -s base -b "cn=schema" "(objectClass=subschema)" "+" | grep
> "modifyTimestamp:"
>
> modifyTimestamp: 20070425172817Z
> --------------------------------------------------------------
>
>
> I verified that with both 1.5.0 and the current trunk. Should I file a
> Jira?
>
>
> But also LS executes on invalid search resquest. RFC4512 specifies that
> the client must use the search filter "(objectClass=subschema)", LS
> sends "(objectClass=*)". It isn't a big deal to change that.
Hmm this is a tough one. Really (objectClass=*) is a relaxed form of the
(objectClass=subschema) so why should it not return (I know I coded it to
return only when you ask for subschema). I wonder if the RFC allows for the
* version?
Unfortunately I'm taking care of some last minute errands today but I will
investigate this later. Perhaps a JIRA is in order just so we can come to a
conclusion on this and change either LS or ApacheDS to suite the proper
behavoir.
Thanks for the investigation,
Alex
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
Hi Alex,
Alex Karasulu schrieb:
> Hi Stefan,
>
> I specifically had worked a JIRA issue to make sure the modify timestamp on
> the
> schema subentry at cn=schema was modified when there were any changes to
> schema entries made via cn=schema modifs or changes made directly on schema
> entries under ou=schema. However I may have botched this. I'm very
> interested
> in finding out if the timestamp update is failing.
>
> Alex
>
The good news: timestamp update works fine.
However I found the reason why LS fails to detect if the schema was
modified. When connecting to the directory LS requests the attributes
modifyTimestamp and createTimestamp by its names from the server, but
they aren't returned:
--------------------------------------------------------------
$ ldapsearch -x -h localhost -p 10389 -D "uid=admin,ou=system" -w
"secret" -s base -b "cn=schema" "(objectClass=subschema)" modifyTimestamp
# schema
dn: 2.5.4.3=schema
--------------------------------------------------------------
However when requesting *all* operational attributes the timestamps are
returned:
--------------------------------------------------------------
ldapsearch -x -h localhost -p 10389 -D "uid=admin,ou=system" -w "secret"
-s base -b "cn=schema" "(objectClass=subschema)" "+" | grep
"modifyTimestamp:"
modifyTimestamp: 20070425172817Z
--------------------------------------------------------------
I verified that with both 1.5.0 and the current trunk. Should I file a Jira?
But also LS executes on invalid search resquest. RFC4512 specifies that
the client must use the search filter "(objectClass=subschema)", LS
sends "(objectClass=*)". It isn't a big deal to change that.
Regards,
Stefan Seelmann
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Alex Karasulu <ak...@apache.org>.
Hi Stefan,
I specifically had worked a JIRA issue to make sure the modify timestamp on
the
schema subentry at cn=schema was modified when there were any changes to
schema entries made via cn=schema modifs or changes made directly on schema
entries under ou=schema. However I may have botched this. I'm very
interested
in finding out if the timestamp update is failing.
Alex
On 4/24/07, Stefan Seelmann <ma...@stefan-seelmann.de> wrote:
>
> Hi Damien,
>
> Damien Tougas schrieb:
> >
> > No matter what I have tried, I have not been able to get LDAP Studio to
> > recognize the new schema. I have tried re-connecting to ApacheDS,
> > stopping/restarting the ApacheDS server, etc. LDAP Studio does not want
> > to recognize the schema.
> >
> > I then tested using LDAP Explorer. LDAP Explorer allowed me to see the
> > new schema elements and use them (the interface is really bad though!).
> > It looks like this is probably a problem with LDAP Studio, and not
> > ApacheDS.
> >
>
> Could you please try the following? Please open the schema browser
> (right-click to the connection, then select 'Open Schema Browser'). In
> the schema browser please press the 'Refresh' button. This forces LDAP
> Studio to reload the schema from the server.
>
> If this doesn't help you could try to delete the connection and create
> it again.
>
> LDAP Studio caches the schema and reloads it only if the schema has
> changes, this is done my comparing the modifyTimestamp of the schema.
> Perhaps there is problem with that, I will investigate on that.
>
> Best Regards,
> Stefan Seelmann
>
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Damien Tougas <da...@tougas.net>.
You guys have all been a great help, thanks! Keep up the good work on
this software!
Emmanuel Lecharny wrote:
> Hi Damien,
>
> i'm happy that you finally made it !
>
> FYI, I think we have a solution for the {128} at the end of syntaxes. As
> suggested by Alex, I modifed the metaSchema to add a m-length attribute,
> and
> we are done !
>
> I will commit the code soon, but I have to add some check in the
> schemaService to be sure that the value is correctly handled by the server
> (I mean, that user will be rebufed if they try ton inject data longer than
> the maximuml allowed :)
>
> Emmanuel
--
Damien Tougas
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Damien,
i'm happy that you finally made it !
FYI, I think we have a solution for the {128} at the end of syntaxes. As
suggested by Alex, I modifed the metaSchema to add a m-length attribute, and
we are done !
I will commit the code soon, but I have to add some check in the
schemaService to be sure that the value is correctly handled by the server
(I mean, that user will be rebufed if they try ton inject data longer than
the maximuml allowed :)
Emmanuel
On 4/24/07, Damien Tougas <da...@tougas.net> wrote:
>
> Hello Stefan,
>
> Stefan Seelmann wrote:
>
> > Could you please try the following? Please open the schema browser
> > (right-click to the connection, then select 'Open Schema Browser'). In
> > the schema browser please press the 'Refresh' button. This forces LDAP
> > Studio to reload the schema from the server.
> >
> > If this doesn't help you could try to delete the connection and create
> > it again.
> >
> > LDAP Studio caches the schema and reloads it only if the schema has
> > changes, this is done my comparing the modifyTimestamp of the schema.
> > Perhaps there is problem with that, I will investigate on that.
>
> Boy, I feel kind of dumb now... I wasn't aware of the 'Open Schema
> Browser' option, nor was I aware of the 'Refresh' button. When I did
> that, the new schema became available.
>
> Thanks for your help, and sorry about missing something that should have
> been obvious...
>
> --
> Damien Tougas
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Damien Tougas <da...@tougas.net>.
Hello Stefan,
Stefan Seelmann wrote:
> Could you please try the following? Please open the schema browser
> (right-click to the connection, then select 'Open Schema Browser'). In
> the schema browser please press the 'Refresh' button. This forces LDAP
> Studio to reload the schema from the server.
>
> If this doesn't help you could try to delete the connection and create
> it again.
>
> LDAP Studio caches the schema and reloads it only if the schema has
> changes, this is done my comparing the modifyTimestamp of the schema.
> Perhaps there is problem with that, I will investigate on that.
Boy, I feel kind of dumb now... I wasn't aware of the 'Open Schema
Browser' option, nor was I aware of the 'Refresh' button. When I did
that, the new schema became available.
Thanks for your help, and sorry about missing something that should have
been obvious...
--
Damien Tougas
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
Hi Damien,
Damien Tougas schrieb:
>
> No matter what I have tried, I have not been able to get LDAP Studio to
> recognize the new schema. I have tried re-connecting to ApacheDS,
> stopping/restarting the ApacheDS server, etc. LDAP Studio does not want
> to recognize the schema.
>
> I then tested using LDAP Explorer. LDAP Explorer allowed me to see the
> new schema elements and use them (the interface is really bad though!).
> It looks like this is probably a problem with LDAP Studio, and not
> ApacheDS.
>
Could you please try the following? Please open the schema browser
(right-click to the connection, then select 'Open Schema Browser'). In
the schema browser please press the 'Refresh' button. This forces LDAP
Studio to reload the schema from the server.
If this doesn't help you could try to delete the connection and create
it again.
LDAP Studio caches the schema and reloads it only if the schema has
changes, this is done my comparing the modifyTimestamp of the schema.
Perhaps there is problem with that, I will investigate on that.
Best Regards,
Stefan Seelmann
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Damien Tougas <da...@tougas.net>.
Hello Stefan,
I have done a little more testing myself...
Stefan Zoerner wrote:
> I have tested the steps in LDAP Studio 0.7 like this:
>
> 1. Load the LDIF provided with my mail (TRUE instead of true) to a fresh
> ApacheDS 1.5.1 SNAPSHOT instance
I stared out by doing the same thing, loading the LDIF with the TRUE values.
> Please not that LDAP Studio does not know the new Schema elements yet,
> because it already has loaded the schema, and does not seem to reload it
> automatically after an LDIF import.
> This is not an error from my point of view (in almost all cases, an LDIF
> will provide normal entry and no schema elements).
> The problem occurs with other tools, Softerra LDAP Administrator for
> instance -- you have to enforce schema reloading.
>
> One option to solve this is to close the connection to ApacheDS and
> afterwards reconnect.
No matter what I have tried, I have not been able to get LDAP Studio to
recognize the new schema. I have tried re-connecting to ApacheDS,
stopping/restarting the ApacheDS server, etc. LDAP Studio does not want
to recognize the schema.
I then tested using LDAP Explorer. LDAP Explorer allowed me to see the
new schema elements and use them (the interface is really bad though!).
It looks like this is probably a problem with LDAP Studio, and not ApacheDS.
Thank you very much for your help.
--
Damien Tougas
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Stefan Zoerner <st...@labeo.de>.
Hi Damien!
Damien Tougas wrote:
> I was able to load your attache LDIF but I am still not able to use it
> with LDAP Studio. The mozillaAbPersonAlpha object class still does not
> show up in the list of available types when I try to add a new entry.
> Perhaps I am encountering a bug with LDAP Studio? How are you using it?
I have tested the steps in LDAP Studio 0.7 like this:
1. Load the LDIF provided with my mail (TRUE instead of true) to a fresh
ApacheDS 1.5.1 SNAPSHOT instance
Please not that LDAP Studio does not know the new Schema elements yet,
because it already has loaded the schema, and does not seem to reload it
automatically after an LDIF import.
This is not an error from my point of view (in almost all cases, an LDIF
will provide normal entry and no schema elements).
The problem occurs with other tools, Softerra LDAP Administrator for
instance -- you have to enforce schema reloading.
One option to solve this is to close the connection to ApacheDS and
afterwards reconnect.
2. Create a new entry below dc=example,dc=com. Here is the modification log
#!RESULT OK
#!CONNECTION ldap://zanzibar:10389
#!DATE 2007-04-24T11:05:58.734
dn: cn=Tori Amos,dc=example,dc=com
changetype: add
objectClass: person
objectClass: top
objectClass: mozillaAbPersonAlpha
cn: Tori Amos
Note that you can't use mozillaAbPersonAlpha alone, because it is only a
auxiliary class.
I hope this helps.
Greetings from Wiesbaden,
Stefan Zoerner (szoerner)
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Damien Tougas <da...@tougas.net>.
Hello Stefan,
I was able to load your attache LDIF but I am still not able to use it
with LDAP Studio. The mozillaAbPersonAlpha object class still does not
show up in the list of available types when I try to add a new entry.
Perhaps I am encountering a bug with LDAP Studio? How are you using it?
Stefan Zoerner wrote:
> Hi!
>
> Here is an addition to my last mail. I changed all "true" to "TRUE" in
> Damien's LDIF, was able to load it (via command line tool ldapmodify)
> and use it.
>
> Find a changed version of the LDIF file attached.
> Greetings,
> Stefan Zoerner (szoerner)
--
Damien Tougas
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Yeah, I prefer this solution too.
The LDIF is generated by the shared-converter library, I'll add a Jira for
this, fix it and integrate a new version of the library in LS.
P-A
On 4/24/07, Stefan Zoerner <st...@labeo.de> wrote:
>
> Emmanuel Lecharny wrote:
> > excerpt form RFC 2252 :
> >
> > ...( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
> >
> > Values in this syntax are encoded according to the following BNF:
> >
> > boolean = "TRUE" / "FALSE" ...
> >
> > May be we can relax this upercase constraint (this is a minor code
> > modification).
> >
> > wdyt ?
>
> The error occurs because of the LDAP Studio generated LDIF. I would
> therefore prefer to change LS in order to generate "TRUE" instead of
> "true". Better implements the syntaxes according to the RFC.
>
> Greetings from Wiesbaden,
> Stefan Zoerner (szoerner)
>
>
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Stefan Zoerner <st...@labeo.de>.
Emmanuel Lecharny wrote:
> excerpt form RFC 2252 :
>
> ...( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
>
> Values in this syntax are encoded according to the following BNF:
>
> boolean = "TRUE" / "FALSE" ...
>
> May be we can relax this upercase constraint (this is a minor code
> modification).
>
> wdyt ?
The error occurs because of the LDAP Studio generated LDIF. I would
therefore prefer to change LS in order to generate "TRUE" instead of
"true". Better implements the syntaxes according to the RFC.
Greetings from Wiesbaden,
Stefan Zoerner (szoerner)
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi,
excerpt form RFC 2252 :
...( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
Values in this syntax are encoded according to the following BNF:
boolean = "TRUE" / "FALSE" ...
May be we can relax this upercase constraint (this is a minor code
modification).
wdyt ?
On 4/23/07, Stefan Zoerner <st...@labeo.de> wrote:
>
> Hi!
>
> Here is an addition to my last mail. I changed all "true" to "TRUE" in
> Damien's LDIF, was able to load it (via command line tool ldapmodify)
> and use it.
>
> Find a changed version of the LDIF file attached.
> Greetings,
> Stefan Zoerner (szoerner)
>
>
>
>
> dn: cn=moz,ou=schema
> objectClass: metaSchema
> objectClass: top
> cn: moz
>
> dn: ou=attributeTypes,cn=moz,ou=schema
> objectClass: organizationalUnit
> objectClass: top
> ou: attributeTypes
>
> dn: m-oid=1.3.6.1.4.1.13769.3.7,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: caseIgnoreMatch
> m-name: mozillaHomeUrl
> m-oid: 1.3.6.1.4.1.13769.3.7
> m-singlevalue: TRUE
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
>
> dn: m-oid=1.3.6.1.4.1.13769.2.1,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-name: mozillaNickname
> m-name: xmozillanickname
> m-oid: 1.3.6.1.4.1.13769.2.1
> m-supattributetype: name
>
> dn: m-oid=1.3.6.1.4.1.13769.3.4,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-name: mozillaHomeState
> m-oid: 1.3.6.1.4.1.13769.3.4
> m-singlevalue: TRUE
> m-supattributetype: name
>
> dn: m-oid=1.3.6.1.4.1.13769.3.8,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: caseIgnoreMatch
> m-name: mozillaWorkStreet2
> m-oid: 1.3.6.1.4.1.13769.3.8
> m-singlevalue: TRUE
> m-substr: caseIgnoreSubstringsMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
>
> dn: m-oid=1.3.6.1.4.1.13769.2.3,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-name: mozillaUseHtmlMail
> m-name: xmozillausehtmlmail
> m-oid: 1.3.6.1.4.1.13769.2.3
> m-singlevalue: TRUE
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.7
>
> dn: m-oid=1.3.6.1.4.1.13769.3.2,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: caseIgnoreMatch
> m-name: mozillaHomeStreet2
> m-oid: 1.3.6.1.4.1.13769.3.2
> m-singlevalue: TRUE
> m-substr: caseIgnoreSubstringsMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
>
> dn: m-oid=1.3.6.1.4.1.13769.4.4,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: caseIgnoreMatch
> m-name: mozillaCustom4
> m-oid: 1.3.6.1.4.1.13769.4.4
> m-singlevalue: TRUE
> m-substr: caseIgnoreSubstringsMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
>
> dn: m-oid=1.3.6.1.4.1.13769.3.3,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-name: mozillaHomeLocalityName
> m-oid: 1.3.6.1.4.1.13769.3.3
> m-singlevalue: TRUE
> m-supattributetype: name
>
> dn: m-oid=1.3.6.1.4.1.13769.4.3,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: caseIgnoreMatch
> m-name: mozillaCustom3
> m-oid: 1.3.6.1.4.1.13769.4.3
> m-singlevalue: TRUE
> m-substr: caseIgnoreSubstringsMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
>
> dn: m-oid=1.3.6.1.4.1.13769.3.5,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: caseIgnoreMatch
> m-name: mozillaHomePostalCode
> m-oid: 1.3.6.1.4.1.13769.3.5
> m-singlevalue: TRUE
> m-substr: caseIgnoreSubstringsMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
>
> dn: m-oid=1.3.6.1.4.1.13769.4.1,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: caseIgnoreMatch
> m-name: mozillaCustom1
> m-oid: 1.3.6.1.4.1.13769.4.1
> m-singlevalue: TRUE
> m-substr: caseIgnoreSubstringsMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
>
> dn: m-oid=1.3.6.1.4.1.13769.3.6,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-name: mozillaHomeCountryName
> m-oid: 1.3.6.1.4.1.13769.3.6
> m-singlevalue: TRUE
> m-supattributetype: name
>
> dn: m-oid=1.3.6.1.4.1.13769.3.9,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: caseIgnoreMatch
> m-name: mozillaWorkUrl
> m-oid: 1.3.6.1.4.1.13769.3.9
> m-singlevalue: TRUE
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
>
> dn: m-oid=1.3.6.1.4.1.13769.2.2,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: caseIgnoreIA5Match
> m-name: mozillaSecondEmail
> m-name: xmozillasecondemail
> m-oid: 1.3.6.1.4.1.13769.2.2
> m-singlevalue: TRUE
> m-substr: caseIgnoreIA5SubstringsMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.26
>
> dn: m-oid=1.3.6.1.4.1.13769.3.1,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: caseIgnoreMatch
> m-name: mozillaHomeStreet
> m-oid: 1.3.6.1.4.1.13769.3.1
> m-singlevalue: TRUE
> m-substr: caseIgnoreSubstringsMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
>
> dn: m-oid=1.3.6.1.4.1.13769.2.4,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: telephoneNumberMatch
> m-name: nsAIMid
> m-name: nscpaimscreenname
> m-oid: 1.3.6.1.4.1.13769.2.4
> m-substr: telephoneNumberSubstringsMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.50
>
> dn: m-oid=1.3.6.1.4.1.13769.4.2,ou=attributeTypes,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaAttributeType
> objectClass: top
> m-equality: caseIgnoreMatch
> m-name: mozillaCustom2
> m-oid: 1.3.6.1.4.1.13769.4.2
> m-singlevalue: TRUE
> m-substr: caseIgnoreSubstringsMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
>
> dn: ou=comparators,cn=moz,ou=schema
> objectClass: organizationalUnit
> objectClass: top
> ou: comparators
>
> dn: ou=ditContentRules,cn=moz,ou=schema
> objectClass: organizationalUnit
> objectClass: top
> ou: ditContentRules
>
> dn: ou=ditStructureRules,cn=moz,ou=schema
> objectClass: organizationalUnit
> objectClass: top
> ou: ditStructureRules
>
> dn: ou=matchingRules,cn=moz,ou=schema
> objectClass: organizationalUnit
> objectClass: top
> ou: matchingRules
>
> dn: ou=matchingRuleUse,cn=moz,ou=schema
> objectClass: organizationalUnit
> objectClass: top
> ou: matchingRuleUse
>
> dn: ou=nameForms,cn=moz,ou=schema
> objectClass: organizationalUnit
> objectClass: top
> ou: nameForms
>
> dn: ou=normalizers,cn=moz,ou=schema
> objectClass: organizationalUnit
> objectClass: top
> ou: normalizers
>
> dn: ou=objectClasses,cn=moz,ou=schema
> objectClass: organizationalUnit
> objectClass: top
> ou: objectClasses
>
> dn: m-oid=1.3.6.1.4.1.13769.9.1,ou=objectClasses,cn=moz,ou=schema
> objectClass: metaTop
> objectClass: metaObjectclass
> objectClass: top
> m-may: c
> m-may: description
> m-may: displayName
> m-may: fax
> m-may: givenName
> m-may: homePhone
> m-may: l
> m-may: mail
> m-may: mobile
> m-may: mozillaCustom1
> m-may: mozillaCustom2
> m-may: mozillaCustom3
> m-may: mozillaCustom4
> m-may: mozillaHomeCountryName
> m-may: mozillaHomeLocalityName
> m-may: mozillaHomePostalCode
> m-may: mozillaHomeState
> m-may: mozillaHomeStreet
> m-may: mozillaHomeStreet2
> m-may: mozillaHomeUrl
> m-may: mozillaNickname
> m-may: mozillaSecondEmail
> m-may: mozillaUseHtmlMail
> m-may: mozillaWorkStreet2
> m-may: mozillaWorkUrl
> m-may: nsAIMid
> m-may: o
> m-may: ou
> m-may: pager
> m-may: postalCode
> m-may: postOfficeBox
> m-may: sn
> m-may: st
> m-may: street
> m-may: telephoneNumber
> m-may: title
> m-must: cn
> m-name: mozillaAbPersonAlpha
> m-oid: 1.3.6.1.4.1.13769.9.1
> m-supobjectclass: top
> m-typeobjectclass: AUXILIARY
>
> dn: ou=syntaxCheckers,cn=moz,ou=schema
> objectClass: organizationalUnit
> objectClass: top
> ou: syntaxCheckers
>
> dn: ou=syntaxes,cn=moz,ou=schema
> objectClass: organizationalUnit
> objectClass: top
> ou: syntaxes
>
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Stefan Zoerner <st...@labeo.de>.
Hi!
Here is an addition to my last mail. I changed all "true" to "TRUE" in
Damien's LDIF, was able to load it (via command line tool ldapmodify)
and use it.
Find a changed version of the LDIF file attached.
Greetings,
Stefan Zoerner (szoerner)
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Damien Tougas <da...@tougas.net>.
Hello Alex,
Alex Karasulu wrote:
>> I am in the process of checking out the directory server for the first
>> time. I am by no means an LDAP expert, but so far I like what I am
>> seeing here. My end goal for this testing is to create a shared address
>> book using the mozillaAbPersonAlpha schema:
>>
>> http://wiki.mozilla.org/MailNews:Mozilla_LDAP_Address_Book_Schema
>>
>> I was able to open the schema in LDAP Studio and export it to an LDIF.
>> The first problem I encountered was that the exported LDIF had a typo
>> which caused the import to fail. The typo was in this section (note the
>> spelling of "matchingRules" in the dn):
>>
>> dn: ou=macthingRules, cn=moz, ou=schema
>> objectclass: organizationalUnit
>> objectclass: top
>> ou: matchingrules
>>
>> Once that was fixed, the import worked without any errors.
>
>
> Ahhh ok I think this can be fixed easily in LdapStudio or one of the shared
> libraries it depends on which probably is responsible for this typo. Could
> you file a JIRA issue for it
> here:
>
> https://issues.apache.org/jira/browse/DIRSTUDIO
Done!
> The next problem I encountered was the fact that the directory server
>> didn't know what to do with the syntax lengths. This problem did not
>> show up when I did the import, but it caused exceptions to get thrown
>> when re-starting the directory server.
>
>
> This is not good. Perhaps you can file a JIRA issue about this. I think
> this may be a bug in the schema subsystem but we need to figure it out.
> Could you attach the LDIF file to the JIRA as an 'attachment'? You can
> file
> the JIRA issue for it here:
>
> https://issues.apache.org/jira/browse/DIRSERVER
Done!
> I need to narrow down what is causing this: whether it is due to LS or
> ApacheDS. I think it's ApacheDS. Perhaps the schema has not been enabled
> for some reason. Do me a favor and connect to the server and look at the
> cn=moz,ou=schema entry. Perhaps you can post it's attributes/LDIF here.
> But just checking if an m-disabled attribute is present on the entry may
> suffice. If this m-disabled attribute is set to TRUE just modify the entry
> so it is set to FALSE or remove the m-disabled attribute altogether.
I exported the entire schema as an LDIF for you to look at, see it below.
> I think by default newly added schema are disabled.
I thought about that, but I didn't see any m-disabled attribute set when
I did the import. For fun, I tried adding it and setting it to TRUE, but
that didn't seem to make any difference either way.
Here is the export of my schema:
dn: cn=moz,ou=schema
objectClass: metaSchema
objectClass: top
cn: moz
dn: ou=attributeTypes,cn=moz,ou=schema
objectClass: organizationalUnit
objectClass: top
ou: attributeTypes
dn: m-oid=1.3.6.1.4.1.13769.3.7,ou=attributeTypes,cn=moz,ou=schema
objectClass: metaTop
objectClass: metaAttributeType
objectClass: top
m-equality: caseIgnoreMatch
m-name: mozillaHomeUrl
m-oid: 1.3.6.1.4.1.13769.3.7
m-singlevalue: true
m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
dn: m-oid=1.3.6.1.4.1.13769.2.1,ou=attributeTypes,cn=moz,ou=schema
objectClass: metaTop
objectClass: metaAttributeType
objectClass: top
m-name: mozillaNickname
m-name: xmozillanickname
m-oid: 1.3.6.1.4.1.13769.2.1
m-supattributetype: name
dn: m-oid=1.3.6.1.4.1.13769.3.4,ou=attributeTypes,cn=moz,ou=schema
objectClass: metaTop
objectClass: metaAttributeType
objectClass: top
m-name: mozillaHomeState
m-oid: 1.3.6.1.4.1.13769.3.4
m-singlevalue: true
m-supattributetype: name
dn: m-oid=1.3.6.1.4.1.13769.3.8,ou=attributeTypes,cn=moz,ou=schema
objectClass: metaTop
objectClass: metaAttributeType
objectClass: top
m-equality: caseIgnoreMatch
m-name: mozillaWorkStreet2
m-oid: 1.3.6.1.4.1.13769.3.8
m-singlevalue: true
m-substr: caseIgnoreSubstringsMatch
m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
dn: m-oid=1.3.6.1.4.1.13769.2.3,ou=attributeTypes,cn=moz,ou=schema
objectClass: metaTop
objectClass: metaAttributeType
objectClass: top
m-name: mozillaUseHtmlMail
m-name: xmozillausehtmlmail
m-oid: 1.3.6.1.4.1.13769.2.3
m-singlevalue: true
m-syntax: 1.3.6.1.4.1.1466.115.121.1.7
dn: m-oid=1.3.6.1.4.1.13769.3.2,ou=attributeTypes,cn=moz,ou=schema
objectClass: metaTop
objectClass: metaAttributeType
objectClass: top
m-equality: caseIgnoreMatch
m-name: mozillaHomeStreet2
m-oid: 1.3.6.1.4.1.13769.3.2
m-singlevalue: true
m-substr: caseIgnoreSubstringsMatch
m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
dn: m-oid=1.3.6.1.4.1.13769.4.4,ou=attributeTypes,cn=moz,ou=schema
objectClass: metaTop
objectClass: metaAttributeType
objectClass: top
m-equality: caseIgnoreMatch
m-name: mozillaCustom4
m-oid: 1.3.6.1.4.1.13769.4.4
m-singlevalue: true
m-substr: caseIgnoreSubstringsMatch
m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
dn: m-oid=1.3.6.1.4.1.13769.3.3,ou=attributeTypes,cn=moz,ou=schema
objectClass: metaTop
objectClass: metaAttributeType
objectClass: top
m-name: mozillaHomeLocalityName
m-oid: 1.3.6.1.4.1.13769.3.3
m-singlevalue: true
m-supattributetype: name
dn: m-oid=1.3.6.1.4.1.13769.4.3,ou=attributeTypes,cn=moz,ou=schema
objectClass: metaTop
objectClass: metaAttributeType
objectClass: top
m-equality: caseIgnoreMatch
m-name: mozillaCustom3
m-oid: 1.3.6.1.4.1.13769.4.3
m-singlevalue: true
m-substr: caseIgnoreSubstringsMatch
m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
dn: m-oid=1.3.6.1.4.1.13769.3.5,ou=attributeTypes,cn=moz,ou=schema
objectClass: metaTop
objectClass: metaAttributeType
objectClass: top
m-equality: caseIgnoreMatch
m-name: mozillaHomePostalCode
m-oid: 1.3.6.1.4.1.13769.3.5
m-singlevalue: true
m-substr: caseIgnoreSubstringsMatch
m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
dn: m-oid=1.3.6.1.4.1.13769.4.1,ou=attributeTypes,cn=moz,ou=schema
objectClass: metaTop
objectClass: metaAttributeType
objectClass: top
m-equality: caseIgnoreMatch
m-name: mozillaCustom1
m-oid: 1.3.6.1.4.1.13769.4.1
m-singlevalue: true
m-substr: caseIgnoreSubstringsMatch
m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
dn: m-oid=1.3.6.1.4.1.13769.3.6,ou=attributeTypes,cn=moz,ou=schema
objectClass: metaTop
objectClass: metaAttributeType
objectClass: top
m-name: mozillaHomeCountryName
m-oid: 1.3.6.1.4.1.13769.3.6
m-singlevalue: true
m-supattributetype: name
dn: m-oid=1.3.6.1.4.1.13769.3.9,ou=attributeTypes,cn=moz,ou=schema
objectClass: metaTop
objectClass: metaAttributeType
objectClass: top
m-equality: caseIgnoreMatch
m-name: mozillaWorkUrl
m-oid: 1.3.6.1.4.1.13769.3.9
m-singlevalue: true
m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
dn: m-oid=1.3.6.1.4.1.13769.2.2,ou=attributeTypes,cn=moz,ou=schema
objectClass: metaTop
objectClass: metaAttributeType
objectClass: top
m-equality: caseIgnoreIA5Match
m-name: mozillaSecondEmail
m-name: xmozillasecondemail
m-oid: 1.3.6.1.4.1.13769.2.2
m-singlevalue: true
m-substr: caseIgnoreIA5SubstringsMatch
m-syntax: 1.3.6.1.4.1.1466.115.121.1.26
dn: m-oid=1.3.6.1.4.1.13769.3.1,ou=attributeTypes,cn=moz,ou=schema
objectClass: metaTop
objectClass: metaAttributeType
objectClass: top
m-equality: caseIgnoreMatch
m-name: mozillaHomeStreet
m-oid: 1.3.6.1.4.1.13769.3.1
m-singlevalue: true
m-substr: caseIgnoreSubstringsMatch
m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
dn: m-oid=1.3.6.1.4.1.13769.2.4,ou=attributeTypes,cn=moz,ou=schema
objectClass: metaTop
objectClass: metaAttributeType
objectClass: top
m-equality: telephoneNumberMatch
m-name: nsAIMid
m-name: nscpaimscreenname
m-oid: 1.3.6.1.4.1.13769.2.4
m-substr: telephoneNumberSubstringsMatch
m-syntax: 1.3.6.1.4.1.1466.115.121.1.50
dn: m-oid=1.3.6.1.4.1.13769.4.2,ou=attributeTypes,cn=moz,ou=schema
objectClass: metaTop
objectClass: metaAttributeType
objectClass: top
m-equality: caseIgnoreMatch
m-name: mozillaCustom2
m-oid: 1.3.6.1.4.1.13769.4.2
m-singlevalue: true
m-substr: caseIgnoreSubstringsMatch
m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
dn: ou=comparators,cn=moz,ou=schema
objectClass: organizationalUnit
objectClass: top
ou: comparators
dn: ou=ditContentRules,cn=moz,ou=schema
objectClass: organizationalUnit
objectClass: top
ou: ditContentRules
dn: ou=ditStructureRules,cn=moz,ou=schema
objectClass: organizationalUnit
objectClass: top
ou: ditStructureRules
dn: ou=matchingRules,cn=moz,ou=schema
objectClass: organizationalUnit
objectClass: top
ou: matchingRules
dn: ou=matchingRuleUse,cn=moz,ou=schema
objectClass: organizationalUnit
objectClass: top
ou: matchingRuleUse
dn: ou=nameForms,cn=moz,ou=schema
objectClass: organizationalUnit
objectClass: top
ou: nameForms
dn: ou=normalizers,cn=moz,ou=schema
objectClass: organizationalUnit
objectClass: top
ou: normalizers
dn: ou=objectClasses,cn=moz,ou=schema
objectClass: organizationalUnit
objectClass: top
ou: objectClasses
dn: m-oid=1.3.6.1.4.1.13769.9.1,ou=objectClasses,cn=moz,ou=schema
objectClass: metaTop
objectClass: metaObjectclass
objectClass: top
m-may: c
m-may: description
m-may: displayName
m-may: fax
m-may: givenName
m-may: homePhone
m-may: l
m-may: mail
m-may: mobile
m-may: mozillaCustom1
m-may: mozillaCustom2
m-may: mozillaCustom3
m-may: mozillaCustom4
m-may: mozillaHomeCountryName
m-may: mozillaHomeLocalityName
m-may: mozillaHomePostalCode
m-may: mozillaHomeState
m-may: mozillaHomeStreet
m-may: mozillaHomeStreet2
m-may: mozillaHomeUrl
m-may: mozillaNickname
m-may: mozillaSecondEmail
m-may: mozillaUseHtmlMail
m-may: mozillaWorkStreet2
m-may: mozillaWorkUrl
m-may: nsAIMid
m-may: o
m-may: ou
m-may: pager
m-may: postalCode
m-may: postOfficeBox
m-may: sn
m-may: st
m-may: street
m-may: telephoneNumber
m-may: title
m-must: cn
m-name: mozillaAbPersonAlpha
m-oid: 1.3.6.1.4.1.13769.9.1
m-supobjectclass: top
m-typeobjectclass: AUXILIARY
dn: ou=syntaxCheckers,cn=moz,ou=schema
objectClass: organizationalUnit
objectClass: top
ou: syntaxCheckers
dn: ou=syntaxes,cn=moz,ou=schema
objectClass: organizationalUnit
objectClass: top
ou: syntaxes
Thanks for your help!
--
Damien Tougas
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Alex Karasulu <ak...@apache.org>.
Damien,
On 4/22/07, Damien Tougas <da...@tougas.net> wrote:
>
> Hello,
>
> I am in the process of checking out the directory server for the first
> time. I am by no means an LDAP expert, but so far I like what I am
> seeing here. My end goal for this testing is to create a shared address
> book using the mozillaAbPersonAlpha schema:
>
> http://wiki.mozilla.org/MailNews:Mozilla_LDAP_Address_Book_Schema
>
> I was able to open the schema in LDAP Studio and export it to an LDIF.
> The first problem I encountered was that the exported LDIF had a typo
> which caused the import to fail. The typo was in this section (note the
> spelling of "matchingRules" in the dn):
>
> dn: ou=macthingRules, cn=moz, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: matchingrules
>
> Once that was fixed, the import worked without any errors.
Ahhh ok I think this can be fixed easily in LdapStudio or one of the shared
libraries it depends on which probably is responsible for this typo. Could
you file a JIRA issue for it
here:
https://issues.apache.org/jira/browse/DIRSTUDIO
The next problem I encountered was the fact that the directory server
> didn't know what to do with the syntax lengths. This problem did not
> show up when I did the import, but it caused exceptions to get thrown
> when re-starting the directory server.
This is not good. Perhaps you can file a JIRA issue about this. I think
this may be a bug in the schema subsystem but we need to figure it out.
Could you attach the LDIF file to the JIRA as an 'attachment'? You can file
the JIRA issue for it here:
https://issues.apache.org/jira/browse/DIRSERVER
To deal with that problem I simply removed the syntax length definitions
> from the exported LDIF (i.e. removed {128} etc.) and did the import
> again (I first had to delete the schemas partition directory in order to
> be able to do this, I am not sure if there is a better way...).
Yeah this should have worked hence why I think it's a bug in the schema
subsystem.
After doing all of that, everything appears to be fine. I cannot,
> however, see the mozillaAbPersonAlpha object class show up in the list
> when trying to add a new entry using LDAP Studio. Is there anything else
> I need to be doing in order to make this new schema active for a
> particular partition?
I need to narrow down what is causing this: whether it is due to LS or
ApacheDS. I think it's ApacheDS. Perhaps the schema has not been enabled
for some reason. Do me a favor and connect to the server and look at the
cn=moz,ou=schema entry. Perhaps you can post it's attributes/LDIF here.
But just checking if an m-disabled attribute is present on the entry may
suffice. If this m-disabled attribute is set to TRUE just modify the entry
so it is set to FALSE or remove the m-disabled attribute altogether.
I think by default newly added schema are disabled.
Alex
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Alex Karasulu <ak...@apache.org>.
Hi,
On 4/23/07, Emmanuel Lecharny <el...@apache.org> wrote:
>
> Damien Tougas a écrit :
SNIP
> I was able to open the schema in LDAP Studio and export it to an LDIF.
> > The first problem I encountered was that the exported LDIF had a typo
> > which caused the import to fail. The typo was in this section (note
> > the spelling of "matchingRules" in the dn):
> >
> > dn: ou=macthingRules, cn=moz, ou=schema
> > objectclass: organizationalUnit
> > objectclass: top
> > ou: matchingrules
>
> Hmmmm. This should not be a problem. OU are not supposed to be case
> sensitive, so matchingRules or matchingrules or even MATCHINGRULES
> should work.
Oh notice btw that matchingRules is misspelled and it is not the case of ou:
ou=macthingRules verses ...
ou=matchingRules
The order of 'c' and 'h' are inverted.
SNIP
> The next problem I encountered was the fact that the directory server
> > didn't know what to do with the syntax lengths. This problem did not
> > show up when I did the import, but it caused exceptions to get thrown
> > when re-starting the directory server.
>
> Ohho... Another problem which needs investigation...
Yeah this worries me.
SNIP
Alex
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Damien Tougas <da...@tougas.net>.
Emmanuel Lecharny wrote:
>> Using LDAP Studio was not an option because the directory server would
>> not start because of the schema exception being thrown.
>
>
> That's *bad* We have to look at it. Could you create a JIRA for us to
> remember to fix this issue?
Done!
--
Damien Tougas
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 4/23/07, Damien Tougas <da...@tougas.net> wrote:
>
> Hello Emmanuel,
> The problem has nothing to do with case sensitivity, it is a spelling
> error. "macthingRules" should be spelled as "matchingRules".
ohhh... My brain should have been sleeping this mornin, while my fingers
were active. Thanks for this information.
>> To deal with that problem I simply removed the syntax length
> >> definitions from the exported LDIF (i.e. removed {128} etc.) and did
> >> the import again (I first had to delete the schemas partition
> >> directory in order to be able to do this, I am not sure if there is a
> >> better way...).
> >
> > This is an option. You could have deleted the entry too, with
> > LdapStudio, for instance.
>
> Using LDAP Studio was not an option because the directory server would
> not start because of the schema exception being thrown.
That's *bad* We have to look at it. Could you create a JIRA for us to
remember to fix this issue?
Thanks !
--
> Damien Tougas
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Damien Tougas <da...@tougas.net>.
Hello Emmanuel,
Thank you very much for your quick reply.
Emmanuel Lecharny wrote:
>> I was able to open the schema in LDAP Studio and export it to an LDIF.
>> The first problem I encountered was that the exported LDIF had a typo
>> which caused the import to fail. The typo was in this section (note
>> the spelling of "matchingRules" in the dn):
>>
>> dn: ou=macthingRules, cn=moz, ou=schema
>> objectclass: organizationalUnit
>> objectclass: top
>> ou: matchingrules
>
> Hmmmm. This should not be a problem. OU are not supposed to be case
> sensitive, so matchingRules or matchingrules or even MATCHINGRULES
> should work.
The problem has nothing to do with case sensitivity, it is a spelling
error. "macthingRules" should be spelled as "matchingRules".
>> To deal with that problem I simply removed the syntax length
>> definitions from the exported LDIF (i.e. removed {128} etc.) and did
>> the import again (I first had to delete the schemas partition
>> directory in order to be able to do this, I am not sure if there is a
>> better way...).
>
> This is an option. You could have deleted the entry too, with
> LdapStudio, for instance.
Using LDAP Studio was not an option because the directory server would
not start because of the schema exception being thrown.
--
Damien Tougas
Re: [ApacheDS] Having problems with schemas in 1.5
Posted by Emmanuel Lecharny <el...@apache.org>.
Damien Tougas a écrit :
> Hello,
>
> I am in the process of checking out the directory server for the first
> time. I am by no means an LDAP expert, but so far I like what I am
> seeing here.
Thanks ! I hope that we won't deceive you at the end ;)
> My end goal for this testing is to create a shared address
> book using the mozillaAbPersonAlpha schema:
>
> http://wiki.mozilla.org/MailNews:Mozilla_LDAP_Address_Book_Schema
>
> I was able to open the schema in LDAP Studio and export it to an LDIF.
> The first problem I encountered was that the exported LDIF had a typo
> which caused the import to fail. The typo was in this section (note
> the spelling of "matchingRules" in the dn):
>
> dn: ou=macthingRules, cn=moz, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: matchingrules
Hmmmm. This should not be a problem. OU are not supposed to be case
sensitive, so matchingRules or matchingrules or even MATCHINGRULES
should work.
>
> Once that was fixed, the import worked without any errors.
Ah, so you mean that importing such an entry (with matchingrule in it)
caused an error? If so, this is a bug.
>
> The next problem I encountered was the fact that the directory server
> didn't know what to do with the syntax lengths. This problem did not
> show up when I did the import, but it caused exceptions to get thrown
> when re-starting the directory server.
Ohho... Another problem which needs investigation...
>
> To deal with that problem I simply removed the syntax length
> definitions from the exported LDIF (i.e. removed {128} etc.) and did
> the import again (I first had to delete the schemas partition
> directory in order to be able to do this, I am not sure if there is a
> better way...).
This is an option. You could have deleted the entry too, with
LdapStudio, for instance.
>
> After doing all of that, everything appears to be fine. I cannot,
> however, see the mozillaAbPersonAlpha object class show up in the list
> when trying to add a new entry using LDAP Studio. Is there anything
> else I need to be doing in order to make this new schema active for a
> particular partition?
Ok, I think we gonna have to test it. Give us a couple of hours, and
you'll get an answer.
Emmanuel
Re: [ApacheDS] 1.5 Experience Not Good on Windows
Posted by Alex Karasulu <ak...@apache.org>.
Hi Mike,
Good to see you pushing this email after our talk on IRC. Hopefully others
can shed some light on the Kerberos specific issues you are having. More
inline ...
On 4/22/07, CORUM, M E [AG/1000] <m....@monsanto.com> wrote:
>
>
> Have others successfully installed and run 1.5 if they previously had
> 1.0.1 (on Windows)? The reason I ask is that the 1.5 installer doesn't
> work unless you not only uninstall 1.0.1 but manually edit the Windows
> registry to fix up the paths. Once I did that, I could get the server
> to come up.
Basically the uninstaller should remove all the registry settings. If not
then
we have a problem. Can you confirm that the uninstaller in fact does this
on
your machine and report back to us?
The next problem comes when I try to import the example data like I did
> in my 1.0.1 server. When I run the import in 1.5, I get:
>
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/directory/shared/asn1/Asn1Object
> at
> org.apache.directory.server.tools.commands.importcmd.ImportCommandExe
> cutorSkeleton.execute(ImportCommandExecutorSkeleton.java:34)
> at
> org.apache.directory.server.tools.commands.importcmd.ImportCommandExe
> cutorStub.execute(ImportCommandExecutorStub.java:36)
> at
> org.apache.directory.server.tools.request.BaseToolCommandCL.execute(B
> aseToolCommandCL.java:67)
> at
> org.apache.directory.server.tools.ApachedsTools.main(ApachedsTools.ja
> va:122)
>
> The interesting thing is that I still get it even if I add a -classpath
> to include the shared-asn1-0.9.6.jar which has that class. Here is the
> command:
>
> C:\apacheds-1.5\bin>java -classpath
> C:\apacheds-1.5\lib\shared-asn1-0.9.6.jar -jar apacheds-tools.jar import
> -f data.ldif -w somedifferentpassword
Sounds to me like you've got an old 1.0.1 version of the tools jar sitting
around
somewhere. First things first just make sure you clean up with a complete
uninstall
and make sure all the directories are completely removed. If some still
persist
just remove them manually.
I was hoping that the Kerberos stuff worked better in 1.5 (I couldn't
> get it to work in 1.0.1 even after finding the hidden docs on the
> internet).
>
> Any help would be much appreciated.
I think Enrique could lend a hand with this. Enrique could you give Mike
some more info on
how to use the Kerberos server in 1.5?
Alex
Re: [ApacheDS] 1.5 Experience Not Good on Windows
Posted by Enrique Rodriguez <en...@gmail.com>.
On 4/22/07, CORUM, M E [AG/1000] <m....@monsanto.com> wrote:
> ...
> I was hoping that the Kerberos stuff worked better in 1.5 (I couldn't
> get it to work in 1.0.1 even after finding the hidden docs on the
> internet).
Hi, Mike,
The "hidden" documentation you are referring to is targeting Apache
Directory 1.5.1, which is why it is in the wiki Sandbox. Apache
Directory 1.5.1 will be a major release for LDAP+Kerberos, with a
number of Kerberos usability issues worked-out. I wrote a narrative
for the issues to address for Kerberos at the following page, also in
the Sandbox:
http://cwiki.apache.org/confluence/display/DIRxSBOX/Realm+Control+Initiatives
A couple of the problems you are running into are directly related to
those initiatives. I have a good handle on the top 5 issues and I
expect to start coding in earnest after the SASL branch merges,
probably in a week.
I'm in the middle of traveling but I'll get on your questions shortly.
Enrique
Re: [ApacheDS] 1.5 Experience Not Good on Windows - More Info - Trying to get basic Import to Work
Posted by Enrique Rodriguez <en...@gmail.com>.
On 4/22/07, CORUM, M E [AG/1000] <m....@monsanto.com> wrote:
> ...
> At this point, I'm on 1.5 trying to get Kerberos to work. I can't
> figure out whether I should use the "before" or "after" section of
> configuration on this link:
> http://cwiki.apache.org/DIRxSBOX/kerberos-protocol-configuration.html.
Hi, Mike,
1.5 is "before." The "after" are the changes that should appear in
1.5.1, currently being evaluated in the SASL branch prior to merge
with trunk.
Enrique
RE: [ApacheDS] 1.5 Experience Not Good on Windows - Next Problem - more on that
Posted by "CORUM, M E [AG/1000]" <m....@monsanto.com>.
That file format works if the name of the file is kerberos.ldif but does
not work if the name of the file is admin.ldif.
If this is specified (c:\\path\\to\\admin.ldif), the error message says
that c:\\path\\to\\?min.ldif can't be found. Notice how the word
"admin" was changed by the code to "?min". This seems to only happen
with the word "admin".
Mike Corum
-----Original Message-----
From: Enrique Rodriguez [mailto:enriquer9@gmail.com]
Sent: Tuesday, April 24, 2007 9:27 PM
To: users@directory.apache.org
Subject: Re: [ApacheDS] 1.5 Experience Not Good on Windows - Next
Problem - more on that
On 4/22/07, CORUM, M E [AG/1000] <m....@monsanto.com> wrote:
> This code for automatically loading an ldif file using the
ldifDirectory
> property seems pretty badly broken on Windows for 1.5. It always
strips
> off the first two characters of the file name and puts a question mark
> in front it. I've tried every combination of file names and
directories
> I can think of and it always defeats me. Does anybody have this
working
> with 1.5 on Windows?
I believe that for Windows you would need the following format:
c:\\path\\to\\admin.ldif
as in:
File f = new File("c:\\path\\to\\admin.ldif");
I've never tried it with just a directory path, so I'm surprised that
works. Also, I'm not on Windows so please let us know if that File
format doesn't work.
Enrique
---------------------------------------------------------------------------------------------------------
This e-mail message may contain privileged and/or confidential information, and is intended to be received only by persons entitled to receive such information. If you have received this e-mail in error, please notify the sender immediately. Please delete it and all attachments from any servers, hard drives or any other media. Other use of this e-mail by you is strictly prohibited.
All e-mails and attachments sent and received are subject to monitoring, reading and archival by Monsanto. The recipient of this e-mail is solely responsible for checking for the presence of "Viruses" or other "Malware". Monsanto accepts no liability for any damage caused by any such code transmitted by or accompanying this e-mail or any attachment.
---------------------------------------------------------------------------------------------------------
Re: [ApacheDS] 1.5 Experience Not Good on Windows - Next Problem - more on that
Posted by Enrique Rodriguez <en...@gmail.com>.
On 4/22/07, CORUM, M E [AG/1000] <m....@monsanto.com> wrote:
> This code for automatically loading an ldif file using the ldifDirectory
> property seems pretty badly broken on Windows for 1.5. It always strips
> off the first two characters of the file name and puts a question mark
> in front it. I've tried every combination of file names and directories
> I can think of and it always defeats me. Does anybody have this working
> with 1.5 on Windows?
I believe that for Windows you would need the following format:
c:\\path\\to\\admin.ldif
as in:
File f = new File("c:\\path\\to\\admin.ldif");
I've never tried it with just a directory path, so I'm surprised that
works. Also, I'm not on Windows so please let us know if that File
format doesn't work.
Enrique
Re: [ApacheDS] 1.5 Experience and Kerberos (any Kerberos experts out there?)
Posted by Enrique Rodriguez <en...@gmail.com>.
On 4/23/07, CORUM, M E [AG/1000] <m....@monsanto.com> wrote:
> (Just an aside on the issue of not being able to load the ldif file on
> startup in Windows. It appears to be somehow related to the filename
> itself. I found that if the ldif filename started with "ad", then the
> weird parsing took place and it always failed. Perhaps this is an issue
> that only occurs on Windows.)
'a' and 'd' happen to be valid HEX, so I'd bet the lack of escaped '\'
made something in the Java File/FileInputStream, etc., classes think
you were escaping unicode or the Windows char set.
For 1.5.1 I hope to have an interceptor that automatically generates
keys and we'll remove the entire "Kerberos-aware" LDIF loader. I
currently have this working with DES keys. This is tracked in JIRA:
https://issues.apache.org/jira/browse/DIRSERVER-897
> Since I was trying to do Kerberos anyway, I found that
> kerberos-example.ldif file and modified it for my environment. I was
> able to get it loaded. I am using a different domain than example.com
> so I'm wondering if something in the server is hard-coded to
> example.com. I had lots of trouble getting it to recognize anything
> other than example.com. I do have a partition matching my new domain
> and was able to load the file from the startup and verify the entries in
> JXplorer.
The server isn't hard-coded, but you do need to specify the realm.
The following set of config for 1.5 and earlier (the "before") should
cover 99% of config.
<prop key="kdc.realm">EXAMPLE.COM</prop>
<prop key="kdc.principal">krbtgt/EXAMPLE.COM@EXAMPLE.COM</prop>
<prop key="kdc.entryBaseDn">ou=users,dc=example,dc=com</prop>
<prop key="kdc.java.naming.security.credentials">secret</prop>
<prop key="kdc.encryption.types">des-cbc-md5</prop>
In 1.5.1 this will change to the Spring bean-based config you see in
the Sandbox' wiki pages. You may want to start working with the trunk
for 1.5.1 after the SASL branch is merged. We have a pile of work
merging in.
> Now, here is my next problem. In my test code, I'm using JAAS with a
> callbackhandler to just shove in a password (rather than using a keytab)
> since all of this is just for test code. I'm trying to figure out what
> value I need to provide for the userid (principal) from JAAS code. For
> now, I use userid@MY.DOMAIN.COM with the appropriate values of course.
> When I do this, it fails with the following message in the IDE:
>
> [ERROR] Mon Apr 23 10:33:02 CDT 2007 jcsi.kerberos: login failed:
> Kerberos error creating ticket:
> com.dstc.security.kerberos.KerberosError: Integrity checked on decrypted
> field failed (Integrity check on decrypted field failed)
> ...
Typically this means there is a mismatch between the combined
password+principal name. Forgive me if you meant this, but more than
the passwords need to match; the principal name is also used (as
"salt") in the string-to-key derivation function that produces the
symmetric key in use here. If you were using the wrong encryption
type you should have seen KDC_ERR_ETYPE_NOSUPP, aka "KDC has no
support for encryption type," since we don't support RC4-HMAC. More
below.
> ...
> By the way, I'm wondering if the default algorithm for the key is
> different. I'm on Windows and use to using 23. I noticed that the
> Krb5EncryptionType is 3 rather than 23 in the directory so I'll look
> into that to see if that is my problem with Kerberos.
The default algorithm for Apache Directory in 1.5 and before is
DES-CBC-MD5, which, yes, is type 3. Type 23 is RC4-HMAC, the Windows
default. We don't currently support RC4-HMAC, though I read RFC 4757
this weekend on a plane and we have a JIRA issue for it. It is low
priority since even the RFC discourages its use (in favor of AES256).
RFC 4757: http://www.ietf.org/rfc/rfc4757.txt
JIRA for RC4-HMAC: https://issues.apache.org/jira/browse/DIRSERVER-156
JIRA for AES: https://issues.apache.org/jira/browse/DIRSERVER-142
Incidentally I have the hard parts of AES256, AES128, and
DES3-CBC-SHA1-KD done so I expect to drop that in just after the SASL
merge. Getting AES and DES3 support added is a bit of a prerequisite
for the key derivation interceptor in DIRSERVER-897. The key
derivation interceptor should produce keys for all three cipher types,
namely DES, DES3, and AES.
https://issues.apache.org/jira/browse/DIRSERVER-897
Enrique
RE: [ApacheDS] 1.5 Experience and Kerberos (any Kerberos experts out there?)
Posted by "CORUM, M E [AG/1000]" <m....@monsanto.com>.
Emmanuel,
Yes, you've been helpful. If I can't figure out anything else to try, I'll go ahead and build the latest from the trunk. Anyway, I tried des-cbc-md5 for the encryption type and still got the same error. I thought that was type 3 but I could be mistaken.
Enrique, are you out there?
MikeC
-----Original Message-----
From: Emmanuel Lecharny [mailto:elecharny@gmail.com]
Sent: Monday, April 23, 2007 10:57 AM
To: users@directory.apache.org
Subject: Re: [ApacheDS] 1.5 Experience and Kerberos (any Kerberos experts out there?)
Hi,
On 4/23/07, CORUM, M E [AG/1000] <m....@monsanto.com> wrote:
>
>
> (Just an aside on the issue of not being able to load the ldif file on
> startup in Windows. It appears to be somehow related to the filename
> itself. I found that if the ldif filename started with "ad", then the
> weird parsing took place and it always failed. Perhaps this is an issue
> that only occurs on Windows.)
Oh? Very strange... Maybe we have hardcoded a method to reject everithing
containing AD on windows ;). Nahhh. Ok, can you post us a failing ldif file
starting with ad ?
Since I was trying to do Kerberos anyway, I found that
> kerberos-example.ldif file and modified it for my environment. I was
> able to get it loaded. I am using a different domain than example.com
> so I'm wondering if something in the server is hard-coded to
> example.com.
No. We have a server.xml file which contains the configuration for this
partition, but nothing more.
I had lots of trouble getting it to recognize anything
> other than example.com. I do have a partition matching my new domain
> and was able to load the file from the startup and verify the entries in
> JXplorer.
Modifying the name in server.xml should be enough. If you had specific
troubles, then let us know. May be the doco is not good enough, and doco is
part of the product, so...
<snip/>
Just because I don't know anyhing about the kerberos part. Enrique, you
around ?
Now, here is the bad part. When I switch log4j.properties to have DEBUG
> as the log level, the server WON'T START!
yeah, this is a *bad* bug we have in 1.5.0. It has been fixed in trunks, so
I engage you to download the sources and build the server. here are the
instructions to do so :
http://directory.apache.org/apacheds/1.5/building-trunks.html
Sorry about that :(
When I flip back to INFO, the server starts fine but I can't get the
> deep details in the log.
>
> Can anybody help?
Hope I did, but if it's not enough, just ask again.
By the way, I'm wondering if the default algorithm for the key is
> different. I'm on Windows and use to using 23. I noticed that the
> Krb5EncryptionType is 3 rather than 23 in the directory so I'll look
> into that to see if that is my problem with Kerberos.
Enrique again ?
MikeC
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
---------------------------------------------------------------------------------------------------------
This e-mail message may contain privileged and/or confidential information, and is intended to be received only by persons entitled to receive such information. If you have received this e-mail in error, please notify the sender immediately. Please delete it and all attachments from any servers, hard drives or any other media. Other use of this e-mail by you is strictly prohibited.
All e-mails and attachments sent and received are subject to monitoring, reading and archival by Monsanto. The recipient of this e-mail is solely responsible for checking for the presence of "Viruses" or other "Malware". Monsanto accepts no liability for any damage caused by any such code transmitted by or accompanying this e-mail or any attachment.
---------------------------------------------------------------------------------------------------------
Re: [ApacheDS] 1.5 Experience and Kerberos (any Kerberos experts out there?)
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi,
On 4/23/07, CORUM, M E [AG/1000] <m....@monsanto.com> wrote:
>
>
> (Just an aside on the issue of not being able to load the ldif file on
> startup in Windows. It appears to be somehow related to the filename
> itself. I found that if the ldif filename started with "ad", then the
> weird parsing took place and it always failed. Perhaps this is an issue
> that only occurs on Windows.)
Oh? Very strange... Maybe we have hardcoded a method to reject everithing
containing AD on windows ;). Nahhh. Ok, can you post us a failing ldif file
starting with ad ?
Since I was trying to do Kerberos anyway, I found that
> kerberos-example.ldif file and modified it for my environment. I was
> able to get it loaded. I am using a different domain than example.com
> so I'm wondering if something in the server is hard-coded to
> example.com.
No. We have a server.xml file which contains the configuration for this
partition, but nothing more.
I had lots of trouble getting it to recognize anything
> other than example.com. I do have a partition matching my new domain
> and was able to load the file from the startup and verify the entries in
> JXplorer.
Modifying the name in server.xml should be enough. If you had specific
troubles, then let us know. May be the doco is not good enough, and doco is
part of the product, so...
<snip/>
Just because I don't know anyhing about the kerberos part. Enrique, you
around ?
Now, here is the bad part. When I switch log4j.properties to have DEBUG
> as the log level, the server WON'T START!
yeah, this is a *bad* bug we have in 1.5.0. It has been fixed in trunks, so
I engage you to download the sources and build the server. here are the
instructions to do so :
http://directory.apache.org/apacheds/1.5/building-trunks.html
Sorry about that :(
When I flip back to INFO, the server starts fine but I can't get the
> deep details in the log.
>
> Can anybody help?
Hope I did, but if it's not enough, just ask again.
By the way, I'm wondering if the default algorithm for the key is
> different. I'm on Windows and use to using 23. I noticed that the
> Krb5EncryptionType is 3 rather than 23 in the directory so I'll look
> into that to see if that is my problem with Kerberos.
Enrique again ?
MikeC
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
RE: [ApacheDS] 1.5 Kerberos Support and Custom Attribute in Schema
Posted by "CORUM, M E [AG/1000]" <m....@monsanto.com>.
Should have said group "object" not attribute.
MikeC
-----Original Message-----
From: CORUM, M E [AG/1000] [mailto:m.e.corum@monsanto.com]
Sent: Wednesday, April 25, 2007 8:09 AM
To: users@directory.apache.org; erodriguez@apache.org
Subject: RE: [ApacheDS] 1.5 Kerberos Support and Custom Attribute in
Schema
Enrique,
I now have SPNs and UPNs working. It turned out that they were just
attributes. I did have to add the objectCategory class but so far it
has gone well. I also have a query working to find out the members of a
group (had to add the AD-specific "group" attribute but "member" was
already there.) I'm now working on testing my client for getting a list
of attributes for the user/account and for adding users to groups.
MikeC
-----Original Message-----
From: Enrique Rodriguez [mailto:enriquer9@gmail.com]
Sent: Tuesday, April 24, 2007 10:12 PM
To: users@directory.apache.org
Subject: Re: [ApacheDS] 1.5 Kerberos Support and Custom Attribute in
Schema
On 4/23/07, CORUM, M E [AG/1000] <m....@monsanto.com> wrote:
> ...
> I now have 1.5 working with some basic (very basic) Kerberos stuff.
I'm
> able from a JUnit test to log on and verify that a different
> account/user is valid. Before I go on to explain my next issue, I
> should explain what I'm trying to accomplish.
I'm happy to see you're progressing. I know the config is a bit
convoluted but we have a better story in the works which will
hopefully coincide with doco that isn't "hidden."
> ... we'd like to set up a test environment on our
> local machines that simulates AD as closely as possible for the
purpose
> of this client code we are writing.
I would like to work closely with you to make Apache Directory
"simulate AD as closely as possible" for purposes of "testing." ;)
All kidding aside, this is interesting work, but I really need to
focus on the "Realm Control Initiatives," since they are prerequisites
for an actually useful Kerberos server.
http://cwiki.apache.org/confluence/display/DIRxSBOX/Realm+Control+Initia
tives
> My next step after verifying accounts (which I can do now) against
> ApacheDS is to verify the SPNs. In Active Directory, an SPN is a
> "servicePrincipalName" attribute that can have a list of values
> (aliases) for the service that the account represents. When I try to
> add a "servicePrincipalName" to a user in my kerberos.ldif file (for
> loading on startup), the startup fails to load the ldif file with the
> following error:
> ...
Yeah, this is classic LDAP here. Instead of adding attributes to the
schema we use for Kerberos it makes more sense to create a new schema
and put the 200 or so AD attributes in there.
> Can anybody help with adding an attribute to the schema or set of
> schemas that ApacheDS uses?
Numerous people here should be able to help with schema setup and
probably there's some doco (I work off unit tests). The issue closer
to home for me is getting the Kerberos protocol provider to work with
SPN's since this requires a new store implementation against a
different schema than the one we're using. But, it's straight forward
JNDI programming. Stores aren't pluggable now but we have techniques
for that.
Enrique
------------------------------------------------------------------------
---------------------------------
This e-mail message may contain privileged and/or confidential
information, and is intended to be received only by persons entitled to
receive such information. If you have received this e-mail in error,
please notify the sender immediately. Please delete it and all
attachments from any servers, hard drives or any other media. Other use
of this e-mail by you is strictly prohibited.
All e-mails and attachments sent and received are subject to monitoring,
reading and archival by Monsanto. The recipient of this e-mail is solely
responsible for checking for the presence of "Viruses" or other
"Malware". Monsanto accepts no liability for any damage caused by any
such code transmitted by or accompanying this e-mail or any attachment.
------------------------------------------------------------------------
---------------------------------
---------------------------------------------------------------------------------------------------------
This e-mail message may contain privileged and/or confidential information, and is intended to be received only by persons entitled to receive such information. If you have received this e-mail in error, please notify the sender immediately. Please delete it and all attachments from any servers, hard drives or any other media. Other use of this e-mail by you is strictly prohibited.
All e-mails and attachments sent and received are subject to monitoring, reading and archival by Monsanto. The recipient of this e-mail is solely responsible for checking for the presence of "Viruses" or other "Malware". Monsanto accepts no liability for any damage caused by any such code transmitted by or accompanying this e-mail or any attachment.
---------------------------------------------------------------------------------------------------------
RE: [ApacheDS] 1.5 Kerberos Support and Custom Attribute in Schema
Posted by "CORUM, M E [AG/1000]" <m....@monsanto.com>.
Enrique,
I now have SPNs and UPNs working. It turned out that they were just
attributes. I did have to add the objectCategory class but so far it
has gone well. I also have a query working to find out the members of a
group (had to add the AD-specific "group" attribute but "member" was
already there.) I'm now working on testing my client for getting a list
of attributes for the user/account and for adding users to groups.
MikeC
-----Original Message-----
From: Enrique Rodriguez [mailto:enriquer9@gmail.com]
Sent: Tuesday, April 24, 2007 10:12 PM
To: users@directory.apache.org
Subject: Re: [ApacheDS] 1.5 Kerberos Support and Custom Attribute in
Schema
On 4/23/07, CORUM, M E [AG/1000] <m....@monsanto.com> wrote:
> ...
> I now have 1.5 working with some basic (very basic) Kerberos stuff.
I'm
> able from a JUnit test to log on and verify that a different
> account/user is valid. Before I go on to explain my next issue, I
> should explain what I'm trying to accomplish.
I'm happy to see you're progressing. I know the config is a bit
convoluted but we have a better story in the works which will
hopefully coincide with doco that isn't "hidden."
> ... we'd like to set up a test environment on our
> local machines that simulates AD as closely as possible for the
purpose
> of this client code we are writing.
I would like to work closely with you to make Apache Directory
"simulate AD as closely as possible" for purposes of "testing." ;)
All kidding aside, this is interesting work, but I really need to
focus on the "Realm Control Initiatives," since they are prerequisites
for an actually useful Kerberos server.
http://cwiki.apache.org/confluence/display/DIRxSBOX/Realm+Control+Initia
tives
> My next step after verifying accounts (which I can do now) against
> ApacheDS is to verify the SPNs. In Active Directory, an SPN is a
> "servicePrincipalName" attribute that can have a list of values
> (aliases) for the service that the account represents. When I try to
> add a "servicePrincipalName" to a user in my kerberos.ldif file (for
> loading on startup), the startup fails to load the ldif file with the
> following error:
> ...
Yeah, this is classic LDAP here. Instead of adding attributes to the
schema we use for Kerberos it makes more sense to create a new schema
and put the 200 or so AD attributes in there.
> Can anybody help with adding an attribute to the schema or set of
> schemas that ApacheDS uses?
Numerous people here should be able to help with schema setup and
probably there's some doco (I work off unit tests). The issue closer
to home for me is getting the Kerberos protocol provider to work with
SPN's since this requires a new store implementation against a
different schema than the one we're using. But, it's straight forward
JNDI programming. Stores aren't pluggable now but we have techniques
for that.
Enrique
---------------------------------------------------------------------------------------------------------
This e-mail message may contain privileged and/or confidential information, and is intended to be received only by persons entitled to receive such information. If you have received this e-mail in error, please notify the sender immediately. Please delete it and all attachments from any servers, hard drives or any other media. Other use of this e-mail by you is strictly prohibited.
All e-mails and attachments sent and received are subject to monitoring, reading and archival by Monsanto. The recipient of this e-mail is solely responsible for checking for the presence of "Viruses" or other "Malware". Monsanto accepts no liability for any damage caused by any such code transmitted by or accompanying this e-mail or any attachment.
---------------------------------------------------------------------------------------------------------
Re: [ApacheDS] 1.5 Kerberos Support and Custom Attribute in Schema
Posted by Enrique Rodriguez <en...@gmail.com>.
On 4/23/07, CORUM, M E [AG/1000] <m....@monsanto.com> wrote:
> ...
> I now have 1.5 working with some basic (very basic) Kerberos stuff. I'm
> able from a JUnit test to log on and verify that a different
> account/user is valid. Before I go on to explain my next issue, I
> should explain what I'm trying to accomplish.
I'm happy to see you're progressing. I know the config is a bit
convoluted but we have a better story in the works which will
hopefully coincide with doco that isn't "hidden."
> ... we'd like to set up a test environment on our
> local machines that simulates AD as closely as possible for the purpose
> of this client code we are writing.
I would like to work closely with you to make Apache Directory
"simulate AD as closely as possible" for purposes of "testing." ;)
All kidding aside, this is interesting work, but I really need to
focus on the "Realm Control Initiatives," since they are prerequisites
for an actually useful Kerberos server.
http://cwiki.apache.org/confluence/display/DIRxSBOX/Realm+Control+Initiatives
> My next step after verifying accounts (which I can do now) against
> ApacheDS is to verify the SPNs. In Active Directory, an SPN is a
> "servicePrincipalName" attribute that can have a list of values
> (aliases) for the service that the account represents. When I try to
> add a "servicePrincipalName" to a user in my kerberos.ldif file (for
> loading on startup), the startup fails to load the ldif file with the
> following error:
> ...
Yeah, this is classic LDAP here. Instead of adding attributes to the
schema we use for Kerberos it makes more sense to create a new schema
and put the 200 or so AD attributes in there.
> Can anybody help with adding an attribute to the schema or set of
> schemas that ApacheDS uses?
Numerous people here should be able to help with schema setup and
probably there's some doco (I work off unit tests). The issue closer
to home for me is getting the Kerberos protocol provider to work with
SPN's since this requires a new store implementation against a
different schema than the one we're using. But, it's straight forward
JNDI programming. Stores aren't pluggable now but we have techniques
for that.
Enrique
RE: [ApacheDS] 1.5 Kerberos Support and Custom Attribute in Schema
Posted by "CORUM, M E [AG/1000]" <m....@monsanto.com>.
Stefan,
Yes, thank you. I had found that page earlier but had not read it yet.
The Kerberos stuff from the page that referenced it was inaccurate so I
wasn't sure whether these wiki pages were trustworthy or not. I'll dig
into this more deeply. Right now, I'm looking into the OIDs for Active
Directory's custom attributes (the over 200 additions to the standard
that AD makes).
Thanks again,
MikeC
-----Original Message-----
From: Stefan Seelmann [mailto:mail@stefan-seelmann.de]
Sent: Monday, April 23, 2007 3:28 PM
To: users@directory.apache.org
Subject: Re: [ApacheDS] 1.5 Kerberos Support and Custom Attribute in
Schema
Hi Mike,
CORUM, M E [AG/1000] schrieb:
>
> [13:00:25] ERROR
> [org.apache.directory.server.protocol.shared.store.LdifFileLoader] -
> Failed to import LDIF into backing store.
>
org.apache.directory.shared.ldap.exception.LdapInvalidAttributeIdentifie
> rException: serviceprincipalname not found in attribute registry!
> at
>
org.apache.directory.server.core.schema.SchemaService.check(SchemaServic
> e.java:1809)
>
> I assume I could add this attribute to the schema. However, when I
read
> the custom schema stuff in the 1.0 documentation, it refers to a
> bootstrapSchemas section in the server.xml that doesn't exist. I
tried
> putting it in and the server won't come up so that doesn't work. How
is
> this done now? I assume it has changed but the change isn't
documented.
>
> Can anybody help with adding an attribute to the schema or set of
> schemas that ApacheDS uses?
>
The schema subsystem has totally changed with 1.5. Here you can find a
first (but good) draft of some documentation:
http://cwiki.apache.org/confluence/display/DIRxSBOX/Add+your+first+eleme
nts+to+the+schema
Regards,
Stefan Seelmann
---------------------------------------------------------------------------------------------------------
This e-mail message may contain privileged and/or confidential information, and is intended to be received only by persons entitled to receive such information. If you have received this e-mail in error, please notify the sender immediately. Please delete it and all attachments from any servers, hard drives or any other media. Other use of this e-mail by you is strictly prohibited.
All e-mails and attachments sent and received are subject to monitoring, reading and archival by Monsanto. The recipient of this e-mail is solely responsible for checking for the presence of "Viruses" or other "Malware". Monsanto accepts no liability for any damage caused by any such code transmitted by or accompanying this e-mail or any attachment.
---------------------------------------------------------------------------------------------------------
Re: [ApacheDS] 1.5 Kerberos Support and Custom Attribute in Schema
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
Hi Mike,
CORUM, M E [AG/1000] schrieb:
>
> [13:00:25] ERROR
> [org.apache.directory.server.protocol.shared.store.LdifFileLoader] -
> Failed to import LDIF into backing store.
> org.apache.directory.shared.ldap.exception.LdapInvalidAttributeIdentifie
> rException: serviceprincipalname not found in attribute registry!
> at
> org.apache.directory.server.core.schema.SchemaService.check(SchemaServic
> e.java:1809)
>
> I assume I could add this attribute to the schema. However, when I read
> the custom schema stuff in the 1.0 documentation, it refers to a
> bootstrapSchemas section in the server.xml that doesn't exist. I tried
> putting it in and the server won't come up so that doesn't work. How is
> this done now? I assume it has changed but the change isn't documented.
>
> Can anybody help with adding an attribute to the schema or set of
> schemas that ApacheDS uses?
>
The schema subsystem has totally changed with 1.5. Here you can find a
first (but good) draft of some documentation:
http://cwiki.apache.org/confluence/display/DIRxSBOX/Add+your+first+elements+to+the+schema
Regards,
Stefan Seelmann
RE: [ApacheDS] 1.5 Kerberos Support and Custom Attribute in Schema
Posted by "CORUM, M E [AG/1000]" <m....@monsanto.com>.
Kerberos Experts,
I now have 1.5 working with some basic (very basic) Kerberos stuff. I'm
able from a JUnit test to log on and verify that a different
account/user is valid. Before I go on to explain my next issue, I
should explain what I'm trying to accomplish.
My task is to create some remote administration Java code for Active
Directory. I've been doing Kerberos for awhile with the Quest/Vintela
VSJ and VSJ Kerberos packages and we have a lot of utility code built up
around these tools. We already have an authenticated LDAP client piece
that we use to do some simple things like verify an account or its SPNs
and change a password. We will now be expanding this code to do more
"intrusive" functions so we'd like to set up a test environment on our
local machines that simulates AD as closely as possible for the purpose
of this client code we are writing. Examples of new features would be
adding an account or adding a user to an AD group. I know almost
nothing about LDAP but I know a few things about Kerberos and working
with AD's Kerberos.
My next step after verifying accounts (which I can do now) against
ApacheDS is to verify the SPNs. In Active Directory, an SPN is a
"servicePrincipalName" attribute that can have a list of values
(aliases) for the service that the account represents. When I try to
add a "servicePrincipalName" to a user in my kerberos.ldif file (for
loading on startup), the startup fails to load the ldif file with the
following error:
[13:00:25] ERROR
[org.apache.directory.server.protocol.shared.store.LdifFileLoader] -
Failed to import LDIF into backing store.
org.apache.directory.shared.ldap.exception.LdapInvalidAttributeIdentifie
rException: serviceprincipalname not found in attribute registry!
at
org.apache.directory.server.core.schema.SchemaService.check(SchemaServic
e.java:1809)
I assume I could add this attribute to the schema. However, when I read
the custom schema stuff in the 1.0 documentation, it refers to a
bootstrapSchemas section in the server.xml that doesn't exist. I tried
putting it in and the server won't come up so that doesn't work. How is
this done now? I assume it has changed but the change isn't documented.
Can anybody help with adding an attribute to the schema or set of
schemas that ApacheDS uses?
MikeC
---------------------------------------------------------------------------------------------------------
This e-mail message may contain privileged and/or confidential information, and is intended to be received only by persons entitled to receive such information. If you have received this e-mail in error, please notify the sender immediately. Please delete it and all attachments from any servers, hard drives or any other media. Other use of this e-mail by you is strictly prohibited.
All e-mails and attachments sent and received are subject to monitoring, reading and archival by Monsanto. The recipient of this e-mail is solely responsible for checking for the presence of "Viruses" or other "Malware". Monsanto accepts no liability for any damage caused by any such code transmitted by or accompanying this e-mail or any attachment.
---------------------------------------------------------------------------------------------------------
RE: [ApacheDS] 1.5 Experience and Kerberos (any Kerberos experts out there?)
Posted by "CORUM, M E [AG/1000]" <m....@monsanto.com>.
(Just an aside on the issue of not being able to load the ldif file on
startup in Windows. It appears to be somehow related to the filename
itself. I found that if the ldif filename started with "ad", then the
weird parsing took place and it always failed. Perhaps this is an issue
that only occurs on Windows.)
Since I was trying to do Kerberos anyway, I found that
kerberos-example.ldif file and modified it for my environment. I was
able to get it loaded. I am using a different domain than example.com
so I'm wondering if something in the server is hard-coded to
example.com. I had lots of trouble getting it to recognize anything
other than example.com. I do have a partition matching my new domain
and was able to load the file from the startup and verify the entries in
JXplorer.
Now, here is my next problem. In my test code, I'm using JAAS with a
callbackhandler to just shove in a password (rather than using a keytab)
since all of this is just for test code. I'm trying to figure out what
value I need to provide for the userid (principal) from JAAS code. For
now, I use userid@MY.DOMAIN.COM with the appropriate values of course.
When I do this, it fails with the following message in the IDE:
[ERROR] Mon Apr 23 10:33:02 CDT 2007 jcsi.kerberos: login failed:
Kerberos error creating ticket:
com.dstc.security.kerberos.KerberosError: Integrity checked on decrypted
field failed (Integrity check on decrypted field failed)
javax.security.auth.login.LoginException: Kerberos error creating
ticket: com.dstc.security.kerberos.KerberosError: Integrity checked on
decrypted field failed (Integrity check on decrypted field failed)
Since the log file is set to INFO in the log4j properties file, all I
get is:
[10:33:01] ERROR
[org.apache.directory.server.kerberos.protocol.KerberosProtocolHandler]
- Additional pre-authentication required
[10:33:02] ERROR
[org.apache.directory.server.kerberos.protocol.KerberosProtocolHandler]
- Integrity check on decrypted field failed
I don't know what to do from here. I'm using the exact same password
for all my users and it is the one I'm providing. I'm using the
ldifFilters entry in server.xml to invoke Krb5KdcEntryFilter on loading
the users in the file so the krb5key and userPassword are set. I
checked that in JXplorer and they are there. So, I'm thinking I'll turn
on DEBUG.
Now, here is the bad part. When I switch log4j.properties to have DEBUG
as the log level, the server WON'T START! Bummer! Here is the error
message I get trying to start the server with DEBUG as the log level
(this worked in 1.0.1 by the way):
[10:16:39] DEBUG
[org.apache.directory.server.schema.registries.DefaultNormalizerRegistry
] - registered normalizer with oid: 1.3.6.1.4.1.18060.0.4.1.1.1
[10:16:39] ERROR [org.apache.directory.daemon.Bootstrapper] - Failed on
org.apache.directory.server.Service.init(InstallationLayout, String[])
java.lang.ArrayIndexOutOfBoundsException: 0
at
org.apache.directory.shared.ldap.schema.AbstractSchemaObject.toString(Ab
stractSchemaObject.java:320)
at java.lang.String.valueOf(Unknown Source)
at java.lang.StringBuilder.append(Unknown Source)
at
org.apache.directory.server.schema.registries.DefaultSyntaxRegistry.regi
ster(DefaultSyntaxRegistry.java:110)
at
org.apache.directory.server.core.schema.PartitionSchemaLoader.loadSyntax
es(PartitionSchemaLoader.java:654)
at
org.apache.directory.server.core.schema.PartitionSchemaLoader.load(Parti
tionSchemaLoader.java:348)
at
org.apache.directory.server.schema.registries.AbstractSchemaLoader.loadD
epsFirst(AbstractSchemaLoader.java:107)
at
org.apache.directory.server.schema.registries.AbstractSchemaLoader.loadD
epsFirst(AbstractSchemaLoader.java:143)
at
org.apache.directory.server.schema.registries.AbstractSchemaLoader.loadD
epsFirst(AbstractSchemaLoader.java:143)
at
org.apache.directory.server.core.schema.PartitionSchemaLoader.loadWithDe
pendencies(PartitionSchemaLoader.java:320)
at
org.apache.directory.server.core.schema.PartitionSchemaLoader.loadEnable
d(PartitionSchemaLoader.java:222)
at
org.apache.directory.server.core.DefaultDirectoryService.initialize(Defa
ultDirectoryService.java:914)
at
org.apache.directory.server.core.DefaultDirectoryService.startup(Default
DirectoryService.java:254)
at
org.apache.directory.server.core.jndi.AbstractContextFactory.getInitialC
ontext(AbstractContextFactory.java:118)
at javax.naming.spi.NamingManager.getInitialContext(Unknown
Source)
at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
at javax.naming.InitialContext.init(Unknown Source)
at javax.naming.InitialContext.<init>(Unknown Source)
at javax.naming.directory.InitialDirContext.<init>(Unknown
Source)
at org.apache.directory.server.Service.init(Service.java:96)
at
org.apache.directory.daemon.Bootstrapper.callInit(Bootstrapper.java:151)
at
org.apache.directory.daemon.ProcrunBootstrapper.prunsrvStart(ProcrunBoot
strapper.java:65)
When I flip back to INFO, the server starts fine but I can't get the
deep details in the log.
Can anybody help?
By the way, I'm wondering if the default algorithm for the key is
different. I'm on Windows and use to using 23. I noticed that the
Krb5EncryptionType is 3 rather than 23 in the directory so I'll look
into that to see if that is my problem with Kerberos.
MikeC
---------------------------------------------------------------------------------------------------------
This e-mail message may contain privileged and/or confidential information, and is intended to be received only by persons entitled to receive such information. If you have received this e-mail in error, please notify the sender immediately. Please delete it and all attachments from any servers, hard drives or any other media. Other use of this e-mail by you is strictly prohibited.
All e-mails and attachments sent and received are subject to monitoring, reading and archival by Monsanto. The recipient of this e-mail is solely responsible for checking for the presence of "Viruses" or other "Malware". Monsanto accepts no liability for any damage caused by any such code transmitted by or accompanying this e-mail or any attachment.
---------------------------------------------------------------------------------------------------------
RE: [ApacheDS] 1.5 Experience Not Good on Windows - Next Problem - more on that
Posted by "CORUM, M E [AG/1000]" <m....@monsanto.com>.
This code for automatically loading an ldif file using the ldifDirectory
property seems pretty badly broken on Windows for 1.5. It always strips
off the first two characters of the file name and puts a question mark
in front it. I've tried every combination of file names and directories
I can think of and it always defeats me. Does anybody have this working
with 1.5 on Windows?
MikeC
-----Original Message-----
From: CORUM, M E [AG/1000]
Sent: Sunday, April 22, 2007 10:33 PM
To: 'users@directory.apache.org'
Subject: RE: [ApacheDS] 1.5 Experience Not Good on Windows - Next
Problem
Now, I'm trying to use the following code in the server.xml:
<property name="ldifDirectory">
<value>C:/ApacheDS_ldapusers</value>
</property>
<property name="ldifFilters">
<list>
<bean
class="org.apache.directory.server.protocol.shared.store.Krb5KdcEntryFil
ter"/>
</list>
</property>
I've tried every value I can think of to try for the "ldifDirectory"
value. I tried a file name at the end and that ended up with the same
exact error as if I didn't use a file name. The error from the code
above is listed below. I have one file in that directory called
"admin.ldif". Can anybody suggest syntax that might work? I tried all
the suggestions in the comments in the file and none worked (although I
didn't try the file:/// syntax - is that really the only one that
works?). Whether I specify a file name or not, it find the file and
swallows the first two letters and puts in a question mark, hmmm.
[22:28:44] ERROR [org.apache.directory.daemon.Bootstrapper] - Failed on
org.apache.directory.server.Service.init(InstallationLayout, String[])
javax.naming.NamingException: Invalid value :
C:\ApacheDS_ldapusers?min.ldif
at
org.apache.directory.shared.ldap.schema.DeepTrimToLowerNormalizer.normal
ize(DeepTrimToLowerNormalizer.java:65)
MikeC
---------------------------------------------------------------------------------------------------------
This e-mail message may contain privileged and/or confidential information, and is intended to be received only by persons entitled to receive such information. If you have received this e-mail in error, please notify the sender immediately. Please delete it and all attachments from any servers, hard drives or any other media. Other use of this e-mail by you is strictly prohibited.
All e-mails and attachments sent and received are subject to monitoring, reading and archival by Monsanto. The recipient of this e-mail is solely responsible for checking for the presence of "Viruses" or other "Malware". Monsanto accepts no liability for any damage caused by any such code transmitted by or accompanying this e-mail or any attachment.
---------------------------------------------------------------------------------------------------------
RE: [ApacheDS] 1.5 Experience Not Good on Windows - Next Problem
Posted by "CORUM, M E [AG/1000]" <m....@monsanto.com>.
Now, I'm trying to use the following code in the server.xml:
<property name="ldifDirectory">
<value>C:/ApacheDS_ldapusers</value>
</property>
<property name="ldifFilters">
<list>
<bean
class="org.apache.directory.server.protocol.shared.store.Krb5KdcEntryFil
ter"/>
</list>
</property>
I've tried every value I can think of to try for the "ldifDirectory"
value. I tried a file name at the end and that ended up with the same
exact error as if I didn't use a file name. The error from the code
above is listed below. I have one file in that directory called
"admin.ldif". Can anybody suggest syntax that might work? I tried all
the suggestions in the comments in the file and none worked (although I
didn't try the file:/// syntax - is that really the only one that
works?). Whether I specify a file name or not, it find the file and
swallows the first two letters and puts in a question mark, hmmm.
[22:28:44] ERROR [org.apache.directory.daemon.Bootstrapper] - Failed on
org.apache.directory.server.Service.init(InstallationLayout, String[])
javax.naming.NamingException: Invalid value :
C:\ApacheDS_ldapusers?min.ldif
at
org.apache.directory.shared.ldap.schema.DeepTrimToLowerNormalizer.normal
ize(DeepTrimToLowerNormalizer.java:65)
MikeC
---------------------------------------------------------------------------------------------------------
This e-mail message may contain privileged and/or confidential information, and is intended to be received only by persons entitled to receive such information. If you have received this e-mail in error, please notify the sender immediately. Please delete it and all attachments from any servers, hard drives or any other media. Other use of this e-mail by you is strictly prohibited.
All e-mails and attachments sent and received are subject to monitoring, reading and archival by Monsanto. The recipient of this e-mail is solely responsible for checking for the presence of "Viruses" or other "Malware". Monsanto accepts no liability for any damage caused by any such code transmitted by or accompanying this e-mail or any attachment.
---------------------------------------------------------------------------------------------------------
RE: [ApacheDS] 1.5 Experience Not Good on Windows - More Info - Trying to get basic Import to Work
Posted by "CORUM, M E [AG/1000]" <m....@monsanto.com>.
Alex,
Thanks, I was using 1.5. I don't even have 1.4 on my machine any more.
However, I found that some of my Kerberos jars actually conflicted with
the ASN.1 stuff in ApacheDS. After I fixed that, the issue is that in
1.0.1, the import command line utility is very clean and doesn't require
any special classpath (or if it does, it handles it internally with the
classpath entry in the manifest file). Woops, as I was typing this, I
found the error in 1.5. The tools jar in the /bin directory has the
same classpath entry in the manifest file as follows:
../lib/shared-asn1-0.9.6-SNAPSHOT.jar
However, the /lib directory has:
shared-asn1-0.9.6.jar (without SNAPSHOT)
The only thing I can think is that 1.0.1 just didn't need ASN.1 for the
import command line utility because it shouldn't have worked there
either but it did.
Anyway, I was able to get an import to work after setting up a special
module in IntelliJ to just bring in only the specific jars I needed for
import and not extras. Perhaps this should be a bug report against the
manifest file in the tools jar.
At this point, I'm on 1.5 trying to get Kerberos to work. I can't
figure out whether I should use the "before" or "after" section of
configuration on this link:
http://cwiki.apache.org/DIRxSBOX/kerberos-protocol-configuration.html.
MikeC
-----Original Message-----
From: akarasulu@gmail.com [mailto:akarasulu@gmail.com] On Behalf Of Alex
Karasulu
Sent: Sunday, April 22, 2007 9:46 PM
To: users@directory.apache.org
Subject: Re: [ApacheDS] 1.5 Experience Not Good on Windows - More Info -
Trying to get basic Import to Work
Ahhh yeah 1.5 is strictly for JDK 1.5. If you're trying to use 1.4 it
will
bomb out.
Alex
On 4/22/07, CORUM, M E [AG/1000] <m....@monsanto.com> wrote:
>
>
> I wired it all up in IntelliJ because I kept finding more Jar files
that
> the import utility needed so I just added all the /lib jars and set up
a
> config in IntelliJ and ran it. It looks from the error like some jars
> are Java 1.4 and others are Java 1.5. Perhaps the attempt to go to
Java
> 1.5 isn't complete in ApacheDS 1.5? Again, any help would be
> appreciated. I'm just trying to load the example data file. It
worked
> great in 1.0.1. Should I just go back to 1.0.1 and continue trying to
> figure out the Kerberos there?
>
> MikeC
>
> Exception in thread "main" java.lang.IncompatibleClassChangeError
> at
>
org.apache.directory.shared.asn1.ber.grammar.AbstractGrammar.<clinit>(Ab
> stractGrammar.java:48)
> at
>
org.apache.directory.shared.ldap.codec.LdapMessageContainer.<init>(LdapM
> essageContainer.java:76)
> at
>
org.apache.directory.shared.ldap.codec.LdapMessageContainer.<init>(LdapM
> essageContainer.java:64)
> at
>
org.apache.directory.server.tools.commands.importcmd.ImportCommandExecut
> or.<init>(ImportCommandExecutor.java:114)
> at
>
org.apache.directory.server.tools.commands.importcmd.ImportCommandExecut
> orSkeleton.execute(ImportCommandExecutorSkeleton.java:34)
> at
>
org.apache.directory.server.tools.commands.importcmd.ImportCommandExecut
> orStub.execute(ImportCommandExecutorStub.java:36)
> at
>
org.apache.directory.server.tools.request.BaseToolCommandCL.execute(Base
> ToolCommandCL.java:67)
> at
>
org.apache.directory.server.tools.ApachedsTools.main(ApachedsTools.java:
> 122)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
> a:39)
> at
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> Impl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
>
> -----Original Message-----
> From: CORUM, M E [AG/1000] [mailto:m.e.corum@monsanto.com]
> Sent: Sunday, April 22, 2007 9:13 PM
> To: users@directory.apache.org
> Subject: RE: [ApacheDS] 1.5 Experience Not Good on Windows
>
>
> Have others successfully installed and run 1.5 if they previously had
> 1.0.1 (on Windows)? The reason I ask is that the 1.5 installer
doesn't
> work unless you not only uninstall 1.0.1 but manually edit the Windows
> registry to fix up the paths. Once I did that, I could get the server
> to come up.
>
> The next problem comes when I try to import the example data like I
did
> in my 1.0.1 server. When I run the import in 1.5, I get:
>
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/directory/shared/asn1/Asn1Object
> at
> org.apache.directory.server.tools.commands.importcmd.ImportCommandExe
> cutorSkeleton.execute(ImportCommandExecutorSkeleton.java:34)
> at
> org.apache.directory.server.tools.commands.importcmd.ImportCommandExe
> cutorStub.execute(ImportCommandExecutorStub.java:36)
> at
> org.apache.directory.server.tools.request.BaseToolCommandCL.execute(B
> aseToolCommandCL.java:67)
> at
> org.apache.directory.server.tools.ApachedsTools.main(ApachedsTools.ja
> va:122)
>
> The interesting thing is that I still get it even if I add a
-classpath
> to include the shared-asn1-0.9.6.jar which has that class. Here is
the
> command:
>
> C:\apacheds-1.5\bin>java -classpath
> C:\apacheds-1.5\lib\shared-asn1-0.9.6.jar -jar apacheds-tools.jar
import
> -f data.ldif -w somedifferentpassword
>
> I was hoping that the Kerberos stuff worked better in 1.5 (I couldn't
> get it to work in 1.0.1 even after finding the hidden docs on the
> internet).
>
> Any help would be much appreciated.
>
> MikeC
>
>
>
>
>
------------------------------------------------------------------------
> ---------------------------------
> This e-mail message may contain privileged and/or confidential
> information, and is intended to be received only by persons entitled
to
> receive such information. If you have received this e-mail in error,
> please notify the sender immediately. Please delete it and all
> attachments from any servers, hard drives or any other media. Other
use
> of this e-mail by you is strictly prohibited.
>
>
> All e-mails and attachments sent and received are subject to
monitoring,
> reading and archival by Monsanto. The recipient of this e-mail is
solely
> responsible for checking for the presence of "Viruses" or other
> "Malware". Monsanto accepts no liability for any damage caused by any
> such code transmitted by or accompanying this e-mail or any
attachment.
>
------------------------------------------------------------------------
> ---------------------------------
>
>
>
>
>
------------------------------------------------------------------------
---------------------------------
> This e-mail message may contain privileged and/or confidential
> information, and is intended to be received only by persons entitled
to
> receive such information. If you have received this e-mail in error,
please
> notify the sender immediately. Please delete it and all attachments
from any
> servers, hard drives or any other media. Other use of this e-mail by
you is
> strictly prohibited.
>
>
> All e-mails and attachments sent and received are subject to
monitoring,
> reading and archival by Monsanto. The recipient of this e-mail is
solely
> responsible for checking for the presence of "Viruses" or other
"Malware".
> Monsanto accepts no liability for any damage caused by any such code
> transmitted by or accompanying this e-mail or any attachment.
>
>
------------------------------------------------------------------------
---------------------------------
>
>
---------------------------------------------------------------------------------------------------------
This e-mail message may contain privileged and/or confidential information, and is intended to be received only by persons entitled to receive such information. If you have received this e-mail in error, please notify the sender immediately. Please delete it and all attachments from any servers, hard drives or any other media. Other use of this e-mail by you is strictly prohibited.
All e-mails and attachments sent and received are subject to monitoring, reading and archival by Monsanto. The recipient of this e-mail is solely responsible for checking for the presence of "Viruses" or other "Malware". Monsanto accepts no liability for any damage caused by any such code transmitted by or accompanying this e-mail or any attachment.
---------------------------------------------------------------------------------------------------------
Re: [ApacheDS] 1.5 Experience Not Good on Windows - More Info - Trying to get basic Import to Work
Posted by Alex Karasulu <ak...@apache.org>.
Ahhh yeah 1.5 is strictly for JDK 1.5. If you're trying to use 1.4 it will
bomb out.
Alex
On 4/22/07, CORUM, M E [AG/1000] <m....@monsanto.com> wrote:
>
>
> I wired it all up in IntelliJ because I kept finding more Jar files that
> the import utility needed so I just added all the /lib jars and set up a
> config in IntelliJ and ran it. It looks from the error like some jars
> are Java 1.4 and others are Java 1.5. Perhaps the attempt to go to Java
> 1.5 isn't complete in ApacheDS 1.5? Again, any help would be
> appreciated. I'm just trying to load the example data file. It worked
> great in 1.0.1. Should I just go back to 1.0.1 and continue trying to
> figure out the Kerberos there?
>
> MikeC
>
> Exception in thread "main" java.lang.IncompatibleClassChangeError
> at
> org.apache.directory.shared.asn1.ber.grammar.AbstractGrammar.<clinit>(Ab
> stractGrammar.java:48)
> at
> org.apache.directory.shared.ldap.codec.LdapMessageContainer.<init>(LdapM
> essageContainer.java:76)
> at
> org.apache.directory.shared.ldap.codec.LdapMessageContainer.<init>(LdapM
> essageContainer.java:64)
> at
> org.apache.directory.server.tools.commands.importcmd.ImportCommandExecut
> or.<init>(ImportCommandExecutor.java:114)
> at
> org.apache.directory.server.tools.commands.importcmd.ImportCommandExecut
> orSkeleton.execute(ImportCommandExecutorSkeleton.java:34)
> at
> org.apache.directory.server.tools.commands.importcmd.ImportCommandExecut
> orStub.execute(ImportCommandExecutorStub.java:36)
> at
> org.apache.directory.server.tools.request.BaseToolCommandCL.execute(Base
> ToolCommandCL.java:67)
> at
> org.apache.directory.server.tools.ApachedsTools.main(ApachedsTools.java:
> 122)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
> a:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> Impl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
>
> -----Original Message-----
> From: CORUM, M E [AG/1000] [mailto:m.e.corum@monsanto.com]
> Sent: Sunday, April 22, 2007 9:13 PM
> To: users@directory.apache.org
> Subject: RE: [ApacheDS] 1.5 Experience Not Good on Windows
>
>
> Have others successfully installed and run 1.5 if they previously had
> 1.0.1 (on Windows)? The reason I ask is that the 1.5 installer doesn't
> work unless you not only uninstall 1.0.1 but manually edit the Windows
> registry to fix up the paths. Once I did that, I could get the server
> to come up.
>
> The next problem comes when I try to import the example data like I did
> in my 1.0.1 server. When I run the import in 1.5, I get:
>
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/directory/shared/asn1/Asn1Object
> at
> org.apache.directory.server.tools.commands.importcmd.ImportCommandExe
> cutorSkeleton.execute(ImportCommandExecutorSkeleton.java:34)
> at
> org.apache.directory.server.tools.commands.importcmd.ImportCommandExe
> cutorStub.execute(ImportCommandExecutorStub.java:36)
> at
> org.apache.directory.server.tools.request.BaseToolCommandCL.execute(B
> aseToolCommandCL.java:67)
> at
> org.apache.directory.server.tools.ApachedsTools.main(ApachedsTools.ja
> va:122)
>
> The interesting thing is that I still get it even if I add a -classpath
> to include the shared-asn1-0.9.6.jar which has that class. Here is the
> command:
>
> C:\apacheds-1.5\bin>java -classpath
> C:\apacheds-1.5\lib\shared-asn1-0.9.6.jar -jar apacheds-tools.jar import
> -f data.ldif -w somedifferentpassword
>
> I was hoping that the Kerberos stuff worked better in 1.5 (I couldn't
> get it to work in 1.0.1 even after finding the hidden docs on the
> internet).
>
> Any help would be much appreciated.
>
> MikeC
>
>
>
>
> ------------------------------------------------------------------------
> ---------------------------------
> This e-mail message may contain privileged and/or confidential
> information, and is intended to be received only by persons entitled to
> receive such information. If you have received this e-mail in error,
> please notify the sender immediately. Please delete it and all
> attachments from any servers, hard drives or any other media. Other use
> of this e-mail by you is strictly prohibited.
>
>
> All e-mails and attachments sent and received are subject to monitoring,
> reading and archival by Monsanto. The recipient of this e-mail is solely
> responsible for checking for the presence of "Viruses" or other
> "Malware". Monsanto accepts no liability for any damage caused by any
> such code transmitted by or accompanying this e-mail or any attachment.
> ------------------------------------------------------------------------
> ---------------------------------
>
>
>
>
> ---------------------------------------------------------------------------------------------------------
> This e-mail message may contain privileged and/or confidential
> information, and is intended to be received only by persons entitled to
> receive such information. If you have received this e-mail in error, please
> notify the sender immediately. Please delete it and all attachments from any
> servers, hard drives or any other media. Other use of this e-mail by you is
> strictly prohibited.
>
>
> All e-mails and attachments sent and received are subject to monitoring,
> reading and archival by Monsanto. The recipient of this e-mail is solely
> responsible for checking for the presence of "Viruses" or other "Malware".
> Monsanto accepts no liability for any damage caused by any such code
> transmitted by or accompanying this e-mail or any attachment.
>
> ---------------------------------------------------------------------------------------------------------
>
>
RE: [ApacheDS] 1.5 Experience Not Good on Windows - More Info - Trying to get basic Import to Work
Posted by "CORUM, M E [AG/1000]" <m....@monsanto.com>.
I wired it all up in IntelliJ because I kept finding more Jar files that
the import utility needed so I just added all the /lib jars and set up a
config in IntelliJ and ran it. It looks from the error like some jars
are Java 1.4 and others are Java 1.5. Perhaps the attempt to go to Java
1.5 isn't complete in ApacheDS 1.5? Again, any help would be
appreciated. I'm just trying to load the example data file. It worked
great in 1.0.1. Should I just go back to 1.0.1 and continue trying to
figure out the Kerberos there?
MikeC
Exception in thread "main" java.lang.IncompatibleClassChangeError
at
org.apache.directory.shared.asn1.ber.grammar.AbstractGrammar.<clinit>(Ab
stractGrammar.java:48)
at
org.apache.directory.shared.ldap.codec.LdapMessageContainer.<init>(LdapM
essageContainer.java:76)
at
org.apache.directory.shared.ldap.codec.LdapMessageContainer.<init>(LdapM
essageContainer.java:64)
at
org.apache.directory.server.tools.commands.importcmd.ImportCommandExecut
or.<init>(ImportCommandExecutor.java:114)
at
org.apache.directory.server.tools.commands.importcmd.ImportCommandExecut
orSkeleton.execute(ImportCommandExecutorSkeleton.java:34)
at
org.apache.directory.server.tools.commands.importcmd.ImportCommandExecut
orStub.execute(ImportCommandExecutorStub.java:36)
at
org.apache.directory.server.tools.request.BaseToolCommandCL.execute(Base
ToolCommandCL.java:67)
at
org.apache.directory.server.tools.ApachedsTools.main(ApachedsTools.java:
122)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
-----Original Message-----
From: CORUM, M E [AG/1000] [mailto:m.e.corum@monsanto.com]
Sent: Sunday, April 22, 2007 9:13 PM
To: users@directory.apache.org
Subject: RE: [ApacheDS] 1.5 Experience Not Good on Windows
Have others successfully installed and run 1.5 if they previously had
1.0.1 (on Windows)? The reason I ask is that the 1.5 installer doesn't
work unless you not only uninstall 1.0.1 but manually edit the Windows
registry to fix up the paths. Once I did that, I could get the server
to come up.
The next problem comes when I try to import the example data like I did
in my 1.0.1 server. When I run the import in 1.5, I get:
Exception in thread "main" java.lang.NoClassDefFoundError:
org/apache/directory/shared/asn1/Asn1Object
at
org.apache.directory.server.tools.commands.importcmd.ImportCommandExe
cutorSkeleton.execute(ImportCommandExecutorSkeleton.java:34)
at
org.apache.directory.server.tools.commands.importcmd.ImportCommandExe
cutorStub.execute(ImportCommandExecutorStub.java:36)
at
org.apache.directory.server.tools.request.BaseToolCommandCL.execute(B
aseToolCommandCL.java:67)
at
org.apache.directory.server.tools.ApachedsTools.main(ApachedsTools.ja
va:122)
The interesting thing is that I still get it even if I add a -classpath
to include the shared-asn1-0.9.6.jar which has that class. Here is the
command:
C:\apacheds-1.5\bin>java -classpath
C:\apacheds-1.5\lib\shared-asn1-0.9.6.jar -jar apacheds-tools.jar import
-f data.ldif -w somedifferentpassword
I was hoping that the Kerberos stuff worked better in 1.5 (I couldn't
get it to work in 1.0.1 even after finding the hidden docs on the
internet).
Any help would be much appreciated.
MikeC
------------------------------------------------------------------------
---------------------------------
This e-mail message may contain privileged and/or confidential
information, and is intended to be received only by persons entitled to
receive such information. If you have received this e-mail in error,
please notify the sender immediately. Please delete it and all
attachments from any servers, hard drives or any other media. Other use
of this e-mail by you is strictly prohibited.
All e-mails and attachments sent and received are subject to monitoring,
reading and archival by Monsanto. The recipient of this e-mail is solely
responsible for checking for the presence of "Viruses" or other
"Malware". Monsanto accepts no liability for any damage caused by any
such code transmitted by or accompanying this e-mail or any attachment.
------------------------------------------------------------------------
---------------------------------
---------------------------------------------------------------------------------------------------------
This e-mail message may contain privileged and/or confidential information, and is intended to be received only by persons entitled to receive such information. If you have received this e-mail in error, please notify the sender immediately. Please delete it and all attachments from any servers, hard drives or any other media. Other use of this e-mail by you is strictly prohibited.
All e-mails and attachments sent and received are subject to monitoring, reading and archival by Monsanto. The recipient of this e-mail is solely responsible for checking for the presence of "Viruses" or other "Malware". Monsanto accepts no liability for any damage caused by any such code transmitted by or accompanying this e-mail or any attachment.
---------------------------------------------------------------------------------------------------------
RE: [ApacheDS] 1.5 Experience Not Good on Windows
Posted by "CORUM, M E [AG/1000]" <m....@monsanto.com>.
Have others successfully installed and run 1.5 if they previously had
1.0.1 (on Windows)? The reason I ask is that the 1.5 installer doesn't
work unless you not only uninstall 1.0.1 but manually edit the Windows
registry to fix up the paths. Once I did that, I could get the server
to come up.
The next problem comes when I try to import the example data like I did
in my 1.0.1 server. When I run the import in 1.5, I get:
Exception in thread "main" java.lang.NoClassDefFoundError:
org/apache/directory/shared/asn1/Asn1Object
at
org.apache.directory.server.tools.commands.importcmd.ImportCommandExe
cutorSkeleton.execute(ImportCommandExecutorSkeleton.java:34)
at
org.apache.directory.server.tools.commands.importcmd.ImportCommandExe
cutorStub.execute(ImportCommandExecutorStub.java:36)
at
org.apache.directory.server.tools.request.BaseToolCommandCL.execute(B
aseToolCommandCL.java:67)
at
org.apache.directory.server.tools.ApachedsTools.main(ApachedsTools.ja
va:122)
The interesting thing is that I still get it even if I add a -classpath
to include the shared-asn1-0.9.6.jar which has that class. Here is the
command:
C:\apacheds-1.5\bin>java -classpath
C:\apacheds-1.5\lib\shared-asn1-0.9.6.jar -jar apacheds-tools.jar import
-f data.ldif -w somedifferentpassword
I was hoping that the Kerberos stuff worked better in 1.5 (I couldn't
get it to work in 1.0.1 even after finding the hidden docs on the
internet).
Any help would be much appreciated.
MikeC
---------------------------------------------------------------------------------------------------------
This e-mail message may contain privileged and/or confidential information, and is intended to be received only by persons entitled to receive such information. If you have received this e-mail in error, please notify the sender immediately. Please delete it and all attachments from any servers, hard drives or any other media. Other use of this e-mail by you is strictly prohibited.
All e-mails and attachments sent and received are subject to monitoring, reading and archival by Monsanto. The recipient of this e-mail is solely responsible for checking for the presence of "Viruses" or other "Malware". Monsanto accepts no liability for any damage caused by any such code transmitted by or accompanying this e-mail or any attachment.
---------------------------------------------------------------------------------------------------------