2017-05-17 23:14 GMT+08:00 Aaron Richton <richton@nbcs.rutgers.edu>:
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