[Balug-test] Archives now working: BALUG-Test list

[Michael Paoli]

Archives are now working.
Relevant bit ... I ought (when I get around to it) check if there's
bug filed (it may already be fixed even - but not yet to stable).
And yes, I did say:
>> Caveats - at present the archives are effectively broken.  It's a web
>> server configuration issue - they're otherwise fine and being archived
>> (and it's not filesystem or file permissions or the like).  I'll get
The missing bit ... I'd (rather than redundantly copied/maintain) used:
(relative to /etc/apache2):
Include ../mailman/apache.conf
in file sites-available/Include/temp.balug.org
that was almost all well fine and good (I'd reviewed
./mailman/apache.conf earlier).  But it left out one key needed bit,
it has:
<Directory /var/lib/mailman/archives/public/>
     Options FollowSymlinks
     AllowOverride None
     Order allow,deny
     Allow from all
</Directory>
but needs:
<Directory /var/lib/mailman/archives/public/>
     Options FollowSymlinks
     AllowOverride None
     Order allow,deny
     Allow from all
     Require all granted
</Directory>
My relatively simple fix,
add to file
sites-available/Include/temp.balug.org
<Directory /var/lib/mailman/archives/public/>
     Options FollowSymlinks
     AllowOverride None
     Order allow,deny
     Allow from all
     Require all granted
</Directory>
after:
Include ../mailman/apache.conf
... Apache doesn't seem to care about the same
<Directory /var/lib/mailman/archives/public/>
appearing twice, and seems in that case to just use the latter fine,
which keeps it a bit neater, by not needing to copy in all the other
configuration contents from ../mailman/apache.conf

The .unroll script
http://lists.balug.org/pipermail/balug-talk-balug.org/2017-July/000082.html
came in handy :-) ... even though it turned out it
wasn't an ordering dependency.  It was very handy to pull all the config
together (in a scratch vi session), toss out irrelevant bits, and
look for relevant information and clues.
That and having the Apache documentation handy (apache2-doc package - so
versions all match 'n such).  Useful clues also began to appear in some of
the comments Debian included, notably with relevant context:
# Sets the default security model of the Apache2 HTTPD server. It does
# not allow access to the root filesystem outside of /usr/share and /var/www.
# The former is used by web applications packaged in Debian,
# the latter may be used for local directories served by the web server. If
# your system is serving content from a sub-directory in /srv you must allow
# access here, or in any related virtual host.
<Directory />
Options FollowSymLinks
AllowOverride None
Require all denied
</Directory>
... bit 'o research/refresher on Directory and Require, and then it was then
quite clear why it wasn't working ... then just matter of try to determine
best fix, apply and test ... and ... fixed.  Works now.

So ... /etc/mailman/apache.conf
should have included but failed to include, in it's section:
<Directory /var/lib/mailman/archives/public/>
the line:
     Require all granted
So ... I think I'd call that a "bug" - even if it's documentation
errata.  Might be a Debian specific patch needed, as other
distributions and/or Apache may have different defaults on
that security.
I don't know that anything in mailman causes
/etc/mailman/apache.conf to be automagically included
or copied in ...
searching to see if any bits of that in the Apache config, other
than what I put in ... nope, ... just what I put in ... but also very
possible mailman might've added it if it were the case I had
a default apache configuration or very close to that ... mine is quite
a bit beyond default, but does also stick with the general Apache/Debian
framework.

I had also fair bit earlier well gone over the permissions/ownerships,
and had determined that was not the issue.  By then clues were pointing
in the direction of webserver configuration.  I don't recall off-hand
(maybe I ought test), but I think also Apache throws and/or logs slightly
different error if it's from EPERM - file/directory permissions rather than
Apache config.  Could also potentially see that it wasn't EPERM by using
strace(1) on the apache processes - but that probably woudln't be
easiest/fastest way to get problem solved ... but it would be a relatively
quick way to see if it was/wasn't an EPERM error and be able to confirm that.

> From: "Rick Moen" <rick@linuxmafia.com>
> Subject: Re: [Balug-test] [BALUG-Admin] (pre-announce / "soft" open)  
> BALUG-Test list
> Date: Mon, 10 Jul 2017 23:13:27 -0700

> Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
>
>> Caveats - at present the archives are effectively broken.  It's a web
>> server configuration issue - they're otherwise fine and being archived
>> (and it's not filesystem or file permissions or the like).  I'll get
>> that fixed (one of the relatively higher priorities).
>
> You might want to check ownership/permissions in
> /var/lib/mailman/archives/private and
> /var/lib/mailman/archives/public .