Wikinaut writes:
I fully understand. Need to look up how to smoothly backup the mailman3 settings and list databases in order to make that move with losing stuff... (kinda "mailman3 backup all" and mailman3 restore all" :-)
One piece of generic Python advice: don't mix OS packages and pip (except for Python itself). Always use a venv if you need to use pip for packages that aren't in your OS distro. (Of course it's possible to do so in many cases if you *really* know what you're doing, but it's almost never worth the pain.)
All of the site configuration data should be in /etc/mailman3 (except for a few template files in $var_dir/templates), and all of the domain, list configuration, and archive data is in the RDBMS (usually PostgreSQL or MySQL). The RDMBS should be backed up regularly according to its procedures, but that's completely out of scope for Mailman.[1] The RDBMS should "just work" with exactly the same Mailman-side configuration as Debian.[2]
As I think Odhiambo mentioned, the Mailman side of the site configuration also does not change (for example, the RDBMS URL and authentication). What you do want to change is the file system configuration. Except for /etc/mailman3, it should be completely different -- as with pip'ing packages, you don't want to share files across a local venv and the OS version of the same package. It just leads to pain.
I think among the developers the preferred root = /opt/mailman (or
/opt/mailman3) for Mailman's directory hierarchy. This will be
populated with subdirectories when you run mailman info (or start
Mailman) the first time. The directories relevant to configuration
are all under $root/var, and you inform Mailman about this by setting
var_dir in mailman.cfg. If there are other file and directory
configurations in mailman.cfg, they need to changed from the Debian
values (probably /var/lib/mailman3/...). You may do fine by simply
deleting all other directory configurations and let Mailman decide
where to put them relative to the var_dir,
You will need to fix the setting for STATIC_ROOT (I think that's the name, if not search for "static") in settings.py, and maybe in mailman-web.cfg. While it's not necessary (and may be a little inconvenient), I recommend changing the root for Mailman's log files from the Debian value (probably /var/log/mailman3) to the Mailman default of $root/var/logs, and similarly for the Django logs in settings.py.
Non-Mailman settings
I think you will need to change the settings for your MTA (usually Postfix or Exim4) so that it will recognize Mailman lists and route them to Mailman correctly. There will probably be mailman-related files in /etc/$MTA/conf.d (or something like that). You can edit them directly, but I recommend changing the name (paranoia so that dpkg doesn't overwrite them).
The only thing I can think of for the webserver (Apache?) is the location of the static directory. I think Debian uses uwsgi by default so you may need to adjust its configuration too.
I think you need to fix logrotate's configuration in /etc/logrotate.d. Not sure how many mailman-related config files are in there.
I think you mentioned systemd .service files. If so that doesn't make
sense to me -- Debian should provide those. You need to make sure
those are disabled or deleted so that Debian Mailman services don't
start on reboot. This is automatic if you delete the Debian packages,
of course, but not for any files you created yourself. Probably the
Debian .service files will work, but you need to make sure they refer
to the venv Mailman (using the full path to the mailman utility in
the venv's bin directory will work, and similarly for mailman-web).
systemd does not configure the /opt hierarchy in it search path by
default. I put the mailman, qcluster, and gunicorn (if you use that
instead of uwsgi) .service files in /usr/local/lib/systemd/system, and
that works for me.
Flotsam and jetsam
If you have run Mailman with any success at all, you may find some
stuff in Debian's $var_dir/queue/* directories or in its
$var_dir/lists/* directories. The queue/* directories contain
incoming messages at various stages of processing, and the lists/*
directories contain files containing multiple messages that are
scheduled to be sent out as digests. You can read the queue files
with mailman qfile /path/to/queue/file.pck, and the digests are just
text files. That way you can check if there's anything important in
them. If not, you can just delete them. If there is, you can just
copy them to the same place in the venv $var_dir as they were in
Debian's $var_dir, but you may want to ask here first before doing
that. It's best to let Mailman run until all the queues are cleared
(except maybe bad and shunt, but if those have any files in them you
need to intervene anyway).
Afterword
I'm sure this sounds complicated, but in fact it's a pretty short list. When you get there we'll help you.
Footnotes: [1] But not for this list. You may as well ask here, somebody probably will tell you the basics quickly. But for troubleshooting, go the the RDBMS's own channels.
[2] In fact, it is possible to keep the Debian installation, copy the the mailman.cfg somewhere, edit it, stop Debian Mailman, and start up the venv Mailman. I don't recommend this -- the point is that the venv and the databases are that isolated from the rest of the system.