[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Nested meta-backends

On Wed, 8 Jun 2005, Pierangelo Masarati wrote:

> The example is not really clear; however, as far as I understand, you 
> should be able to do that provided you can design a hierarchy of 
> suffixes that doesn't cause conflicts, and at the expense of multiple 
> translations from internal to LDAP and viceversa of all operations...  
> You could do something like

OK, I guess I was hiding too much information; for obvious reasons I 
didn't want to mention the actual domains etc, but I've realised that I 
don't understand some concepts that your examples have highlighted.

> database meta
> suffix ou=View1
> uri ldap://host1.example.com/ou=View1
> uri ldap://host2.example.com/ou=View1

I'm confused by the requirement that the naming context end in the suffix; 
I found that if it doesn't, I get an obscure "error 80".

Intuitively (for me anyway), that example above says to search those URIs, 
with a search base of "View1" (which likely doesn't exist), and glue them 
together, calling it "View1".

> database meta
> suffix ""
> uri ldap://localhost/ou=View1
> uri ldap://localhost/ou=View2

And here's another confusing bit.  I can see that the naming context sort 
of ends in the suffix (i.e. all strings end in a null string), but was the 
choice of "" purely arbitrary?

> should do the trick, although I wouldn't recommend it for high 
> performances.

Performance won't be an issue (yet), as it's low-volume traffic.

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.

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.

So, host1 would also have (ignore the access rule; it will change):

database	meta
access		to * by * read
suffix		"ou=UserView"
lastmod		off

uri		"ldap://host1.example.com/ou=UserView";
rewriteEngine	on
rewriteContext	default
rewriteRule	"(.*)ou=UserView$" "%1dc=network,dc=net,dc=au" ":"
rebind-as-user
binddn		"cn=Manager,dc=network,dc=net,dc=au"
bindpw		secret

uri		"ldap://host1.example.com/ou=UserView";
rewriteEngine	on
rewriteContext	default
rewriteRule	"(.*)ou=UserView$" "%1dc=group,dc=org,dc=au" ":"
rebind-as-user
binddn		"cn=Manager,dc=group,dc=org,dc=au"
bindpw		secret

uri		"ldap://host2.example.com/ou=UserView";
rewriteEngine	on
rewriteContext	default
rewriteRule	"(.*)ou=UserView$" "%1dc=secret,dc=com,dc=au" ":"
rebind-as-user
binddn		"cn=Manager,dc=secret,dc=com,dc=au"
bindpw		secret

The above works, but I have a feeling it could be done in a better way.

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.

-- 
Dave Horsfall  DTM  VK2KFU  daveh@ci.com.au  Ph: +61 2 8425-5508 (d) -5500 (sw)
Corinthian Engineering, Level 1, 401 Pacific Hwy, Artarmon, NSW 2064, Australia