Moving existing lists to a new domain
I've moved lists and archives between domains in Mailman 2.1 and Pipermail, but not yet with Mailman 3 and Hyperkitty.
I have a working multi-domain deployment, and one of the organizations using it is working on changing their domain name. Forwarding incoming messages at the MTA and setting up redirects on the Web server are simple enough, but internally within MM3/Django reside the bits I'm less certain about.
Since all the lists for the given domain will be moving to the same unused new domain on the existing server, and can move at the same time, I suppose this could be done through (offline if necessary) backend database update queries. Is there anything outside the DB which would need updating or regenerating for this too? Is this how others have tackled similar tasks in the past, or is it recommended to export/import lists one at a time out of one domain and into another?
Any tips are greatly appreciated!
Jeremy Stanley
On 9/18/24 10:13, Jeremy Stanley wrote:
Since all the lists for the given domain will be moving to the same unused new domain on the existing server, and can move at the same time, I suppose this could be done through (offline if necessary) backend database update queries.
Yes.
For the mailing list, the only changes needed are to the mailinglist table; A query like
UPDATE mailinglist SET mail_host = 'new.domain' WHERE mail_host =
'old_domain';
would do, but this leaves the question of list_id. According to RFC 2919, section 4, the list_id should not change, but this is problematic in that if it isn't changed, a Postorius URL like https://example.com/mailman3/lists/list_name@new.domain will retrieve the list, but https://example.com/mailman3/lists/list_name.new.domain will not work. It would need to be https://example.com/mailman3/lists/list_name.old.domain so to reduce confusion, it may be better to update the list_id values
A query like the following after the above should do it
UPDATE mailinglist SET list_id = CONCAT(list_name, '.', mail_host) WHERE
mail_host = 'new_domain';
For HyperKitty, similar changes need to be made to the
hyperkitty_mailinglist table. The name column entries need to be
changed from listname@old.domain to listname@new.domain and the
list_id column entries need to be changed from listname.old.domain
to listname.new.domain
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 2024-09-18 16:36:50 -0700 (-0700), Mark Sapiro wrote:
On 9/18/24 10:13, Jeremy Stanley wrote: [...]
Since all the lists for the given domain will be moving to the same unused new domain on the existing server, and can move at the same time, I suppose this could be done through (offline if necessary) backend database update queries. [...] For the mailing list, the only changes needed are to the mailinglist table; but this leaves the question of list_id. According to RFC 2919, section 4, the list_id should not change, but this is problematic in that if it isn't changed, [...] so to reduce confusion, it may be better to update the list_id values [...] For HyperKitty, similar changes need to be made to the hyperkitty_mailinglist table. [...]
Thanks! This looks even more straightforward than I'd hoped.
-- Jeremy Stanley
On 2024-09-18 16:36:50 -0700 (-0700), Mark Sapiro wrote:
On 9/18/24 10:13, Jeremy Stanley wrote: [...]
Since all the lists for the given domain will be moving to the same unused new domain on the existing server, and can move at the same time, I suppose this could be done through (offline if necessary) backend database update queries. [...]
UPDATE mailinglist SET mail_host = 'new.domain' WHERE mail_host = 'old_domain';[...]
UPDATE mailinglist SET list_id = CONCAT(list_name, '.', mail_host) WHERE mail_host = 'new_domain';For HyperKitty, similar changes need to be made to the hyperkitty_mailinglist table. The
namecolumn entries need to be changed fromlistname@old.domaintolistname@new.domainand thelist_idcolumn entries need to be changed fromlistname.old.domaintolistname.new.domain
Preparing to test this, I poked around the schema a bit and noticed that the domain names are also embedded as strings in the following fields:
django_mailman3_maildomain.mail_domain
django_site.domain
django_site.name
domain.mail_hostCan anyone think of any additional tables/columns which would need updating for this? I'll see if scanning a dump of the full DB content turns up anything I might be missing too. Thanks again!
-- Jeremy Stanley
On 11/21/24 07:43, Jeremy Stanley wrote:
Preparing to test this, I poked around the schema a bit and noticed that the domain names are also embedded as strings in the following fields:
django_mailman3_maildomain.mail_domain django_site.domain django_site.name
These are all Django things. You can modify those values in the db.
Note that django_site.name is just a name and doesn't need to be the exact domain name.
domain.mail_host
This is Mailman core's domain table. Again, you can modify the value in the db.
Can anyone think of any additional tables/columns which would need updating for this? I'll see if scanning a dump of the full DB content turns up anything I might be missing too. Thanks again!
I don't think there's anything else.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 11/21/24 14:22, Mark Sapiro wrote:
On 11/21/24 07:43, Jeremy Stanley wrote:
Can anyone think of any additional tables/columns which would need updating for this? I'll see if scanning a dump of the full DB content turns up anything I might be missing too. Thanks again!
I don't think there's anything else.
I was thinking of the database, but you need to check all the places where the old domain is mentioned id Django's settings.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 2024-11-21 14:22:27 -0800 (-0800), Mark Sapiro wrote:
On 11/21/24 07:43, Jeremy Stanley wrote:
Preparing to test this, I poked around the schema a bit and noticed that the domain names are also embedded as strings in the following fields:
django_mailman3_maildomain.mail_domain django_site.domain django_site.nameThese are all Django things. You can modify those values in the db.
Note that django_site.name is just a name and doesn't need to be the exact domain name.
domain.mail_hostThis is Mailman core's domain table. Again, you can modify the value in the db.
Yeah, I was planning to address all of those with additional SQL update queries, just wanted to make sure I found all relevant references to the domain name.
Can anyone think of any additional tables/columns which would need updating for this? I'll see if scanning a dump of the full DB content turns up anything I might be missing too. Thanks again!
I don't think there's anything else.
Awesome, thanks again, as always!
Jeremy Stanley
participants (2)
-
Jeremy Stanley -
Mark Sapiro