[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: certbot service experience
Re: certbot service experience
Sat, 29 Apr 2017 20:00:16 -0700
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)
Christopher Allan Webber <address@hidden> writes:
> Chris Marusich writes:
>> Christopher Allan Webber <address@hidden> writes:
>>> - I was surprised that I was prompted for an email while doing guix
>>> system reconfigure
>> That does seem odd. Why were you prompted for an email address? Can
>> that be fixed somehow?
> It's the certbot initial-setup script firing off here. The email
> address is given so you can be notified for security updates, etc.
> Maybe recovery? Don't remember about that last bit.
I see. Having never used certbot before myself, I don't think I can
really give useful advice here. It just seems a little strange to
require user interaction during the reconfigure. One would think that
one could provide any necessary information declaratively in the
operating system configuration file.
>>> 2) Enable the certbot-service-type (and mcron-service-type if you
>>> haven't already):
>>> (service certbot-service-type
>>> ;; Replace these with your own domain and web root
>>> (hosts '("test.activitypub.rocks"))
>>> (webroot "/srv/activitypub.rocks/site/")))
>>> ;; if you don't have an mcron service already
>>> (service mcron-service-type)
>> Where is the certbot-service-type defined? I couldn't find it in the
>> master branch. Also, why is mcron required? I don't know much about
>> LetsEncrypt, but I thought certbot was a one-time thing that you do
>> manually... Why is it a "service" here?
> It's not in the master branch is why. I was looking at the
> wip-git-https branch. :) I think it's also in the wip-potluck branch.
That explains it! :)
> It's extending the mcron service so it can install an auto-update rule
> for you, which is pretty cool!
I see. I would have thought that if service A extends service B, and
one defines service A in the operating system configuration file,
service B gets pulled in automatically. Is that not true?
>>> 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
>>> ;; Again, adjust to your site
>>> (server-name '("test.activitypub.rocks"))
>>> (root "/srv/activitypub.rocks/site/")
>>> Reconfigure and cross your fingers!
>>> 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! :)
>>> So, this involved reconfiguring, reconfiguring, reconfiguring, and then
>>> a restart, then it worked for me. (Well, plus a few reconfigures where
>>> nothing worked at all because I broke things of course. ;)) I wonder if
>>> that can be improved?
>> I wonder if it is possible to define a custom service which orchestrates
>> the execution of nginx and certbot in the way you require, so that you
>> can define it all in one place, at once, without needing to reconfigure
>> multiple times?
> It might be, I dunno! Maybe in starting the service, if it sees that
> the keys have not been generated yet, it pulls up nginx temporarily just
> to do the registration with the nginx that doesn't have the keys in it,
> does the generation of the keys and verifies them with letsencrypt, then
> pulls up the proper nginx at last.
> I don't know how easy/feasible this is.
It would be nice if we could just declare what we want in the operating
system configuration file, and get it without having to run multiple
reconfigures or interact with the user. But hey, anything that works is
a step in the right direction!
Description: PGP signature