Moving / upgrading Mailman from Solaris to Linux
Hello,
We are planning to move our Mailman installation from Solaris to Linux, and upgrade in the process. I'd love to hear from anyone who has run production Mailman on Linux.
What experiences have list members had with RedHat vs. Ubuntu Mailman packages, vs. compiling Mailman from source?
At this point, even though I prefer to use packages when possible, I am leaning toward compiling Mailman from source because of:
- Red Hat packages are typically more ancient
- Ubuntu packages seem to include non-standard patches to Mailman (still sorting this out)
Additionally, has anyone run into problems with Python packages provided by Red Hat and Ubuntu?
Thank you for your time,
Ivan.
Ivan Fetch wrote:
We are planning to move our Mailman installation from Solaris to Linux, and upgrade in the process. I'd love to hear from anyone who has run production Mailman on Linux.
What experiences have list members had with RedHat vs. Ubuntu Mailman packages, vs. compiling Mailman from source?
I run Mailman installed from source on CentOS 5 for my production lists. The default Python on this server is the CentOS/RedHat 2.4.3-27.el5 (you need both python and python-devel to install Mailman from source). I also have Python 2.6.5 on this server installed from source. I have installed and run Mailman in production at various times with both Python versions. Currently I'm running Mailman installed with Python 2.6.5.
My lists are small to moderate size (<500 members) and low to moderate traffic (zero to two or three dozen posts per list daily).
Everything works fine (I fix the Mailman bugs when I find them ;)
At this point, even though I prefer to use packages when possible, I am leaning toward compiling Mailman from source because of:
- Red Hat packages are typically more ancient
- Ubuntu packages seem to include non-standard patches to Mailman (still sorting this out)
I've never used the Debian/Ubuntu package, but I've had issues with some of their patches. I've fixed the significant problems addressed by the Debian patches, at least those I understand, upstream in 2.1.13 and 2.1.14.
Additionally, has anyone run into problems with Python packages provided by Red Hat and Ubuntu?
The RedHat Python 2.4.3 package works for me, but it is old. There are python26 packages in the epel repository, but I haven't used them.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hello,
Thank you, Mark, Adam, and Andrew for your replies. More below.
-----Original Message----- From: Mark Sapiro [mailto:mark@msapiro.net] Sent: Thursday, November 11, 2010 12:19 AM To: Ivan Fetch; MailMan Subject: Re: [Mailman-Users] Moving / upgrading Mailman from Solaris to Linux
Ivan Fetch wrote:
We are planning to move our Mailman installation from Solaris to
Linux, and upgrade in the process. I'd love to hear from anyone who has run production Mailman on Linux.
What experiences have list members had with RedHat vs. Ubuntu Mailman
packages, vs. compiling Mailman from source?
I run Mailman installed from source on CentOS 5 for my production lists. The default Python on this server is the CentOS/RedHat 2.4.3-27.el5 (you need both python and python-devel to install Mailman from source). I also have Python 2.6.5 on this server installed from source. I have installed and run Mailman in production at various times with both Python versions. Currently I'm running Mailman installed with Python 2.6.5.
My lists are small to moderate size (<500 members) and low to moderate traffic (zero to two or three dozen posts per list daily).
Everything works fine (I fix the Mailman bugs when I find them ;)
At this point, even though I prefer to use packages when possible, I am leaning toward compiling Mailman from source because of:
- Red Hat packages are typically more ancient
- Ubuntu packages seem to include non-standard patches to Mailman (still sorting this out)
I've never used the Debian/Ubuntu package, but I've had issues with some of their patches. I've fixed the significant problems addressed by the Debian patches, at least those I understand, upstream in 2.1.13 and 2.1.14.
What issues have you had with their patches? E.G> the way they have fixed a bug on their own?
Additionally, has anyone run into problems with Python packages provided by Red Hat and Ubuntu?
The RedHat Python 2.4.3 package works for me, but it is old. There are python26 packages in the epel repository, but I haven't used them.
I will look into the EPEL python, it would be nice to have acces to something somewhat newer than what ships with RHEL. Although ... RHEL 6 is out now. :-)
- Ivan
Ivan Fetch wrote:
What issues have you had with their patches? E.G> the way they have fixed a bug on their own?
For example, the patch 30_pipermail_threads.patch fixes an obscure bug <http://bugs.debian.org/167758>, but breaks indentation in the threaded archive index for messages with message-ids containing hyphens. Fixed properly upstream in Mailman 2.1.13.
The patch 77_header_folding_in_attachments.patch fixes <http://bugs.debian.org/244673>, <https://bugs.launchpad.net/mailman/+bug/265967>, but IIRC breaks archiving of messages containing body lines beginning with "From ". Fixed properly upstream in Mailman 2.1.13.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Wed, Nov 10, 2010 at 01:23:17PM -0700, Ivan Fetch wrote:
At this point, even though I prefer to use packages when possible, I am leaning toward compiling Mailman from source because of:
- Red Hat packages are typically more ancient
- Ubuntu packages seem to include non-standard patches to Mailman (still sorting this out)
From what I remember, the Mailman packages for both Debian and Ubuntu are pretty much the same.
In such a case, you're reliant on the maintainer updating fixes promptly (or very rarely, the security team), along with necessary modifications to conform with Debian policy.
Once one gets around those, one has something that's usable, and not too difficult to operate, but I've not done a source <--> source comparison for a while.
I'm lazy, and just use the versions in the repos, but am aware a couple of folks on list either build their own PPAs or use others.
Additionally, has anyone run into problems with Python packages provided by Red Hat and Ubuntu?
Not with Ubuntu. I've not used Red Hat on my own boxes for several years, now, mind.
-- Experience is what enables you to recognise a mistake the second time you make it.
Adam McGreggor wrote:
In such a case, you're reliant on the maintainer updating fixes promptly (or very rarely, the security team), along with necessary modifications to conform with Debian policy.
Yes, I am still waiting for the latest Mailman security patch to be included in the stable Debian repo, and it is a shame imho that we aren't likely to get 2.1.14 in the next Debian release (the latest Debian package seems to be a patched 2.1.13).
Once one gets around those, one has something that's usable, and not too difficult to operate, but I've not done a source <--> source comparison for a while.
It is easy to install and operate, I will give you that.
I'm lazy, and just use the versions in the repos, but am aware a couple of folks on list either build their own PPAs or use others.
I am thinking of trying to build my own install for the reasons I outlined above, the reasons I am holding off this are:
- Having to move everything out of the directory structure you get with the Debian package.
- Knowing what functionality/bug fixes I am getting with the Debian specific patches that I wouldn't otherwise get from the upstream package.
Thanks. Andrew.
Andrew Hodgson wrote:
I am thinking of trying to build my own install for the reasons I outlined above, the reasons I am holding off this are:
- Having to move everything out of the directory structure you get with the Debian package.
I'm not sure what the Debian directory structure is, but you should be able to get very close via the --prefix, --exec-prefix and --with-var-prefix options to configure.
- Knowing what functionality/bug fixes I am getting with the Debian specific patches that I wouldn't otherwise get from the upstream package.
I have been through the patches at <http://patch-tracker.debian.org/package/mailman>, and those issues that are addressed that are significant, not Debian specific and that I could understand have all been fixed in Mailman 2.1.14.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
Andrew Hodgson wrote:
I am thinking of trying to build my own install for the reasons I outlined above, the reasons I am holding off this are:
- Having to move everything out of the directory structure you get with the Debian package.
I'm not sure what the Debian directory structure is, but you should be able to get very close via the --prefix, --exec-prefix and --with-var-prefix >options to configure.
Actually I have just come out the other side of the upgrade, it wasn't too painful. I actually put everything in /usr/local/mailman, as it allowed me to sort the configs etc out without breaking the working install.
I built the source on a virtual machine I do other testing on, then copied the mailman directory over to the live system, running fix_perms to ensure everything worked fine.
I built it with the user and group of list, and set the mail-gid and cgi-gid according to the Debian package.
I stole the scripts from /etc/init.d/mailman, /etc/logrotate.d/mailman and /etc/cron.d/mailman after tweaking a bit to keep the working init, logrotate and cron scripts working.
I then changed the Apache configs to point to the new installation, and after stopping the services, moved the archives and lists directories over. I ran the new qrunner and everything started up ok.
The only issue I had which had me scratching my head for a bit was that simlinks in /usr/local/mailman/archives/public were broken, these are now fixed.
End result: Working Mailman with security patch applied :)
If anyone wants more detailed steps please let me know.
Thanks. Andrew.
participants (4)
-
Adam McGreggor -
Andrew Hodgson -
Ivan Fetch -
Mark Sapiro