Andrew Bartlett wrote:
The warning is gone, but the link between masteredBy and hasMasterNCs still doesn't appear.
It is actually a special case, as it is between containers/databases/partitions (what is the right term?).
OK, the overlay, the way you're using it (stacking within a database) will only allow reverse links between entities that belong to that database. You can try making that instance of the overlay as global (i.e. placing it before the first database). I don't think I ever tested it that way, so there might be pending issues, but in principle it should work.
For example: dn: cn=NTDS Settings,cn=LOCALDC1,cn=Servers,cn=Default-First-Site-Name,cn=Sites,cn=Configuration,dc=samba,dc=example,dc=com hasMasterNCs: cn=Configuration,dc=samba,dc=example,dc=com hasMasterNCs: cn=Schema,cn=Configuration,dc=samba,dc=example,dc=com hasMasterNCs: dc=samba,dc=example,dc=com
This is record is created with an 'add', but none of those link targets have a masteredBy record.
overlay memberof memberof-dangling error memberof-refint TRUE memberof-group-oc top memberof-member-ad hasMasterNCs memberof-memberof-ad masteredBy
Perhaps there a restriction that the memberof-group-oc should be unique?
No, there shouldn't. You usage is quite different from what I envisaged, though, as using "top" for the group objectclass is definitely triggering consistency checks more often than I expected.
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 ---------------------------------------