Closed peternewman closed 2 years ago
We could add an option but according to the Development Guidelines "Unknown" should only be used for internal (plugin) issues.
Invalid command line arguments were supplied to the plugin or low-level failures internal to the plugin (such as unable to fork, or open a tcp socket) that prevent it from performing the specified operation. Higher-level errors (such as name resolution errors, socket timeouts, etc) are outside of the control of plugins and should generally NOT be reported as UNKNOWN states.
We could add an option but according to the Development Guidelines "Unknown" should only be used for internal (plugin) issues.
Invalid command line arguments were supplied to the plugin or low-level failures internal to the plugin (such as unable to fork, or open a tcp socket) that prevent it from performing the specified operation. Higher-level errors (such as name resolution errors, socket timeouts, etc) are outside of the control of plugins and should generally NOT be reported as UNKNOWN states.
Ah nice, I'd not found something so clear-cut before. Although I note they don't tell you what state to actually return if e.g. name resolution has failed so whether the certificate is good or not is unknown.
Given that specific example, if you can work out what state it should be instead, maybe this should be changed? https://github.com/matteocorti/check_ssl_cert/blob/5468c14404c4974e2b7b80fa5a0a869a37613078/check_ssl_cert#L3346
Also I hadn't realised you had tests, that's awesome!
I guess this might be controversial, so maybe it needs an option instead?