Re: up and running, integrated with exim4 mta

[Eric Wong <e@yhbt.net>]

lkcl <lkcl@libre-riscv.org> wrote:
> On Thu, Mar 19, 2020 at 3:06 AM Eric Wong <e@yhbt.net> wrote:
 
> > > a section to disable spam and also adding the listid to the config is
> > > critical otherwise public-inbox-mda fails silently.
> >
> > There's also '--no-precheck' on the command-line to disable
> > spam filtering, but yes, listid is useful.
> 
> veera couldn't get it working without

Oh, nevermind :>  Well, --no-precheck is a different set of
checks, actually (it's in the -mda manpage).

> > > regarding the httpd it was a nuisance to set up as there was no error
> > > reporting.  i tracked down in the exammples how to add 3 lines to do
> > > logging, this really should be there by default at least commented out.
> >
> > Huh?  Do you mean AccessLog middleware or something else?
> 
> yes AccessLog::Timed.  it was in the cgi script (commented-out), i was
> having a hell of a job working out the difference between "is this
> failing at nginx proxy_pass, is this failing at fcgid, is this failing
> at public-inbox-httpd, is the url correct on nginx proxy_pass" and
> because of the complete lack of access log indication that anything
> was going through, let alone what url was being passed from nginx
> (when i finally got that running), it was much more challenging than
> it should have been.
> 
> > Errors should be logged to stderr.
> >
> > AccessLog isn't enabled by default since either folks don't care
> > and don't want to waste space;
> 
> that's what logrotate is for :)  and, also, i have fail2ban monitoring
> log files, with a rather draconian "zero tolerance" policy for anyone
> trying to access anything with ".php" let alone
> "wordpressadminlogin.php".  you run a server, so you know how mental
> things get.

I discourage fail2ban for read-only stuff over HTTP(S) or
NNTP(S) entirely.  It's too easy to end up with collateral
damage with shared IPs coming from public WiFi, Tor exits,
etc...

I don't want to burden people with setting up logrotate or
anything else, either.  I'm actually considering making Plack an
optional requirement for the -httpd and WWW stuff since it's a
lot to install and we don't use much of it.

> > or they're very picky about what
> > format their logs are in and any default format wouldn't work for
> > them.
> 
> it's better than a kick in the teeth.  commented-out - in
> public-inbox-httpd - would at least give them the hint.  ideally it
> should be command-line-enabled (and the format specifier allowed to be
> overridden, that's how it works in nginx / apache2).

Since public-inbox-httpd is a normal PSGI server(*), it accepts
.psgi files.  I've just sent a patch for examples to hopefully
make them more obvious:

	https://public-inbox.org/meta/20200319235550.10401-1-e@yhbt.net/

I'm avoiding multiple ways of enabling the same options.
Having command-line functionality overlap with what .psgi
files provide would increase the support and documentation
burden.

> > > also being able to specify the URL for git repos would be handy because
> > > we already run gitweb and git-daemon, the URL is different ane would
> > > need source hacking to specify an alternative.
> >
> > Huh?  Do you mean $INBOX_DIR/cloneurl for the inbox?  That's
> > gitweb-compatible for v1 inboxes, at least.
> 
> yes the clone url.  it... works!  however i have one via gitweb as well.

Viewing git repos used for v1 or v2 inboxes would via gitweb or
cgit would be kinda pointless.  v1 inboxes could get really
expensive for gitweb as trees grow, too (that's why v2 was
created).

> > Or do you mean for coderepos? There's `coderepo.<nick>.cgitUrl'
> > (see public-inbox-config(5)) right now, but perhaps
> > `coderepo.<nick>.gitwebUrl' should also be supported.
> 
> https://git.libre-riscv.org/?p=libre-riscv-dev.git;a=summary
> 
> i'd like that URL (or its git clone equivalent for gitweb) to be in
> the list of mirrors.  i looked up those two config options, they don't
> seem to exist (not exactly by those names).

Oh, "coderepo" stuff is only for code and totally optional.

I've also started calling inbox-specific repos "inboxdir"
instead of "mainrepo" a few months back, since v2 format inboxes
are made up of multiple git repos.

Maybe the example config snippet for git@vger.kernel.org
archives showing the relationship between the git.git source
code mirror and inboxdir hopefully gives a better idea:

	https://public-inbox.org/git/_/text/config/raw