I'm working on the following tree structure (represented here with dn
| `-- c
| |-- e1
| |-- e2
| |-- e3
| `-- e4
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:
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 ?