From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Allan Webber Subject: Re: certbot service experience Date: Tue, 02 May 2017 19:07:28 -0500 Message-ID: <878tmedcqn.fsf@dustycloud.org> 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]:44363) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d5hpv-0003m9-3i for guix-devel@gnu.org; Tue, 02 May 2017 20:08:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d5hpJ-0003dr-Uz for guix-devel@gnu.org; Tue, 02 May 2017 20:08:07 -0400 Received: from dustycloud.org ([2600:3c02::f03c:91ff:feae:cb51]:60260) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d5hpJ-0003cg-Mx for guix-devel@gnu.org; Tue, 02 May 2017 20:07:29 -0400 In-reply-to: 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: Andy Wingo Cc: Guix-devel , 26685@debbugs.gnu.org Andy Wingo writes: > 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! 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 :)