Nagios Support Forum

Moderator Edit: This thread has been split from another - https://support.nagios.com/forum/viewto ... 37&t=41776
In the future, please create a new thread and link to the old one instead of adding on.

Forgive me for stomping on the thread but because something is difficult doesn't mean you shouldn't do it

We are currently evaluating Nagios for our company, we have a perfectly functioning Directory service (AD) which many and most application play well with. This limit is circumvented by other applications. I'm surprised by this, essentially Nagios will only work with:

- Companies with fewer than 1,000 user obejcts in AD
- Companies using local or other LDAP directories
- Companies who segment their user objects across multiple OUs

Surely there must be a way around this? Or provide the option to apply LDAP Group Objects to roles so that there's no need to copy users in the first place?

Anyone know of other Nagios derivatives that handle this issue?

remiego wrote:Surely there must be a way around this?

Yes.

We would need to use a later version of PHP. However, the default for RHEL 6 is PHP 5.3, and we have many users on old versions of PHP.

There are currently many feature requests for improved LDAP functionality. The public roadmap for the next NLS says Q3, but that's likely pessimistic. I can't say much more than that about the timeline, unfortunately.

Thanks for the response, that's useful to know.

I'm a little surprised this is yet to be addressed when the product is at version 5.x. There must be some customers who have gotten around this? Is there no way to apply a filter to the LDAP query (even in a localised PHP file) and 'chunking' the data up using filters?

I suspect this limitation takes nagios out of the reckoning for a monitoring platform for us, even if there were ways to get around the restriction.

It stinks, but it's pretty firmly an issue with the current PHP version being distributed by the CentOS/RedHat repository maintainers. The necessary "chunking" you mentioned would require a paginated LDAP query which isn't something that can be done in the version of openLDAP that runs on PHP versions less than 5.6. I think 5.4 is the latest version in the mainstream repositories currently.

It really, really stinks and I understand the frustration. We can't really recommend 3rd party repos that *do* distribute PHP 5.6 though because then our product becomes entirely dependent on that repository which almost assuredly does not have the same level of support as the official RedHat/CentOS repositories.