From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS11403 66.111.4.0/24 X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 916851F4BD for ; Sat, 5 Oct 2019 13:06:06 +0000 (UTC) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 911BB22108; Sat, 5 Oct 2019 09:06:05 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Sat, 05 Oct 2019 09:06:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h= from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type; s=fm1; bh=A5LX5NcDjSPOsq7Vgsdiy2bMRz h+Js+Db3puPwccF5k=; b=EwCwcsAkqq2rnB7ke37r7OFplkl863hhuGYXsKtPCS V4btmmVU6tAo4y/f69J6nRp6C/j+SLbIDqzQvL8Saqh3EgOGPeLiJyVH+hHgwXBc Ung6V294BifvngDC1zOJHT2+GhNwlu5r8uSLmZy5jKcJh4A8SjseRTGI0k1uJdd7 3vHdTnSmJ+AZMBgWpRje4sHjTE+5SmnP2Jg4JTM3j+oobsRQRN55VPb8vYbbKZTA cE/FwsCJECsjZz8PrQIEzvntY/QejX8PfOoJqjfxcteEZxIN/Br6eJ2N38CAAaJa E86S1wxRUh/syUAg0XRm5HIZ27vTRIdZe9xqeDtzluSg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=A5LX5N cDjSPOsq7Vgsdiy2bMRzh+Js+Db3puPwccF5k=; b=EJ8x1ImJjVYzFCK6pe20wk ivPPsfjHP6daGwW9wT31pM1IXtMikYsNa9WhPpfnd65NOUHDkm6aAXBHiXZx/dYk 9Me5AmWBQiElTjPlYLHt5d9k7luWbuse3babnP8MgrcpvF/t1QpVI1F3UtBWUE4M nRX8z6WjOWYzZnsawpdHl3AnErZCOEl4G+SYkFAenOrnxVRJALOw1wBa/hPJdI0J /0HalEV3Z+nOG7aSkRH4EOgOUKh1r3x1Qd0qmR4GFNFlDXbEXunrM1r+YtPq1fkj gC5HFT1J8uNtw2SZS31RaLJRr/aUn9OVI2VIjotbyWQD+UbBekVCde5hiQ4bOHDA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrheefgdeiudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephffvufgjfhffkfggtgesghdtreertd dttdenucfhrhhomheptehlhihsshgrucftohhsshcuoehhihesrghlhihsshgrrdhisheq necukfhppeekgedrudekgedrvddvgedrudehtdenucfrrghrrghmpehmrghilhhfrhhomh ephhhisegrlhihshhsrgdrihhsnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from localhost (p54b8e096.dip0.t-ipconnect.de [84.184.224.150]) by mail.messagingengine.com (Postfix) with ESMTPA id 3097AD60057; Sat, 5 Oct 2019 09:06:04 -0400 (EDT) From: Alyssa Ross To: Eric Wong Cc: meta@public-inbox.org Subject: Re: public-inbox-init with minimal info In-Reply-To: <20191005051434.GA23947@dcvr> References: <87bluyhyfi.fsf@alyssa.is> <20191004024559.GA24741@dcvr> <878sq0iwt2.fsf@alyssa.is> <20191005051434.GA23947@dcvr> Date: Sat, 05 Oct 2019 13:05:48 +0000 Message-ID: <87pnjb4a1f.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" List-Id: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > There isn't any config stored in the inbox directories > themselves, although there's some metadata in SQLite for > incremental indexing and indexlevel for Xapian. Cool, okay, I think this is what I wanted to know. I'll generate an inbox and see what's in sqlite, and omit anything that isn't used there. > I'm not sure how the public-inbox config file can/should remain > read-only. It's analogous to a config file for cgit or gitweb, > so maybe modules for those can offer some inspiration... I've been using cgit fine with a readonly config for ages, fwiw. >> As an example, Tor in NixOS looks like this: >>=20 >> { ... }: >>=20 >> { >> services.tor.enable =3D true; >> services.tor.hiddenServices =3D [ >> { >> name =3D "public-inbox"; >> map =3D [ { port =3D 80; destination =3D 8000; } ]; >> version =3D 3; >> }; >> ]; >> }; >>=20 >> This will generate a static tor.service and tor config file -- we do as >> much as possible staticly and purely because then we know that if a >> configuration is rolled back, we can remove the service etc. For state, >> however, like the hidden service private key (in this case -- I could >> have used a static one here if I'd wanted), it will be generated either >> at boot time or in Tor's ExecStartPre. This is the same mechanism I >> would use to run public-inbox-init. > > So that means a new tor process is spawned for every hidden > service? (instead of one tor process running multiple > services). It works, but it's not memory-efficient (but > could be more secure if tor has bugs). No. If I had added multiple hidden services above, Nix would still generate one config file, one systemd service, etc. > But yeah, packaging services/modules for different systems and > use-cases is hard, everybody seems to do it differently and > want different things. So I'm really not sure how packaging > a module would work, it seems like that's something each user > would want to manage on their own. Well, the idea is to provide sufficient configuration options that it should be sufficient for almost everybody's needs. Tor has way more options than I showed above, for example. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEH9wgcxqlHM/ARR3h+dvtSFmyccAFAl2YlSwACgkQ+dvtSFmy ccBS7A/7B5RJQYF7kLtrAoDNtBIWWg+QIQUHfJ48+AoVzBSGCUjgzap13qJhvWXq cGzCXf6M3q05KmVXZKoJ8uP1D89th8vnvV65TUWiFuN6WwBBhwTf9kSirVJv1CoH olo0K7M2y/IrledrdUS5SFWAan/hSReGvvoZoiBgHdNbPEreVqddFsZ/irn7qxsA kaG7oo+53ryV4QoXj0Z/NtiZWsI66L9p0wBQuDrfOvZ3Q9IFBbLLgFwcm8D/xFjO kkYclUNLZ+sTLaeUUXqPRVeAXbg8Pn/q9ndE4sXSMBus029l3E4W0RNdEKtj/N9u CuTxgQOcbxU8o3VTrt8xNgoRxU4w/CVXMQNh81Pw4rkpx6MS8EB0u5dOkykuVlfj 8t9ViOBfrz0JFYu5/uJYrm2Q/FUzXv/w2/zQpjuuPMcwM1F0q/UQkH0GDaG153lW suVsp7QdDtP70gfECFm7jQA/51sQYenhU698gh2/DRsFchWWoG5R/Yfjwn8gyPFk HgbmoeKGDw1TYpLmcIu4nfgpIqhdLA3kqhspOxENjUCh8arI5Xg0O3KQ5pkGkwIi cA7E0WWQ5QOB9lApvyZmgJQtSwxNCYu1dLYEZLy2zpmTWCY+fYJabE4Gn3FhXN6Q 9iCpKQtWNIioqIR2urkk8um7xGKyAXWo6KmZBFGGac/IWpwV2+E= =tc2h -----END PGP SIGNATURE----- --=-=-=--