suffixmassaging to ancestor suffix

[Jean-Jacques Puig <jean-jacques.puig@espci.fr>]

Hi,

I'm working on the following tree structure (represented here with dn 
chunks):

z
`-- y
    |-- o1
    |-- o2
    |   `-- c
    |       |-- e1
    |       |-- e2
    |       |-- e3
    |       `-- e4
    |-- o3
    |-- s1
    |-- s2
    |-- s3
    `-- s4

where 'dc=y,dc=z' is base dn. Entries o* have same objectClass, so have 
s* and e*. The tree contains duplicate information: for any i, all 
attributes in e$i can be mapped to attributes in the corresponding s$i, 
and c entry contains no information wrt my applications. e* are end 
nodes (leaves), while s* are not. Suffix 'dc=y,dc=z' is served by a 
single database. My goal is to get rid of the c subtree with no side 
effects for my applications and with limited risks as a whole.

I currently do this with slapd-relay and slapo-rwm. I first attempted:

database relay
suffix "ou=c,ou=o2,dc=y,dc=z"
relay "dc=y,dc=z"
overlay rwm
rwm-suffixmassage "dc=y,dc=z"

When I inserted this definition before that of the database serving 
suffix "dc=y,dc=z", I had the following error: cannot find database of 
relay dn "dc=y,dc=z" in "olcRelay <dn>. This makes sense.

When I inserted this definition after that of the database serving 
suffix "dc=y,dc=z", I had: <suffix> namingContext
"ou=c,ou=o2,dc=y,dc=z" already served by a preceding bdb
database serving namingContext "dc=y,dc=z". This also makes sense.

I got rid of the '^relay' line, so as not to refer to a specific 
database, and inserted the definition before "dc=y,dc=z" database;
slaptest passed. When I tested a simple search on objectClasses , I had 
a burst of slapd crashes (our server is run within a shell loop), and no 
log. I thought first that a infinite loop exhausting memory might be the 
explanation, bouncing from 'ou=c,ou=o2,dc=y,dc=z" to "dc=y,dc=z" and 
back again. I was for some time deceived in thinking so because I did 
not notice at first that rwm-suffixemassage implied recursive rewrite 
and I was doing tests on suffix such as 
'ou=c,ou=o2,ou=c,ou=o2,dc=y,dc=z' to assert loop situation.

Eventually, I could not reproduce the failing situation, and it seems 
there is no loop. Am I right about this ? What actually happens when 
rewriting to an ancestor suffix without 'relay' reference ? In such a 
situation, is there any way to inforce relay to a later-defined database ?

I further had to remap classes and attributes:

rwm-map objectclass E S
rwm-map attribute e_att1 s_att1
rwm-map attribute e_att2 s_att2

where E is objectclass of e*, S objectclass of s*, e_att1, e_att2 
attributes of E, s_att1, s_att2 attributes of S. This works fine, but on 
searches such as:
ldapsearch -s one -b 'ou=c,ou=o2,dc=y,dc=z' objectClass=E
I get all attributes related to S. Normal but not desirable. I thus added:
rwm-map attribute *
The preceeding command then returns... nothing. How can I make this 
search work while limiting attributes mapping ?

Because it's necessary, I further added access rules:
access to dn.base="ou=c,ou=o2,dc=y,dc=z"
	by * read stop
access to dn.one="ou=c,ou=o2,dc=y,dc=z"
	by * read stop
access to *
	by * none stop

I wanted to deny read access deeper in the tree (there are passwords 
hashes out there). Is there another way to constrain scope on 
consultations on 'ou=c,ou=o2,dc=y,dc=z' ? Btw, are the above rules 
expressed in the simplest way ?

In order to limit entries attributes visibility, as I could not use 
rwm-map attribute *, I mention e_att* as attrs= in the #2 access rule. 
But there again the search would return no result. What am I missing ?

From a general perspective, is the slapd-relay slapo-rwm combination 
the relevant way to solve my issue ?

Thanks !

--
Jean-Jacques Puig