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 out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id D8F7F1F4BD for ; Fri, 4 Oct 2019 11:18:09 +0000 (UTC) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C181C20D98; Fri, 4 Oct 2019 07:18:08 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 04 Oct 2019 07:18:08 -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=KvnMDB326fBHEi5turH4fF956G hh47hpAzmh0BBTuNU=; b=ZUg3kCHeqeb9PM8ixwnY/4+o6eGEZLpQ2GqARVNGS3 dDWPhc/ZsquV3rrmLvBNs3kuq6guKx9D8NsSv+2Q1yBfIERddShv7mdAkilxRVQP vlekeWlZpcXKuMccx6IcChuy80gpO0xxa6RTb2k6HXY9Vrt+TJm4EwH+vKu+Kxm0 268ao0MPEQyJvR6VW8S7ibSjjpIw17udLzTLEs0WL7W08ssWcIF0z0+ode/3cRoH 3i81Tc1fvebHIzG5ptdqXvwFutbkovAQ+9npfI934gCb+n+8BCmc8UUPVonoGJ96 xx5ErkyAOyF9hWrIfkK49cMe/qjMzhWCl7qUz43QA3MA== 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=KvnMDB 326fBHEi5turH4fF956Ghh47hpAzmh0BBTuNU=; b=F7mtxF1wE+IG2Mw6sgOg/f waZv4nLAQV/I7hG27/iu8FyuQdZNv+G8MXePDBnEvfSVxOLOHhDb9AeEqC2LTtAd iwbwFktZPS5aJTpACCHZDeCIh/QhWjCsBjhiU2KzQrneaiheC7jcN70PjdogX1S2 ACw8+JouL7DWNAqsy2cAU0fmOHOCsaez/q5WejkOGr8S1BfAYkFi0kLCZCVGVV3c VSwVUvUWdPK5xX98qTAesl/177gJinwMXjZmc+6Dg8/ZnIv9Bte/zfIVn7NJBaiE ueigpt6Rrbl+Mx2Yk1pz6tFMk8Roe2WmC2QvWb9XB6VlXNOtdXVxydRaL7dgMCZQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrhedugdeffecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephffvufgjfhffkfggtgesghdtreertd dttdenucfhrhhomheptehlhihsshgrucftohhsshcuoehhihesrghlhihsshgrrdhisheq necukfhppeekgedrudekhedrfeeirddvtddunecurfgrrhgrmhepmhgrihhlfhhrohhmpe hhihesrghlhihsshgrrdhishenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from localhost (p54b924c9.dip0.t-ipconnect.de [84.185.36.201]) by mail.messagingengine.com (Postfix) with ESMTPA id A20C580059; Fri, 4 Oct 2019 07:18:07 -0400 (EDT) From: Alyssa Ross To: Eric Wong Cc: meta@public-inbox.org Subject: Re: public-inbox-init with minimal info In-Reply-To: <20191004024559.GA24741@dcvr> References: <87bluyhyfi.fsf@alyssa.is> <20191004024559.GA24741@dcvr> Date: Fri, 04 Oct 2019 11:18:01 +0000 Message-ID: <878sq0iwt2.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 >> Since the V2 initialization isn't encapsulated in one easy command, I'm >> wondering what the best way to accomplish initialization without writing >> a config file or asking for unnecessary information is. I could just >> run public-inbox-init with PI_CONFIG=/dev/null, but then it's still not >> clear to me what information about the mailbox the script requires to be >> able to initialize the mailbox. Looking at the code, I see that at >> least the primary address is passed to PublicInbox::Inbox, but I'm not >> sure what that would actually be used for inside the inbox. > > That address is used for making commits using the > public-inbox-{learn,edit,purge} commands, and also matching > with public-inbox-mda for delivery. I'm guessing those read from the config file, though? I'm trying to figure out what configuration is stored in the inbox directory as opposed to the config file. > You want to provide that inbox during the post-install? > > I'm not sure if I understand what's going on (but it's been a > long day :x). I'm not sure if providing an inbox on package > installation is necessary or even a good thing... > > Using git itself as an analogy: I wouldn't expect installing git > to auto-generate an empty git repo for me. So same with > public-inbox, and stuff like cgit/gitweb... I agree -- creating an inbox on package installation would be a terrible idea, and is not what I'm proposing to do. Some background: in the Nix ecosystem, we have a package repository, Nixpkgs. These packages are fairly typical except for unusual paths (containing checksums of the "inputs" -- think dependencies -- of the package) and the functional language they're written in. We also have NixOS, which is a GNU/Linux distribution, that uses those packages but also adds the concept of "modules", written in the same language as the packages. These modules do things like configuring the users on your system, setting up config files, etc. The idea being that you can generate a whole Linux system from pure (in the functional programming sense) configuration, reproducibly, and have the system stuff be read only at runtime to the maximum extent possible. I'm working on both a package _and_ a module for public-inbox. The package will do exactly what you'd expect a package to do, but the module will let you express global and per-inbox configuration in the Nix language, generate a read-only public-inbox config file and systemd units from those, and, at boot time or configuration change time, initialize the inboxes defined by the user. As an example, Tor in NixOS looks like this: { ... }: { services.tor.enable = true; services.tor.hiddenServices = [ { name = "public-inbox"; map = [ { port = 80; destination = 8000; } ]; version = 3; }; ]; }; 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. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEH9wgcxqlHM/ARR3h+dvtSFmyccAFAl2XKmkACgkQ+dvtSFmy ccAtZw/+Jy9ZOY4KOzYnxBX/jHJZf0gTMxZSaHdZHUEH+3WQflIYIHQnv56Xi+iW Naqq3AuYaDULeaGQqmjvSBYdWUNCfSFvC+mq0B1bZvf8LzjL8BOIj27QXcLUBpg4 2SPiub22JZmPpH3ehty0p9+5gUcmUMg42t+iFINUokJZHGoucEtc8qV16IyCMi+Q BS0N6Nq+ukOf1RauTn3GtkY7av0KTCPMGgy7M/Yio/dwKGJwu28aYeDmF7Hu4lPn rSPOlozPcBTTF678pBzdiAm3HsWNP+Nh8AbrPVI7+q3QwRrPQss09ozS3AZd6dfA SYPMEG9tg1FuLQlbtAdUmSQdcMS0TVdlvATeyCm9tsWP3LjS2oUXVug/ZpHBec8b D52zg3JGx6ArhtEjpnhaicBU8mUYIJ1dVW6zGfNEVDtH46kbRquq52Jd08EfPswx 56VO9nTPykUUmuPxm7KUaQ4zHfG15L9j4tL7FT28BhIwhmq8y/Yir27cDXBowCX8 92aXbyAQd8urWmSeKpeRPNn2kcR5pge8TWghj4K9KdKuHUFz8jB/6a1JPB/U5A7L MWt2aapfISU5Ygf/W8mwzWbglqMU31CTl5PUgHCueAVEExsGzxQoO8Hyhgss4wyu l6ur8ruWFv+m9hdL0K88yrZraPl5SaQrfogEnp8ya03ReXNir6E= =YED7 -----END PGP SIGNATURE----- --=-=-=--