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

suffixmassaging to ancestor suffix



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