Using back-meta or back-relay plus slapo-rwm as a proxy to a local database
Ryan Steele <ryans <at> aweber.com>
2010-05-16 21:51:33 GMT
Ok, fair warning - this is a little long-winded, but I'd rather give too much detail than not enough. Also, all
examples are in slapd.conf format, since there is no documentation for cn=config, and I'm using slapd with
-f and -F to
make the conversion.
Anyways, I'm working on implementing some rewrite rules with slapo-rwm, using back-relay (or possibly
back-meta if that
doesn't work out) as the backend on top of which slapo-rwm will sit, to make available some features that
would be
otherwise not be present with back-ldap, or in the absence of a proxy backend altogether.
In its most basic form, the slapo-rwm overlay can be used without a proxy or relay backend, but the feature
I'm after
appears to require either the slapd-meta backend or the slapd-relay backend. For now, I've chosen to try with
slapd-relay, as my research has indicated it supports the feature I'm after. For reference, this feature I
desire is
the 'searchResult' rewriteContext, as I'm interested in rewriting dynamic group membership DN's (i.e.,
the 'member'
attribute, as defined in rfc2307bis) as plain uid's, so clients that only know about rfc2307 (and thus,
look only for
entries of the same format as memberUid and fail to perform any mappings to translate membership DN's to
UID's) can make
use of the dynamic groups I've created in my directory.
Since my slapd-hdb database's rootDSE is dc=example,dc=com, I really couldn't find any way to get around
using a virtual
naming context; creating a back-meta database on the same host with the same suffix as the back-hdb
database seemed
ambiguous at best (in terms of how to ensure that clients would always speak to the back-meta db first), and
using the
suffix "dc=com" seemed inappropriate, as did creating several relay databases, one for each of the
entries below the
slapd-hdb database's rootDSE (e.g., ou=Users,dc=example,dc=com, ou=Groups,dc=example,dc=com,
etc.). Creating several
relay databases in that fashion presents other problems as well, and wouldn't do me any good for clients
which query for
entries using dc=example,dc=com as their search base.
Given that, and the fact that I'm only looking to remap/rewrite data going to and from a single local
database with a
single naming context, I decided it was a better idea to create a single back-relay database with a bogus
"proxy" naming
context and use a suffixmassage to rewrite it, e.g.:
database relay
suffix "dc=example-proxy,dc=com"
relay "dc=example,dc=com"
overlay rwm
rwm-rewriteEngine on
rwm-suffixmassage "dc=example-proxy,dc=com" "dc=example,dc=com"
rwm-rewriteContext searchResult
rwm-rewriteRule "^uid=([^,]+?),ou=Users,dc=example,dc=com$" "$1"
For reference, here is the back-meta database configuration I was going to use before I discovered that back-relay
supported the searchResult rewriteContext:
database meta
suffix "dc=example-proxy,dc=com"
overlay rwm
rwm-rewriteEngine on
uri "ldap://localhost/dc=example-proxy,dc=com"
rwm-suffixmassage "dc=example-proxy,dc=com" "dc=example,dc=com"
rwm-rewriteContext searchResult
rwm-rewriteRule "^uid=([^,]+?),ou=Users,dc=example,dc=com$" "$1"
In either case, I have a few questions going forward from this point:
1. Is it legal to rewrite the search result DN's as described in the example above? I'm hoping that since the data
being manipulated is going from server -> client and is not being stored in the directory, the attributes
I'm rewriting
would not be subjected to the syntax requirements of the entry that holds them.
2. Are there any benefits or drawbacks to using a rewriteMap to accomplish this task? In my mind, it just
seems like
another means to the same end, at least based on the following configuration I came up with:
rwm-rewriteMap ldap dn2uid "ldap://localhost/ou=Users,dc=example,dc=com?uid?sub"
rwm-rewriteContext searchResult
rwm-rewriteRule "^uid=([^,]+?),ou=Users,dc=example,dc=com$" "${dn2uid($1)}"
3. Is there a better way to go about doing this that I've failed to see or consider?
4. Considering the slapd-meta man page, which mentions that some of its features could potentially result
in excessive
overhead for some installations, are the features used in the aforementioned configuration(s)
efficient enough to scale
well in a very busy environment? I'm aware that's a pretty vague and loaded question with lots of variables,
so I'm
just looking for an educated opinion from a 10,000 foot view, assuming excellent hardware, high network
capacity, and
heavy - say, 5k, 10k, 15k queries per second - traffic. Performance will obviously be tested before
implementing this,
but it'd still be nice to have a rough idea of what to expect going in.
Lastly, on a somewhat tangential note, given that there's no documentation with respect to cn=config for
setting up
slapo-rwm (or doing it in conjunction with a proxy backend), is there any way to discover the cn=config
attributes and
objectclasses for those backend and overlays that's better or more efficient than creating a standard slapd.conf
configuration and converting it with slapd using -f and -F? Perhaps an official or unofficial bit of documentation
floating around out there other than a few miscellaneous postings on the mailing lists and some ITS
contents? On a
similar note in the same vein, as far as I can tell, none of the man pages, admin guide sections, or
FAQ-O-Matic entries
on slapd-relay mention which rewrite contexts are available with it, and I didn't realize that
slapd-relay accepted the
searchResult rewrite context until I read the servers/slapd/back-relay/README file (while searching
for code that might
reveal slapo-rwm's cn=config attribute equivalents). Would it be objectionable to update these
reference points with
said information? I'd be happy to file an ITS and submit patches and/or content for updating the
documentation, if
Gavin is too busy, unavailable, or would like some help.
Thanks for any and all advice, musings, criticisms, and opinions!
-Ryan
--
--
Ryan Steele
Systems Administrator
AWeber Communications
RSS Feed