
I tried yesterday unsuccessfully from upgrade mailman-2.1.5.1-34.rhel4.6 on Centos 4 to the latest 2.1.11 from sourceforge.
When I ran "configure" it said I needed to install Python from source or install the Python-devel package, so I installed the python-devel.
# yum -y install python-devel
Then "configure" said my mailman package path was not in "/usr/local/mailman", which it is not, it is in "/usr/lib/mailman".
So, within the unpackaged mailman 2.1.11 dir, I did a global replace to put my path in there:
# perl -pi -e 's/usr/local/mailman/usr/lib/mailman/g' find ./ -type f
Then "configure" ran successfully, then ran "make", then "make install". All seemed to go well. I did "check_perms" and fixed permissions. started up mailman "service mailman start", and all seemed to be running fine, but now none of my lists showed "lists_lists". My "mm_cfg.py" was untouched. Being in a hurry because I didn't alert any of the lists members of downtime, I freaked out and restored my system. Luckily I just did a full backup of my LVM, so booted up via live CD and restored the LVM from the dump file and was back online.
Is there anything special to do when updating from source? I've usually done it from RPM packages. Any pointers? Thanks.

Paul wrote:
I tried yesterday unsuccessfully from upgrade mailman-2.1.5.1-34.rhel4.6 on Centos 4 to the latest 2.1.11 from sourceforge.
When I ran "configure" it said I needed to install Python from source or install the Python-devel package, so I installed the python-devel.
# yum -y install python-devel
Good.
Then "configure" said my mailman package path was not in "/usr/local/mailman", which it is not, it is in "/usr/lib/mailman".
So, within the unpackaged mailman 2.1.11 dir, I did a global replace to put my path in there:
# perl -pi -e 's/usr/local/mailman/usr/lib/mailman/g'
find ./ -type f
This is probably insufficient and definitely wrong. First, if ALL of your existing Mailman is in /usr/lib/mailman, you should be able to successfully configure with
./configure --prefix=/usr/lib/mailman (plus your other configure options like
--with-mail-gid group name mail programs run as --with-cgi-gid group name CGI programs run as --with-mailhost specify the hostname part for outgoing email --with-urlhost specify the hostname part of urls )
Then "configure" ran successfully, then ran "make", then "make install". All seemed to go well. I did "check_perms" and fixed permissions. started up mailman "service mailman start", and all seemed to be running fine, but now none of my lists showed "lists_lists". My "mm_cfg.py" was untouched. Being in a hurry because I didn't alert any of the lists members of downtime, I freaked out and restored my system. Luckily I just did a full backup of my LVM, so booted up via live CD and restored the LVM from the dump file and was back online.
Is there anything special to do when updating from source? I've usually done it from RPM packages. Any pointers? Thanks.
The most likely explanation is your existing installation is RedHats FHS compliant Mailman, and various parts of it are all over the place. See http://mail.python.org/pipermail/mailman-developers/2004-October/017343.html.
If this is the case, you could try to apply the patch attached to that post before running configure, but it may not apply to 2.1.11 since it's against a 2.1.5 base. I wouldn't recommend that approach.
Assuming you are not running SELinux, I suggest you start over with a fresh unpack of the 2.1.11 tarball and configure with the options
--prefix=/usr/lib/mailman --with-var-prefix=/var/lib/mailman
in addition to any others you might need. Then allow some time for the next steps.
Stop Mailman
Create /var/lib/mailman/data/ and /var/lib/mailman/qfiles/ if necessary. Move /etc/mailman/* to /var/lib/mailman/data/ Stop the MTA
If you are using Postfix and automatic alias generation for Postfix, update alias_maps and if applicable, virtual_alias_maps in Postfix's main.cf to point to the new locations in /var/lib/mailman/data/.
Move /var/spool/mailman/* to /var/lib/mailman/qfiles/ make install Start the MTA Start Mailman
If you are running SELinux, you will either have to stick with the current locations for everything and use RedHat's patch or revise your security policies.
participants (2)
-
Mark Sapiro
-
Paul