Re: certbot service experience

[Andy Wingo]

On Sat 29 Apr 2017 23:33, Christopher Allan Webber <address@hidden> writes:

> I'm crossposting this to guix-devel, even though it's in reply to
> guix-patches bug #26685 adding the cerbot service, because I think it's
> more about my experiences with workflow and less about what might affect
> that specific bug.  (If you reply on guix-devel, maybe remove the
> debbugs address.)

Oh, I think this does bear on the service.  Thanks for the detailed
report!

>  - I was surprised that I was prompted for an email while doing guix
>    system reconfigure (and in being asked if I was willing to supply
>    that info to the EFF so they can put me on their mailing lists, which
>    I'm not against but was surprising to encounter in a reconfigure).
>    IIRC this is the first time anything like that has happened.  I
>    generally anticipate such a reconfigure to be "prompt-less".
>    I wonder if there should be an email field we can provide, so that it
>    doesn't do this prompt?  Granted, it's for the first time run only.
>    Maybe it's okay to do things as they are, but we should document it?
>    I dunno?

Yeah I don't know :)  I mean, good that it worked.  I hadn't tested this
bit entirely -- I didn't have a spare source of domain names handy (!).
And I forgot about it asking me for my email.

However apparently what happens is that certbot will prompt you for
things if you run it with an interactive terminal.  We can pass
--no-interactive, but AFAIU that will require you to go later and
"register" your account with an after-step -- and if you miss that you
have to do that, perhaps your cert stops working soon.  Not sure what
the best practice is here.  In any case we need to document this!

>  - Not specifically something to do with this package, but nginx wasn't
>    coming up at a few points (btw, default nginx configuration won't
>    work, because it points at certificate filepaths that we don't
>    "automatically" put in place).  When nginx doesn't come up, there's
>    pretty much no information as to why; nothing in the shepherd logs,
>    nothing useful from shepherd itself ("shepherd: Service nginx could
>    not be started."), and nothing in the nginx logs either.

I think the default nginx configuration works, because it defines no
servers.  If you run just (nginx-configuration), then certbot extends it
correctly to allow it to request a certificate.  You are right that the
default server config does want to listen on HTTPS and it will balk
if/when there is no cert.  (Does that prevent the whole nginx server
from running?  That would be a bummer.)

>  - Getting the certbot stuff to work basically involved three stages:
>
>    1) Enable nginx without cert certbot, and point the root somewhere
>       which will be the same place you'll set certbot-configuration's
>       webroot at in the next step.  This looks something like the
>       following:
>
>         (service nginx-service-type
>           (nginx-configuration
>            (server-blocks
>             (list
>              (nginx-server-configuration
>               ;; Replace these with your own domain and web root
>               (server-name '("test.activitypub.rocks"))
>               (root "/srv/activitypub.rocks/site/")
>               ;; Note that you have to disable https and any certificates
>               ;; esp because our nginx config defaults to pointing at keys
>               ;; that probably aren't there.  Without doing this nginx
>               ;; will die mysteriously.
>               (https-port #f)
>               (ssl-certificate #f)
>               (ssl-certificate-key #f))))))

Pretty sure you could do this with just the default nginx-configuration
and no sites configured and having the certbot service.

>   3) Okay hopefully that went successfully!  It should say.  Assuming it
>      did, *now* we can add the keys appropriately to the nginx config.
>
>        (service nginx-service-type
>                 (nginx-configuration
>                  (server-blocks
>                   (list
>                    (nginx-server-configuration
>                     ;; Again, adjust to your site
>                     (server-name '("test.activitypub.rocks"))
>                     (root "/srv/activitypub.rocks/site/")
>                     (ssl-certificate
>                      
> "/etc/letsencrypt/live/test.activitypub.rocks/fullchain.pem")
>                     (ssl-certificate-key
>                      
> "/etc/letsencrypt/live/test.activitypub.rocks/privkey.pem"))))))

Now it works yes :)

>   4) At this point I was surprised that it seemed like nginx should have
>      been working with https since everything was in place, but I
>      couldn't access it from my browser over https.  Frustrated, I
>      restarted the server.
>
>      And then it worked! :)

Incidentally I found this a few times too.  Like you change the
nginx config but the nginx server never restarts because somehow
shepherd wasn't updated with the new config.  Why would that be?  I
didn't understand it either and just restarted the server.  Oh well.

Thanks again for the feedback!  Definitely needs to be better documented
I guess.  We need to make sure nginx can partially start, and if that's
not the case, then introduce a dependency between nginx start and
certbot run, and arrange for the initial certbot run to make its own web
server for that initial phase.

Andy