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: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 9CFC51F4BD; Sat, 5 Oct 2019 19:58:38 +0000 (UTC) Date: Sat, 5 Oct 2019 19:58:38 +0000 From: Eric Wong To: Alyssa Ross Cc: meta@public-inbox.org Subject: Re: public-inbox-init with minimal info Message-ID: <20191005195838.nypagsfok24b5odr@dcvr> References: <87bluyhyfi.fsf@alyssa.is> <20191004024559.GA24741@dcvr> <878sq0iwt2.fsf@alyssa.is> <20191005051434.GA23947@dcvr> <87pnjb4a1f.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87pnjb4a1f.fsf@alyssa.is> List-Id: Alyssa Ross wrote: > > 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. Is that possible without scan-path/project-list options in cgitrc? public-inbox has nothing analogous to those options, right now. > >> 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. > > > > 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. one systemd service == one tor process, right? I haven't looked too deeply into systemd, though, so maybe there's some way to add services to an existing tor process... > > 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. I tried to make the defaults reasonable, so I don't think any config is needed outside of what's required to map inboxes/addresses to directories (which public-inbox-init does)