RE: back-dnssrv

["Pierangelo Masarati" <ando@sys-net.it>]

>> -----Original Message-----
>> From: owner-openldap-devel@OpenLDAP.org
>> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Pierangelo
>> Masarati
>
>> > back-dnssrv seems to be lately broken.
>> >
>> > First, I'm not quite sure what the purpose of the following
>> > assertion is, but it crashes slapd for normal searches:
>> >
>> > 	assert( get_manageDSAit( op ) );
>> >
>> > Should it perhaps be inverted? This is in dnssrv_back_search() and
>> dnssrv_back_compare().
>
> Well, that assert has been in search.c since rev 1.7, so this isn't a
> new behavior. Odd that no one has tripped over it before now. Given that
> the only entries that dnssrv_back_search generates are referral objects,
> I suppose it makes sense that you must provide the manageDSAit control
> if you expect to get any entries back from your search request. But
> probably it shouldn't be an assert, maybe sending
> LDAP_UNWILLING_TO_PERFORM or LDAP_OPERATIONS_ERROR in the absence of the
> control might make more sense. Or simply calling send_search_reference
> instead of send_search_entry...
>
> dnssrv_back_compare isn't even referenced, it's just an orphaned stub.
>
>> > Secondly, rs->sr_ref is uninitialized, which causes a further
>> > assertion failure in send_ldap_response().
>
> This is very odd. None of the other backends have a problem with this,
> and the SlapReply is exactly the same for all the code since it's only
> initialized in one place, connection_operation().
>>
>> I'll have a look at it; probably the new ABI upgrade left over
>> some typos/flaws.

I applied a couple of fixes, which are blind because I don't
have access to dns here.  Please check.  I note that the compare
function also asserted manageDSAit, but it is not set in the
bi_info structure because it's not implemented; I don't know
if it'll ever be useful, so I don't think we need to implement it.

I'd also like to integrate back-dnssrv into back-ldap, so that
it can be configured with (empty?) suffix and default uri, and
try to resolve the actual URI, but chasing the referral on behalf
of the client, resorting to the default URI in case of no match.

Maybe this operation might be stacked on top of back-ldap ...

Ando.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it