Differences between revisions 12 and 15 (spanning 3 versions)
Revision 12 as of 2015-02-08 11:15:59
Size: 5824
Editor: JimTittsler
Comment: non-wikiwords
Revision 15 as of 2016-10-05 23:09:48
Size: 5955
Editor: msapiro
Comment: Add section headers and other minor cleanup.
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:

If you have access to the command line tools, you can simplify this by doing the following after creating the new list:
=== Method 1 - create a new list and use command line tools to transfer config and membership ===
If you have access to the command line tools, you can simplify the process of configuring and adding members to the new list by doing the following after creating the new list:
Line 17: Line 17:

However, if you have sufficient access to do this, you probably have sufficient access to use a better method.
Line 29: Line 31:
=== Method 2 - use the clone_list script ===
Line 31: Line 33:
=== Method 3 - moving files ===
Line 53: Line 55:
{{{#!wiki warning

scrub_nondigest

If you have been running lists with scrub_nondigest = Yes, the scrubbed attachments only exist in the old archives/private/LISTNAME/attachments/ directory. They will have to be moved and the links thereto updated manually or possibly by some programmatic process.
}}}
Note however that if the list's scrub_nondigest is Yes, the scrubbed attachments will be preserved, but the links in the message bodies will not be fixed by bin/arch and will still point to the old list.
Line 65: Line 62:

Depending upon your version of Mailman, you may find that after performing the second type of renaming procedure, above, that when you log into the admin screen for '!NewList,' the list name in the first box still shows '!OldList' and needs changing to '!NewList.' Upon trying to submit that change, you may be presented with:
=== cPanel issue ===
Depending upon your version of Mailman, you may find that after performing the third type of renaming procedure, above, that when you log into the admin screen for '!NewList,' the list name in the first box still shows '!OldList' and needs changing to '!NewList.' Upon trying to submit that change, you may be presented with:
Line 91: Line 88:

Converted from the Mailman FAQ Wizard

This is one of many [[../Frequently Asked Questions|Frequently Asked Questions]].

4.70. How do I change the name of (rename) a list?

You need access to the Mailman installation which is why this is a 'site' administrator task. If you don't have this access, you need to create a new list configured like the old one and transfer the members as described in FAQ 3.25 <How do I remove subscribers from a list and put them on a different list?>.

Method 1 - create a new list and use command line tools to transfer config and membership

If you have access to the command line tools, you can simplify the process of configuring and adding members to the new list by doing the following after creating the new list:

 bin/config_list -o file oldlist
 bin/config_list -i file newlist (see note)
 bin/list_members -o digest_file -p -d -f oldlist
 bin/list_members -o regular_file -p -r -f oldlist
 bin/add_members -d digest_file -r regular_file [other options] newlist

Use the --help options on the above commands for more information.

However, if you have sufficient access to do this, you probably have sufficient access to use a better method.

bin/ in the commands above and below refers to Mailman's bin/ directory, not some system /bin/ or /usr/bin/ directory.

In the above sequence, before running the second config_list, edit 'file' to either change the line "real_name = 'OldList'" to "real_name = 'NewList'" or just remove that line from the file.

The drawback of the above methods is member information other than name and regular/digest is not transferred and the archives are not transferred.

Method 2 - use the clone_list script

There is now a script at http://www.msapiro.net/scripts/clone_list (mirrored at http://fog.ccsf.edu/~msapiro/scripts/clone_list) which can be used to clone an existing list similarly to the above process. Unlike the above process, this script can preserve all the membership information and can also copy archives, pending requests, list specific edited templates and messages collected for the next digest so the result is like the following procedure except it doesn't remove the old list. The caveats below about archives apply to this process too, but if you have Postfix/Mailman integration, this process will create the aliases for the new list.

Method 3 - moving files

The following procedure (requiring full server access) will preserve everything. Before doing this, consider whether you want to stop your incoming MTA during the process to prevent possible message loss.

 mv lists/oldlist lists/newlist
 mv archives/private/oldlist archives/private/newlist
 mv archives/private/oldlist.mbox archives/private/newlist.mbox
 mv archives/private/newlist.mbox/oldlist.mbox archives/private/newlist.mbox/newlist.mbox

Then go to the web admin interface for the 'newlist' list and change the real_name from 'OldList' to 'NewList'.

You might be tempted to change the names of any data/heldmsg-oldlist-nnn.pck (or .txt) files. Don't do this. The old names are in the lists request.pck files, and changing the name will result in the file not being found.

Also, don't be too concerned about symlinks in the archives/public/ directory. Mailman will automatically create them as needed for the new name. If you leave the old symlinks, they will point to non-existant directories, and trying to visit old public archive URLs will probably give a 403 - forbidden error, so removing them is a good idea, but then visiting the old URLs will still produce a 404 - not found error.

At this point, everything is OK except the 'more information about this list' links on some archive pages will still point to the 'oldlist' list which doesn't exist. More importantly, links to scrubbed attachments will also point to the oldlist. You can fix those manually or rebuild the archive with

 bin/arch --wipe newlist

Note however that if the list's scrub_nondigest is Yes, the scrubbed attachments will be preserved, but the links in the message bodies will not be fixed by bin/arch and will still point to the old list.

Finally, if your MTA uses aliases for mailman lists rather than some process that automatically understands list names from the contents of the lists/ directory, you will have to update your aliases. If you do this manually, edit your aliases to change 'oldlist' to 'newlist' (a total of 2 changes per alias for 10 aliases), and then run 'newaliases' or whatever command rebuilds your alias database. It you have Postfix/Mailman integration, just run

bin/genaliases

cPanel issue

Depending upon your version of Mailman, you may find that after performing the third type of renaming procedure, above, that when you log into the admin screen for 'NewList,' the list name in the first box still shows 'OldList' and needs changing to 'NewList.' Upon trying to submit that change, you may be presented with:

Error: real_name attribute not changed! It must differ from the list's name by case only.

This will occur with cPanel Mailman and probably only with cPanel.

In that case, use the following commands to change the real_name:

 $ bin/withlist -l newname
 Loading list newname (locked)
 The variable `m' is the newname MailList instance
 >>> m.real_name
 'OldName'
 >>> m.real_name = 'NewName'
 >>> m.Save()
 >>>
 Unlocking (but not saving) list: newname
 Finalizing
 $

You type the withlist command, and within withlist, you type the responses to the >>> prompts. On the >>> last line, your entry is control-D (end of file). This procedure was found in the archives of the Mailman-Users mailing list:

http://www.mail-archive.com/mailman-users@python.org/msg50278.html

MailmanWiki: DOC/4.70 How do I change the name of (rename) a list? (last edited 2016-10-05 23:09:48 by msapiro)