2017-05-17 23:14 GMT+08:00 Aaron Richton <[email protected]>:
> On Wed, 17 May 2017, Roger Szabo wrote:
>
> The goal is to perform frequent periodic calls to check the health of
>> OpenLDAP using anonymous bind.
>>
>> Someone at http://stackoverflow.com/questions/16077473/ldap-bind-
>> vs-search suggested that a ldapcompare would perform better than a
>> ldapsearch because "there is only a single response per entry (a compare
>> result) rather than two (a search result entry and a search result done)".
>>
>> This explanation makes sense but it would be really great to hear the
>> opinion of an expert on this, thank you very much :)
>>
>
> Overall, seems a bit oversimplified. I suppose the common case compare
> would typically be cheaper than a search, but you could just as easily be
> comparing against some dynamic membership where the matching is expensive,
> potentially invoking multiple internal searches (there goes your savings).
> On the other hand, if the search requires access to unindexed data, maybe
> the search is more expensive. If the result set is large, maybe the search
> is more expensive even if it is indexed!
>
>
Yeah, to offer a more precise example:
ldapcompare -x -H ldaps://xxxxxx:xxx "o=test" "o:test"
This method simply checks whether the attribute "o" of the DIT's root
element "o=test" actually contains the value "test". For this example it
looks like there would theoretically be no ldapsearch on the same root
element that would perform equally or even better, wouldn't it?
> But you're talking about health, so the entire conversation may need to be
> reframed. There's nothing in the RFC that says you have to search nor
> compare. You could do something definitely in-core, i.e. ldapwhoami(1) ...
> or a simple "can I speak the protocol properly?" could be connect, BIND,
> UNBIND, close.
>
>
Yeah, but would a bind (even without being configured to auto-write last
login time etc.) perform better than an anonymous ldapsearch like the
example above?
>
> As with most things, you'd have to think through your precise cases and
> plan accordingly. If you're only concerned with general health of slapd(8),
> a back-null or back-monitor would both be fairly cheap (back-null literally
> being as cheap as it gets). But it IS possible to have backend(s) fail
> while the slapd(8) frontend remains operational, so monitoring of
> individual backends may be warranted too. (This is my practice -- each
> backend gets an indexed monitoring search, with a search congruent with the
> common use case for each backend.)
>
>
If I'm not mistaken, with the ldapcompare example above, supposedly the
backend's health is checked as well. I would be really interested though in
the monitoring search you mentioned, maybe it would be possible to provide
an anonymised example?
>
>
> The counterargument to all of this, across any network service, is "if
> your monitoring strains your capacity limits you're probably running too
> hot anyway."
Hehe, absolutely, looks like this could actually summarize the result of
this discussion :D
