Attribute type is operational
Hi, I'm running Openldap 2.4 on Rhel5. I've got the basics working, user accounts etc, but have tried adding some new schemas which I'm getting problems with. I followed a VERY helpful Blog at http://oracle-cookies.blogspot.com/2007/01/get-tnsnamesora-from-openldap.html which allowed me to install some Oracle OID schema's so we can move away from Oracle OID. This Blog is a little out of date and I have some attributetypes which I need to add-in to the schema. I've added the following 2 lines: attributetypes ( 2.16.840.1.113894.1.1.37 NAME 'orclGuid' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) attributetypes ( 2.16.840.1.113894.1.1.1000 NAME 'orclnormdn' EQUALITY distinguishedNameMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) I took these from the current 10.2.0 OID installation so wasn't 100% sure they were correct but they are similar in construct the others found on the blog. When I restart ldap2.4 I get error: service ldap2.4 restart Checking config file /etc/openldap2.4/slapd.conf: [FAILED] /etc/openldap2.4/schema/oidbase.schema: line 27 attributetypes: 2.16.840.1.113894.1.1.37 is operational slaptest2.4: bad configuration file! Having Googled it, I found this to mean that the attributetype had already been declared but I cannot find where, I checked in my current schemas and the defaults under /usr/share/openldap2.4/schema but found nothing. Anyone help here? Thanks, Stuart Cherrington. _ http://clk.atdmt.com/UKM/go/19780/direct/01/ Do you have a story that started on Hotmail? Tell us now
Re: Attribute type is operational
On Mon, 12 Jul 2010 08:10:56 +, Stuart Cherrington stuart_cherring...@hotmail.co.uk wrote: Hi, I'm running Openldap 2.4 on Rhel5. I've got the basics working, user accounts etc, but have tried adding some new schemas which I'm getting problems with. I followed a VERY helpful Blog at http://oracle-cookies.blogspot.com/2007/01/get-tnsnamesora-from-openldap.html which allowed me to install some Oracle OID schema's so we can move away from Oracle OID. This Blog is a little out of date and I have some attributetypes which I need to add-in to the schema. I've added the following 2 lines: attributetypes ( 2.16.840.1.113894.1.1.37 NAME 'orclGuid' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) attributetypes ( 2.16.840.1.113894.1.1.1000 NAME 'orclnormdn' EQUALITY distinguishedNameMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) I took these from the current 10.2.0 OID installation so wasn't 100% sure they were correct but they are similar in construct the others found on the blog. When I restart ldap2.4 I get error: service ldap2.4 restart Checking config file /etc/openldap2.4/slapd.conf: [FAILED] /etc/openldap2.4/schema/oidbase.schema: line 27 attributetypes: 2.16.840.1.113894.1.1.37 is operational slaptest2.4: bad configuration file! This error message is complaining that the attributetype declared is an operational attribute (USAGE directoryOperation). Reading through the code, I see the following comment: operational attributes should be defined internally. I therefore presume that you cannot define operational attributes by way of schema files. These attributes won't be operational anyway in the sense that they will not be automatically managed by the OpenLDAP server, since it knows nothing about them. If you just need them for compatibility with OID, I suggest you change the declaration to make them non-operational. You'll probably want to remove the NO-USER-MODIFICATION flag too, if you want to be able to modify them with user accounts. Hope this helps. Regards, Jonathan
Re: Attribute type is operational
Jonathan Clarke wrote: On Mon, 12 Jul 2010 08:10:56 +, Stuart Cherrington stuart_cherring...@hotmail.co.uk wrote: Hi, I'm running Openldap 2.4 on Rhel5. I've got the basics working, user accounts etc, but have tried adding some new schemas which I'm getting problems with. I followed a VERY helpful Blog at http://oracle-cookies.blogspot.com/2007/01/get-tnsnamesora-from-openldap.html which allowed me to install some Oracle OID schema's so we can move away from Oracle OID. This Blog is a little out of date and I have some attributetypes which I need to add-in to the schema. I've added the following 2 lines: attributetypes ( 2.16.840.1.113894.1.1.37 NAME 'orclGuid' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) attributetypes ( 2.16.840.1.113894.1.1.1000 NAME 'orclnormdn' EQUALITY distinguishedNameMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) I took these from the current 10.2.0 OID installation so wasn't 100% sure they were correct but they are similar in construct the others found on the blog. When I restart ldap2.4 I get error: service ldap2.4 restart Checking config file /etc/openldap2.4/slapd.conf: [FAILED] /etc/openldap2.4/schema/oidbase.schema: line 27 attributetypes: 2.16.840.1.113894.1.1.37 is operational slaptest2.4: bad configuration file! This error message is complaining that the attributetype declared is an operational attribute (USAGE directoryOperation). Reading through the code, I see the following comment: operational attributes should be defined internally. I therefore presume that you cannot define operational attributes by way of schema files. Correct. Operational attributes are, by definition, used internally by a directory server. They have no meaning unless you provide code that implements them. These attributes won't be operational anyway in the sense that they will not be automatically managed by the OpenLDAP server, since it knows nothing about them. If you just need them for compatibility with OID, I suggest you change the declaration to make them non-operational. You'll probably want to remove the NO-USER-MODIFICATION flag too, if you want to be able to modify them with user accounts. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
