Override config file settings from User interface

[jvejv]

Hi *,

I'm fighting with my users over the configuration of some services: a service defined as passive in the config file (active_checks_enabled 0) can be turned into an active one from the user interface (Enable active checks of this service), which then leads (us) to strange ends.
Not sure if this is a bug or a feature... if it's a feature, is there a way to disable it ? To protect the config file setting from being overriden by a user command ?

- it's different with checks defined as active: it makes sense (to me) to let the users stop Nagios checking them from time to time
- yes, I am trying to stop/avoid the trouble later (on the way to those strange ends), but this seems (to me) to be the point of confusion

Thanks for advice/help,
jvejv

[abrist]

You cannot individually turn off that behavior. You would have to remove permissions from the users that allow them to take any command action in order to accomplish this.

[jvejv]

Yes, it seems to me that there's not much that I can do about it.
The problem is that the active check (programmed to be otherwise activated in freshness checks) gives some kind of a "No data" result, which (in a way) puts the blame on the guy that runs the monitoring system.
I can give the users a nasty message ("I told you not to touch it'') as the result of the active check... but then I risk misleading them in case of stale passive checks monitored for freshness (it took me some time to digest and configure that, so I don't want to give it up).
So my question is: Is it really intended behaviour to let users override config file setting of passively checked items and turn them into actively checked ?
Is there a case for it ? Shouldn't it be prevented ?

Thanks, jvejv

[sreinhardt]

Is it really intended behaviour to let users override config file setting of passively checked items and turn them into actively checked ?

Was this the direct intent, no. However considering they can disable active checks which internally puts active_checks=0 in the objects.cache under that host, we have no way of really determining without a ton of nasty logic, that this host was not originally intended as active and should be made active again. Such would be the case for a passive that someone makes active.

What I can help you with is the no data message! That simply means that your freshness\active check is not configured to output anything to standard out. If you are using check_dummy or something similar, simply alter your command from:

$USER1$/check_dummy 0
TO
$USER1$/check_dummy 0 "This service should not be an active check."

This will make a service now respond with "this should not be an active check" instead of no data. You might want to change the exitcode (0) to something else as well, but I'll leave that to you. To make this as wide spread as possible, I would suggest setting this directly in a template, not specifically on host or service object configs. This way an object can override if it really should have a freshness or active check. Does that make sense, and hopefully help this at least somewhat?

[jvejv]

we have no way of really determining without a ton of nasty logic, that this host was not originally intended as active and should be made active again.

Well... I thought of not letting the users turn on active checks on items defined as passive in the configuration file. I can imagine that it would mean to distinguish the config file settings from those introduced by users at runtime. (I don't know whether they really are the same... and I don't even know if there is some other config file setting that can be overriden at runtime). In my view, there is a difference between an item defined as passive and an item whose active checks have been suspended for some reason. It seems that Nagios does not make the distinction - it also puts a question-mark to passively checked services, which is somewhat misleading for the users (Why a question-mark ? What's wrong with that service ?).

What I can help you with is the no data message! That simply means that your freshness\active check is not configured to output anything to standard out. If you are using check_dummy or something similar, simply alter your command from:

$USER1$/check_dummy 0
TO
$USER1$/check_dummy 0 "This service should not be an active check."

This will make a service now respond with "this should not be an active check" instead of no data. You might want to change the exitcode (0) to something else as well, but I'll leave that to you. To make this as wide spread as possible, I would suggest setting this directly in a template, not specifically on host or service object configs. This way an object can override if it really should have a freshness or active check. Does that make sense, and hopefully help this at least somewhat?

Clear: that's the "I told you not to touch it" message I mentioned before. But then I can't use the active check for freshness checking (where the "No data" message is appropriate). Or do I miss something again ?

Thanks, jvejv

[sreinhardt]

Ah I thought the no data received was just from our default, not something you had setup or left that way intentionally. In that case yes changing that message would cause that issue. I agree that a passive and active service as defined in the configs are not strictly speaking the same things. If you would like to make a feature request on tracker.nagios.org, I'd be happy to make a corresponding internal request for it. Otherwise at this time, there isn't a whole lot I could tell you do to to restrict this without heavy modification of core and recompilation of at least the cgi's.