Revision: 8153
http://svn.sourceforge.net/mailman/?rev=8153&view=rev
Author: bwarsaw
Date: 2007-02-07 08:34:10 -0800 (Wed, 07 Feb 2007)
Log Message:
-----------
Move FAQ
Added Paths:
-----------
trunk/mailman/docs/readmes/FAQ.txt
Removed Paths:
-------------
trunk/mailman/docs/FAQ.txt
Deleted: trunk/mailman/docs/FAQ.txt
===================================================================
--- trunk/mailman/docs/FAQ.txt 2007-02-07 16:32:45 UTC (rev 8152)
+++ trunk/mailman/docs/FAQ.txt 2007-02-07 16:34:10 UTC (rev 8153)
@@ -1,389 +0,0 @@
-Mailman - The GNU Mailing List Management System
-Copyright (C) 1998-2007 by the Free Software Foundation, Inc.
-51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
-
-Note: We're migrating the FAQ to an on-line interactive system called
- "FAQ Wizard". To see the Mailman FAQ Wizard in action, go to
- http://www.python.org/cgi-bin/faqw-mm.py
-
-FREQUENTLY ASKED QUESTIONS
-
-Q. How do you spell this program?
-
-A. You spell it "Mailman", with a leading capital "M" and a lowercase
- second "m". It is incorrect to spell it "MailMan" (i.e. you should
- not use StudlyCaps).
-
-Q. I'm getting really terrible performance for outgoing messages. It
- seems that if the MTA has trouble resolving DNS for any recipients,
- qrunner just gets really slow clearing the queue. Any ideas?
-
-A. What's likely happening is that your MTA is doing DNS resolution on
- recipients for messages delivered locally (i.e. from Mailman to
- your MTA via SMTPDirect.py). This is a Bad Thing. You need to
- turn off synchronous DNS resolution for messages originating from
- the local host.
-
- In Exim, the value to edit is receiver_verify_hosts. See
- README.EXIM for details. Other MTAs have (of course) different
- parameters and defaults that control this. First check the README
- file for your MTA and then consult your MTA's own documentation.
-
-Q. My list members are complaining about Mailman's List-* headers!
- What can I do about this?
-
-A. These headers are described in RFC 2369 and are added by Mailman
- for the long-term benefit of end-users. While discouraged, the
- list admin can disable these via the General Options page. See
- also README.USERAGENT for more information.
-
-Q. Can I put the user's address in the footer that Mailman adds to
- each message?
-
-A. Yes, in Mailman 2.1. The site admin needs to enable personalization by
- setting the following variable in the mm_cfg.py file:
-
- OWNERS_CAN_ENABLE_PERSONALIZATION = Yes
-
- Once this is done, list admins can enable personalization for regular
- delivery members (digest deliveries can't be personalized currently). A
- personalized list can include the user's address in the footer.
-
-Q. My users hate HTML in their email and for security reasons, I want
- to strip out all MIME attachments. How can I do this?
-
-A. Mailman 2.1 has this feature built-in. See the Content Filtering
- Options page in the admin interface.
-
-Q. What if I get "document contains no data" from the web server, or
- mail isn't getting delivered, or I see "Premature end of script
- headers" or "Mailman CGI error!!!"
-
-A. The most likely cause of this is that the GID that is compiled into
- the C wrappers does not match the GID that your Web server invokes
- CGI scripts with. Note that a similar error could occur if your
- mail system invokes filter programs under a GID that does not match
- the one compiled into the C mail wrapper.
-
- To fix this you will need to re-configure Mailman using the
- --with-cgi-gid and --with-mail-gid options. See the INSTALL file
- for details.
-
- These errors are logged to syslog and they do not show up in the
- Mailman log files. Problems with the CGI wrapper do get reported
- in the web browser though (unless STEALTH_MODE is enabled), and
- include the expected GID, so that should help a lot.
-
- You may want to have syslog running and configured to log the
- mail.error log class somewhere; on Solaris systems, the line
-
- mail.debug /var/log/syslog
-
- causes the messages to go to them in /var/log/syslog, for example.
- (The distributed syslog.conf forwards the message to the loghost,
- when present. See the syslog man page for more details.)
-
- If your system is set like this, and you get a failure trying to
- visit the mailman/listinfo web page, and it's due to a UID or GID
- mismatch, then you should get an entry at the end of
- /var/log/syslog identifying the expected and received values.
-
- If you are not getting any log messages in syslog, or in Mailman's
- own log files, but messages are still not being delivered, then it
- is likely that qrunner is not running (qrunner is the process that
- handles all mail in the system). In Mailman 2.0, qrunner was
- invoked from cron so make sure your crontab entries for the
- `mailman' user have been installed. In Mailman 2.1, qrunner is
- started with the bin/mailmanctl script, which can be invoked
- manually, or merged with your OS's init scripts.
-
-Q. What should I check periodically?
-
-A. Many of the scripts have their standard error logged to
- $prefix/logs/error, and some of the modules write caught errors
- there, as well, so you should check there at least occasionally to
- look for bugs in the code and problems in your setup.
-
- You may want to periodically check the other log files in the logs/
- directory, perhaps occasionally rotating them with something like
- the Linux logrotate script.
-
-Q. I can't access the public archives. Why?
-
-A. If you are using Apache, you must make sure that FollowSymLinks is
- enabled for the path to the public archives. Note that the actual
- archives always reside in the private tree, and only when archives
- are public, is the symlink followed. See this archive message for
- more details:
-
- http://mail.python.org/pipermail/mailman-users/1998-November/000150.html
-
-Q. Still having problems? Running QMail?
-
-A. Make sure that you are using "preline" before calling the "mailman"
- wrapper:
-
- |preline /home/mailman/mail/mailman post listname
-
- "preline" adds a Unix-style "From " header which the archiver requires.
- You can fix the archive mbox files by adding:
-
- From somebody Mon Oct 9 12:27:34 MDT 2000
-
- before every message and re-running the archive command
- "bin/arch listname". The archives should now exist. See README.QMAIL
- for more information.
-
-Q. Still having problems? Running on GNU/Linux?
-
-A. See the README.LINUX file.
-
-Q. I want to get rid of some messages in my archive. How do I do
- this?
-
-A. David Rocher posts the following recipe:
-
- * remove $prefix/archives/private/<listname>
- * edit $prefix/archives/private/<listname>.mbox/<listname>.mbox [optional]
- * run $prefix/bin/arch <listname>
-
-Q. How secure are the authentication mechanisms used in Mailman's web
- interface?
-
-A. If your Mailman installation run on an SSL-enabled web server
- (i.e. you access the Mailman web pages with "https://..."; URLs),
- you should be as safe as SSL itself is.
-
- However, most Mailman installation run under standard,
- encryption-unaware servers. There's nothing wrong with that for
- most applications, but a sufficiently determined cracker *could*
- get unauthorized access by:
-
- * Packet sniffing: The password used to do the initial
- authentication for any non-public Mailman page is sent as clear
- text over the net. If you consider this to be a big problem, you
- really should use an SSL-enabled server.
-
- * Stealing a valid cookie: After successful password
- authentication, Mailman sends a "cookie" back to the user's
- browser. This cookie will be used for "automatic" authentication
- when browsing further within the list's protected pages. Mailman
- employs "session cookies" which are set until you quit your
- browser or explicitly log out.
-
- Gaining access to the user's cookie (e.g. by being able to read
- the user's browser cookie database, or by means of packet
- sniffing, or maybe even by some broken browser offering all it's
- cookies to any and all sites the user accesses), and at the same
- time being able to fulfill the other criteria for using the
- cookie could result in unauthorized access.
-
- Note that this problem is more easily exploited when users browse
- the web via proxies -- in that case, the cookie would be valid
- for any connections made through that proxy, and not just for
- connections made from the particular machine the user happens to
- be accessing the proxy from.
-
- * Getting access to the user's terminal: This is really just
- another kind of cookie stealing. The short cookie expiration
- time is supposed to help defeat this problem. It can be
- considered the price to pay for the convenience of not having to
- type the password in every time.
-
-Q. I want to backup my lists. What do I need to save?
-
-A. See this FAQ wizard entry:
- http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.006.htp
-
-Q. How do I rename a list?
-
-A. Renaming a list is currently a bit of a pain to do completely
- correctly, especially if you want to make sure that the old list
- contacts are automatically forwarded to the new list. This ought
- to be easier. :(
-
- The biggest problem you have is how to stop mail and web traffic to
- your list during the transition, and what to do about any mail
- undelivered to the old list after the move. I don't think there
- are any foolproof steps, but here's how you can reduce the risk:
-
- - Temporarily disable qrunner. To do this, you need to edit the
- user `mailman's crontab entry. Execute the following command,
- commenting out the qrunner line when you're dropped into your
- editor. Then save the file and quit the editor.
-
- % crontab -u mailman -e
-
- - Turn off your mail server. This is mostly harmless since remote
- MTAs will just keep retrying until you turn it back on, and it's
- not going to be off for very long.
-
- - Next turn off your web server if possible. This of course means
- your entire site will be off-line while you make the switch and
- this may not be acceptable to you. The next best suggestion is
- to set up your permanent redirects now for the list you're
- moving. This means that anybody looking for the list under its
- old name will be redirected to the new name, but they'll get
- errors until you've completed the move.
-
- Let's say the old name is "oldname" and the new name is
- "newname". Here are some Apache directives that will do the
- trick, though YMMV:
-
- RedirectMatch permanent /mailman/(.*)/oldname(.*)
http://www.dom.ain/mailman/$1/newname$2
- RedirectMatch permanent /pipermail/oldname(.*)
http://www.dom.ain/pipermail/newname$1
-
- Add these to your httpd.conf file and restart Apache.
-
- - Now cd to the directory where you've installed Mailman. Let's
- say it's /usr/local/mailman:
-
- % cd /usr/local/mailman
-
- and cd to the `lists' subdirectory:
-
- % cd lists
-
- You should now see the directory `oldname'. Move this to
- `newname':
-
- % mv oldname newname
-
- - Now cd to the private archives directory:
-
- % cd ../archives/private
-
- You will need to move the oldname's .mbox directory, and the
- .mbox file within that directory. Don't worry about the public
- archives; the next few steps will take care of them without
- requiring you to fiddle around in the file system:
-
- % mv oldname.mbox newname.mbox
- % mv newname.mbox/oldname.mbox newname.mbox/newname.mbox
-
- - You now need to run the `bin/move_list' script to update some of
- the internal archiver paths. IMPORTANT: Skip this step if you
- are using Mailman 2.1!
-
- % cd ../..
- % bin/move_list newname
-
- - You should now regenerate the public archives:
-
- % bin/arch newname
-
- - You'll likely need to change some of your list's configuration
- options, especially if you want to accept postings addressed to
- the old list on the new list. Visit the admin interface for your
- new list:
-
- o Go to the General options
-
- o Change the "real_name" option to reflect the new list's name,
- e.g. "Newname"
-
- o Change the subject prefix to reflect the new list's name,
- e.g. "[Newname] " (yes, that's a trailing space character).
-
- o Optionally, update other configuration fields like info,
- description, or welcome_msg. YMMV.
-
- o Save your changes
-
- o Go to the Privacy options
-
- o Add the old list's address to acceptable_aliases.
- E.g. "[EMAIL PROTECTED]". This way, (after the /etc/aliases
- changes described below) messages posted to the old list will
- not be held by the new list for "implicit destination"
- approval.
-
- o Save your changes
-
- - Now you want to update your /etc/aliases file to include the
- aliases for the new list, and forwards for the old list to the
- new list. Note that these instructions are for Sendmail style
- alias files, adjust to the specifics of how your MTA is set up.
-
- o Find the lines defining the aliases for your old list's name
-
- o Copy and paste them just below the originals.
-
- o Change all the references of "oldname" to "newname" in the
- pasted stanza.
-
- o Now change the targets of the original aliases to forward to
- the new aliases. When you're done, you will end up with
- /etc/aliases entries like the following (YMMV):
-
- XXX This needs updating for MM2.1!
-
- # Forward the oldname list to the newname list
- oldname: [EMAIL PROTECTED]
- oldname-request: [EMAIL PROTECTED]
- oldname-admin: [EMAIL PROTECTED]
- oldname-owner: [EMAIL PROTECTED]
-
- newname: "|/usr/local/mailman/mail/mailman post newname"
- newname-admin: "|/usr/local/mailman/mail/mailman mailowner newname"
- newname-request: "|/usr/local/mailman/mail/mailman mailcmd newname"
- newname-owner: newname-admin
-
- o Run newaliases
-
- - Before you restart everything, you want to make one last check.
- You're looking for files in the qfiles/ directory that may have
- been addressed to the old list but weren't delivered before you
- renamed the list. Do something like the following:
-
- % cd /usr/local/mailman/qfiles
- % grep oldname *.msg
-
- If you get no hits, skip to the next step, you've got nothing to
- worry about.
-
- If you did get hits, then things get complicated. I warn you
- that the rest of this step is untested. :(
-
- For each of the .msg files that were destined for the old list,
- you need to change the corresponding .db file. Unfortunately
- there's no easy way to do this. Anyway...
-
- Save the following Python code in a file called 'hackdb.py':
-
- -------------------------hackdb.py
- import sys
- import marshal
- fp = open(sys.argv[1])
- d = marshal.load(fp)
- fp.close()
- d['listname'] = sys.argv[2]
- fp = open(sys.argv[1], 'w')
- marshal.dump(d, fp)
- fp.close()
- -------------------------
-
- And then for each file that matched your grep above, do the
- following:
-
- % python hackdb.py reallylonghexfilenamematch1.db newname
-
- - It's now safe to turn your MTA back on.
-
- - Turn your qrunner back on by running
-
- % crontab -u mailman -e
-
- again and this time uncommenting the qrunner line. Save the file
- and quit your editor.
-
- - Rejoice, you're done. Send $100,000 in shiny new pennies to the
- Mailman cabal as your downpayment toward making this easier for
- the next list you have to rename. :)
-
-
-
-Local Variables:
-mode: text
-indent-tabs-mode: nil
-End:
Copied: trunk/mailman/docs/readmes/FAQ.txt (from rev 8149,
trunk/mailman/docs/FAQ.txt)
===================================================================
--- trunk/mailman/docs/readmes/FAQ.txt (rev 0)
+++ trunk/mailman/docs/readmes/FAQ.txt 2007-02-07 16:34:10 UTC (rev 8153)
@@ -0,0 +1,389 @@
+Mailman - The GNU Mailing List Management System
+Copyright (C) 1998-2007 by the Free Software Foundation, Inc.
+51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
+
+Note: We're migrating the FAQ to an on-line interactive system called
+ "FAQ Wizard". To see the Mailman FAQ Wizard in action, go to
+ http://www.python.org/cgi-bin/faqw-mm.py
+
+FREQUENTLY ASKED QUESTIONS
+
+Q. How do you spell this program?
+
+A. You spell it "Mailman", with a leading capital "M" and a lowercase
+ second "m". It is incorrect to spell it "MailMan" (i.e. you should
+ not use StudlyCaps).
+
+Q. I'm getting really terrible performance for outgoing messages. It
+ seems that if the MTA has trouble resolving DNS for any recipients,
+ qrunner just gets really slow clearing the queue. Any ideas?
+
+A. What's likely happening is that your MTA is doing DNS resolution on
+ recipients for messages delivered locally (i.e. from Mailman to
+ your MTA via SMTPDirect.py). This is a Bad Thing. You need to
+ turn off synchronous DNS resolution for messages originating from
+ the local host.
+
+ In Exim, the value to edit is receiver_verify_hosts. See
+ README.EXIM for details. Other MTAs have (of course) different
+ parameters and defaults that control this. First check the README
+ file for your MTA and then consult your MTA's own documentation.
+
+Q. My list members are complaining about Mailman's List-* headers!
+ What can I do about this?
+
+A. These headers are described in RFC 2369 and are added by Mailman
+ for the long-term benefit of end-users. While discouraged, the
+ list admin can disable these via the General Options page. See
+ also README.USERAGENT for more information.
+
+Q. Can I put the user's address in the footer that Mailman adds to
+ each message?
+
+A. Yes, in Mailman 2.1. The site admin needs to enable personalization by
+ setting the following variable in the mm_cfg.py file:
+
+ OWNERS_CAN_ENABLE_PERSONALIZATION = Yes
+
+ Once this is done, list admins can enable personalization for regular
+ delivery members (digest deliveries can't be personalized currently). A
+ personalized list can include the user's address in the footer.
+
+Q. My users hate HTML in their email and for security reasons, I want
+ to strip out all MIME attachments. How can I do this?
+
+A. Mailman 2.1 has this feature built-in. See the Content Filtering
+ Options page in the admin interface.
+
+Q. What if I get "document contains no data" from the web server, or
+ mail isn't getting delivered, or I see "Premature end of script
+ headers" or "Mailman CGI error!!!"
+
+A. The most likely cause of this is that the GID that is compiled into
+ the C wrappers does not match the GID that your Web server invokes
+ CGI scripts with. Note that a similar error could occur if your
+ mail system invokes filter programs under a GID that does not match
+ the one compiled into the C mail wrapper.
+
+ To fix this you will need to re-configure Mailman using the
+ --with-cgi-gid and --with-mail-gid options. See the INSTALL file
+ for details.
+
+ These errors are logged to syslog and they do not show up in the
+ Mailman log files. Problems with the CGI wrapper do get reported
+ in the web browser though (unless STEALTH_MODE is enabled), and
+ include the expected GID, so that should help a lot.
+
+ You may want to have syslog running and configured to log the
+ mail.error log class somewhere; on Solaris systems, the line
+
+ mail.debug /var/log/syslog
+
+ causes the messages to go to them in /var/log/syslog, for example.
+ (The distributed syslog.conf forwards the message to the loghost,
+ when present. See the syslog man page for more details.)
+
+ If your system is set like this, and you get a failure trying to
+ visit the mailman/listinfo web page, and it's due to a UID or GID
+ mismatch, then you should get an entry at the end of
+ /var/log/syslog identifying the expected and received values.
+
+ If you are not getting any log messages in syslog, or in Mailman's
+ own log files, but messages are still not being delivered, then it
+ is likely that qrunner is not running (qrunner is the process that
+ handles all mail in the system). In Mailman 2.0, qrunner was
+ invoked from cron so make sure your crontab entries for the
+ `mailman' user have been installed. In Mailman 2.1, qrunner is
+ started with the bin/mailmanctl script, which can be invoked
+ manually, or merged with your OS's init scripts.
+
+Q. What should I check periodically?
+
+A. Many of the scripts have their standard error logged to
+ $prefix/logs/error, and some of the modules write caught errors
+ there, as well, so you should check there at least occasionally to
+ look for bugs in the code and problems in your setup.
+
+ You may want to periodically check the other log files in the logs/
+ directory, perhaps occasionally rotating them with something like
+ the Linux logrotate script.
+
+Q. I can't access the public archives. Why?
+
+A. If you are using Apache, you must make sure that FollowSymLinks is
+ enabled for the path to the public archives. Note that the actual
+ archives always reside in the private tree, and only when archives
+ are public, is the symlink followed. See this archive message for
+ more details:
+
+ http://mail.python.org/pipermail/mailman-users/1998-November/000150.html
+
+Q. Still having problems? Running QMail?
+
+A. Make sure that you are using "preline" before calling the "mailman"
+ wrapper:
+
+ |preline /home/mailman/mail/mailman post listname
+
+ "preline" adds a Unix-style "From " header which the archiver requires.
+ You can fix the archive mbox files by adding:
+
+ From somebody Mon Oct 9 12:27:34 MDT 2000
+
+ before every message and re-running the archive command
+ "bin/arch listname". The archives should now exist. See README.QMAIL
+ for more information.
+
+Q. Still having problems? Running on GNU/Linux?
+
+A. See the README.LINUX file.
+
+Q. I want to get rid of some messages in my archive. How do I do
+ this?
+
+A. David Rocher posts the following recipe:
+
+ * remove $prefix/archives/private/<listname>
+ * edit $prefix/archives/private/<listname>.mbox/<listname>.mbox [optional]
+ * run $prefix/bin/arch <listname>
+
+Q. How secure are the authentication mechanisms used in Mailman's web
+ interface?
+
+A. If your Mailman installation run on an SSL-enabled web server
+ (i.e. you access the Mailman web pages with "https://..."; URLs),
+ you should be as safe as SSL itself is.
+
+ However, most Mailman installation run under standard,
+ encryption-unaware servers. There's nothing wrong with that for
+ most applications, but a sufficiently determined cracker *could*
+ get unauthorized access by:
+
+ * Packet sniffing: The password used to do the initial
+ authentication for any non-public Mailman page is sent as clear
+ text over the net. If you consider this to be a big problem, you
+ really should use an SSL-enabled server.
+
+ * Stealing a valid cookie: After successful password
+ authentication, Mailman sends a "cookie" back to the user's
+ browser. This cookie will be used for "automatic" authentication
+ when browsing further within the list's protected pages. Mailman
+ employs "session cookies" which are set until you quit your
+ browser or explicitly log out.
+
+ Gaining access to the user's cookie (e.g. by being able to read
+ the user's browser cookie database, or by means of packet
+ sniffing, or maybe even by some broken browser offering all it's
+ cookies to any and all sites the user accesses), and at the same
+ time being able to fulfill the other criteria for using the
+ cookie could result in unauthorized access.
+
+ Note that this problem is more easily exploited when users browse
+ the web via proxies -- in that case, the cookie would be valid
+ for any connections made through that proxy, and not just for
+ connections made from the particular machine the user happens to
+ be accessing the proxy from.
+
+ * Getting access to the user's terminal: This is really just
+ another kind of cookie stealing. The short cookie expiration
+ time is supposed to help defeat this problem. It can be
+ considered the price to pay for the convenience of not having to
+ type the password in every time.
+
+Q. I want to backup my lists. What do I need to save?
+
+A. See this FAQ wizard entry:
+ http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.006.htp
+
+Q. How do I rename a list?
+
+A. Renaming a list is currently a bit of a pain to do completely
+ correctly, especially if you want to make sure that the old list
+ contacts are automatically forwarded to the new list. This ought
+ to be easier. :(
+
+ The biggest problem you have is how to stop mail and web traffic to
+ your list during the transition, and what to do about any mail
+ undelivered to the old list after the move. I don't think there
+ are any foolproof steps, but here's how you can reduce the risk:
+
+ - Temporarily disable qrunner. To do this, you need to edit the
+ user `mailman's crontab entry. Execute the following command,
+ commenting out the qrunner line when you're dropped into your
+ editor. Then save the file and quit the editor.
+
+ % crontab -u mailman -e
+
+ - Turn off your mail server. This is mostly harmless since remote
+ MTAs will just keep retrying until you turn it back on, and it's
+ not going to be off for very long.
+
+ - Next turn off your web server if possible. This of course means
+ your entire site will be off-line while you make the switch and
+ this may not be acceptable to you. The next best suggestion is
+ to set up your permanent redirects now for the list you're
+ moving. This means that anybody looking for the list under its
+ old name will be redirected to the new name, but they'll get
+ errors until you've completed the move.
+
+ Let's say the old name is "oldname" and the new name is
+ "newname". Here are some Apache directives that will do the
+ trick, though YMMV:
+
+ RedirectMatch permanent /mailman/(.*)/oldname(.*)
http://www.dom.ain/mailman/$1/newname$2
+ RedirectMatch permanent /pipermail/oldname(.*)
http://www.dom.ain/pipermail/newname$1
+
+ Add these to your httpd.conf file and restart Apache.
+
+ - Now cd to the directory where you've installed Mailman. Let's
+ say it's /usr/local/mailman:
+
+ % cd /usr/local/mailman
+
+ and cd to the `lists' subdirectory:
+
+ % cd lists
+
+ You should now see the directory `oldname'. Move this to
+ `newname':
+
+ % mv oldname newname
+
+ - Now cd to the private archives directory:
+
+ % cd ../archives/private
+
+ You will need to move the oldname's .mbox directory, and the
+ .mbox file within that directory. Don't worry about the public
+ archives; the next few steps will take care of them without
+ requiring you to fiddle around in the file system:
+
+ % mv oldname.mbox newname.mbox
+ % mv newname.mbox/oldname.mbox newname.mbox/newname.mbox
+
+ - You now need to run the `bin/move_list' script to update some of
+ the internal archiver paths. IMPORTANT: Skip this step if you
+ are using Mailman 2.1!
+
+ % cd ../..
+ % bin/move_list newname
+
+ - You should now regenerate the public archives:
+
+ % bin/arch newname
+
+ - You'll likely need to change some of your list's configuration
+ options, especially if you want to accept postings addressed to
+ the old list on the new list. Visit the admin interface for your
+ new list:
+
+ o Go to the General options
+
+ o Change the "real_name" option to reflect the new list's name,
+ e.g. "Newname"
+
+ o Change the subject prefix to reflect the new list's name,
+ e.g. "[Newname] " (yes, that's a trailing space character).
+
+ o Optionally, update other configuration fields like info,
+ description, or welcome_msg. YMMV.
+
+ o Save your changes
+
+ o Go to the Privacy options
+
+ o Add the old list's address to acceptable_aliases.
+ E.g. "[EMAIL PROTECTED]". This way, (after the /etc/aliases
+ changes described below) messages posted to the old list will
+ not be held by the new list for "implicit destination"
+ approval.
+
+ o Save your changes
+
+ - Now you want to update your /etc/aliases file to include the
+ aliases for the new list, and forwards for the old list to the
+ new list. Note that these instructions are for Sendmail style
+ alias files, adjust to the specifics of how your MTA is set up.
+
+ o Find the lines defining the aliases for your old list's name
+
+ o Copy and paste them just below the originals.
+
+ o Change all the references of "oldname" to "newname" in the
+ pasted stanza.
+
+ o Now change the targets of the original aliases to forward to
+ the new aliases. When you're done, you will end up with
+ /etc/aliases entries like the following (YMMV):
+
+ XXX This needs updating for MM2.1!
+
+ # Forward the oldname list to the newname list
+ oldname: [EMAIL PROTECTED]
+ oldname-request: [EMAIL PROTECTED]
+ oldname-admin: [EMAIL PROTECTED]
+ oldname-owner: [EMAIL PROTECTED]
+
+ newname: "|/usr/local/mailman/mail/mailman post newname"
+ newname-admin: "|/usr/local/mailman/mail/mailman mailowner newname"
+ newname-request: "|/usr/local/mailman/mail/mailman mailcmd newname"
+ newname-owner: newname-admin
+
+ o Run newaliases
+
+ - Before you restart everything, you want to make one last check.
+ You're looking for files in the qfiles/ directory that may have
+ been addressed to the old list but weren't delivered before you
+ renamed the list. Do something like the following:
+
+ % cd /usr/local/mailman/qfiles
+ % grep oldname *.msg
+
+ If you get no hits, skip to the next step, you've got nothing to
+ worry about.
+
+ If you did get hits, then things get complicated. I warn you
+ that the rest of this step is untested. :(
+
+ For each of the .msg files that were destined for the old list,
+ you need to change the corresponding .db file. Unfortunately
+ there's no easy way to do this. Anyway...
+
+ Save the following Python code in a file called 'hackdb.py':
+
+ -------------------------hackdb.py
+ import sys
+ import marshal
+ fp = open(sys.argv[1])
+ d = marshal.load(fp)
+ fp.close()
+ d['listname'] = sys.argv[2]
+ fp = open(sys.argv[1], 'w')
+ marshal.dump(d, fp)
+ fp.close()
+ -------------------------
+
+ And then for each file that matched your grep above, do the
+ following:
+
+ % python hackdb.py reallylonghexfilenamematch1.db newname
+
+ - It's now safe to turn your MTA back on.
+
+ - Turn your qrunner back on by running
+
+ % crontab -u mailman -e
+
+ again and this time uncommenting the qrunner line. Save the file
+ and quit your editor.
+
+ - Rejoice, you're done. Send $100,000 in shiny new pennies to the
+ Mailman cabal as your downpayment toward making this easier for
+ the next list you have to rename. :)
+
+
+
+Local Variables:
+mode: text
+indent-tabs-mode: nil
+End:
This was sent by the SourceForge.net collaborative development platform, the
world's largest Open Source development site.
_______________________________________________
Mailman-checkins mailing list
[email protected]
Unsubscribe:
http://mail.python.org/mailman/options/mailman-checkins/archive%40jab.org
