Hi,
Main LDAP server is 2.4 on openSUSE. The memberof overlay is in use.
On any openSUSE clients (also OpenLDAP 2.4), ldapsearch on a uid with a '+' for the attribute arguments correctly returns the memberOf attributes as created by the overlay.
On Scientific Linux 5.4 I have a build of OpenLDAP 2.4 (not mine, supplied by our vendor which repackages some components). I've setup a proxy server there which uses slapd-ldap to proxy connections back to the openSUSE LDAP server.
On the SL system, ldapsearch talking directly to the openSUSE server correctly returns the memberOf attributes when using '+'. But when going through the local proxy server, they don't appear. The server log says "PROXIED attributeDescription "MEMBEROF" inserted"; if I specify the attribute explicitly (e.g. ldapsearch uid=liam memberof) the memberOf attributes are displayed, but all in capitals, as if there's a schema missing.
One possibly important point: we're using the rfc2307bis schema on our main server, and this isn't supplied with the SL distribution of OpenLDAP, so I've just copied it over to the SL system.
I think this suggests a broken build of OpenLDAP 2.4 supplied by our vendor, but is there anything I might be doing wrong? The proxy server's slapd.conf file is as so:
include /cm/local/apps/openldap/etc/schema/core.schema include /cm/local/apps/openldap/etc/schema/cosine.schema include /cm/local/apps/openldap/etc/schema/inetorgperson.schema include /cm/local/apps/openldap/etc/schema/rfc2307bis.schema include /cm/local/apps/openldap/etc/schema/rcsperson.schema
argsfile /var/run/openldap/slapd.args pidfile /var/run/openldap/slapd.pid
database ldap monitoring off
uri ldap://opensuse.ldapserver.example.com tls start tls_cacertdir=/etc/openldap/certs suffix dc=example,dc=com rootdn "cn=admin,dc=example,dc=com"
Hi,
Main LDAP server is 2.4 on openSUSE. The memberof overlay is in use.
On any openSUSE clients (also OpenLDAP 2.4), ldapsearch on a uid with a '+' for the attribute arguments correctly returns the memberOf attributes as created by the overlay.
On Scientific Linux 5.4 I have a build of OpenLDAP 2.4 (not mine, supplied by our vendor which repackages some components). I've setup a proxy server there which uses slapd-ldap to proxy connections back to the openSUSE LDAP server.
On the SL system, ldapsearch talking directly to the openSUSE server correctly returns the memberOf attributes when using '+'. But when going through the local proxy server, they don't appear. The server log says "PROXIED attributeDescription "MEMBEROF" inserted"; if I specify the attribute explicitly (e.g. ldapsearch uid=liam memberof) the memberOf attributes are displayed, but all in capitals, as if there's a schema missing.
The schema definition of memberOf is in fact missing in the proxy. That definition is hardcoded in slapo-memberof(5). Your build probably has slapo-memberof(5) built as module, or not built at all. You need to just load the module, so the schema definition takes place.
p.
On 27/05/2010 23:33, masarati@aero.polimi.it wrote:
The server log says "PROXIED attributeDescription "MEMBEROF" inserted"; if I specify the attribute explicitly (e.g. ldapsearch uid=liam memberof) the memberOf attributes are displayed, but all in capitals, as if there's a schema missing.
The schema definition of memberOf is in fact missing in the proxy. That definition is hardcoded in slapo-memberof(5). Your build probably has slapo-memberof(5) built as module, or not built at all. You need to just load the module, so the schema definition takes place.
Thanks - it looks like slapo-memberof hasn't been included at all in our build. I can ditch the vendor-supplied version and use our own.
masarati@aero.polimi.it wrote:
The schema definition of memberOf is in fact missing in the proxy. That definition is hardcoded in slapo-memberof(5). Your build probably has slapo-memberof(5) built as module, or not built at all. You need to just load the module, so the schema definition takes place.
To me this approach still looks wrong. It does not make sense to load an additional module non-functional in a proxy just for having the schema around. Rather slapd overlays and backends relying on a certain schema should simply check by OID whether everything is present during startup.
Ciao, Michael.
masarati@aero.polimi.it wrote:
The schema definition of memberOf is in fact missing in the proxy. That definition is hardcoded in slapo-memberof(5). Your build probably has slapo-memberof(5) built as module, or not built at all. You need to just load the module, so the schema definition takes place.
To me this approach still looks wrong. It does not make sense to load an additional module non-functional in a proxy just for having the schema around. Rather slapd overlays and backends relying on a certain schema should simply check by OID whether everything is present during startup.
There is a good reason: slapd does not allow to define via configuration operational attributes. This is a legacy of the pre-module, pre-overlay time, when it as obvious that operational attributes could only be used in conjunction with the code that dealt with them. ITS#5714 is about that.
However, I see some good reason in defining middleware specific schema through the middleware that uses them: compactness, and guarantee that the module and its schema are consistent. Moreover, if anyone using slapo-memberof(5) were to load memberof.schema first, we'd see many complaints like "slapd doesn't start; it says 'load memberof.schema first'; what am I supposed to do?"
p.
openldap-technical@openldap.org
-
Liam Gretton -
masarati＠aero.polimi.it -
Michael Ströder