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(a)sys-net.it
---------------------------------------