On 12/04/2014 10:40 PM, Lindsay Haisley wrote:

This is a relatively minor thing, but perhaps it should be mentioned in the Install docs on http://www.gnu.org/software/mailman/mailman-install/node10.html

Recent Ubuntu server installs of Apache 2.4 need "Require all granted" in place of, or in addition to "Allow from all" to grant access to a portion of the filesystem. So somewhere in the conf files for Apache2 is needed something like:

<Directory "/var/lib/mailman/archives/public/"> Options FollowSymLinks .... etc. Require all granted ...... etc. </Directory>

I'm not sure that this should be on that page. That page is intended to be fairly generic and even though some of the given examples are Apache directives, it is intended to be a guide for all web servers. Thus, something specific to some versions of a particular web server, albeit a very popular one, may not be appropriate.

I'll consider adding something more generic about allowing access.

Also note, I think that Require all granted is also required on the ScriptAlias directory, at least I have it in my config.

I went to the Launchpad bug database for Mailman and it looks like it's ages out of date, so I thought I'd pass this on here, and y'all can run with it to the developers list or wherever.

The Launchpad tracker is the place.

Note that the first bug listed at <https://bugs.launchpad.net/mailman/+bugs?orderby=-id&start=0> is <https://bugs.launchpad.net/mailman/+bug/1397170> which was reported and fixed only a week ago.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Lindsay Haisley writes:

Recent Ubuntu server installs of Apache 2.4 need "Require all granted" in place of, or in addition to "Allow from all" to grant access

The old "allow from ..." syntax has been deprecated in favor of the "require ... granted" syntax for quite a while. Recent Apache has changed that from "deprecated" to "invalid".

I'm personally not in favor of adding all of this upstream stuff to distributed Mailman docs. I think it's obnoxious of Apache to gratuitously break existing installations without any warning[1] this way.

I wouldn't be averse to adding it to the FAQ, though.

This seems to be in line with a policy of hardening Apache2 server security,

It has nothing to do with "hardening". The semantics is exactly equivalent, only the syntax has changed. That's what pisses me off. It's "purity before practicality".

Someone with less experience might spend a lot more time troubleshooting this, and a note in the documentation might help. Keeping up with the times is good :)

Sure, but for gratuitous stuff that screws all the users of the cooperating software (I noticed it not because of Mailman but because my whole website suddenly stopped working!), I'd be in favor of not adding specifics, and giving general debugging information, like:

Mailman bugs do manifest occasionally out of the blue.  However,
if
  - you haven't touched Mailman or it's a brand new install, and
  - a bug suddenly occurs (or on first installation), and
  - Mailman's own debugging scripts don't identify or solve the
    problem,
it's at least as likely to be an issue with cooperating software,
often to be resolved by reconfiguration.  (See mailman/bin for the
scripts; they're mostly named check_* or fix*.)

The most likely candidates are your MTA (typically Postfix, Exim,
or Sendmail, though there are others) if mail receipt or delivery
is the issue.  Or, if the problem is with the website (archives
and administration), with your webserver (typically Apache but
there is wide variation here).  Another common culprit is
operating system security (eg, SELinux).  Check the configuration
files for such software.  (Often software provides a configuration
checker assistant that is stricter than the actual application is
about configuration issues.)

In all cases, check for distribution updates (recent, causing the
issue, or available, resolving the issue) in these areas, and look
for changes in "permission" or "capability" defaults or even in
syntax of related directives.  Sometimes there's an outright bug,
but that's less likely these days (Mailman does not exercise the
"latest and greatest" features of that software).

Another possibility is a Python upgrade or a change in the default
version in your distribution.  This is not very likely but has
been known to happen in the past.

In all of the cases described above, you are most likely to find
information in your distribution's issue tracker or FAQ, followed
by upgrade notes (sometimes a few upgrades back!)  Next, check the
associated software's resources.  Often such issues will not be
mentioned in Mailman resources -- people who install the newest
Mailman from source typically also are keeping up with changes in
cooperating software and don't report issues to Mailman which are
not Mailman issues.  On the other hand, the distributions are
pretty good about correct configuration; users of Mailman etc from
a distribution are well-protected from these issues.  So we're
often the last to know!

> I went to the Launchpad bug database for Mailman and it looks like

it's ages out of date,

Yeah, almost all the "bugs" that occur these days are configuration issues. I would guess that most "bugs" (for 2.1.x) on Launchpad are actually nonbugs now, but nobody has gone through, checked, and closed the resolved or irreproducible issues.

so I thought I'd pass this on here, and y'all can run with it to the developers list or wherever.

This is probably the best place (high visibility) to report it. As you see, it's not obvious that the developers will run with it at all! :-/

I think the best place for it is the FAQ.

Footnotes: [1] Maybe there's something in the logs about deprecated configuration syntax. But nothing "in your face". Granted, it's hard to do that with daemon software.

