|Deletions are marked like this.||Additions are marked like this.|
|Line 53:||Line 53:|
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.|
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?>.
If you have access to the command line tools, you can simplify this 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.
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.
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.
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
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:
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:
Converted from the Mailman FAQ Wizard
This is one of many Frequently Asked Questions.