Re: public-inbox-init with minimal info

[Eric Wong <e@80x24.org>]

Alyssa Ross <hi@alyssa.is> 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)