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 64.147.123.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 wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 3EAAC1F4BE for ; Mon, 7 Oct 2019 20:52:41 +0000 (UTC) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 7B32B576; Mon, 7 Oct 2019 16:52:40 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 07 Oct 2019 16:52:40 -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=j7jCmkMGf4ES9ntc6h0rVGvbGG CzalfDSE2ZQtm5qFk=; b=lKny81QMA7fekHEzarmiC3KMlLXtcOP9fqi4gkANsg 4r8pI5ZybpdlzFpOT52uEEoh727ttJmCGcFAUMq0L1/aml8BHM4PurXzqlXw6saR kw5PgOIWhc6PVH9oCnNs4NWhH8VnAE543yZ0thql1MZP4tNJH/cEqnQwTfo8XqB0 f5XGOmsKUtTueTAhJY41AeFyHZCALgroRkegm2aDIhgQK9Z4+XB9BLvCk+40q2D1 IGF3jmng8WE/3tPZCH/+6tovNo3qbmSS/6Iiu9rB9xJMv/3bGkYeLKEcor2bXDg+ miDmhrqJsf8N+cEJ9MW6gDlKAKvU4Naob4hp4hWIJ/bg== 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=fm1; bh=j7jCmk MGf4ES9ntc6h0rVGvbGGCzalfDSE2ZQtm5qFk=; b=Ji0iJ33YDVW9qCfDA+KbJA KKaZPxSK9dzDNSsBg8ownjnBz0O+UrNotq1e5epkMUQ1irEor0ZIzZLzWBWpYZNg qQA55bZPnh7m1A/kqAHRPTQm1raCjJYmWyRy+0+jlZAlS3k6jL9Y/4WAMrjJTpxK CGy8A3ppKab+yMj2T8OUMqEM8ZSH+Jfq+nekDONV+KSl7qxIqwyTK/Z95I/gsFmD MF7BlQt8al5JncqtRZXER2OvuNQm29KZNo0GZbKxQ4Oy3UQ2cgWdMdm/0GL09kgn GgkrjsyBTnzoCR/fXpOJhtQ0ZPlokAPLhAra0Grcm/HFyIFQZOxdEc3Q5mycT83Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrheejgddugeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffujghffffkgggtsehgtderre dttddtnecuhfhrohhmpeetlhihshhsrgcutfhoshhsuceohhhisegrlhihshhsrgdrihhs qeenucffohhmrghinhepnhhigihoshdrohhrghdpvgigrghmphhlvgdrohhrghenucfkph epudejiedruddvrddutdejrddufedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpehhihes rghlhihsshgrrdhishenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from localhost (unknown [176.12.107.132]) by mail.messagingengine.com (Postfix) with ESMTPA id 207E8D60062; Mon, 7 Oct 2019 16:52:39 -0400 (EDT) From: Alyssa Ross To: Eric Wong Cc: meta@public-inbox.org Subject: Re: public-inbox-init with minimal info In-Reply-To: <20191006120104.GA24228@dcvr> References: <87bluyhyfi.fsf@alyssa.is> <20191004024559.GA24741@dcvr> <878sq0iwt2.fsf@alyssa.is> <20191005051434.GA23947@dcvr> <87pnjb4a1f.fsf@alyssa.is> <20191005195838.nypagsfok24b5odr@dcvr> <87h84m42vc.fsf@alyssa.is> <20191006120104.GA24228@dcvr> Date: Mon, 07 Oct 2019 20:52:32 +0000 Message-ID: <87tv8k5ldb.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 > OK, it seems like you can "build" the full public-inbox config > file the same way you'd build your cgitrc. Yep! I've had that working for a couple of weeks now and it's working great! > Yeah, I run -httpd, -nntpd, and -watch as services (see examples/ dir); > so it makes sense to have those in a package. -httpd/-nntpd > generally run on the same machines, but they don't need -watch > on the same server (they can be running off git-clone/fetch && > public-inbox-index) I haven't looked into watch yet -- I've been implementing for my use case first, which is using public-inbox as an archiver for a mailing list hosted on the same server. But that does make sense, and I'll make sure to account for it. >> # Add spamassassin to the PATH of public-inbox-mda, >> # public-inbox-watch, etc. >> services.public-inbox.path =3D with pkgs; [ spamassassin ]; > > They'll all need git, too (unless that's in the default path). > Also, httpd/nntpd don't need spamassassin. Yeah, this is only for -mda and -watch. git is just added to the PATH of every public-inbox-* executable in the package using a wrapper script. > Note: one slight oddity is there's also a "publicinboxwatch.spamc" > in addition to "publicinboxmda.spamc"... I figure some folks will > want differently-configured spamcheckers depending on whether the > mail hits -mda or -watch (so -watch defaults to not having a > spamchecker at all). Noticed that, and will account for it. As above, I'm just not using =2Dwatch in my setup. > Does Nix allow users to set things in the config file directly? > (instead of going through the functional language). It does; see below. > I'm also not sure if you need to have > "services.public-inbox.mda.spamCheck" at all, since "spamc" > is the default value. Correct -- that's a remnant of when I had it disabled because I hadn't set up spamassassin yet. I should have deleted the line rather than changing it. >> services.public-inbox.http.mount =3D "/lists/archives/"; > > I think all the services would want access to the same > directories, not just httpd (if I'm understanding that config > correctly). Also, httpd/nntpd only need read-only access to their > mount points, in case that affects things... "mount" here is in the PSGI sense, not the file system sense. My public-inboxes are at https://example.org/lists/archives/. Maybe there's a better name. > The purity and rollback parts definitely sound good :) > > However, I'm wondering what level of customization can be > supported by editing the public-inbox config directly? (instead > of using the Nix language) > > Having both an upstream and distro-specific ways to configure the > same thing could be confusing to both users and people trying to > help them. > > I can agree with things like PATH, environment variables, > services-to-enable and mount-points being environment and/or > distro-specific. The rest (everything in public-inbox-config(5)), > I'm not sure about; it would increase support/doc overhead. We accept that we can't package every option and have two conventions for making sure that our users can always use every option upstream gives them. One is to provide an option called extraConfig, which just adds a string verbatim to the end of the configuration file. The other is to provide an option called config, which is structured Nix that gets turned into the appropriate configuration. The latter is preferred, because then from our point of view the configuration is still structured, and can be read back in Nix without having to parse a string, etc. Since public-inbox's configuration format is well-defined as git config, there's no reason to support the former. So, supposing you introduce a new option, publicinbox.foo, and the NixOS module hasn't yet been updated to support it natively yet. In that case, a user could use this option as an escape hatch to use it anyway: services.public-inbox.config =3D { publicinbox.foo =3D "bar"; }; This will then be compiled into git config using a function I've written that essentially runs git config --add for each config option to build up a configuration file. By now I'm sure you're wondering "why bother adding individual NixOS options for each setting at all, if you can do this?", and there are a couple of reasons why we try to do it anyway. One is that we can do type checking -- setting publicinboxmda.spamcheck to "invalid" can be a build-time failure rather than a runtime one. The other is that we can provide documentation for each option, and our users can see documentation for every option available on their NixOS system in one place at . We regularly hear from users that this is one of their favourite things about NixOS. A single place to search configuration options for every package they use. I hear your concerns about this being difficult for people trying to help NixOS users with public-inbox. It's absolutely not my goal to fragment the ecosystem. I'm not aware of this having been a significant issue for any of the hundreds of modules we have so far. Users seem to be generally pretty good at figuring out what's a NixOS issue and what's an upstream issue, and, if a NixOS user does need upstream support, it's still easy enough for them to find the generated configuration file to share with non-NixOS users. Overall, we've found that the benefits of "heavyweight" NixOS modules, for want of a better term, outweigh the disadvantages. Should this end up having a negative impact on the public-inbox system, I'd be happy to review the approach. But I think that instead, we'll end up with public-inbox being accessible to more people by being available with the advantages of NixOS -- declarative configuration, reproducibility, near-atomic updates and rollbacks, etc. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEH9wgcxqlHM/ARR3h+dvtSFmyccAFAl2bpZAACgkQ+dvtSFmy ccCc9A//RIyHYZ8Fs1llyu0wrn32KzRKFeytHkeHVV2rMN7yJim+W5/cNNvJQdHc colT/86GqUbTuYbz9xzHPZTgyxI26FYa/XwZk2nnG4n+jw8FlgG2AkHCJjKrXwkE bHO1DpEAa/TprbyfFylFLmX7mJJXQNqDr+JAc9kc+g5S/h+nPuz/boKYDxaIqUl0 fR0DpNXVaXBpzNc3By5EDeHqwXAgF7cT55iDpLnQenxuGMiRga5qhrBMcuisDPBX N4gmWjlZFRwdmcyAJFHrSHkI66sp5aZP8mXoSaLlt2iAK3sMmRQivMpZMvNCGAtb MhK3al/WyA9ZxYk3tPiGFrSb1lG7u/v9dPHj3jnT7qeaHIgWus/Ju8gFQqwpE10v 0lKrxges8eyGUv9L39RkwOke7q47itB+dNoXFL07NYXaaqQqqJ4kORsjd8Dm2qZQ Iz094DoMH48DI+VKuVVthVpl9sllIGyHhqqvENfFVPo2zUtcw2sQ/9oqbjIaYKUo bAf8/Tp0ws14L+iWdmteNJyuPrq+yJuNesFGTDupzFOUuwmDx4tkP2Jb6/yT8qoX itPoHKZDbnl8XjAJ+eVjQuZBCZTLxVl+VxE0eqpOvLVhBgD14eTXJ82/dVmW9xNt sUWxA8eukfXtCP5Bdnw0UyVvX2mDEWasj/V98xHHdhEMotzbGo0= =fxxZ -----END PGP SIGNATURE----- --=-=-=--