guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#26685: certbot service experience


From: Christopher Allan Webber
Subject: bug#26685: certbot service experience
Date: Tue, 02 May 2017 19:07:28 -0500
User-agent: mu4e 0.9.18; emacs 25.2.1

Andy Wingo writes:

> 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!

Glad it helps!

>>  - 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 sure what the best practice is either, but documenting it would be a
step in the right direction!

>>  - 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.)
> [...]
> Pretty sure you could do this with just the default nginx-configuration
> and no sites configured and having the certbot service.
>

Oh, I didn't realize certbot was extending the nginx config...!  Clever.

>>   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.

Cool.  I have no idea how to do that with current shepherd setup!  But
maybe it doesn't need to be complex; maybe these tests can just be part
of the service start-up recipe or something.

Thanks for the thoughtful reply :)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]