Andrew Bartlett wrote:
I've been working with current CVS OpenLDAP and the memberof plugin, for Samba4 integration.
Following your suggestion, I'm trying to load multiple memberof instances, but the syntax doesn't seem to work for me. Attached is how I'm currently configuring the overlay. It causes this when loading:
overlay_config(): overlay "memberof" already in list overlay_config(): overlay "memberof" already in list
That's harmless; It's like that because in principle there might be overlays that can only be instantiated once, but this now has to be declared by setting an appropriate flag, which is tested for right after that message. So I'm conditioning the message only in case a once-only overlay is being instantiated multiple times.
...
It also only appears to work for the first entry (happily that is member/memberof, and this seems to have worked).
AFAIR, it should work for all. However, with the combination of parameters you specified I've spotted an error: it seems to only work when __modifying__ a group, not when creating it with an already existing member. I'm looking at it, and I'll file an ITS as soon as I can single out what's the critical combination of parameters.
Is the syntax I'm using correct, or does the module need to be reworked for this operation?
Probably, the module should be reworked in many directions, but not for what you're trying to do (except fixing the bug I mentioned above).
Finally, I'm wondering if the error returns can be adjusted:
When I add invalid member to a group, OpenLDAP returns LDAP_CONSTRAINT_VIOLATION <adding non-existing object as group member>, but AD returns error 32, LDAP_NO_SUCH_OBJECT for this situation. Would it be reasonable to change this, or could it be made configurable. Having the LDAP server give me the error the client expects would avoid the need for a translation layer. (it might be nobody ever looks at this, but I don't like to make that assumption).
LDAP_CONSTRAINT_VIOLATION was chosen since it correctly expresses what is the real error: the overlay was configured to be picky on checking referential integrity, which, to me, is a constraint; LDAP would otherwise be happy to have broken referential integrity, since that's the responsibility of the application layer (the overlay in our case). Returning LDAP_NO_SUCH_OBJECT for an operation (add, modify) whose object (the request DN) is that of the group, and it exists, would be rather misleading. Of course, as the slapo-memberof is an aplication layer, I don't see a strong objection to making this error configurable, but I strongly recommend to use LDAP_CONSTRAINT_VIOLATION as default.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. 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 ---------------------------------------