On 12/04/2014 10:40 PM, Lindsay Haisley wrote:

This is a relatively minor thing, but perhaps it should be mentioned in the Install docs on http://www.gnu.org/software/mailman/mailman-install/node10.html

Recent Ubuntu server installs of Apache 2.4 need "Require all granted" in place of, or in addition to "Allow from all" to grant access to a portion of the filesystem. So somewhere in the conf files for Apache2 is needed something like:

<Directory "/var/lib/mailman/archives/public/"> Options FollowSymLinks .... etc. Require all granted ...... etc. </Directory>

I'm not sure that this should be on that page. That page is intended to be fairly generic and even though some of the given examples are Apache directives, it is intended to be a guide for all web servers. Thus, something specific to some versions of a particular web server, albeit a very popular one, may not be appropriate.

I'll consider adding something more generic about allowing access.

Also note, I think that Require all granted is also required on the ScriptAlias directory, at least I have it in my config.

I went to the Launchpad bug database for Mailman and it looks like it's ages out of date, so I thought I'd pass this on here, and y'all can run with it to the developers list or wherever.

The Launchpad tracker is the place.

Note that the first bug listed at <https://bugs.launchpad.net/mailman/+bugs?orderby=-id&start=0> is <https://bugs.launchpad.net/mailman/+bug/1397170> which was reported and fixed only a week ago.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Lindsay Haisley writes:

Recent Ubuntu server installs of Apache 2.4 need "Require all granted" in place of, or in addition to "Allow from all" to grant access

The old "allow from ..." syntax has been deprecated in favor of the "require ... granted" syntax for quite a while. Recent Apache has changed that from "deprecated" to "invalid".

I'm personally not in favor of adding all of this upstream stuff to distributed Mailman docs. I think it's obnoxious of Apache to gratuitously break existing installations without any warning[1] this way.

I wouldn't be averse to adding it to the FAQ, though.

This seems to be in line with a policy of hardening Apache2 server security,

It has nothing to do with "hardening". The semantics is exactly equivalent, only the syntax has changed. That's what pisses me off. It's "purity before practicality".

Someone with less experience might spend a lot more time troubleshooting this, and a note in the documentation might help. Keeping up with the times is good :)

Sure, but for gratuitous stuff that screws all the users of the cooperating software (I noticed it not because of Mailman but because my whole website suddenly stopped working!), I'd be in favor of not adding specifics, and giving general debugging information, like:

Mailman bugs do manifest occasionally out of the blue.  However,
if
  - you haven't touched Mailman or it's a brand new install, and
  - a bug suddenly occurs (or on first installation), and
  - Mailman's own debugging scripts don't identify or solve the
    problem,
it's at least as likely to be an issue with cooperating software,
often to be resolved by reconfiguration.  (See mailman/bin for the
scripts; they're mostly named check_* or fix*.)

The most likely candidates are your MTA (typically Postfix, Exim,
or Sendmail, though there are others) if mail receipt or delivery
is the issue.  Or, if the problem is with the website (archives
and administration), with your webserver (typically Apache but
there is wide variation here).  Another common culprit is
operating system security (eg, SELinux).  Check the configuration
files for such software.  (Often software provides a configuration
checker assistant that is stricter than the actual application is
about configuration issues.)

In all cases, check for distribution updates (recent, causing the
issue, or available, resolving the issue) in these areas, and look
for changes in "permission" or "capability" defaults or even in
syntax of related directives.  Sometimes there's an outright bug,
but that's less likely these days (Mailman does not exercise the
"latest and greatest" features of that software).

Another possibility is a Python upgrade or a change in the default
version in your distribution.  This is not very likely but has
been known to happen in the past.

In all of the cases described above, you are most likely to find
information in your distribution's issue tracker or FAQ, followed
by upgrade notes (sometimes a few upgrades back!)  Next, check the
associated software's resources.  Often such issues will not be
mentioned in Mailman resources -- people who install the newest
Mailman from source typically also are keeping up with changes in
cooperating software and don't report issues to Mailman which are
not Mailman issues.  On the other hand, the distributions are
pretty good about correct configuration; users of Mailman etc from
a distribution are well-protected from these issues.  So we're
often the last to know!

> I went to the Launchpad bug database for Mailman and it looks like

it's ages out of date,

Yeah, almost all the "bugs" that occur these days are configuration issues. I would guess that most "bugs" (for 2.1.x) on Launchpad are actually nonbugs now, but nobody has gone through, checked, and closed the resolved or irreproducible issues.

so I thought I'd pass this on here, and y'all can run with it to the developers list or wherever.

This is probably the best place (high visibility) to report it. As you see, it's not obvious that the developers will run with it at all! :-/

I think the best place for it is the FAQ.

Footnotes: [1] Maybe there's something in the logs about deprecated configuration syntax. But nothing "in your face". Granted, it's hard to do that with daemon software.