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 .