user/dev discussion of public-inbox itself
 help / color / mirror / code / Atom feed
From: Alyssa Ross <hi@alyssa.is>
To: Eric Wong <e@80x24.org>
Cc: meta@public-inbox.org
Subject: Re: public-inbox-init with minimal info
Date: Sat, 05 Oct 2019 13:05:48 +0000	[thread overview]
Message-ID: <87pnjb4a1f.fsf@alyssa.is> (raw)
In-Reply-To: <20191005051434.GA23947@dcvr>

[-- Attachment #1: Type: text/plain, Size: 2251 bytes --]

> 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:
>> 
>>     { ... }:
>> 
>>     {
>>       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.

> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2019-10-05 13:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-03 11:16 public-inbox-init with minimal info Alyssa Ross
2019-10-04  2:45 ` Eric Wong
2019-10-04 11:18   ` Alyssa Ross
2019-10-05  5:14     ` Eric Wong
2019-10-05 13:05       ` Alyssa Ross [this message]
2019-10-05 19:58         ` Eric Wong
2019-10-06  9:52           ` Alyssa Ross
2019-10-06 12:01             ` Eric Wong
2019-10-07 20:52               ` Alyssa Ross
2019-10-08  7:11                 ` Eric Wong
2019-10-09 12:09                   ` Alyssa Ross
2019-10-10  8:19                     ` Eric Wong
2019-10-16 10:04                       ` Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://public-inbox.org/README

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pnjb4a1f.fsf@alyssa.is \
    --to=hi@alyssa.is \
    --cc=e@80x24.org \
    --cc=meta@public-inbox.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/public-inbox.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).