Re: Nested meta-backends

[Howard Chu <hyc@symas.com>]

Dave Horsfall wrote:
> Let's see if I can make my problem clearer.  Hope it's not too long...
>
> Host "host1.example.com" provides suffixes "dc=au,dc=example,dc=com", 
> "dc=sg,dc=example,dc=com" (as a slave), "dc=network,dc=net,dc=au", and 
> "dc=group,dc=org,dc=au".
>
> Over on host2.example.com, we have "dc=secret,dc=com,dc=au" (for political 
> reasons it's on a separate server, even though it's in the same rack).
>
> The important bits in their slapd.conf files would be:
>
> host1.example.com:
>
> database	bdb
> include		/usr/local/etc/openldap/example-master.acl
> suffix		"dc=au,dc=example,dc=com"
> rootdn		"cn=Manager,dc=au,dc=example,dc=com"
> rootpw		secret
> directory	/usr/local/openldap-data/example.com/au
>
> database	bdb
> include		/usr/local/etc/openldap/example-slave.acl
> suffix		"dc=sg,dc=example,dc=com"
> rootdn		"cn=Manager,dc=sg,dc=example,dc=com"
> rootpw		secret
> directory	/usr/local/openldap-data/example.com/sg
> syncrepl	rid=1 ...
> updateref	ldap://ldap.sg.example.com:389
>
> database	bdb
> include		/usr/local/etc/openldap/example-master.acl
> suffix		"dc=example,dc=com"
> rootdn		"cn=Manager,dc=example,dc=com"
> rootpw		secret
> directory	/usr/local/openldap-data/example.com/master
>
> This last one just contains referrals such as:
>
> 	dn: dc=au,dc=example,dc=com
> 	objectClass: extensibleObject
> 	objectClass: referral
> 	objectClass: top
> 	dc: au
> 	ref: ldap://host1.example.com/dc=au,dc=example,dc=com
>
> It could probably be done better with a meta-backend, once I understand 
> them better.
>   
The above would be a better candidate for backglue/subordinates; no 
referrals needed.
> database	bdb
> include		/usr/local/etc/openldap/network-master.acl
> suffix		"dc=network,dc=net,dc=au"
> rootdn		"cn=Manager,dc=network,dc=net,dc=au"
> rootpw		secret
> directory	/usr/local/openldap-data/network.net.au
>
> database	bdb
> include		/usr/local/etc/openldap/group-master.acl
> suffix		"dc=group,dc=org,dc=au"
> rootdn		"cn=Manager,dc=group,dc=org,dc=au"
> rootpw		secret
> directory	/usr/local/openldap-data/group.org.au
>
> On host2.example.com, slapd.conf would be obvious, so I won't include it.
>
> Now, with one client operation, we want to search Network, Group, and 
> Secret, to see who hosts a particular application; something like 
> "ldapsearch ... -b ou=UserView (objectClass=Apps) Appl=PogoSticks".
>
> We want results to come back unmolested e.g. I want to see something like 
> "dn: Appl=PogoSticks,ou=Applications,dc=secret,dc=com,dc=au" instead of 
> "dn: Appl=PogoSticks,ou=Applications,ou=UserView", which means a rewrite 
> rule.
>   
Rather than doing that, it would be better to define a dc=au database 
with stub entries for
   dc=net,dc=au
   dc=network,dc=net,dc=au
   dc=org,dc=au
   dc=group,dc=org,dc=au
   dc=com,dc=au
   dc=secret,dc=com,dc=au

and then use subordinate/backglue to attach the actual databases. In 
this case, you only need to use back-ldap to access the dc=secret 
database. Such a setup will get your "unmolested" view of the trees 
without requiring any rewrite rules.
> Now, my problem is that I want to define an administrative view of *all* 
> suffixes, called "ou=AdminView", without duplicating all those lines; in 
> other words, I want to glue "dc=example,dc=com" and "ou=UserView" together 
> (or indeed, any other arbitrary view I may create).
>
> I tried this:
>
> database	meta
> access		to * by * read
> suffix		"ou=AdminView"
> lastmod		off
>
> uri		"ldap://host1.example.com/ou=AdminView";
> rewriteEngine	on
> rewriteContext	default
> rewriteRule	"(.*)ou=AdminView$" "%1dc=example,dc=com" ":"
> rebind-as-user
> binddn		"cn=Manager,dc=example,dc=com"
> bindpw		secret
>
> uri		"ldap://host1.example.com/ou=UserView";
> rewriteEngine	on
> rewriteContext	default
> rewriteRule	"(.*)ou=AdminView$" "%1ou=UserView" ":"
> rebind-as-user
> binddn		"cn=Manager,dc=example,dc=com"
> bindpw		secret
>
> And I was getting the infamous "error 80", which I've learned happens when 
> there's a mismatch between the suffix and the naming context.
>
> So, what should the last meta look like?  I worked around it by simply 
> repeating the "UserView" configuration, but that's ugly.
You didn't mention what the AdminView should really look like (e.g., 
whether you want to see the true suffix or the ou=AdminView suffix) on 
returned entries.

But here you could use back-meta with two URIs pointing to the actual 
suffixes, and rewrite to your ou=AdminView suffix as desired.
   uri   ldap://host1.example.com/dc=example,dc=com
...
   uri   ldap://host1.example.com/dc=au

--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support