Hi all,
I've uploaded the Mailman 2.0.5 patch and tarball to SourceForge. Please check out
http://sourceforge.net/project/showfiles.php?group_id=103I've tested this on my system and on {python,zope}.org and it seems to work well. Still, I would love to get some feedback on this specific patch before making a wider announcement (won't it be great when I have a unit test suite? :).
Please give it a shot and let me know. If there are no showstoppers, I will make the announcement on Monday.
Thanks, -Barry
On Fri, May 04, 2001 at 12:58:54PM -0400, Barry A. Warsaw wrote:
Hi all,
I've uploaded the Mailman 2.0.5 patch and tarball to SourceForge. Please check out
http://sourceforge.net/project/showfiles.php?group_id=103
lynx -dump http://lists.sourceforge.net/lists/listinfo/test | grep version version 2.0.5 [7]Python Powered [8]GNU's Not Unix [9]Mailman home page
The uprade procedure was a bit painful, because once again, update touched all my lists as root, recreated all the config.db files as root, which broke all the lists on my system (admittedly, that's my fault for having restricted hardlinks)
This, in the update process, is what is screwing me over:
- updating old public mbox file looks like you have a really recent CVS installation... you're either one brave soul, or you already ran me
Can't update see that upgrading from 2.0.x to 2.0.y doesn't require that and only run it when it's really really needed? (in my case, with 10,000+ lists, it takes a really long time to run, up to 10-20mn).
Would you accept a patch that made update change its uid to mailman (requiring make install to be ran as root or mailman) for everyone? The problem is that securelinux_fix is to be run after make install, and while make install is being run, and update goes through all the lists, all the lists are non functionning on my system
Anyway, everything is back up now, I cleared the lock directory, and ran: find lists | grep config.db | grep -v "config.db.last" | grep -v config.db$ | xargs rm
I'll try to remember to check it again on sunday night and report back.
Marc
Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key
"MM" == Marc MERLIN <marc_news@valinux.com> writes:
MM> The uprade procedure was a bit painful, because once again, MM> update touched all my lists as root, recreated all the MM> config.db files as root, which broke all the lists on my MM> system (admittedly, that's my fault for having restricted MM> hardlinks) | This, in the update process, is what is screwing me over: | - updating old public mbox file | looks like you have a really recent CVS installation... | you're either one brave soul, or you already ran me Close, but not quite. There's a step in bin/update, function dolist(), which sets some list attributes unconditionally. Of course, to do this, it must lock the list, change the attrs and save the list. There's a similar step in main() where the old gate_watermarks file is transformed into the usenet_watermark attribute, but that step isn't done if the gate_watermarks file isn't found (which it won't be for any 2.0.x upgrade). The problem is that while the dolist() step happens unconditionally, it only needs to be done if it updates the archive_directory or private_archive_file_dir attributes. Below is a patch to skip this step if those attrs don't need to be upgraded. MM> Would you accept a patch that made update change its uid to MM> mailman (requiring make install to be ran as root or mailman) MM> for everyone? I'm not so sure. Say I install Mailman as user `barry', I don't want to be running the upgrade as user `mailman'. Probably a better approach is to refuse to run update if the effective uid doesn't equal mm_cfg.MAILMAN_UID. On the other hand, the attached patch might be enough. On the third hand, maybe bin/update should just be culled of all ability to upgrade from a pre-2.0 revision? In that case, I'll bet bin/update can just go away. -Barry -------------------- snip snip -------------------- Index: update =================================================================== RCS file: /cvsroot/mailman/mailman/bin/update,v retrieving revision 1.24.2.1 diff -u -r1.24.2.1 update --- update 2001/03/02 23:19:33 1.24.2.1 +++ update 2001/05/04 20:25:01 @@ -80,28 +80,25 @@ def dolist(listname): errors = 0 mlist = MailList.MailList(listname, lock=0) - try: - mlist.Lock(0.5) - except TimeOutError: - print 'WARNING: could not acquire lock for list:', listname - return 1 - - mbox_dir = make_varabs('archives/private/%s.mbox' % (listname)) - mbox_file = make_varabs('archives/private/%s.mbox/%s' % (listname, - listname)) + + mbox_dir = make_varabs('archives/private/%s.mbox' % listname) + mbox_file = make_varabs('archives/private/%s.mbox/%s' % + (listname, listname)) - o_pub_mbox_file = make_varabs('archives/public/%s' % (listname)) - o_pri_mbox_file = make_varabs('archives/private/%s' % (listname)) + o_pub_mbox_file = make_varabs('archives/public/%s' % listname) + o_pri_mbox_file = make_varabs('archives/private/%s' % listname) html_dir = o_pri_mbox_file - o_html_dir = makeabs('public_html/archives/%s' % (listname)) + o_html_dir = makeabs('public_html/archives/%s' % listname) # # make the mbox directory if it's not there. # if not os.path.exists(mbox_dir): ou = os.umask(0) - os.mkdir(mbox_dir, 02775) - os.umask(ou) + try: + os.mkdir(mbox_dir, 02775) + finally: + os.umask(ou) else: # this shouldn't happen, but hey, just in case if not os.path.isdir(mbox_dir): @@ -197,10 +194,17 @@ # save the new variables and # let it create public symlinks if necessary # - mlist.archive_directory = make_varabs('archives/private/%s' % (listname)) - mlist.private_archive_file_dir = make_varabs('archives/private/%s.mbox' % - listname) - mlist.Save() + archivedir = make_varabs('archives/private/%s' % listname) + if mlist.archive_directory <> archivedir or \ + mlist.private_archive_file_dir <> mbox_dir: + print " I have to update the list's archive directory attributes" + mlist.Lock() + try: + mlist.archive_directory = archivedir + mlist.private_archive_file_dir = mbox_dir + mlist.Save() + finally: + mlist.Unlock() # # check to see if pre-b4 list-specific templates are around # and move them to the new place if there's not already @@ -222,8 +226,6 @@ else: print "- both %s and %s exist, leaving untouched" \ % (o_tmpl, n_tmpl) - # Avoid eating filehandles with the list lockfiles - mlist.Unlock() return 0 @@ -296,18 +298,14 @@ if listname not in listnames: # this list no longer exists continue - mlist = MailList.MailList(listname, lock=0) + mlist = MailList.MailList(listname) try: - mlist.Lock(0.5) - except TimeOutError: - print 'WARNING: could not acquire lock for list:', listname - errors = errors + 1 - else: # Pre 1.0b7 stored 0 in the gate_watermarks file to indicate # that no gating had been done yet. Without coercing this to # None, the list could now suddenly get flooded. mlist.usenet_watermark = d[listname] or None mlist.Save() + finally: mlist.Unlock() os.unlink(wmfile) print '- usenet watermarks updated and gate_watermarks removed'
On Fri, May 04, 2001 at 04:25:52PM -0400, Barry A. Warsaw wrote:
The problem is that while the dolist() step happens unconditionally, it only needs to be done if it updates the archive_directory or private_archive_file_dir attributes. Below is a patch to skip this step if those attrs don't need to be upgraded.
Great, thanks.
MM> Would you accept a patch that made update change its uid to MM> mailman (requiring make install to be ran as root or mailman) MM> for everyone?I'm not so sure. Say I install Mailman as user
barry', I don't want to be running the upgrade as usermailman'.
Yeah, I figured that afterwards. Fair enough.
Probably a better approach is to refuse to run update if the effective uid doesn't equal mm_cfg.MAILMAN_UID. On the other hand, the attached
Mmmh, that will fail for you when you do make install as barry, then. Letme think. How about if euid != mm_cfg.MAILMAN_UID: if euid == 0 setgid (mm_cfg.MAILMAN_GID) setuid (mm_cfg.MAILMAN_UID)
This way, when you install as root, it setuids to mailman first, if you install as mailman, everything is fine too, and if you install as barry, that continues to work (although it obviously won't work with restricted hardlinks)
patch might be enough. On the third hand, maybe bin/update should just be culled of all ability to upgrade from a pre-2.0 revision? In that case, I'll bet bin/update can just go away.
The upgrade code is probably useful to some. I don't mind it myself as long as it doesn't try to run on my machines when I upgrade from 2.0.x to 2.0.y. :-)
I'll apply your patch to my tree when I upgrade mailman on my 3 other list servers, and I'll report back.
Thanks, Marc
Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key
- (Barry A. Warsaw)
| On the third hand, maybe bin/update should just be culled of all | ability to upgrade from a pre-2.0 revision? In that case, I'll bet | bin/update can just go away.
Please, please, please, please don't do that. It will force me to maintain that code in Debian, because Debian stable has an old version (1.1) and we absolutely need to have a clean upgrade path.
--
Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
On Fri, May 04, 2001 at 12:14:00PM -0700, Marc MERLIN wrote:
I'll try to remember to check it again on sunday night and report back.
Just for info: No stale locks showed up over the weekend with 2.0.5, and messages are still happily flowing.
2.0.5 looks good.
Thanks Barry Marc
Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key
"MM" == Marc MERLIN <marc_news@valinux.com> writes:
MM> Just for info: No stale locks showed up over the weekend with
MM> 2.0.5, and messages are still happily flowing.
MM> 2.0.5 looks good.Yay!
MM> Thanks Barry
MM> MarcYou're very welcome, thanks for the feedback. Announcements go out tomorrow.
-Barry
"BAW" == Barry A Warsaw <barry@digicool.com> writes:
BAW> I've uploaded the Mailman 2.0.5 patch and tarball to
BAW> SourceForge. Please check outThe 2.0.5 tarball had a bug in the admindb.py. Thanks to Phil Barnett who helped discover this. The patch file did not have the bug.
I've just uploaded a new 2.0.5 tarball, and will be sending out the announcements tomorrow morning.
Cheers, -Barry
On 6 May 2001, at 21:44, Barry A. Warsaw wrote:
"BAW" == Barry A Warsaw <barry@digicool.com> writes:
BAW> I've uploaded the Mailman 2.0.5 patch and tarball to BAW> SourceForge. Please check outThe 2.0.5 tarball had a bug in the admindb.py. Thanks to Phil Barnett who helped discover this. The patch file did not have the bug.
I've just uploaded a new 2.0.5 tarball, and will be sending out the announcements tomorrow morning.
Confiming:
The new tarball works great. Thanks.
-- Phil Barnett mailto:midnight@the-oasis.net WWW http://www.the-oasis.net/ FTP Site ftp://ftp.the-oasis.net
participants (4)
-
barry＠digicool.com -
Marc MERLIN -
Phil Barnett -
Tollef Fog Heen