From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Wingo Subject: Re: certbot service experience Date: Tue, 02 May 2017 09:47:23 +0200 Message-ID: References: <87tw56dhlp.fsf@dustycloud.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54726) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d5SX2-0006Ug-B2 for guix-devel@gnu.org; Tue, 02 May 2017 03:47:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d5SWz-00052G-9E for guix-devel@gnu.org; Tue, 02 May 2017 03:47:36 -0400 Received: from pb-sasl1.pobox.com ([64.147.108.66]:50571 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d5SWz-00051g-1v for guix-devel@gnu.org; Tue, 02 May 2017 03:47:33 -0400 In-Reply-To: <87tw56dhlp.fsf@dustycloud.org> (Christopher Allan Webber's message of "Sat, 29 Apr 2017 16:33:22 -0500") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Christopher Allan Webber Cc: Guix-devel , 26685@debbugs.gnu.org On Sat 29 Apr 2017 23:33, Christopher Allan Webber 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