Alternative Puppet Module about puppet-letsencrypt

[danzilio]

Hi @pgassmann! I took a look at your module and it looks good!

I'd rather stay away from wrapping the nginx or apache modules. I think I'd rather focus on configuring letsencrypt and let the user handle the vhost their own way.

My module does allow for configuration in a single Puppet run, we just let the user decide how they want to include the letsencrypt class. I should call this out more explicitly in the documentation.

I'm a little conflicted on merging the modules. I did make the decision to use Puppet 4 features consciously. I'm a little hesitant to add backwards compatibility for Puppet < 4. Let me think about this a bit!

[pgassmann]

They don't have to merge.

My module was mostly a personal challenge to see how letsencrypt can be automated the "Puppet Way".

Especially if letsencrypt is used on a ssl proxy, where the actual document root is on a different machine. I had to look at the acme specifictation to find the ./well-known/acme-challenge path. Then I saw that it is possible to specify a separate document root for a certain location. With that, letsencrypt can be used and configured by puppet without interfering with anything else.

Then there's the challenge, that the document root might not be the same before and after the new vhost is configured, and it's again something different when nginx was not installed before. I tried to take care of all these scenarios with as few "engineering" required by the user of the module. That's why I think it is useful to have a module that provides simple solutions for these challenges.

Also automatic renewals should be configured by Puppet.

[domcleal]

I'd rather stay away from wrapping the nginx or apache modules. I think I'd rather focus on configuring letsencrypt and let the user handle the vhost their own way.

This was the main benefit for me choosing this module, it's much easier to integrate.

My module does allow for configuration in a single Puppet run, we just let the user decide how they want to include the letsencrypt class. I should call this out more explicitly in the documentation.

The first run mode of @pgassmann's module is quite useful here I think (pgassmann/puppet-letsencrypt@54f09b0) when using webroot mode and with say, apache::vhost pointing at the expected certificates.

It runs the client first in standalone mode to retrieve a cert, then on subsequent runs in webroot mode. If startup of the web server is correctly chained after letsencrypt::certonly then the first run will start up LE in standalone mode, gets the certs and then uses the running web server in future to renew it. I've been thinking of sending a PR to this module for a similar feature.

I did make the decision to use Puppet 4 features consciously. I'm a little hesitant to add backwards compatibility for Puppet < 4. Let me think about this a bit!

I did this over at https://github.com/domcleal/puppet-letsencrypt (puppet-3). I'm happy to continue maintaining it as long as I can, or I can send you a PR with the changes to consider.

[pgassmann]

Thank you for your comments. Good to know, that there is now a Puppet-3 compatible version of the module. I could imagine then to refactor my module, so it uses danzilio/puppet-letsencrypt or your version to install LE and manage the certificates, but keep the wrappers and firstrun mode. I just did not find the time and need to update my module.

[danzilio]

The firstrun mode interests me, though I'd like to see a fact that's a bit smarter than just a semaphore. I wonder how we could detect that with an external fact.

I'm still mulling over Puppet 3 compatibility. @domcleal if you submitted your puppet-3 branch as a PR we could use it as a place to aggregate the discussion.

[pgassmann]

In my module, a simple semaphore is enough, because I add locations to the nginx vhosts, so that after the first run, it will always have the same webroot. But if you allow different webroots, then you need a more generic approach.

[domcleal]

The firstrun mode interests me, though I'd like to see a fact that's a bit smarter than just a semaphore. I wonder how we could detect that with an external fact.

I think I confused two features in the other module, firstrun_standalone (which is what I want and described) and firstrun_webroot, which assumes there's a HTTP server up and running but at the wrong path - perhaps as a result of a package being installed and starting a service before the cert's requested.

The standalone mode may boil down to detecting whether the port's in use or not, either 80 or 443 (IIRC, the client and ACME is switchable) and potentially, on a specific interface. If there's no service running on an HTTP port then the standalone client should be able to bind to it and request the cert.

This mode would work on a first run if letsencrypt::certsonly was ordered before package installation, but not with some more complex scenarios (e.g. adding new SNI-based vhosts to an existing HTTPS server, which would require stopping the service).

I'm still mulling over Puppet 3 compatibility. @domcleal if you submitted your puppet-3 branch as a PR we could use it as a place to aggregate the discussion.

Sure, I opened #12. Thanks for considering it.

[pgassmann]

I reworked my module completely, now using your module to manage letsencrypt.

It now manages the nginx integration, and the firstrun logic.
https://github.com/pgassmann/puppet-letsencrypt_nginx

[danzilio]

That's awesome!! Thanks @pgassmann!

[pgassmann]

It's now also available on the forge with updated documentation: https://forge.puppetlabs.com/pgassmann/letsencrypt_nginx