mirror of
https://github.com/dehydrated-io/dehydrated.git
synced 2026-01-11 22:30:44 +01:00
Integration with a free monitoring system via an API #249
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @dancvrcek on GitHub (Aug 28, 2017).
Hi, we are building a pretty powerful certificate expiry monitoring system (https://keychest.net) and one of things in our workshop is an RESTful API now. We consider 2 basic functions:
Expiry check is not quite related to an LE client (I think). Regarding the first one as a simple POST or GET call, i.e., a single line calling 'curl' - with or without a personalised parameter (e.g., API key).
Either way, is some kind of integration of dehydrated with a monitoring API a topic of interest and would you be likely to approve a PR that would a) change the main script, or b) introduce a "simple wrapper" like "dehydrated_le"?
Cheers
Dan
@lukas2511 commented on GitHub (Sep 20, 2017):
I don't really know what you'd need to change around the script to be able to monitor it?!
If you want to use dehydrated to allow your users to automatically add hosts to monitoring you can easily do that with a hook script.
I'm closing this for now, if you have any specific requests feel free to open a new ticket.
@dancvrcek commented on GitHub (Sep 20, 2017):
Hi, the thinking was more around a possibility to "register" it with an external monitoring, which would be independent on the script itself.
While I'm interested in it as we build our own system, I can imagine it could be useful to integrate with a general IT monitoring systems like Zabbix, Remedy, ...
@lukas2511 commented on GitHub (Sep 20, 2017):
Sorry but it doesn't really make any sense to me what an integration of dehydrated into a monitoring system would look like.
Running it and monitoring the exit code or output would be best to see if something failed together with external checks on the certificate files and the actually used certificates should basically handle everything I could think of... everything else could also be done via hooks (e.g. notifying the monitoring that a challenge verification failed).
@dancvrcek commented on GitHub (Sep 20, 2017):
The downside of checking exit codes is that this would be still part of the operational "process".
More robust approach is to check result of the run, content of CT logs, and handshake with the server. That way you can see if dehydrated failed, cert. deployment failed (e.g. Nginx wasn't reloaded), or someone else created a certificated was the given server.
Basically, we try to verify that everything works fine for users. Hooks are good, but they may be harder to work with if you have more servers. Our experience was that it was easy to make a mistake with the initial config.
I appreciate it's not a proper Linux admin approach and goes against the idea of a dependable OS. My experience is that the problem is usually between chair and keyboard. :)