From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id 0LpyKruOuWVXYgEAe85BDQ:P1 (envelope-from ) for ; Wed, 31 Jan 2024 01:05:15 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id 0LpyKruOuWVXYgEAe85BDQ (envelope-from ) for ; Wed, 31 Jan 2024 01:05:15 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=koszko.org header.s=mail header.b=xmhNz8ex; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1706659515; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=S9WELKVl6xYZ3m3by8O2Ngl4Z3GSixh2GkO5Ug/SdZI=; b=Uuxay6jMcvFduSR+yq8sneqhtZUDxSw8D77Ho2FvM+MhzocvvVTIsuEuI0/d+6AbxtP/u/ YmmVVsL02ATK9AMUKutAR2X8Ws0Pax9rtUQisx53lr+tY1lgnwvxlt6yh7xOsrM9waaWtW WA84bMFQP/qN+89daD3lT5Uv/QM/PGl2kXO8i76TyW5p/ubgtO7HtIsjTB8rqzJwBRXIqv qMB4N51Xv+AajGyrIEC8hQRjGGEWMGSlKwx+KAByvEbOO9Sfp9Rjf06xd2xOTGseI0NMtK PqLtpU+sRd6+qKa1E0adASpuPq2pDRmmC4tvX1RlAZsPoJbFQFlU+qSnClShsw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=koszko.org header.s=mail header.b=xmhNz8ex; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1706659515; a=rsa-sha256; cv=none; b=A+QtPvRtuXlk21tLvUvrUJFKntz6BP12q0B8cwzOTcEDq21AD6gZqMFBqOzkO03PH24KBN CPzgFeI0GOl1WvWDrP5w7u+yBnf2GkhD1OIu48bF0qorn0nUl7JKK1oCv3O8F+fa1z1Ji6 49x+ASAOIT/8XjztkwU8kl8darzhCyUNTsaHe6dy38/01/TpvC41ogQkX5tVaJ3NxJ8G1h /JBS86lL3/0gFF/MykBy/JoutRUspv+ldgLOYK+jXdoCWilrDr01QtSpynwcI1c6SfXM7O Y96FFqPJsEnDU81zsbuEIWkQyKKofll25J18iWvDo4eDQyl18v2LEfGuZdC/Jg== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 2A8C621D32 for ; Wed, 31 Jan 2024 01:05:15 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rUy5l-0005tx-Dm; Tue, 30 Jan 2024 19:04:37 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rUy5j-0005sU-1T for guix-devel@gnu.org; Tue, 30 Jan 2024 19:04:35 -0500 Received: from koszko.org ([93.95.227.159]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rUy5h-00074c-4Z for guix-devel@gnu.org; Tue, 30 Jan 2024 19:04:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=koszko.org; s=mail; h=Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject :Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=S9WELKVl6xYZ3m3by8O2Ngl4Z3GSixh2GkO5Ug/SdZI=; b=xmhNz8exJx9l1gg4ZdauUhJt9K ULoJDRBe5ZnR177EmtWq60Nv9nl/IOO90/2ykI6Hefq1SazK6CUxcChYclkn3V1qtLEKGAXN8QFD8 oUA9NBl/a+rUATeSNtNNMdOiXJjfoGtbg9mtG7NGIybRA+HN4hSSVKz3LSBwBycmitR/340R54Lsz 8JxVMwSzLYS+xAiPqviZ8NraNGbSSO1iV4tZw8EfNmFhhdBqaAGQ3NPj+o4NOyQRcMc1Y3yD0bKjh AKZ7J0uPmdd0zoptH2VM37QeSA2NOVZXfxH34lUxYDuF8wxaMH5pNTwe+Cx4taMS+I2UNqPubNa7u ttFQcFJKOT9RT52+sO79X7jRCT8zLY4cqQbNsRfLy+UdgDAFLEv2SGoBbOq4zG6cjAvOCg1EvsiJZ ds02Ll7dftC4iO1xYfVH977wNPHu/IrGgjfia8vo+2O7caLn+mzElfPmRNz3LdfWTn8ugVhkiirky HveiV5lBdiC2u6CD3D+IdbTuEnW84oSywZO+LfvNgebGUoEQURxvKh8fp0kwZp7JuQIGRUqVt2GpS eTRKtlxIWEw0Xt0WUrMlwu1zS9k23OjNwte2GTv3bYkO3gp0MSbQ9Mql4/gMmaM4L0n7s3MDx9d4h EtWhPqVWgRaSXQv5SRC7Onamt4rg25J0B72Cw+Omc=; Received: from 78-11-235-220.static.ip.netia.com.pl ([78.11.235.220] helo=localhost) by koszko.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.1) (envelope-from ) id 1rUy5O-0007Tb-1f; Wed, 31 Jan 2024 01:04:14 +0100 Date: Wed, 31 Jan 2024 01:04:12 +0100 To: Carlo Zancanaro Cc: Felix Lechner , 46961@debbugs.gnu.org, clement@lassieur.org, brice@waegenei.re, guix-devel@gnu.org Subject: Re: [PATCH v2 0/4] Make certbot play more nicely with nginx Message-ID: <20240131010412.299d6a03.koszko@koszko.org> In-Reply-To: <87r0hyphni.fsf@zancanaro.id.au> References: <875xzanaer.fsf@lease-up.com> <87r0hyphni.fsf@zancanaro.id.au> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.37; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/VWt6fu+OTRQ=RDJNp5isi7l"; protocol="application/pgp-signature"; micalg=pgp-sha256 Received-SPF: pass client-ip=93.95.227.159; envelope-from=koszko@koszko.org; helo=koszko.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-to: Wojtek Kosior From: Wojtek Kosior via "Development of GNU Guix and the GNU System distribution." Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -9.26 X-Spam-Score: -9.26 X-Migadu-Queue-Id: 2A8C621D32 X-Migadu-Scanner: mx12.migadu.com X-TUID: Iorvq70B6qP5 --Sig_/VWt6fu+OTRQ=RDJNp5isi7l Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I sympathize with your approach (I, too, have been supplementing Certbot with self-signed certs for some time). What would also be cool is not to have `certbot-service-type` depend on `nginx-service-type` in the first place. So that one can more easily use another HTTP server. It can of course be achieved with `remove-service-extensions` from `(gnu services)`, it's just less elegant than having it supported directly. Perhaps some variant of the "dependency inversion principle" would fit here? How about the following set of service types? - certbot-tool-service-type =E2=80=94 does what `certbot-service-type` used= to do until now except it doesn't extend `nginx-service-type` and can itself be extended with not just ``s but also `` - certbot/nginx-service-type =E2=80=94 takes in ``, extends both `certbot-tool-service-type` and `nginx-service-type` - certbot/httpd-service-type =E2=80=94 takes in ``, extends both `certbot-tool-service-type` and `httpd-service-type` - certbot-service-type =E2=80=94 deprecated, functions as an alias for `certbot/nginx-service-type` Your proposals are of course useful as well, regardless of this being done Best :) Wojtek -- (sig_start) website: https://koszko.org/koszko.html fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A follow me on Fediverse: https://friendica.me/profile/koszko/profile =E2=99=A5 R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ=3D=3D | =C3=B7 c2luIHNlcGFyYXR= lZCBtZSBmcm9tIEhpbQ=3D=3D =E2=9C=9D YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ=3D=3D | ? U2hhbGwgSSBiZWNvbWUg= SGlzIGZyaWVuZD8=3D -- (sig_end) On Wed, 31 Jan 2024 08:48:54 +1100 Carlo Zancanaro = wrote: > Hi Felix, >=20 > On Tue, Jan 30 2024, Felix Lechner wrote: > > On Tue, Jan 30 2024, Carlo Zancanaro wrote: =20 > >> certbot can't produce certificates without a functional nginx =20 > > > > Yes, it can. The option is called --standalone. [1] =20 >=20 > You are correct, of course. If I had been more precise I would=20 > have said "with our current configuration, certbot can't produce=20 > certificates without a functional nginx". >=20 > > Maybe another way to bootstrap the certificates would be to hold=20 > > off on starting Nginx or Apache until all certificates are=20 > > obtained? =20 >=20 > This could work, but I see a few downsides. >=20 > As Cl=C3=A9ment has already mentioned, this would make nginx dependent=20 > on certbot. This causes problems for servers disconnected from the=20 > general internet, but it also shifts complexity into the nginx=20 > service without much benefit over the patch series I'm proposing.=20 > We'd need to add more configuration on the nginx side to control=20 > whether to delay startup based on whether we actually want=20 > certificates. This would delay the startup of the whole nginx=20 > process, even if some server configurations don't require new=20 > certificates. >=20 > For renewal, we would also have two options: (1) use --standalone,=20 > and require a period of downtime for our web server; or (2) use=20 > --webroot, and maintain two code paths for the two cases. I think=20 > it's a bad idea for Guix to make a decision that requires downtime=20 > of user systems if there's an alternative, so I don't like (1).=20 > Maintaining two "similar but different" code paths for (2) doesn't=20 > seem like a clear advantage over the patch series I'm proposing. >=20 > > Anyway, that's what I do manually. =20 >=20 > I use the DNS challenge type, with hooks which automatically=20 > create/remove DNS records. This solves all the problems I'm=20 > bringing up (i.e. doesn't require nginx, doesn't involve downtime,=20 > has a single code path), but I don't think Guix can assume that=20 > all users have the ability to do this. My aim with this patch=20 > series is to make the default certbot configuration work for the=20 > common case of a simple web server, without manual intervention. >=20 > Carlo >=20 --Sig_/VWt6fu+OTRQ=RDJNp5isi7l Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTpcnBg48VjfIpPS0JLxSIcWnn9GgUCZbmOfAAKCRBLxSIcWnn9 GnphAP9fimVBSPwXO2DvCnpJwYYfd+D3DZEyCM/lAg8tuci9bAD/SZ9HNA/tAVNn rpdR8LN6Wtan37zPQuM+KArL20FxLQY= =COVG -----END PGP SIGNATURE----- --Sig_/VWt6fu+OTRQ=RDJNp5isi7l--