Installing Mailman on a Debian system with Apache 2.4.2, CGI error!
Hi,
This is a weird one. I think of myself as knowing my way around Mailman pretty well for a user/admin/installer/upgrader. I'm upgrading to a Debian 9 system from CentOS 6.5. Debian's Apache configs took a bit of getting used to, but I actually like them better. It uses Apache 2.4.2.
I wanted to install Mailman from source, since the latest version is 2.1.26, Debian has 2.1.23, and IIRC that's too old to have some screen reader optimizations I want. So I built, installed, all working well. I copied over the Mailman config from my CentOS system to use in Apache, making some changes so it'd work under 2.4.2. Here it is:
# # httpd configuration settings for use with mailman. #
ScriptAlias /mailman/ /usr/lib/mailman/cgi-bin/ <Directory /usr/lib/mailman/cgi-bin/> AllowOverride None Options ExecCGI Require all granted
</Directory>
Alias /pipermail/ /var/lib/mailman/archives/public/ <Directory /var/lib/mailman/archives/public> Options Indexes MultiViews FollowSymLinks AllowOverride None Require all granted AddDefaultCharset Off
</Directory>
# Uncomment the following line, to redirect queries to /mailman to the # listinfo page (recommended).
# RedirectMatch ^/mailman[/]*$ /mailman/listinfo
The problem is that the CGI isn't working. If I go to http://temphostname/mailman/listinfo/mailman for example, Apache says /usr/lib/mailman/cgi-bin/listinfo/mailman doesn't exist. If I just go to /mailman/listinfo I get an Elf binary thrown at me, rather than the page saying there are no advertised lists. If I do the same thing from the server using the Lynx web browser, I get the same binary thrown at me, with a page title, "Mailman CGI error!" It sounds to me like Apache 2.4.2 isn't seeing that /usr/lib/mailman/cgi-bin is, in fact, CGI scripts, and is trying to treat them like regular files. Has something else changed between Apache versions?
Thanks,
Jayson
On 05/06/2018 07:16 PM, Jayson Smith wrote:
ScriptAlias /mailman/ /usr/lib/mailman/cgi-bin/ <Directory /usr/lib/mailman/cgi-bin/> AllowOverride None Options ExecCGI Require all granted
</Directory>
This looks correct.
The problem is that the CGI isn't working. If I go to http://temphostname/mailman/listinfo/mailman for example, Apache says /usr/lib/mailman/cgi-bin/listinfo/mailman doesn't exist. If I just go to /mailman/listinfo I get an Elf binary thrown at me, rather than the page saying there are no advertised lists. If I do the same thing from the server using the Lynx web browser, I get the same binary thrown at me, with a page title, "Mailman CGI error!" It sounds to me like Apache 2.4.2 isn't seeing that /usr/lib/mailman/cgi-bin is, in fact, CGI scripts, and is trying to treat them like regular files. Has something else changed between Apache versions?
Is Suexec enabled? That could explain it. If that isn't it, are the various compiled wrappers in /usr/lib/mailman/cgi-bin/ all in Mailman's group (probably 'mailman' if you installed from source, but Debian likes 'list') and permissions like -rwxr-sr-x (o+x is I think the important one here).
And are there any other Directory blocks in the apache config for /, /usr, /usr/lib or /usr/lib/mailman?
Hello,
Okay, now I feel like a total dummy. No, Suexec wasn't enabled as far as I can tell. Yes, the CGI scripts are owned by mailman:mailman. Yes, the permissions are correct. So what was the problem, you ask.
It seems that by default, Debian's Apache install doesn't enable the CGI module. Somehow, it sort of works better if you enable CGI. It works better if you plug it in.
Head…desk. I'd spent hours trying to troubleshoot this! Sometimes the most obvious things escape the best of us.
Thanks anyway.
Jayson
On 5/6/2018 11:10 PM, Mark Sapiro wrote:
On 05/06/2018 07:16 PM, Jayson Smith wrote:
ScriptAlias /mailman/ /usr/lib/mailman/cgi-bin/ <Directory /usr/lib/mailman/cgi-bin/> AllowOverride None Options ExecCGI Require all granted
</Directory>
This looks correct.
The problem is that the CGI isn't working. If I go to http://temphostname/mailman/listinfo/mailman for example, Apache says /usr/lib/mailman/cgi-bin/listinfo/mailman doesn't exist. If I just go to /mailman/listinfo I get an Elf binary thrown at me, rather than the page saying there are no advertised lists. If I do the same thing from the server using the Lynx web browser, I get the same binary thrown at me, with a page title, "Mailman CGI error!" It sounds to me like Apache 2.4.2 isn't seeing that /usr/lib/mailman/cgi-bin is, in fact, CGI scripts, and is trying to treat them like regular files. Has something else changed between Apache versions?
Is Suexec enabled? That could explain it. If that isn't it, are the various compiled wrappers in /usr/lib/mailman/cgi-bin/ all in Mailman's group (probably 'mailman' if you installed from source, but Debian likes 'list') and permissions like -rwxr-sr-x (o+x is I think the important one here).
And are there any other Directory blocks in the apache config for /, /usr, /usr/lib or /usr/lib/mailman?
On 05/06/2018 08:37 PM, Jayson Smith wrote:
It seems that by default, Debian's Apache install doesn't enable the CGI module. Somehow, it sort of works better if you enable CGI. It works better if you plug it in.
Head…desk. I'd spent hours trying to troubleshoot this! Sometimes the most obvious things escape the best of us.
Don't feel bad. I knew I'd seen this before, and I couldn't remember the cause, and it never occurred to me either that the obvious explanation was mod_cgi not enabled.
On 05/06/2018 08:37 PM, Jayson Smith wrote:
It seems that by default, Debian's Apache install doesn't enable the CGI module. Somehow, it sort of works better if you enable CGI. It works better if you plug it in.
Head…desk. I'd spent hours trying to troubleshoot this! Sometimes the most obvious things escape the best of us.
On Mon, 7 May 2018, Mark Sapiro replied:
Don't feel bad. I knew I'd seen this before, and I couldn't remember the cause, and it never occurred to me either that the obvious explanation was mod_cgi not enabled.
Heh.
I tightened a new server upgrade recently, thinking 'I don't use CGI (only php-fpm) - let's disable it for extra security!'
And if it wasn't for this helpful message here I would STILL be scratching my head like Jayson was...
These archives are still gold. Thanks for sharing, folks!
Brett
partecipanti (3)
-
Brett Delmage -
Jayson Smith -
Mark Sapiro