From: Eric Wong <e@80x24.org>
To: Alyssa Ross <hi@alyssa.is>
Cc: meta@public-inbox.org
Subject: Re: public-inbox-init with minimal info
Date: Sat, 5 Oct 2019 19:58:38 +0000 [thread overview]
Message-ID: <20191005195838.nypagsfok24b5odr@dcvr> (raw)
In-Reply-To: <87pnjb4a1f.fsf@alyssa.is>
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)
next prev parent reply other threads:[~2019-10-05 19:58 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
2019-10-05 19:58 ` Eric Wong [this message]
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: https://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=20191005195838.nypagsfok24b5odr@dcvr \
--to=e@80x24.org \
--cc=hi@alyssa.is \
--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).