What about https://github.com/matteocorti/check_ssl_cert instead inventing the wheel again?

What about https://github.com/matteocorti/check_ssl_cert instead inventing the wheel again?

Because that's non-standard. We use openSUSE and monitoring-plugins is vetted and comes with it automatically. I don't want to have to track down a custom build.

By analogy, if you buy a car it always comes with a stereo - even though there is a thriving economy for aftermarket stereos.

Maybe it does not make sense to include such things into a dead horse? :) (Just to keep analogy.)

As of now, the horse is still alive, so we should continue to feed and water it :)

Just as a note: check_curl has a differently named option and reversed semantics:

 -D, --verify-cert
   Verify the peer's SSL certificate and hostname

Just as a note: check_curl has a differently named option and reversed semantics:

Thanks. I was trying to keep consistent with the Nagios plugin, which also uses --verify-host.

Whether that's a laudable goal is up for debate... I'm happy to change it if need be (or add an alias).

A, maybe then check_curl should be adapted to --verify-host of nagios-plugins? It's
better to stick close to nagios-plugins.

maybe then check_curl should be adapted to --verify-host of nagios-plugins?

Sounds like a good idea - though it's beyond the scope of this PR.

Thanks.

Sure, your pull request can remain as is, of course. :-)
I just wanted to add the argument here for keeping check_http and check_curl in sync (command-line-option-wise).

Updated patch to resolve conflict with recent addition to master branch.

Ping... is there anything else to discuss/review for this change?

This ability of check_http verify SSL certificates seems like an obvious feature to have. So unless there's a problem with the patch let's get this in there...

Thanks.

For me, I would consider check_http in a state, where we fix regressions and not adding features into it, which we drop midterm. But that's just my personal opinion.

For me, I would consider check_http in a state, where we fix regressions and not adding features into it, which we drop midterm. But that's just my personal opinion.

OK thanks for your opinion.

What's the official policy here? Is check_http being maintained or not?

If not, then where's the replacement for all of its functionality?

More generally I don't understand the general sense of inertia here.

Maybe someone can provide more context.

Who is in charge here and what's going on?

Thanks.

If not, then where's the replacement for all of its functionality?

I guess you didn't found https://github.com/monitoring-plugins/monitoring-plugins/blob/master/plugins/check_curl.c yet?

If not, then where's the replacement for all of its functionality?

I guess you didn't found https://github.com/monitoring-plugins/monitoring-plugins/blob/master/plugins/check_curl.c yet?

Previously I did not know about it - because check_curl is not available in openSUSE for some dumb reason (but there is a proposed patch).

Also, quoting check_curl -h ...

$ ./plugins/check_curl -h
check_curl v2.3.5.101.g246c (monitoring-plugins 2.3git)
...
WARNING: check_curl is experimental. Please use
check_http if you need a stable version.
...
 -D, --verify-cert
   Verify the peer's SSL certificate and hostname
...
 Please note that this plugin does not check if the presented server
 certificate matches the hostname of the server, or if the certificate
 has a valid chain of trust to one of the locally installed CAs.

The WARNING is scary because yes, I do need a stable version of this check. Is the warning obsolete??

The note also had me confused at first - it seems to directly contradict -D. Maybe that note should be removed?

If check_curl is actually considered stable then it should work for me, in which case I'll work on the openSUSE side to get it included.

puh ... not really related to the issue, but looking into https://build.opensuse.org/package/view_file/server:monitoring/monitoring-plugins/monitoring-plugins.spec?expand=1 makes me feel a bit sad, cause for me it looks like folks at suse seems to carry patches not pushing upstream. At least I didn't found traces of it.

it looks like folks at suse seems to carry patches not pushing upstream. At least I didn't found traces of it.

openSUSE policy is for all patches to be submitted to upstream if appropriate. Of course that's a judgement call.

In the spec file, the patches that are marked PATCH-FIX-UPSTREAM supposedly have been submitted to upstream via the quoted URL. But of course you can see that one of these is to RedHat's bugzilla, not sure why it went there.

In any case I'd encourage a quick review of any/all of those patches for inclusion here. Of course doing so only makes the openSUSE happier, because upstream'd patches lower their maintenance burden.

Of course doing so only makes the openSUSE happier, because upstream'd patches lower their maintenance burden.

That's exactly the reason why I'm pushing issues and patches upstream from Debian, in the end saving resources for all.