masarati@aero.polimi.it wrote:
h.b.furuseth@usit.uio.no wrote:
Full_Name: Hallvard B Furuseth Version: RE24, HEAD OS: Linux x86_64 URL: http://folk.uio.no/hbf/OpenLDAP/rwmhang-draft.txt Submission from: (NULL) (193.157.201.147) Submitted by: hallvard
rwm suppresses the LDAP response message if rwm_response() fails. This hangs waiting for the response:
include servers/slapd/schema/core.schema database monitor overlay rwm rwm-rewriteEngine on rwm-rewriteContext matchedDN # Rewrite to nonexistent $1 or broken DN rwm-rewriteRule ".*time.*" "cn=test,$1" : rwm-rewriteRule ".*" "urgle" :
ldapcompare -x cn=hello,cn=time,cn=monitor l:x ldapsearch -xLLL -b cn=hello,cn=monitor
The enclosed patch seems to fix it, but I've only looked briefly at what's going on.
Good catch; however, the problem might need a slightly different fix; in fact, yours prevents rwm_response from aborting the operation by forcing an "unwilling to perform" based on the contents of the referral/matched.
However, this is probably conflicting (as in many other cases in slapo-rwm(5)), with the fact that some operations (e.g. extended) do not return response directly, but delegate the frontend; or, like the bind operation, only return unsuccessful results directly, and delegate successful responses to the frontend.
Perhaps this ITS could serve as a reminder to remove those two inconsistencies from the structure of this code. The historical reasons for Bind's behavior no longer apply. I don't believe there was ever any special reason why exops needed to behave this way.