Comments (9)
I have no idea yet how to approach this. The simplest would probably be to check if the file /etc/init.d/{{service_name}}
exists, but what about systems using systemd or upstart? We can look how the service
module selects the right launch daemon, but that would mean we need to follow future changes to that module and reflect them here too. Maybe it's appropriate to give this upstream to Ansible to add a soft-fail option on services? .. feedback welcome 😅
from ansible-letsencrypt.
Well, right now the role only targets Debian based systems, with a promise of Ubuntu 14.04. I think it's safe to in this case check whether Apache2 is installed using commands available on these systems. If someone contributes to make the role work for say RPM based Linuxes, then those commands can be expanded to suit.
So something like this and then remove apache2
from the letsencrypt_pause_services
list if not installed?
from ansible-letsencrypt.
That would probably work on all Debian based linux hosts and with some conditional tasks we could also add support for other distributions and BSD. We'd need to keep track of package and according service names in case both are not identical. That list should be easy to extend from outside, so that we can deal with unknown services too.
The approach of stopping running services results in downtime of (production) systems, which we could try to improve in the same breath. I could imagine two ways to reduce the downtime:
Option 1: Using the Firewall to redirect traffic
Serving the certbot acme challenge on different tcp ports and temporary configuring the firewall to forward incoming traffic to these would allow to keep all services running, so that we would not have to deal with that. (The downtime would still remains a problem - ideally we know the source IPs used by LetsEncrypt.)
Edit: Example with iptables
iptables-save > /tmp/iptables-rules.v4
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -t nat -F
iptables -t mangle -F
iptables -F
iptables -X
iptables-restore < /tmp/iptables-rules.v4
Option 2: Serve .well-known/acme-challenge/ with the running webserver
Many common webservers support global overrides for specific paths on all virtual hosts. Like done here with nginx or here with apache2. Reloading the service once after configuring the override and one more time after cleaning up would allow us to switch to the new certificates without having a downtime at all.
from ansible-letsencrypt.
I'm a strong fan of option 2, definitely. Initially I wanted to look at something like that but ended up going for the simple stop/start, which unfortunately does not go well in more demanding environments that can't allow downtime. The SO answer though does have some comments that it might not work on all virtualhosts, but that is probably a tweaking issue :) Also, Apache 2.2 and 2.4 might have some differences - here 2.4 should be at least supported.
from ansible-letsencrypt.
I wonder if we should just provide some examples how to configure nginx, apache2 and some other common webservers to server the acme-challenges from a common directory that certbot exports to. Personally I do not like the idea of fiddling with existing webserver configs from within this role.
The only thing we need to do is to allow switching off --standalone
and add --webroot-path
instead.
from ansible-letsencrypt.
I would still like the role to be able to be used without the user having to pre-configure anything for it, so would prefer to at least by default the behaviour to install temporary configuration into apache / nginx, and then remove it. The configuration of these is pretty standard.
For the edge cases or those who want to not have this role mess with their web server, provide a possibility to disable configuring apache/nginx?
Closing this would allow all the service start/stop code to be removed I guess?
from ansible-letsencrypt.
For the edge cases or those who want to not have this role mess with their web server, provide a possibility to disable configuring apache/nginx?
In more complex setups the last thing I would want is certbot trying to be smart and automatically change configuration of a service that is not running on port 80/443 at all.
I think we should not start maintaining single services to allow continuous service, but instead add a mode where certbot puts the the challenge to a configurable output directory (not using --standalone
). Doesn't certbot already has the ability to tweak configurations that we could mask behind a configuration option?
Closing this would allow all the service start/stop code to be removed I guess?
Nope, it works as intended. The services are stopped before certbot runs. In case of failure during certificate creation the service should most probably come up again anyway - renewing a certificate is a common task with this role and you don't want your service to stay down just because LetsEncrypt was not reachable. What you probably still want is that the rest of your playbook is not executed and error's out, so that you become aware of the problem.
from ansible-letsencrypt.
What about certbot-external plugin? It makes a temporary virtualhost afaict, and we could provide variants of the handler script for both Apache and nginx. This would not need any global config changes - and of course we could allow disabling this via configuration, but this could be an easy to adopt default way of getting certificates without stopping the web server for downtime.
from ansible-letsencrypt.
See also discussion in this issue.
from ansible-letsencrypt.
Related Issues (11)
- Use deb instead of wrapper HOT 3
- Exit with error when certificate request failed HOT 2
- Running Certbot as non-root user
- Certbot checkout fails with "error: pathspec 'v0.8.1' did not match any file(s) known to git." HOT 2
- Having an issue when not specifying letsencrypt_pause_services HOT 9
- Ensure certificate is generated with correct name
- Add renew to cron HOT 2
- letsencrypt_certbot_args HOT 1
- Multiple domain validation HOT 3
- Cannot install via ansible galaxy HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ansible-letsencrypt.