On Sat, Nov 18, 2023 at 11:48 AM Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Odhiambo Washington writes:
Hello Stephen et al,
Since this topic is relevant to something I am faced with at the moment, I believe it's okay if I piggyback on the thread.
I think continuing the thread is appropriate, but I personally would change the Subject to reflect the specifics.
I have a server that is already actively distributing Mailman list traffic, and managing users and archives. I have offered to take over another community ML (also using MM3) from another server and host the list on my server. I am scratching my head bald trying to figure out how to bring in this other MM3 site and list into my existing server, especially with regard to the DB backend.
The list - let's call it users@domainX.name was using MySQL backend and had a separate DB for Mailman core and Mailman web. I believe combining these into one isn't a problem. But getting to merge this DB into my current one is what I am not sure about.
Any pointers on how to bring in this new site into my current setup??
I don't have pointers, in the sense of concrete advice I would not be horrified if you followed it to the letter. Here's how I would attack the problem.
Decide the List-Id and List-Post questions. I disagree with Mark about List-Id (or maybe he mistyped List-Post?) -- the List-Id should NOT be changed. I don't know how many users are taking advantage of List-Id (my filters do!), but they will thank you for keeping it the same.
The List-Post question is contingent. Will you be serving their domain, or will you change the List-Post address?
The idea is to (if possible) not change anything at all. I will be serving the list using the original domain. I am hoping for a seamless migration where no one notices any change except for the IP address where the MM3 is running.
Note that with some additional configuration to Mailman and your MTA they could set up a forwarding configuration for their lists to your server, Or if they don't have other email needs, set up an MX. Or they can transfer their domain name's A and MX records to your host.
As it is, I have been given full control of the domain for this purpose so I can point A and MX records to my server. The ML itself is currently down. I have a dump of the /opt/mailman as well as the DBs used by Core and Web.
Alternatively you can change the List-Post address.to yourdomain. In that case you will have to edit the List-Post address in your database.
I am hoping that should not be necessary. I actually had thought it wouldn't be complex doing this until I sat down and said wait - there is a DB involved :)
- There are similar issues for mailman-web (especially host names). I have not thought about them at all, so I'll leave that for the interested reader. ;-)
Hehee.. Wrapping my head around this has not been easy, to say the least.
- (If the DB engines are different) Dump both databases in text
format (ie, scripts of SQL commands). Check to see how they differ.
The DB is MySQL. My running setup uses MariaDB. I am not getting what you mean here by how they differ.
- Adapt the foreign database to its new environment with search and
replace. (Be verbose about the search terms, include lots of context to minimize the chance of inadvertantly replacing something in the wrong context that you missed in step 3.) This is where you would change the List-Post address, as well. You will also want to change the 'mailmanweb' database to just 'mailman'.
If going with what I have mentioned above, is this step still necessary?
- (Optional if your name is "Daredevil") Create a new Mailman suite install using your current configs, preferably in a new VM or set of containers. Configure the MTA to save all outgoing mail to a file, or maybe firewall off outgoing network traffic to port 25 and leave all the posts in the MTA queues. Create a new 'mailman-test' database. Copy all the dumps to the VM, and edit the names of the databases in the SQL to 'mailman-test'. Restore the dump of your system into the database, and test. Then do the same, restoring the mailman and mailmanweb databases from the foreign system into this new database.
I was thinking about this as one way of testing the situation, much as it is quite involving.
- Adjust to address any issues discovered in 5. If none, go to 7,
Otherwise go back to 5.
- Apply any changes made in 6 to your configs, and read the foreign dumps into your system, and you should be ready to go for the distribution part. Not sure about host and webserver configuration for mailman-web, though.
Suppose I just do: that I am yet to understand here around SITE_ID when you have multiple
- Create the new list on my server using the inherited domain and configure it appropriately,
- Configure Django to handle the different domains (there is something
sites!) 3. Extract the users from the list and subscribe them afresh (I can shoot an email to let them know the ML had to be moved so they can set their preferences again) 4. Import the archives of the list I should more or less achieve the migration, no?
What about setting up on /opt/mailman2 a complete replica of the list? That'd be the real "Daredevil" :)
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]