Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for renewal hook scripts #20

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Add support for renewal hook scripts #20

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
61e8926
Add support for renewal hook scripts
andrew-vant Dec 6, 2017
669be95
Add support for hook literals in pillar
andrew-vant Dec 7, 2017
5ac07b9
Cosmetic improvement to hook state name
andrew-vant Dec 7, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 22 additions & 0 deletions README.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -191,6 +191,28 @@ You are able to use multidomain certificates:
- awk.opensource-expert.com
- www.awk.opensource-expert.com

You can add renewal hooks if needed; these can be useful for services that
don't run as root, to move certs somewhere they can access:

.. code-block:: yaml

letsencrypt:
client:
hooks:
pre:
- salt://path/to/prehook1.sh
- salt://path/to/prehook2.sh
deploy:
- salt://path/to/deployhook1.sh
post:
- salt://path/to/posthook1.sh
# You can define hooks literally in pillar too
pillarhooks:
deploy:
deployhook1.sh: |
#!/bin/bash
echo "Triggered deploy hook"

Legacy configuration
--------------------

Expand Down
28 changes: 28 additions & 0 deletions letsencrypt/client/init.sls
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -107,4 +107,32 @@ certbot_cron:

{%- endif %}

{%- for hookset, hooks in client.get("hooks", {}).items() %}
{%- for hook in hooks %}
{#- FIXME: Should probably complain if something other than
pre/post/deploy is given, but I'm not sure how. #}
{%- set basename = hook.split("/") | last %}
certbot_renewal_{{ hookset }}_hook_{{ basename }}:
file.managed:
- name: /etc/letsencrypt/renewal-hooks/{{ hookset }}/{{ basename }}
- source: {{ hook }}
- template: jinja
- mode: 700
- require:
- cmd: certbot_installed
{%- endfor %}
{%- endfor %}

{%- for hookset, hooks in client.get("pillarhooks", {}).items() %}
{%- for basename in hooks.keys() %}
certbot_renewal_{{ hookset }}_phook_{{ loop.index }}:
file.managed:
- name: /etc/letsencrypt/renewal-hooks/{{ hookset }}/{{ basename }}
- contents_pillar: letsencrypt:client:pillarhooks:{{ hookset }}:{{ basename }}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer structure that I proposed before:

letsencrypt:
  client:
    hook:
      pre:
        - source: salt://path/to/prehook1.sh
      deploy:
        - script: |
            #!/bin/bash
            echo "blahblah"

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about it, but it seems awkward. First because the jinja logic gets tangled (lists of single-element dictionaries that require different file.managed arguments) and second because the - script notation has no way to specify a filename, so you're stuck with 'script1.sh', etc.

- mode: 700
- require:
- cmd: certbot_installed
{%- endfor %}
{%- endfor %}

{%- endif %}