On 07/04/2013 11:58 AM, David wrote: > > Our sysadmin has the new Debian server set up, Mailman is installed and our > lists are copied over. This new server does not yet have our domain name or > IP address. We want to test the new setup before making those changes. > > I would appreciate some recommendations for how to do this testing. What > mail functions can we test? (Our MX records don't point to the new server > yet.) Afaik, we can't really test normal mail processing in advance of > making the final cut-over (or can we?).
If the mail server on the new box thinks list domains are in its local delivery space (mydestination in Postfix), you can just send mail from an MUA on the local box configured to deliver via SMTP to the local MTA, and it all should work except that mail from Mailman to local addresses will be delivered to the new box instead of the current live box. > Are there things in addition to > changing /etc/hosts that I can implement on my computer for testing the new > Mailman server? Any ideas or suggestions are appreciated. Adding an entry for 127.0.0.1 (IPv4) with the domain name should be enough for a local web browser to access Mailman. > Also, in terms of the actual cut-over, how can we avoid bounced or lost > messages if it takes several hours to transition? You need to stop the MTA on the old box so it doesn't accept mail that won't get moved. Then, during the transition before the IP is moved to the new box, mail to the MTAs attempting to deliver to to IP will get a connection refused or a time out; probably connection refused because nothing is listening on port 25. This is a retryable error. Possibly the majority of MTAs will retry for 5 days before giving up and bouncing the mail. Almost all will retry for at least 24 hours. Only a pathological few will bounce the mail within a few hours, although some may send a delayed DSN after say 4 hours but keep trying. > My plan is roughly something like this: > > First I will moderate any pending messages. Then I will stop mailman. At > this point our sysadmin will do a final data migration. Then I will shut > down the server. If you stop Mailman before stopping the MTA, be sure that Mailman's qfiles are migrated. > I will do the IP swap at Linode. Then I will boot up the > new server. I hope we can do all that within a window of about an hour. I > appreciate any advice on this too. > > For reference, here are some posts I have read in preparation for this move: > > How do I move a list to a different server-Mailman installation. - > Documentation - Confluence > http://wiki.list.org/pages/viewpage.action?pageId=4030682 > > Re: [Mailman-Developers] Upgrading from 2.0.10 to 2.1.b2 > http://www.mail-archive.com/mailman-developers@python.org/msg03127.html > > [Mailman-Users] migrating mailman lists > http://mail.python.org/pipermail/mailman-users/2007-January/055208.html > > [Mailman-Users] migrating mailman lists > http://mail.python.org/pipermail/mailman-users/2007-January/055211.html > > [Mailman-Users] export/import of lists > http://mail.python.org/pipermail/mailman-users/2004-June/037086.html > > > BTW, does anyone have an itemized check list of all files that need to be > copied? The posts above are not 100% complete (afaik) because, for example, > they don't consider that some apache config settings may be related to > Mailman. In our case we have ScriptAlias /m/ /usr/lib/cgi-bin/mailman/ and > related changes. Many posts on this subject are not 100% complete because they are based on a standard GNU Mailman installation of Mailman itself. They do not address the issue of getting Mailman installed and working as you want on the new server. As Stephen points out, this is highly dependent on source vs. package install, which package and what things have been locally tweaked. >From the Mailman point of view, at least for a source install, the only things that need to be moved are the contents of Mailman's var-prefix directory which are the directories $var-prefix/archives/ $var-prefix/data/ $var-prefix/lists/ $var-prefix/locks/ $var-prefix/logs/ $var-prefix/qfiles/ and $var-prefix/spam/ Everything else comes under the heading of making Mailman work on the new server as opposed to migrating lists, archives, etc. from the old server. This is further confused and complicated by the fact that various packages split that into different places. For example, RedHat puts some of these directories in /var/lib/mailman, but locks/ is /var/lock/mailman/, logs is /var/log/mailman/ and qfiles is /var/spool/mailman. > Furthermore, files like /etc/mailname are related to Mailman configuration. I happen to know that this is a Debian package trick for providing the group with which the MTA invokes the mail wrapper to the wrapper without recompiling the wrapper (is there a similar one for the web server group?), but I can't possibly know all these things for all packages (See the FAQ at <http://wiki.list.org/x/OIDD>). > If anyone has or can come up with an itemized, file-by-file, checklist, I > would like to be able to offer that to our sysadmin. The only alternative I > know is a trial and error approach to making sure we don't overlook > anything, and I prefer to avoid that method (especially the "and error" > part!). If Mailman works on the new box, all you need to move is the mutable data described above. There is one important CAVEAT! The contents of the archives/public/ directory are symlinks. You don't actually have to move them at all as they are rewritten as needed each time a list is saved, but if you do move them, you MUST move the symlinks, not the referent directories in archives/private/. If you move the referent directories, that static structure will never be updated and the 'pipermail' public archive URL will continue to show the archive as of the move. The actual archive in archives/private will be updated and the updated will be visible via the 'private' URL but not via the 'public' one. Also note that if you are using an MTA with manual Mailman aliases, you need to move those too. This does not apply to Postfix with Postfix/Mailman integration as in that case, Mailman's aliases are in the $var-prefix/data/ directory. Finally, after the migration, run Mailman's bin/check_perms to be sure ownership and permissions are OK. It wouldn't hurt to run it on the old box before the move to get a baseline (some packages tend to use symlinks which check_perms was not designed to handle). -- Mark Sapiro <m...@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
