Add support for renewal hook scripts

[andrew-vant]

#17 notes that support for renewal hooks would be useful. This manages the directories under /etc/letsencrypt/renewal-hooks.

I find something like this necessary for making certs available to non-root daemons -- in my case ejabberd.

[andrew-vant]

Hrm. Not entirely sure why the CI build failed, or if it has anything to do with my addition. Its log seems to think the letsencrypt state isn't there.

[fpytloun]

I think you should be able to supply whole scripts in model and not only source on salt filesystem.

[andrew-vant]

I'm not sure I understand the request. Could you give an example?

[fpytloun]

I would suggest using metadata like this:

letsencrypt:
  client:
    hook:
      pre:
        # Use salt fileserver
        - source: salt://path/to/prehook1.sh
        # Or generate file by script as a content
        - script: |
            #!/bin/bash
            echo "Triggered pre-hook"

So you can supply scripts on salt filesystem or pass them directly.

[andrew-vant]

Putting scripts directly in pillar fills me with fear and loathing, but I don't really have a good argument against supporting it, except perhaps that it would make the state more complicated. I'll see what I can do and then update the PR.

[andrew-vant]

Updated with hook literals. I chose a slightly different pillar structure than suggested. I am still not sure why the CI check is failing.

[andrew-vant]

Any further thoughts on this?

[fpytloun]

I would prefer structure that I proposed before:

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

[andrew-vant]

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.