Hi,
When starting openldap, i'm getting this error:
line 27 (modulepath /usr/lib/openldap) /usr/local/etc/openldap/slapd.conf: line 27: keyword <modulepath> ignored
I'm using openldap-2.4.25 on CentOs 5.
The config command was: export LDFLAGS='-L/usr/local/lib -L/usr/local/lib -L/usr/local/lib' export CPPFLAGS='-I/usr/local/include -I/usr/local/include -I/usr/local/include' ./configure --enable-bdb --enable-crypt --with-tls --enable-overlays=mod --enable-modules=yes --enable-ppolicy=mod --libexecdir=/usr/sbin
Any help ???
TIA Sarath
sarath chandra writes:
line 27 (modulepath /usr/lib/openldap) /usr/local/etc/openldap/slapd.conf: line 27: keyword <modulepath> ignored
That's supposed to mean slapd was compiled without --enable-modules, so only statically linked modules will be available.
I'm using openldap-2.4.25 on CentOs 5.
The config command was: export LDFLAGS='-L/usr/local/lib -L/usr/local/lib -L/usr/local/lib' export CPPFLAGS='-I/usr/local/include -I/usr/local/include -I/usr/local/include' ./configure --enable-bdb --enable-crypt --with-tls --enable-overlays=mod --enable-modules=yes --enable-ppolicy=mod --libexecdir=/usr/sbin
Maybe that config command is for some other slapd executable than the one you are running?
Hi fellows,
-------------------------------- OpenLDAP 2.4.24, built from sources. Ubuntu 10.10 debug : -1 config : ldif format, no slapd.conf --------------------------------
I'm facing some weird issue while trying to inject an new AttributeType using a modify operation :
#!ERROR [LDAP: error code 21 - attributeTypes: value #0 invalid per syntax] dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.18060.0.4.1.2.10001 NAME 'type1' SUP name ) -
I'm a bit surprised, the syntax is perfectly valid (spaces are present, order of elements is correct) and it works fine in ApacheDS.
Is there something obvious I'm missing ?
Emmanuel Lecharny writes:
#!ERROR [LDAP: error code 21 - attributeTypes: value #0 invalid per syntax] dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.18060.0.4.1.2.10001 NAME 'type1' SUP name )
See the admin guide. In OpenLDAP you add schema by modifying a schema below cn=schema,cn=config, and you set 'olcAttributeTypes' rather than 'attributeTypes'.
OTOH you can *read* the full schema controlling an entry from the DN named by that entry's subschemaSubentry attribute. In OpenLDAP, that defaults to cn=subschema, not cn=schema.
On 4/11/11 3:21 PM, Hallvard B Furuseth wrote:
Emmanuel Lecharny writes:
#!ERROR [LDAP: error code 21 - attributeTypes: value #0 invalid per syntax] dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.18060.0.4.1.2.10001 NAME 'type1' SUP name )
See the admin guide. In OpenLDAP you add schema by modifying a schema below cn=schema,cn=config, and you set 'olcAttributeTypes' rather than 'attributeTypes'.
Makes sense... Although the error message is extremely misleading :/
Ok, get it. It would be cool (tm) that OpenLDAP accepts direct modifications of the schema through LDAP requests.
Emmanuel Lécharny writes:
On 4/11/11 3:21 PM, Hallvard B Furuseth wrote:
Emmanuel Lecharny writes:
#!ERROR [LDAP: error code 21 - attributeTypes: value #0 invalid per syntax]
(...) See the admin guide. In OpenLDAP you add schema by modifying a schema below cn=schema,cn=config, and you set 'olcAttributeTypes' rather than 'attributeTypes'.
Makes sense... Although the error message is extremely misleading :/
Yes, OpenLDAP could use an effort to improve error messages.
Ok, get it. It would be cool (tm) that OpenLDAP accepts direct modifications of the schema through LDAP requests.
Eh? You can, that's why cn=config exists. Just set up some DN to have write access to it. Normally a rootdn for database config.
It's just that you can't modify cn=subschema directly - then slapd wouldn't know in which schema entry to store the attribute. Look at ldapsearch ... -LLL -b cn=schema,cn=config -s one 1.1 which has one entry per schema file originally loaded into slapd.
Hallvard B Furuseth wrote:
Emmanuel Lécharny writes:
On 4/11/11 3:21 PM, Hallvard B Furuseth wrote:
Emmanuel Lecharny writes:
#!ERROR [LDAP: error code 21 - attributeTypes: value #0 invalid per syntax]
(...) See the admin guide. In OpenLDAP you add schema by modifying a schema below cn=schema,cn=config, and you set 'olcAttributeTypes' rather than 'attributeTypes'.
Makes sense... Although the error message is extremely misleading :/
Yes, OpenLDAP could use an effort to improve error messages.
Ok, get it. It would be cool (tm) that OpenLDAP accepts direct modifications of the schema through LDAP requests.
Eh? You can, that's why cn=config exists. Just set up some DN to have write access to it. Normally a rootdn for database config.
It's just that you can't modify cn=subschema directly - then slapd wouldn't know in which schema entry to store the attribute. Look at ldapsearch ... -LLL -b cn=schema,cn=config -s one 1.1 which has one entry per schema file originally loaded into slapd.
In principle, one could modify cn=schema by using back-relay and a slapo-rwm that maps "cn=schema" to the appropriate "cn=config" node, and attributeTypes to olcAttributeTypes.
p.
Pierangelo Masarati writes:
In principle, one could modify cn=schema by using back-relay and a slapo-rwm that maps "cn=schema" to the appropriate "cn=config" node, and attributeTypes to olcAttributeTypes.
Nice. But what's the appropriate "cn=config" node? I think you'd have to map cn=schema cn=schema,cn=config. Or maybe call it cn=schema-config, to avoid confusing apps which do not expect cn=schema to be a tree.
On 4/12/11 10:08 AM, Hallvard B Furuseth wrote:
Ok, get it. It would be cool (tm) that OpenLDAP accepts direct modifications of the schema through LDAP requests.
Eh? You can, that's why cn=config exists. Just set up some DN to have write access to it. Normally a rootdn for database config.
No, you can't if you want to use the syntax for AttributeType/OvjecClass. You have to use a specific LDIF format, and this is the key we were discussing with some peeps : how to modify schema for existing Ldap server in a portable way (more specifically, it would be useful in Apache Directory Studio).
Of course, using a LDIF format with olcXXX AT is working, but it's non standard.
As I said, it would be very cool if OpenLDAP were allowing the schema modification through direct LDAP modify request on cn=subschema... (of course, ths has many implication : saving the data into cn=schema, make the server switch the schema internally without restarting it, etc, etc...)
Not a piece of cake !
Emmanuel Lécharny writes:
On 4/12/11 10:08 AM, Hallvard B Furuseth wrote:
Ok, get it. It would be cool (tm) that OpenLDAP accepts direct modifications of the schema through LDAP requests.
Eh? You can, that's why cn=config exists. Just set up some DN to have write access to it. Normally a rootdn for database config.
No, you can't if you want to use the syntax for AttributeType/OvjecClass. You have to use a specific LDIF format, and this is the key we were discussing with some peeps : how to modify schema for existing Ldap server in a portable way (more specifically, it would be useful in Apache Directory Studio).
Well, that's not what you said. Anyway, yes it would be friendly if OpenLDAP used the same attribute types for reading and writing schema, without an 'olc' prefix for writing. I presume there's a good reason it doesn't, and I don't know how hard that would be to change.
But beyond that, server administration is not part of the LDAP standard. There's no portable way to administer LDAP servers. If Apache Directory Studio thinks there is, that's a limitation of that application, not of any server implementation.
Of course, using a LDIF format with olcXXX AT is working, but it's non standard.
As I said, it would be very cool if OpenLDAP were allowing the schema modification through direct LDAP modify request on cn=subschema... (of course, ths has many implication : saving the data into cn=schema, make the server switch the schema internally without restarting it, etc, etc...)
That happens if you just modify the correct schema entry. But a modify request against cn=subschema lacks information about how to administer the schema change - i.e. which cn=schema child to put it in.
Not a piece of cake !
On 4/12/11 11:27 AM, Hallvard B Furuseth wrote:
Emmanuel Lécharny writes:
On 4/12/11 10:08 AM, Hallvard B Furuseth wrote:
Ok, get it. It would be cool (tm) that OpenLDAP accepts direct modifications of the schema through LDAP requests.
Eh? You can, that's why cn=config exists. Just set up some DN to have write access to it. Normally a rootdn for database config.
No, you can't if you want to use the syntax for AttributeType/OvjecClass. You have to use a specific LDIF format, and this is the key we were discussing with some peeps : how to modify schema for existing Ldap server in a portable way (more specifically, it would be useful in Apache Directory Studio).
Well, that's not what you said.
Yeah, sorry, I was a bit rough and fuzzy in my first mail...
Anyway, yes it would be friendly if OpenLDAP used the same attribute types for reading and writing schema, without an 'olc' prefix for writing. I presume there's a good reason it doesn't, and I don't know how hard that would be to change.
It's not easy... But definitively feasible. Too sad I don't code in C any more :-)
But beyond that, server administration is not part of the LDAP standard. There's no portable way to administer LDAP servers. If Apache Directory Studio thinks there is, that's a limitation of that application, not of any server implementation.
RFC 4512 says explicitely (chap 4.2) : "Servers MAY allow subschema modification. Procedures for subschema modification are discussed in Section 14.5 of [X.501]." (btw, it's 15.5, NOT 14.5...)
In X/500, such modification is to be supported, but it might have been considered as a rigid constraint in LDAP.
However, Studio does not care if OpenLDAP support or not such a feature. It will provide a way to update OpenLDAP schema whatever the way we have to do it, it's just painful that we can't do it in a more standard (ie X500) way...
Not to mention that someone who want to address this very problem (ie, updating the schema) programmatically is actually totally on his own... But this is not an OpenLDAP problem, it's really a lack in LDAP specifications !
Hallvard B Furuseth wrote:
Emmanuel Lécharny writes:
On 4/12/11 10:08 AM, Hallvard B Furuseth wrote:
Ok, get it. It would be cool (tm) that OpenLDAP accepts direct modifications of the schema through LDAP requests.
Eh? You can, that's why cn=config exists. Just set up some DN to have write access to it. Normally a rootdn for database config.
No, you can't if you want to use the syntax for AttributeType/OvjecClass. You have to use a specific LDIF format, and this is the key we were discussing with some peeps : how to modify schema for existing Ldap server in a portable way (more specifically, it would be useful in Apache Directory Studio).
Well, that's not what you said. Anyway, yes it would be friendly if OpenLDAP used the same attribute types for reading and writing schema, without an 'olc' prefix for writing. I presume there's a good reason it doesn't, and I don't know how hard that would be to change.
We use a custom attributeType since ours has an ORDERED-VALUES flag in the schema definition. The generic attributeType does not, and we obviously wouldn't change the generic one to add that flag.
But beyond that, server administration is not part of the LDAP standard. There's no portable way to administer LDAP servers. If Apache Directory Studio thinks there is, that's a limitation of that application, not of any server implementation.
Of course, using a LDIF format with olcXXX AT is working, but it's non standard.
As I said, it would be very cool if OpenLDAP were allowing the schema modification through direct LDAP modify request on cn=subschema... (of course, ths has many implication : saving the data into cn=schema, make the server switch the schema internally without restarting it, etc, etc...)
That happens if you just modify the correct schema entry. But a modify request against cn=subschema lacks information about how to administer the schema change - i.e. which cn=schema child to put it in.
Not a piece of cake !
As Hallvard said, OpenLDAP already supports dynamic schema changes, and changes take effect immediately without any restart required. And, as noted, throwing all dynamic changes into a single cn=subschema subentry (or 99user.ldif as some other servers do) is messy. I prefer to keep things well organized, with related schema elements all in their own entry. This makes schema development and management a lot easier and understandable, particularly when you're wondering what schema element came from where.
The original LDAP designers obviously didn't understand schema to begin with, let alone the issues of designing and maintaining them. (Just ces and cis? Ridiculous...)
On 4/12/11 8:52 PM, Howard Chu wrote:
Not a piece of cake !
As Hallvard said, OpenLDAP already supports dynamic schema changes, and changes take effect immediately without any restart required. And, as noted, throwing all dynamic changes into a single cn=subschema subentry (or 99user.ldif as some other servers do) is messy. I prefer to keep things well organized, with related schema elements all in their own entry. This makes schema development and management a lot easier and understandable, particularly when you're wondering what schema element came from where.
We do allow modification in both cn=schema (cn=subschema in OpenLDAP) and in ou=schema (cn=schema,cn=config in OpenLDAP) in ApacheDS, and whether you modify one or the other, both are impacted.
Considering that the cn=(sub)schema is just a virtual DiT (ie, it's built on the fly when a user request it), it's should not be a real problem to update it.
What kind of problem can you foresee, Howard ?
Emmanuel Lécharny wrote:
On 4/12/11 8:52 PM, Howard Chu wrote:
Not a piece of cake !
As Hallvard said, OpenLDAP already supports dynamic schema changes, and changes take effect immediately without any restart required. And, as noted, throwing all dynamic changes into a single cn=subschema subentry (or 99user.ldif as some other servers do) is messy. I prefer to keep things well organized, with related schema elements all in their own entry. This makes schema development and management a lot easier and understandable, particularly when you're wondering what schema element came from where.
We do allow modification in both cn=schema (cn=subschema in OpenLDAP) and in ou=schema (cn=schema,cn=config in OpenLDAP) in ApacheDS, and whether you modify one or the other, both are impacted.
Considering that the cn=(sub)schema is just a virtual DiT (ie, it's built on the fly when a user request it), it's should not be a real problem to update it.
What kind of problem can you foresee, Howard ?
Performing an update is not the problem. Funneling updates of cn=subschema into meaningful branches of the schema tree is the problem.
On 4/12/11 11:19 PM, Howard Chu wrote:
Emmanuel Lécharny wrote:
On 4/12/11 8:52 PM, Howard Chu wrote:
Not a piece of cake !
As Hallvard said, OpenLDAP already supports dynamic schema changes, and changes take effect immediately without any restart required. And, as noted, throwing all dynamic changes into a single cn=subschema subentry (or 99user.ldif as some other servers do) is messy. I prefer to keep things well organized, with related schema elements all in their own entry. This makes schema development and management a lot easier and understandable, particularly when you're wondering what schema element came from where.
We do allow modification in both cn=schema (cn=subschema in OpenLDAP) and in ou=schema (cn=schema,cn=config in OpenLDAP) in ApacheDS, and whether you modify one or the other, both are impacted.
Considering that the cn=(sub)schema is just a virtual DiT (ie, it's built on the fly when a user request it), it's should not be a real problem to update it.
What kind of problem can you foresee, Howard ?
Performing an update is not the problem. Funneling updates of cn=subschema into meaningful branches of the schema tree is the problem.
Got it.
We have a workaround for that : each schema is stored in it's own sub-entry, with each schema element in a dedicated sub-entry :
ou=schema cn=core ou=attributeTypes m-oid=2.5.4.4 (sn) ... ou=objectClasses ... cn=system ...
With such a structure, the mapping is straightforward (note that we added a x-schema extension in the schema elements to retrieve the schema they will be stored in). Now, for every newly added schema element, as we can't require this x-schema to be present (otherwise it would not be portable), they will be added to a special schema file, named 'other'.
wdyt ?
Emmanuel Lécharny writes:
On 4/12/11 11:19 PM, Howard Chu wrote:
Performing an update is not the problem. Funneling updates of cn=subschema into meaningful branches of the schema tree is the problem.
Got it.
We have a workaround for that : each schema is stored in it's own sub-entry, with each schema element in a dedicated sub-entry :
ou=schema cn=core ou=attributeTypes m-oid=2.5.4.4 (sn) ... ou=objectClasses ... cn=system ...
With such a structure, the mapping is straightforward
So far, it seems just as straightforward in either implementation - same information, just arranged (or at least exposed) differently.
The difference is in what you wrote next:
(note that we added a x-schema extension in the schema elements to retrieve the schema they will be stored in).
Which means that the admin only can do half the job with standard schema syntax. With your server too, the admin still needs a non-standard syntax if he wants to finish the job and properly organize his schemas.
Now, for every newly added schema element, as we can't require this x-schema to be present (otherwise it would not be portable), they will be added to a special schema file, named 'other'.
wdyt ?
Howard already answered that:
throwing all dynamic changes into a single cn=subschema subentry (or 99user.ldif as some other servers do) is messy. I prefer to keep things well organized, with related schema elements all in their own entry. This makes schema development and management a lot easier and understandable, particularly when you're wondering what schema element came from where.
There are other ways one could specify which internal schema entry/tree to use when that is not specified in the LDAP update operation - e.g. cn=schema,cn=config & children could hold mappings from OID/schema element name to the entry which should receive the update. Not sure if that's any better. I wonder what X.500 servers do.
I wrote:
There are other ways one could specify which internal schema entry/tree to use when that is not specified in the LDAP update operation - e.g. cn=schema,cn=config & children could hold mappings from OID/schema element name to the entry which should receive the update.
I meant, a mapping using wildcards or regexps to match element OID/name.
Not sure if that's any better. I wonder what X.500 servers do.
On 4/13/11 11:40 AM, Hallvard B Furuseth wrote:
throwing all dynamic changes into a single cn=subschema subentry (or 99user.ldif as some other servers do) is messy. I prefer to keep things well organized, with related schema elements all in their own entry. This makes schema development and management a lot easier and understandable, particularly when you're wondering what schema element came from where.
There are other ways one could specify which internal schema entry/tree to use when that is not specified in the LDAP update operation - e.g. cn=schema,cn=config& children could hold mappings from OID/schema element name to the entry which should receive the update. Not sure if that's any better. I wonder what X.500 servers do.
I have no idea about how X.500 handle that.
What comes to my mind now is that we (the OSS gang) could define a common extension to help organize those added schema elements. That could help...
Emmanuel Lécharny writes:
What comes to my mind now is that we (the OSS gang) could define a common extension to help organize those added schema elements. That could help...
I'm in favor of that as long as someone else does the work:-) Don't know if I'd have time to do much about it for a while.
On 4/15/11 1:02 PM, Hallvard B Furuseth wrote:
Emmanuel Lécharny writes:
What comes to my mind now is that we (the OSS gang) could define a common extension to help organize those added schema elements. That could help...
I'm in favor of that as long as someone else does the work:-) Don't know if I'd have time to do much about it for a while.
There is no urgency... I suggest we discuss this matter during the coming OpenLDAP conference this fall, fueled by beers...
Emmanuel Lécharny writes:
There is no urgency... I suggest we discuss this matter during the coming OpenLDAP conference this fall, fueled by beers...
I've never been to LDAPCon, maybe I should go someday.
I do have one opinion: There's nothing to discuss until someone checks what the X.500 folks are doing, in case they've done it as well or better than we would.
Howard Chu writes:
Hallvard B Furuseth wrote:
(...) it would be friendly if OpenLDAP used the same attribute types for reading and writing schema, without an 'olc' prefix for writing. I presume there's a good reason it doesn't, and I don't know how hard that would be to change.
We use a custom attributeType since ours has an ORDERED-VALUES flag in the schema definition. The generic attributeType does not, and we obviously wouldn't change the generic one to add that flag.
Not sure what you mean. OpenLDAP does extend the syntax of attributeTypes and ldapSyntaxes with some 'X-...' keywords, reserved for private experiments in rfc 4512. This: ldapsearch -x -b cn=subschema -s base + |perl -p00e 's/\n //g' |grep X- shows some non-OpenLDAP syntaxes, and OpenLDAP 'olc*' attribute types.
There are a few uses of X- in etc/openldap/schema/, but only in already unportable/unsupported schemas (dyngroup and pmi).
(...) The original LDAP designers obviously didn't understand schema to begin with, let alone the issues of designing and maintaining them. (Just ces and cis? Ridiculous...)
Those were not supposed to be schema administration at all, since that was done in the X.500 server & library installation which the LDAP server was a gateway to. I remember that one of the attractions of the original LDAP for a sysadmin was getting rid of client-side schema files, or at least the requirement of keeping them updated.
Then they probably proceeded with an excessive minimalist approach as a reaction to the pointlessly heavyweight Quipu (free X.500) server, and we are still living with the consequences:-(
openldap-technical@openldap.org