It might be more appropriate to handle this issue on the consumer than the provider. An arbitrary LDAP sync client might want this and other DSA specific attributes included in the content. That is, the provider should not assume the consumer is doing server-to-server replication.
Kurt
At 01:10 PM 12/23/2006, hyc@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays
Modified Files: accesslog.c 1.68 -> 1.69
Log Message: ITS#4788 don't return auditContext attr on syncrepl searches
CVS Web URLs: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/ http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/accesslog.c
Changes are generally available on cvs.openldap.org (and CVSweb) within 30 minutes of being committed.
Kurt D. Zeilenga wrote:
It might be more appropriate to handle this issue on the consumer than the provider. An arbitrary LDAP sync client might want this and other DSA specific attributes included in the content. That is, the provider should not assume the consumer is doing server-to-server replication.
True. The problem was that the auditContext attribute wasn't defined on the consumer. There's no obvious way to configure a consumer to exclude unknown attributes, and turning schema checking off doesn't help here.
Kurt
At 01:10 PM 12/23/2006, hyc@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays
Modified Files: accesslog.c 1.68 -> 1.69
Log Message: ITS#4788 don't return auditContext attr on syncrepl searches
CVS Web URLs: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/ http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/accesslog.c
Changes are generally available on cvs.openldap.org (and CVSweb) within 30 minutes of being committed.
At 05:00 PM 12/23/2006, Howard Chu wrote:
Kurt D. Zeilenga wrote:
It might be more appropriate to handle this issue on the consumer than the provider. An arbitrary LDAP sync client might want this and other DSA specific attributes included in the content. That is, the provider should not assume the consumer is doing server-to-server replication.
True. The problem was that the auditContext attribute wasn't defined on the consumer. There's no obvious way to configure a consumer to exclude unknown attributes,
Personally, I think this kind of problem is better solved by configuration then by code. Configuration wise, this can be addressed on either consumer side via a narrower attrs list, or on the provider side with an ACL.
Kurt
Kurt D. Zeilenga wrote:
At 05:00 PM 12/23/2006, Howard Chu wrote:
Kurt D. Zeilenga wrote:
It might be more appropriate to handle this issue on the consumer than the provider. An arbitrary LDAP sync client might want this and other DSA specific attributes included in the content. That is, the provider should not assume the consumer is doing server-to-server replication.
True. The problem was that the auditContext attribute wasn't defined on the consumer. There's no obvious way to configure a consumer to exclude unknown attributes,
Personally, I think this kind of problem is better solved by configuration then by code. Configuration wise, this can be addressed on either consumer side via a narrower attrs list, or on the provider side with an ACL.
Sure, but both of those require new action on the administrator's part. In general we try not to break existing configurations when we add new features. The addition of the auditContext attribute breaks existing configurations for pretty much no benefit.
The other fix I'm leaning toward is making slap_mods_check honor the no_schema_check flag, and use slap_bv2undef_ad for unrecognized attributes in that case. Another option is to pass slap_mods_check a flag that tells it to simply drop unrecognized attributes in these situations. If the administrator actually wants the attribute replicated, they can load up a schema definition for it. Otherwise they should be able to carry on undisturbed.
Howard Chu wrote:
The other fix I'm leaning toward is making slap_mods_check honor the no_schema_check flag, and use slap_bv2undef_ad for unrecognized attributes in that case. Another option is to pass slap_mods_check a flag that tells it to simply drop unrecognized attributes in these situations. If the administrator actually wants the attribute replicated, they can load up a schema definition for it. Otherwise they should be able to carry on undisturbed.
Maybe related to this the build of current HEAD fails:
cc -g -O4 -march=pentium4 -I../../include -I. -I./slapi -I. -I../../include -I/opt/bdb-4.5/include -I/opt/sasl/include -I/opt/heimdal/include -c -o sasl.o sasl.c sasl.c: In function ‘slap_auxprop_store’: sasl.c:467: warning: passing argument 1 of ‘slap_mods_check’ from incompatible pointer type sasl.c:467: warning: passing argument 2 of ‘slap_mods_check’ from incompatible pointer type sasl.c:467: warning: passing argument 3 of ‘slap_mods_check’ from incompatible pointer type sasl.c:467: warning: passing argument 4 of ‘slap_mods_check’ makes pointer from integer without a cast sasl.c:467: warning: passing argument 5 of ‘slap_mods_check’ makes integer from pointer without a cast sasl.c:467: error: too few arguments to function ‘slap_mods_check’ make[2]: *** [sasl.o] Error 1 make[2]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/servers' make: *** [all-common] Error 1
Ciao, Michael.
Michael Ströder wrote:
Maybe related to this the build of current HEAD fails:
cc -g -O4 -march=pentium4 -I../../include -I. -I./slapi -I. -I../../include -I/opt/bdb-4.5/include -I/opt/sasl/include -I/opt/heimdal/include -c -o sasl.o sasl.c sasl.c: In function ‘slap_auxprop_store’: sasl.c:467: warning: passing argument 1 of ‘slap_mods_check’ from incompatible pointer type sasl.c:467: warning: passing argument 2 of ‘slap_mods_check’ from incompatible pointer type sasl.c:467: warning: passing argument 3 of ‘slap_mods_check’ from incompatible pointer type sasl.c:467: warning: passing argument 4 of ‘slap_mods_check’ makes pointer from integer without a cast sasl.c:467: warning: passing argument 5 of ‘slap_mods_check’ makes integer from pointer without a cast sasl.c:467: error: too few arguments to function ‘slap_mods_check’ make[2]: *** [sasl.o] Error 1 make[2]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/servers' make: *** [all-common] Error 1
Michael,
I've blind fixed that, please check.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
Pierangelo Masarati wrote:
Michael Ströder wrote:
Maybe related to this the build of current HEAD fails:
cc -g -O4 -march=pentium4 -I../../include -I. -I./slapi -I. -I../../include -I/opt/bdb-4.5/include -I/opt/sasl/include -I/opt/heimdal/include -c -o sasl.o sasl.c sasl.c: In function ‘slap_auxprop_store’: sasl.c:467: warning: passing argument 1 of ‘slap_mods_check’ from incompatible pointer type sasl.c:467: warning: passing argument 2 of ‘slap_mods_check’ from incompatible pointer type sasl.c:467: warning: passing argument 3 of ‘slap_mods_check’ from incompatible pointer type sasl.c:467: warning: passing argument 4 of ‘slap_mods_check’ makes pointer from integer without a cast sasl.c:467: warning: passing argument 5 of ‘slap_mods_check’ makes integer from pointer without a cast sasl.c:467: error: too few arguments to function ‘slap_mods_check’ make[2]: *** [sasl.o] Error 1 make[2]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/servers' make: *** [all-common] Error 1
I've blind fixed that, please check.
Works. Thanks.
Ciao, Michael.
Michael Ströder wrote:
I've blind fixed that, please check.
Works. Thanks.
I mean: I know it compiles; the code might be broken though, as I didn't check if it behaves as expected. All tests pass, but I'm unsure whether that portion of code is tested or not...
Cheers, p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
-
Howard Chu -
Kurt D. Zeilenga -
Michael Ströder -
Pierangelo Masarati