all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Christopher Allan Webber <cwebber@dustycloud.org>
To: Andy Wingo <wingo@igalia.com>
Cc: Guix-devel <guix-devel@gnu.org>, 26685@debbugs.gnu.org
Subject: Re: certbot service experience
Date: Tue, 02 May 2017 19:07:28 -0500	[thread overview]
Message-ID: <878tmedcqn.fsf@dustycloud.org> (raw)
In-Reply-To: <cuca86vd7jo.fsf@igalia.com>

Andy Wingo writes:

> On Sat 29 Apr 2017 23:33, Christopher Allan Webber <cwebber@dustycloud.org> 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	other threads:[~2017-05-03  0:08 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-27 20:12 bug#26685: certbot service Andy Wingo
2017-04-28  9:24 ` Clément Lassieur
2017-04-28 12:47   ` Andy Wingo
2017-04-29  9:14     ` Clément Lassieur
2017-05-02  7:31       ` Andy Wingo
2017-05-02 19:40         ` Clément Lassieur
2017-04-29  9:25     ` Clément Lassieur
2017-04-28 19:33   ` Leo Famulari
2017-04-29  9:44     ` Clément Lassieur
2017-04-29 21:33 ` certbot service experience Christopher Allan Webber
2017-04-30  2:15   ` Chris Marusich
2017-04-30  2:35     ` Christopher Allan Webber
2017-04-30  3:00       ` Chris Marusich
2017-05-02  7:47   ` Andy Wingo
2017-05-03  0:07     ` Christopher Allan Webber [this message]
2017-07-26  8:59   ` [bug#26685] " Ludovic Courtès
2017-07-27 13:24     ` Christopher Allan Webber
2017-07-30  9:17       ` ng0
2017-07-30  9:22         ` ng0
2017-07-30  9:56           ` Julien Lepiller
2017-07-27 17:30     ` Tobias Geerinckx-Rice
2017-08-22 13:19       ` Ludovic Courtès
2017-08-23 14:57         ` Christopher Allan Webber
2017-10-24 14:26           ` Christopher Allan Webber
2017-10-24 15:27             ` Leo Famulari
2017-10-24 16:27             ` Ludovic Courtès
2017-11-28 22:41               ` bug#26685: " Ludovic Courtès
2017-11-29  5:45                 ` [bug#26685] " Christopher Allan Webber
2017-11-29 16:55                   ` Ludovic Courtès
2017-11-29 19:08                     ` Christopher Allan Webber
2017-10-24 14:53       ` Leo Famulari
2017-10-24 15:25         ` Christopher Allan Webber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878tmedcqn.fsf@dustycloud.org \
    --to=cwebber@dustycloud.org \
    --cc=26685@debbugs.gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=wingo@igalia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.