On 1/16/21 6:06 PM, bruce.dubbs@gmail.com wrote:

I am trying to set up Mailman 3 on a new server. So far I have run:

pip3 install Django==3.1.5

This will be a minor issue. django-mailman3 requires Django>=2.0,<3.2; HyperKitty requires Django>=2.2,<3.2, but postorius requires Django>=1.11,<3.1. We really should be more consistent with these requirements, but what this means is

pip3 install postorius

will install Django 3.0.11 alongside Django 3.1.5.

pip3 install Hyperkitty pip3 install mailman pip3 install uwsgi

All that went well. I've been struggling with the configuration though. I am using /etc/mailman.cfg and that seems to be explained in the documentation OK. From there I am confused.

I do have sqlite installed, but the documentation discusses mysql/mariadb and postresql. What are the considerations as to why I would need one of these other DBs?

You can use sqlite, but if you don't already have a mysql/mariadb database on the server, we recommend postgresql for performance and robustness. I personally have had issues with mysql and use postgresql on one production server that uses mysql for other applications.

I think I can follow the instructions to set up postfix.

In the section 'Configure Web Frontend', it discusses setting up the administrator. As I want to put Mailman on /srv/mailman I can create that, but what should the owner/permissions be? Later the docs discuss editing Django's settings.py. Where do I find that file? I'll note here that my experience with python is quite limited and my knowledge of Django is nil.

There should be a 'mailman' user that is the user under which you run things. Don't run things as root.

sudo chown -R mailman:mailman /srv/mailman

For settings.py and some others, see <https://gitlab.com/mailman/mailman-suite/-/tree/master/mailman-suite_project>. The end of settings.py imports from settings_local so you put your local overrides in settings_local.py in the same directory as settings.py

Later in the section 'Set up HyperKitty', it sends me to a page that discusses installing it. I did that with pip3. Then it says to 'Setup your django project'. What django project is that.

Postorius and HyperKitty. See settings.py. These files, settings.py and settings_local.py need to be in a directory that also includes an empty __init__.py so python can import from it and this directory needs to be in the path that Django runs with. This is a shell script I use to run django. It uses a virtualenv, but that isn't necessary. Also my stuff is in /opt/mailman/mm/, but it could just as well be /srv/mailman.

#!/bin/bash . /opt/mailman/mm/venv/bin/activate cd /opt/mailman/mm export PYTHONPATH=/opt/mailman/mm export DJANGO_SETTINGS_MODULE=settings django-admin $@

I would appreciate advice or a pointer to where I can figure this out. Thanks.

There is a work in progress you may find more helpful. See <https://gitlab.com/mailman/mailman-suite-doc/-/merge_requests/55#note_487120699> and the 'Rendered documentation' linked therefrom.

You might also find <https://wiki.list.org/x/17891998> and/or the docs linked from its first paragraph to be helpful.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

• Mark Dadgar (mark@pdc-racing.net) [210117 19:59]:

Do not "just start with sqlite to get it running and then I’ll migrate it to something else down the road.” There is currently no validated way to migrate a mailman3 instance from sqlite to something else, and by “no validated way” what I actually mean is “no one has managed to get this to work, me included.”

I need to disagree to the last part of the sentence because I did it, but my strong recommendation based on expirence is: save the effort, start directly with postgresql. It's not much more work, and migrating is .. well, just don't try or do it.

Andi

• Mark Dadgar (mark@pdc-racing.net) [210117 20:27]:

On Jan 17, 2021, at 11:01 AM, Andreas Barth <aba@ayous.org> wrote:

Did you document it anywhere? I could not find evidence of a successful migration when I looked 6 months ago, including in this list’s archives.

That would be great information for the community, if only as a cautionary tale.

Stop all external connections to your systems for the whole migration.

Loading the database with any of the tools from postgresql in a fresh database, e.g. pgloader.

Setting up another database and dump both databases.

Merge the data from the pgloader-database and structure (sequences etc) from the new database.

Happy fixing of anything not loading into yet another database ( = the actual database), e.g. broken tables - especially the tables with intervals won't load without manual action. And make sure at least this database has encoding UTF8 (and especially not SQL_ASCII). E.g. by adding -E UTF8 to the createdb call. Or call your createcluster with e.g. --locale de_DE.UTF-8. That's recommended also if you start directly with postgresql as backend BTW :)

And then, just look where you get exceptions and keep on fixing until there are no anymore. And continue to look at your logfiles. Reenable connections sometimes during that and see what great exceptions can happen if e.g. lmtp doesn't recognire an list because there are non-ascii characters somewhere and your locale is broken (see above).

Or just avoid all of that and start directly with postgresql.

Regards, Andi