[Mailman-Users] Anything to look out for in a 2.1.9 to2.1.14-1upgrade?

[Mark Sapiro]

Steve Burling wrote:

>On 1/16/12 12:09 PM, "Mark Sapiro" <mark at msapiro.net> wrote:
>
>> You can fix this by removing the email directory from
>> /usr/lib/mailman/pythonlib so that Mailman will use the Python 2.6
>> email package instead of Mailman's which is not compatible, but this
>> won't fix all the Mailman 2.1.9/Python 2.6.x incompatibilities.
>
>Would doing this also break mail delivery, since the contents of
>/usr/lib64/python2.4/email (on the mail delivery machine) look very
>different than the contents of /usr/lib64/python2.6/email on the web server?


No. It should be OK. The email package shipped with Mailman and
installed in Mailman's pythonlib is email 2.5.8. The one in Python
2.6.6 is 4.0.1. The contents shouldn't be that different, just mixed
case names in 2.5.8 vs. all lower case in 4.0.1, and missing Python
2.1 and 2.2 compatibility modules and MIME constructors moved to a sub
directory.

The mixed case names are mapped to the lower case names in the 4.0.1
package, so Mailman works. The incompatibility arose in your case
because Mailman's Mailbox module imports Python's mailbox module and
get's the Python 2.6.6 mailbox which then imports email.message, but
email has already been imported from Mailman's pythonlib and that
email only knows email.Message, not email.message.

In fact, configure and make in recent Mailman will not install email in
pythonlib and will remove it if it's there if Python's email is 2.5.8
or newer.


>At this point, the question is academic, though, see below.
>
>> However, I have other questions.
>> 
>> Is RedHat distributing Mailman 2.1.9 with Python 2.6.6? If so, this is
>> bad, and see <http://wiki.list.org/x/OIDD>. If not, perhaps there is a
>> RedHat RPM you can use to upgrade.
>> 
>> OTOH, from the paths I see in the traceback above (prefix =
>> /opt/mailman), it seems your current Mailman may have been installed
>> from source rather than a RedHat RPM. If this is the case, just
>> configure Mailman 2.1.14-1 with the same options you used for 2.1.9,
>> stop mailman, make install and start mailman and you should be OK.
>
>This is, indeed, an installation from source. I've been reading the list
>long enough that I've never actually used a Red Hat packaged version of
>mailman.


Good.


>Red Hat is delivering mailman 2.1.12-17 with Red Hat 6.
>
>What we think is the most straight-forward fix for this, with the least
>likelihood of breaking mail delivery, is to run a limited httpd on the mail
>delivery machine as http://lists.our.domain, and add a re-write rule to our
>main web server to redirect references to http://www.our.domain/mailman/ to
>http://lists.our.domain/mailman/ instead.
>
>Does that seem like a reasonable approach?


That may or may not be viable. You probably would need to also set

DEFAULT_URL_HOST = 'lists.our.domain'

in Mailman and run fix_url. Otherwise, the action URLs in forms are
likely to be www.our.domain URLs and the redirect will lose the POST
data from form submissions.

If I were you, I would just upgrade Mailman. There should be no problem
in upgrading a 2.1.9 source install to 2.1.14-1.

I'm guessing here, but if you have Mailman installed on the mail server
and only the web portion running on the web server with the Mailman
files shared via NFS or other file sharing, you could just stop
sharing Mailman's pythonlib and create an empty directory on the web
server. With Python 2.6.6, there is nothing in Mailman's pythonlib
that isn't also in Python.

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