[MM3-users] moving lists to another server

bryan.kartzman@yu.edu writes:

I have both my mailman lists and django config in postgres databases.

These are Mailman 3 lists? What Django config? Do you mean Postorius and HyperKitty? Do you intend to use Postorius and HyperKitty on the new server?

If I want to move my lists to another server that is running mailman 3, aside from copying the databases to the other server,

Do you mean the other server is already actively distributing Mailman list traffic, managing users and archives? Or is it fresh instance?

what other things (perhaps all files under /var/lib/mailman3?, etc) would I need to bring over to the other server?

That's going to vary depending on the way your existing server is set up. A Mailman 3 instance is a complex system of cooperating applications. Assuming you have not patched or added any Python code, typical configuration and customizations include

1. Your webserver (Apache, nginx are most common) needs configuration to handle WSGI applications and may need modules enabled or installed for the WSGI server. This is usually installed as an OS distro package, and the configurations will live in /etc/apache2 or similar for another webserver. Depending on other content served by the two hosts you may have to edit the configuration on the new host rather than copy it from the old one.
2. The WSGI server is typically a separate application, although there is an Apache module for this. Gunicorn is a Python application usually installed via pip. I like to keep its Django configuration, which I call gunicorn.conf.py, in /etc/mailman3. (Mailman core also uses gunicorn, but that is transparent to you, it should not need custom configuration.) uwsgi is a C or C++ application normally supplied as a distro package. Don't know where it keeps its config files but since it's a distro package my first guess is /etc/uwsgi.
3. Your MTA, usually Postfix or Exim4, maybe Sendmail or qmail needs to be configured to route mail to Mailman, and apply any milters, signatures, and perhaps anti-yahoo configurations such as ARC.
4. Your database server, usually PostgreSQL or MySQL.
5. Mailman core has a single configuration file mailman.cfg, which I keep in /etc/mailman3. It also has a crontab, which in Debian- derived systems typically lives in the file /etc/cron.d/mailman3. Note that this could be implmented as a systemd timer, but I don't know if any distros do that.
6. Django, Postorius, and HyperKitty together constitute the mailman-web subsystem. I strongly recommend you use the mailmanweb Python package to manage Django and its applications. In any case I am not familiar with other organizations of those packages, so I'm going to assume it. If you are not using mailmanweb, you will need to be careful because most subpackages in the Django subsystem name their configuration files settings.py, urls.py, and views.py just like top-level, and distinguish them by using Python's attribute notation (eg, postorius.urls). a. Django application configuration for Postorius and HyperKitty goes in settings.py, which I put in /etc/mailman3. b. Django site configuration for Postorius and HyperKitty goes in urls.py (the routing configuration mapping URLs to views) and views.py (mapping views to Python code). I put these in /etc/mailmn3. c. Full-text indexing for HyperKitty. Default is Whoosh (a Python application) whose configuration goes in Django's settings.py. I prefer Xapian, which requires a separate application (Debian and Ubuntu have packages), but the needed configuration can be done in the top-level settings.py.
7. Template customization. If you have any customized templates for Mailman's email or Django's views, you'll need to copy and move them too. I haven't customized email, but Django's page templates can be kept separately with a path variable set in settings.py. I put them in a hierarchy under /etc/mailman3/templates. Maybe Mailman core has a similar setting?
8. Transient files. Aside from code and configuration, everything in Django is in the RDBMS, there are be no random files strewn around as far as I know. Mailman core is another matter. You can hope that all Mailman transient files are in its "var" hierarchy. $var_dir (the setting in mailman.cfg or inherited from schema.cfg) is the root of this hierarchy. I set var_dir=/opt/mailman/var, I think Mark may use var_dir=/opt/mailman/mm/var. I would guess that FHS-conformant distros would likely use var_dir=/var/lib/mailman3. a. The queue directories $var_dir/queue/* should be empty. Shut down the incoming mail and let mailman run until it's clear. (Normally takes < 5 seconds.) The exceptions are the shunt and bad queues, which are messages that Mailman doesn't know what to do with. With the venv active, run "mailman unshunt" to attempt to clear the shunt queue. Move anything that's left in shunt as well as any .bak or .tmp files into the bad queue for later treatment. These can be copied to the bad queue in the new instance. Use "mailman qfile <file>" to examine them to see if they can be deleted. b. I think the only stuff that ends up in the $var_dir/lists/* directories are digests being built for later distribution. Use the usual tools to send them off or copy them over to the new instance. c. There should be nothing in $var_dir/archives/hyperkitty/spool, which is temporary storage for messages to be archived. That is, it should get cleared up by the few seconds while incoming mail is stopped and outgoing messages are being processed. If there's anything still there, stash it away for later examination using "mailman qfile". (Don't put it in queue/bad or queue/archive though, this is a different process from the normal pipeline.)

I think that's about it.

Steve