(sorry if this appears twice, I've posted this some time ago before I was subscribed to the list and it didn't seem to appear)
I'm trying to migrate an LDAP from Solaris/OpenLDAP 2.3 to Linux/OpenLDAP 2.4, and I have an issue with a custom schema:
# slaptest -f etc/slapd.conf /data/openldap/etc/schema/nxx.schema: line 10 attributetype: Inconsistent duplicate attributeType: "memberOf"
Now the problem is, I have no idea where this previous definiton of memberOf comes from....
These are the included schemas:
# grep include etc/slapd.conf include /data/openldap/etc/schema/core.schema include /data/openldap/etc/schema/cosine.schema include /data/openldap/etc/schema/inetorgperson.schema include /data/openldap/etc/schema/nis.schema include /data/openldap/etc/schema/nxx.schema
And none of them besides nxx defines a memberOf:
# grep memberOf etc/schema/* etc/schema/nxx.schema:attributetype ( NxxLDAPattributeType:1 NAME 'memberOf' etc/schema/nxx.schema: MAY ( memberOf $ host $ lastLogin $ passwordHistory $ loginFailures $ passwordRecoveryMailAddress $ passwordRecoveryChallenge) )
<end of grep output>
Also, nxx defines it only once (it's pasted below).
After commenting nxx and generating a config directory with slaptest, I found this in cn=schema.ldif:
# grep memberOf openldap-config/cn=config/cn=schema.ldif olcAttributeTypes: ( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC 'Group that t
Where does this come from? Apparently not from the schemas I included, as a grep for memberOf doesn't return anything. There are also no other includes in these schema files. Is there any default schema data included besides what is given in include statements? Can I somehow get rid of this?
Any help appreciated. Also I know that the attribute in the custom schema had better been prefixed, but this is an installation running since 2004 and "memberOf" is in scripts all over the place, so I'd rather not rename it.
Thanks Christian
nxx.schema
objectIdentifier NxxRoot 1.3.6.1.4.1.21654
objectIdentifier NxxLDAP NxxRoot:3 objectIdentifier NxxLDAPattributeType NxxLDAP:1 objectIdentifier NxxLDAPobjectClass NxxLDAP:2
attributetype ( NxxLDAPattributeType:1 NAME 'memberOf' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
# for password aging attributetype ( NxxLDAPattributeType:2 NAME 'lastLogin' DESC 'Stores the last successful login of a user' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
attributetype ( NxxLDAPattributeType:3 NAME 'passwordHistory' DESC 'Stores all password ever used by a user' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( NxxLDAPattributeType:4 NAME 'loginFailures' DESC 'Stores successives login failures for a user' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
attributetype ( NxxLDAPattributeType:5 NAME 'passwordRecoveryMailAddress' EQUALITY caseExactIA5Match DESC 'Stores mail address for self password recovery' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( NxxLDAPattributeType:6 NAME 'passwordRecoveryChallenge' DESC 'Stores challenge for self password recovery' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
objectclass ( NxxLDAPobjectClass:1 NAME 'OssAccount' SUP top AUXILIARY DESC 'Additional attributes for OSS Accounts' MUST uid MAY ( memberOf $ host $ lastLogin $ passwordHistory $ loginFailures $ passwordRecoveryMailAddress $ passwordRecoveryChallenge) )
objectclass ( NxxLDAPobjectClass:2 NAME 'OssHost' SUP top AUXILIARY DESC 'Additional attributes for OSS Accounts' MUST uid MAY ( host ) )
My mail still doesn't seem to have reached the list, if it ever does:
I've found that the memberOf Attribute is added to the schema by the memberof overlay. As I'm required to use the RPM that comes with SusE SLES, I gave in and renamed the attribute in our schema - case closed :)
On 7/13/11 5:32 PM, Christian Ramseyer wrote:
(sorry if this appears twice, I've posted this some time ago before I was subscribed to the list and it didn't seem to appear)
I'm trying to migrate an LDAP from Solaris/OpenLDAP 2.3 to Linux/OpenLDAP 2.4, and I have an issue with a custom schema:
# slaptest -f etc/slapd.conf /data/openldap/etc/schema/nxx.schema: line 10 attributetype: Inconsistent duplicate attributeType: "memberOf"
Now the problem is, I have no idea where this previous definiton of memberOf comes from....
These are the included schemas:
# grep include etc/slapd.conf include /data/openldap/etc/schema/core.schema include /data/openldap/etc/schema/cosine.schema include /data/openldap/etc/schema/inetorgperson.schema include /data/openldap/etc/schema/nis.schema include /data/openldap/etc/schema/nxx.schema
And none of them besides nxx defines a memberOf:
# grep memberOf etc/schema/* etc/schema/nxx.schema:attributetype ( NxxLDAPattributeType:1 NAME 'memberOf' etc/schema/nxx.schema: MAY ( memberOf $ host $ lastLogin $ passwordHistory $ loginFailures $ passwordRecoveryMailAddress $ passwordRecoveryChallenge) )
<end of grep output>
Also, nxx defines it only once (it's pasted below).
After commenting nxx and generating a config directory with slaptest, I found this in cn=schema.ldif:
# grep memberOf openldap-config/cn=config/cn=schema.ldif olcAttributeTypes: ( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC 'Group that t
Where does this come from? Apparently not from the schemas I included, as a grep for memberOf doesn't return anything. There are also no other includes in these schema files. Is there any default schema data included besides what is given in include statements? Can I somehow get rid of this?
Any help appreciated. Also I know that the attribute in the custom schema had better been prefixed, but this is an installation running since 2004 and "memberOf" is in scripts all over the place, so I'd rather not rename it.
Thanks Christian
nxx.schema
objectIdentifier NxxRoot 1.3.6.1.4.1.21654
objectIdentifier NxxLDAP NxxRoot:3 objectIdentifier NxxLDAPattributeType NxxLDAP:1 objectIdentifier NxxLDAPobjectClass NxxLDAP:2
attributetype ( NxxLDAPattributeType:1 NAME 'memberOf' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
# for password aging attributetype ( NxxLDAPattributeType:2 NAME 'lastLogin' DESC 'Stores the last successful login of a user' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
attributetype ( NxxLDAPattributeType:3 NAME 'passwordHistory' DESC 'Stores all password ever used by a user' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( NxxLDAPattributeType:4 NAME 'loginFailures' DESC 'Stores successives login failures for a user' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
attributetype ( NxxLDAPattributeType:5 NAME 'passwordRecoveryMailAddress' EQUALITY caseExactIA5Match DESC 'Stores mail address for self password recovery' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( NxxLDAPattributeType:6 NAME 'passwordRecoveryChallenge' DESC 'Stores challenge for self password recovery' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
objectclass ( NxxLDAPobjectClass:1 NAME 'OssAccount' SUP top AUXILIARY DESC 'Additional attributes for OSS Accounts' MUST uid MAY ( memberOf $ host $ lastLogin $ passwordHistory $ loginFailures $ passwordRecoveryMailAddress $ passwordRecoveryChallenge) )
objectclass ( NxxLDAPobjectClass:2 NAME 'OssHost' SUP top AUXILIARY DESC 'Additional attributes for OSS Accounts' MUST uid MAY ( host ) )
On 07/13/2011 05:32 PM, Christian Ramseyer wrote:
(sorry if this appears twice, I've posted this some time ago before I was subscribed to the list and it didn't seem to appear)
I'm trying to migrate an LDAP from Solaris/OpenLDAP 2.3 to Linux/OpenLDAP 2.4, and I have an issue with a custom schema:
# slaptest -f etc/slapd.conf /data/openldap/etc/schema/nxx.schema: line 10 attributetype: Inconsistent duplicate attributeType: "memberOf"
Now the problem is, I have no idea where this previous definiton of memberOf comes from....
These are the included schemas:
# grep include etc/slapd.conf include /data/openldap/etc/schema/core.schema include /data/openldap/etc/schema/cosine.schema include /data/openldap/etc/schema/inetorgperson.schema include /data/openldap/etc/schema/nis.schema include /data/openldap/etc/schema/nxx.schema
And none of them besides nxx defines a memberOf:
# grep memberOf etc/schema/* etc/schema/nxx.schema:attributetype ( NxxLDAPattributeType:1 NAME 'memberOf' etc/schema/nxx.schema: MAY ( memberOf $ host $ lastLogin $ passwordHistory $ loginFailures $ passwordRecoveryMailAddress $ passwordRecoveryChallenge) )
<end of grep output>
Also, nxx defines it only once (it's pasted below).
After commenting nxx and generating a config directory with slaptest, I found this in cn=schema.ldif:
# grep memberOf openldap-config/cn=config/cn=schema.ldif olcAttributeTypes: ( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC 'Group that t
Where does this come from? Apparently not from the schemas I included, as a grep for memberOf doesn't return anything. There are also no other includes in these schema files. Is there any default schema data included besides what is given in include statements? Can I somehow get rid of this?
Any help appreciated. Also I know that the attribute in the custom schema had better been prefixed, but this is an installation running since 2004 and "memberOf" is in scripts all over the place, so I'd rather not rename it.
It's hardcoded in the slapo-memberof(5) overlay.
p.
On 7/19/11 12:50 PM, Pierangelo Masarati wrote:
On 07/13/2011 05:32 PM, Christian Ramseyer wrote:
# grep memberOf openldap-config/cn=config/cn=schema.ldif olcAttributeTypes: ( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC 'Group that t
Where does this come from? Apparently not from the schemas I included, as a grep for memberOf doesn't return anything. There are also no other includes in these schema files. Is there any default schema data included besides what is given in include statements? Can I somehow get rid of this?
It's hardcoded in the slapo-memberof(5) overlay.
p.
Hi Pierangelo
Thanks for your response, my mail took some time to appear on the list and in the meantime I've found the piece of code in the overlay that adds it.
I have renamed the conflicting attribute in our schema, fixing the queries in the software that uses it wasn't as complicated as I thought.
Christian
openldap-technical@openldap.org