4 ms·

The official let's encrypt client is very heavy-weight. In my case I've build a much simpler thing using acmetool (https://github.com/hlandau/acme https://githu

by pilif 11y ago

The official let's encrypt client is very heavy-weight. In my case I've build a much simpler thing using acmetool (https://github.com/hlandau/acme https://github.com/hlandau/acme) which is mcuh simpler to use and nicely runs without root rights. In my case, a lot of the routing of domains to customers is stored in a postgres database and a trigger fires an event anyways, so I have a little daemon that listens to these events and the fires off acmetool as needed in order go generate certificates. I just completed this last week, so when I've seen this article here, I thought that I just wasted some time over this because now there's an integrated nginx solution, but thankfully, this is just an article about doing what I was doing using a tool that's more complicated to use and brings half of an OS installation as dependencies. For those interested, https://gist.github.com/pilif/1e2610dd7aa57323e0b2 https://gist.github.com/pilif/1e2610dd7aa57323e0b2 is the script in question. It's really a quick hack, but it works very well for me to auto-create nginx config files.

hlandau 11y ago
I'm the author of acmetool. It's quite interesting to know that people are using the design to its full potential. Ideally, I should probably make something more library/daemon-based for these largescale, custom solutions, though of course I'd like to do it some manner of modular way that allows the existing codebase to be leveraged. For the time being only the acmeapi package within acmetool is stable and suitable for use by other libraries. Something to think about...
- mholt 11y ago
  We should join forces with https://github.com/mholt/certs https://github.com/mholt/certs then. (Still in design phase.)
  - hlandau 11y ago
    I've done some thinking on what makes sense and ended up at this very rough first sketch. Comments welcome. https://gist.github.com/hlandau/ed6a96150c69945143be https://gist.github.com/hlandau/ed6a96150c69945143be
- pilif 11y ago
  For me, the current interface is perfect (though I wouldn't call our usage large-scale by a long shot), though it would be even better if acmetool would indicate using the exit code whether the web server needs restarting or not after reconciliation. I know there are the hooks and that's what I'm using now, but if I could get a distinct exit code to tell me that changes happened to the certificate store, then I could get away without needing to also keeping the hooks around. That said, this should probably be on your github issues, not in here. That also said: This was such a small issue for me that I didn't even want to bother you - but as you're coming here to post, I guess it doesn't hurt :p
  - hlandau 11y ago
    I can't use the exit code, because a nonzero exit code by UNIX convention indicates failure, which will spam people in their cron jobs. There's only one exit code which conventionally means 'success'. I could modify acmetool to output a word 'NEEDS-RELOADING' or something, which you could grep for programmatically. But this is another option (it would have to be an option; any output from acmetool is liable to get e. mailed to people via cron) for something which can be, as you yourself admit, dealt with as well via hooks. And probably more robustly, too. So on balance, I don't think it's worth doing.

by pilif 11y ago

hlandau 11y ago

I'm the author of acmetool. It's quite interesting to know that people are using the design to its full potential. Ideally, I should probably make something more library/daemon-based for these largescale, custom solutions, though of course I'd like to do it some manner of modular way that allows the existing codebase to be leveraged. For the time being only the acmeapi package within acmetool is stable and suitable for use by other libraries. Something to think about...

mholt 11y ago
We should join forces with https://github.com/mholt/certs https://github.com/mholt/certs then. (Still in design phase.)
- hlandau 11y ago
  I've done some thinking on what makes sense and ended up at this very rough first sketch. Comments welcome. https://gist.github.com/hlandau/ed6a96150c69945143be https://gist.github.com/hlandau/ed6a96150c69945143be
pilif 11y ago
For me, the current interface is perfect (though I wouldn't call our usage large-scale by a long shot), though it would be even better if acmetool would indicate using the exit code whether the web server needs restarting or not after reconciliation. I know there are the hooks and that's what I'm using now, but if I could get a distinct exit code to tell me that changes happened to the certificate store, then I could get away without needing to also keeping the hooks around. That said, this should probably be on your github issues, not in here. That also said: This was such a small issue for me that I didn't even want to bother you - but as you're coming here to post, I guess it doesn't hurt :p
- hlandau 11y ago
  I can't use the exit code, because a nonzero exit code by UNIX convention indicates failure, which will spam people in their cron jobs. There's only one exit code which conventionally means 'success'. I could modify acmetool to output a word 'NEEDS-RELOADING' or something, which you could grep for programmatically. But this is another option (it would have to be an option; any output from acmetool is liable to get e. mailed to people via cron) for something which can be, as you yourself admit, dealt with as well via hooks. And probably more robustly, too. So on balance, I don't think it's worth doing.