Re: Unable to access mailman web interface

[Bob Proulx]

Glenn Morris wrote:
> Bob Proulx wrote:
> > I am still not happy seeing the warning message though so am going to
> > tinker with it a little bit longer and see if I can't fix it so that
> > there are no warnings.
> 
> I know the feeling. :)  Good luck!

I figured out the source of the warnings.  There were *three*
overlapping ScriptAlias directives.  I think I understand how it works
now so have tried to simplify things.

There is an upstream package installed Apache configuration snippet
conf-enabled/serve-cgi-bin.conf that includes cgi-bin as a global
configuration.  Can be overridden by an individual VirtualHost.  By
default points to the system /usr/lib/cgi-bin/ directory.

There is a local conf-enabled/httpd.conf configuration that also
installs a global cgi-bin configuration.  Points to the /var/www/cgi/
directory.  Can be overridden by an individual VirtualHost.

The overlap warning was between the two above configurations.  Since
AFAICS more specific VirtualHost is allowed to override without a
conflict notice since it is the more specific.

There is a VirtualHost local cgi-bin that overrides both of the above
pointing to the system /usr/lib/cgi-bin/ directory.  This is most
specific and the one that takes actual effect.  So we were actually
using this configuration.

Mostly.  The VirtualHost config had the older Apache version 2.2
configuration using "Order allow,deny" and "Allow from all" which is
also cautioned against mixing with the newer Apache version 2.4
configuration "Require all granted".  I have been reading this Apache
doc reference and my head is now swimming.

    https://httpd.apache.org/docs/current/upgrading.html

But I think I understand that now.  That's why both the
serve-cgi-bin.conf and the more specific VirtualHost had been needed
together.  Because serve-cgi-bin.conf supplied the newer 2.4 Require
all granted part, which allowed access, and the more specific
VirtualHost part overrode the global httpd.conf part.  Maybe.  Put a
big "I think" there.  Seems plausible.  Mixing the versions is
cautioned against in the docs.

I can sneak up on things by disabling the global serve-cgi-bin.conf
config snippet.  That leaves the more specific VirtualHost config
pointing to /usr/lib/cgi-bin/ in place and overriding the
conf-enabled/httpd.conf file pointing to the /var/www/cgi/ directory.

And with that there is no warning and everything seems to be
functioning.  And I think /usr/lib/cgi-bin/ is how it has been
functioning as that is where the mailman configuration resides under
the /usr/lib/cgi-bin/mailman/ directory.

Meanwhile...  httpd.conf installs two cgi related things.  One is that
global ScriptAlias /cgi-bin/ "/var/www/cgi/" which is overridden.  The
other is a cgi-script handler for the BTS scripts.  Along with two
more aliases for mailman archives that are otherwise unrelated.

    AddHandler cgi-script cgi pl

The single location /cgi-bin/ needing to be shared between the BTS and
Mailman has apparently created a conflict in the past that drove
things to be slightly different on debbugs.  Because upstream BTS I
see uses cgi-bin URLs similar to /cgi-bin/bugreport.cgi?bug=123
whereas debbugs users /cgi/bugreport.cgi?bug=123 now.  I assume that
arose to avoid the namespace merge between BTS and Mailman.  Just
guessing.

I reconfigured things this way.  I disabled the cgi-bin section in the
more specific VirtualHost section.  I disabled the cgi-bin ScriptAlias
in the conf-enabled/httpd.conf file.  I moved the <Directory> access
control for /var/www/cgi into the specific VirtualHost section.  Also
updated to the newer version 2.4 "Require all granted".  I enabled the
Apache packaged conf-enabled/serve-cgi-bin.conf file.  There is now
only one section with Rewrite rules instead of two.

So now the package standard stuff is in the package standard locations
and the local configuration stuff is in the local VirtualHost section
file.  I renamed and consolidated everything regarding the VirtualHost
into a sites-available/debbugs.conf file.

And everything seems to be working in this configuration.  Please let
me know if something is not working.

> Thanks for fixing the mailman web interface so promptly.

I broke it last night when I set up the new certificate by trying to
remove that warning and didn't notice that it broke Mailman there. :-(

Bob