All,

I asked Brian to help with the installation of Mailman after I and 2 experts each made attempts and got bogged down in incomprehensible installation instructions and gave up. Brian did it in short order and has been extremely helpful since.

No, he is not paying me for this. No, I have not invested in EMWD. Yes, I just want to recommend a service that is more than worth it.

Happy New Year to all. Especially to the tireless people who have supported Mailman installations for decades, including my own installations. Without you, not many installations would be humming.

Yours,

Allan Hansen hansen@rc.org

On Dec 31, 2020, at 17:28 , Brian Carpenter <brian_carpenter@emwd.com> wrote:

On 12/31/20 8:13 PM, ieso@johnwillson.com wrote:

...

So I've been trying for the last two weeks to get a new mailman3 server running on a virtualized server (any server), and I'm turning to this list after having failed many times and running out of holiday time.

I started trying a non-docker installation on Ubuntu 18.04 (https://docs.google.com/document/d/1xIcSsoNFp2nHi7r4eQys00s9a0k2sHhu1V5Plant...) , which got me the closest. Except I had a problem with inbound email only being triggered when it came from certain accounts. But that clearly wasn't good enough for production, so after many attempts to figure out where it was failing, I decided to turn to docker as a solution that should be cleaner.

A few attempts at doing a docker installation on digitalocean.com failed, which I realized might be due to it not routing private IP addresses, so I moved to AWS after checking that their VPC policy would fit mailman's docker requirements. I found a great but slightly outdated guide on how to do this (https://xiaoxing.us/2018/01/01/deploy-mailman-3-on-aws-using-docker/). By this point I knew enough to correct a number of places where the environment had changed since the procedure was written, but postorius still failed at the curl test.

The challenge for me has been the difficulty to know how to troubleshoot the different different systems and network infrastructure that are used to keep mailman3 humming. I've tried about 7 different installation walkthroughs (there are no recent ones on Youtube by the way, in case anyone wants to seize that opportunity!), and the good guides provide ways to check each stage to try to help you a bit on that front.

Nonetheless, I feel stuck and thought I'd ask the simple question... for a completely basic, barebones new installation, what's the easiest way to get a mailman3 installation up-and running? (e.g. Which server provider? Which operating system and version? Docker or otherwise?)

Any pointers highly appreciated. Google Groups is clearly on its way out, as it no longer allows for people to easily join groups by sending an email or clicking a link, so that should be a big opportunity for mailman3 to step up and help give those mailing list migrants a new home... which is what we're looking for. We're just not quite as smart as you guys. ;-)

---

Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/

If you are looking for commercial assistance, please visit our Mailman 3 hosting site at https://mailmanhost.com (Harmony Lists). Feel free to contact me off list if you have any questions.

For us, we chose Debian 10, Postfix, Nginx, and PostgreSQL as the server environment for Mailman 3. We used PIP via a Python virtual environment to install Mailman 3 from source. The Debian packages I believe have older versions of Mailman 3/Postorius/Hyperkitty which is why we went with source. I have a walk-through that is a work in project at:

https://wiki.list.org/DOC/Howto_Install_Mailman3_On_Debian10

I am available to hire to install Mailman 3 for you if you want to run your own server.

With Harmony Lists, we went a step further with Mailman 3 and created our own custom interfaces: Affinity (admin) and Empathy (forum/archive). However they are only available to our own Mailman 3 clients.

Have a Happy New Year.

-- Brian Carpenter Harmonylists.com Emwd.com

---

Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/

Brian, How do I contact you off list?

Okay, thanks for the feedback, I'll go back to Ubuntu 20.04 and give that a shot with docker. Any guidance on what platform to use (i.e. AWS, DigitalOcean, etc.), if we haven't got access to a dedicated production server?

Hi,

I completed this on a Debian Buster server instance during last year and have got some notes on the process. I decided to go down the venv route rather than use Docker, but I already had it up and running using the Docker instance on another machine. I found getting it up and running on Docker helped me understand how everything hung together, but ultimately I wanted to run it under a venv so I could understand it a bit more and also I wasn't using Docker in the rest of the environment on that server. I also got caught out earlier on with the Docker containers changing the search engine from Woosh to Xapian which is why I wanted more control over what was going on. Here is a copy of those notes for interest.

I used package managers to provide PostgreSQL support as that was what the Docker install gave me to start with. I may have chosen another DB engine but as I was already using Postgres I stuck with that. I also installed Xapian using the package manager as well as Exim, Nginx, Sassc and Python using the package managers. I didn't install Memcached.

I mainly followed the instructions at: https://wiki.list.org/DOC/Mailman%203%20installation%20experience

My directory structure uses /opt/mailman as the base, the instructions on this web page use /opt/mailman/mm and I didn't have this extra subdirectory. I ensured this directory was owned by list:list. I installed my venv under /opt/mailman/venv choosing to copy over the existing distribution installed Python packages and installed the following packages via Pip after activating it:

Upgrade packages that are already installed which need an upgrade to work with Mailman3: pip3 install -U pip zope.interface

Get the rest installed: pip3 install mailman mailmanclient django-mailman3 mailman-hyperkitty hyperkitty postorius psycopg2-binary xapian-haystack

This also installs Gunicorn which I use as the backend wsgi server.

The reason I chose to use existing system packages as part of the venv is because I wanted to use the Xapian installation I had installed via system packages as I ran into issues installing it via Pip. In future I think I will try and install the PostgreSQL driver this way as well.

Once deactivating the venv I recommend getting the directory structure and files copied to the right places from the links on the wiki, noting that in my cases I had to edit the files to change the relevant paths to suit my new layout, and also where necessary (Systemd units) change the user/group. . You should then run all the Mailman specific commands using these scripts in /opt/mailman/bin. I learnt the hard way that you will run into problems if you try and run Mailman from the venv directory as it will look for files in the wrong place and create data files in the wrong directory. As I went down this road my configuration files mailman.cfg and mailman-hyperkitty.cfg are actually located in /opt/mailman/etc but that isn't a requirement if you follow the wiki and use the scripts provided.

I obtained manage.py, settings.py, urls.py and wsgi.py from the Gitlab Mailman-suite project instead of the wiki site to ensure I got the latest versions and put these files in /opt/mailman. Regarding /opt/mailman/bin/mailman-post/update, I removed the references to Memcached as I didn't use it. I also didn't symlink /opt/mailman/logs to /opt/mailman/var/logs as advised by the wiki but will do this on a reinstall.

I generated a new Mailman PostgreSQL user and restored my existing database to the new server (which also upgraded the DB to a newer Postgresql version as the Docker-Compose from the Mailman Docker project uses an older Postgresql container). I copied the Mailman runtime files from the Mailman core container data volume to /opt/mailman/var. I generated a Hyperkitty API secret key and also a Django secret key.

Taking the mailman.cfg file from the wiki as a base, I updated the following parts:

[database] class: mailman.database.postgresql.PostgreSQLDatabase url: postgres://mailman:[password]@localhost/mailmandb

[mailman] site_owner: mailman-owner@lists.domain.com

[mta] incoming: mailman.mta.exim4.LMTP configuration: python:mailman.config.exim4

[archiver.hyperkitty] class: mailman_hyperkitty.Archiver enable: yes configuration: /opt/mailman/etc/mailman-hyperkitty.cfg

In /opt/mailman/etc/mailman-hyperkitty.cfg add the following: [general] base_url: http://localhost:8000/hyperkitty/ api_key: [generated-hyperkitty-api-key]

Using systemctl see if you can start Mailman and observe logs etc.

In terms of the Django stuff you need to create /opt/mailman/settings-local.py which will be read in by the system and will overwrite the default settings in /opt/mailman/settings.py obtained from the Mailman-suite project. This directly configures the Django framework which the Mailman web components Postorius and Hyperkitty run under.

Here is a outline copy of my file:

import os

BASE_DIR = os.path.dirname(os.path.abspath(__file__)) SECRET_KEY = '[generated-django-secret-key]' MAILMAN_ARCHIVER_KEY = '[generated-hyperkitty-api-key]' DEFAULT_FROM_EMAIL = 'mailman-owner@lists.domain.com' EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend' DEBUG = False USE_X_FORWARDED_HOST = True SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')

ALLOWED_HOSTS = [ 'localhost', 'lists.domain.com' ]

INSTALLED_APPS = ( # Copy the installed apps from the settings.py and remove the social provider logins you don't want to support. )

DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql_psycopg2', 'NAME': 'mailmandb', 'USER': 'mailman', 'PASSWORD': '[password]', 'HOST': 'localhost' } }

HAYSTACK_CONNECTIONS = { 'default': { 'PATH': os.path.join(BASE_DIR, "fulltext_index"), 'ENGINE': 'xapian_backend.XapianEngine' }, }

LOGGING = { # Copy the complete LOGGING section from settings.py and change the path as follows, if there is a way of just adding the relevant path override to this file let me know. I am doing this only because I didn't create a symlink for /opt/mailman/logs. 'version': 1, 'disable_existing_loggers': False, 'filters': { [...] } }, 'handlers': { 'mail_admins': { [...] }, 'file':{ 'level': 'INFO', 'class': 'logging.handlers.WatchedFileHandler', 'filename': os.path.join(BASE_DIR, 'var/logs', 'mailmansuite.log'), 'formatter': 'verbose', }, 'console': { [...] }, }, 'loggers': { 'django.request': { [...] }, 'django': { [...] }, 'hyperkitty': { [...] }, 'postorius': { [...] }, }, 'formatters': { 'verbose': { [...] }, 'simple': { [...] }, }, }

Try running /opt/mailman/bin/mailman-post-update and choose to rebuild indexes, see if the static files get saved to /opt/mailman/static and the search indexes get saved to /opt/mailman/fulltext_index. In my case I had plenty of indexing to do, not sure if these files are created on a green-field installation with nothing archived. This command will also populate the Postgresql database schema.

See if the Systemd units for mailman-web and mailman-cluster come up. Observe logs. If everything ok the Gunicorn should be listening on localhost:8000.

For Nginx integration I followed the wiki, only change I had to make was to send the host header to the backend server, here is a partial config file:

server { server_name lists.domain.com; root /var/www/lists; access_log /var/log/nginx/lists-access.log; error_log /var/log/nginx/lists-error.log warn; listen [::]:443 ssl; # managed by Certbot listen 443 ssl; # managed by Certbot ssl_certificate /etc/letsencrypt/live/lists.domain.com/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/lists.domain.com/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

location = /favicon.ico {
    log_not_found off;
}

location = /robots.txt {
    log_not_found off;
}

location / {
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $host;
    proxy_pass http://localhost:8000/;
}

location /static {
    alias /opt/mailman/static;
}

}

server { if ($host = lists.domain.com) { return 301 https://$host$request_uri; } # managed by Certbot

listen 80; listen [::]:80; server_name lists.domain.com; return 404; # managed by Certbot }

For Exim integration I followed to the letter the information here: https://mailman.readthedocs.io/en/latest/src/mailman/docs/mta.html#exim

Here is a Logrotate script which is not in the Mailman wiki:

/opt/mailman/var/logs/*.log { missingok sharedscripts su list list postrotate /opt/mailman/bin/mailman reopen &>/dev/null || true if [ -r /opt/mailman/var/gunicorn.pid ]; then PID=cat /opt/mailman/var/gunicorn.pid kill -s USR1 $PID fi endscript }

I have been running this setup since March 2020, I run around 10 lists on this server with around 10 mails per list per day. I actually had more issues when moving from Mailman2 to Mailman3 using the Docker containers and actually this process made me understand a lot more how everything hangs together and where to troubleshoot issues.

Hope this helps someone out there. Andrew.

-----Original Message----- From: Matthew Alberti <matthew@alberti.us> Sent: 01 January 2021 02:48 To: ieso@johnwillson.com Cc: 'Mailman users' <mailman-users@mailman3.org> Subject: [MM3-users] Re: Easiest way to install a new mailman3 deployment?

I had a very similar experience. I don't mean to knock the dev team; Mailman3 is an awesome  tool that really meets a need. It is really much much more than a 'tool.' A very comprehensive software suite.

For me, I ended up using the docker option on Ubuntu 20.04. My advice is to give up on the idea of using OS package managers. They just aren't current enough (certainly for Ubuntu LTS), or updated frequently enough, for the current development of Mailman3. Nothing but problems for me on Ubuntu, and Debian is about the same.

Pypi, or installation in a virtualized environment, was equally challenging. I strongly recommend the docker installation method. It is not quite turnkey, but the documentation is close enough where it might  'just work' in your environment. I used MariaDB, and that introduced some challenges. If you are using postgre, postfix, and nginx, you are pretty close to a very easy installation.

This list is very supportive, with very frequent responses from the core dev team. And there are guys like me who really struggled to get to a production instance.  Please let us all know what isn't working in the docker approach, and we will try to help I'm sure.

• Matt Alberti

⁣Get BlueMail for Android ​

On Dec 31, 2020, 8:15 PM, at 8:15 PM, ieso@johnwillson.com wrote:

So I've been trying for the last two weeks to get a new mailman3 server running on a virtualized server (any server), and I'm turning to this list after having failed many times and running out of holiday time.

I started trying a non-docker installation on Ubuntu 18.04 (https://docs.google.com/document/d/1xIcSsoNFp2nHi7r4eQys00s9a0k2sHhu1V 5PlantPTs/edit#) , which got me the closest. Except I had a problem with inbound email only being triggered when it came from certain accounts. But that clearly wasn't good enough for production, so after many attempts to figure out where it was failing, I decided to turn to docker as a solution that should be cleaner.

A few attempts at doing a docker installation on digitalocean.com failed, which I realized might be due to it not routing private IP addresses, so I moved to AWS after checking that their VPC policy would fit mailman's docker requirements. I found a great but slightly outdated guide on how to do this (https://xiaoxing.us/2018/01/01/deploy-mailman-3-on-aws-using-docker/). By this point I knew enough to correct a number of places where the environment had changed since the procedure was written, but postorius still failed at the curl test.

The challenge for me has been the difficulty to know how to troubleshoot the different different systems and network infrastructure that are used to keep mailman3 humming. I've tried about 7 different installation walkthroughs (there are no recent ones on Youtube by the way, in case anyone wants to seize that opportunity!), and the good guides provide ways to check each stage to try to help you a bit on that front.

Nonetheless, I feel stuck and thought I'd ask the simple question... for a completely basic, barebones new installation, what's the easiest way to get a mailman3 installation up-and running? (e.g. Which server provider? Which operating system and version? Docker or otherwise?)

Any pointers highly appreciated. Google Groups is clearly on its way out, as it no longer allows for people to easily join groups by sending an email or clicking a link, so that should be a big opportunity for mailman3 to step up and help give those mailing list migrants a new home... which is what we're looking for. We're just not quite as smart as you guys. ;-) _______________________________________________ Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/

Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/

On 1/1/21 2:29 PM, John Willson wrote:

So here's my latest (failed) attempt, to see if anyone can spot where I went wrong. Again, I'm just trying to get a dedicated mailman3 server up from scratch. Oh, I should add that I tried the mailman4 AWS Mailman3-as-SaaS <https://aws.amazon.com/marketplace/pp/New-IT-Mailman-4/B089M2PCVV>, and that worked just fine. However we can't host our data on a SaaS platform, so that's unfortunately not an option for us. I just want to mention it for anyone looking for a "give me mailman services in five minutes for $30/month" solution.

I made it pretty clear we could also install Mailman 3 on your own server.

-- Brian Carpenter Harmonylists.com Emwd.com

ieso@johnwillson.com wrote:

@AndrewH.

Yes, I saw your notes, but the impression I got during this effort is that package-based/non-docker implementations change too much between versions, so anything written based on Ubuntu 16.04 or earlier just didn't feel worth spending significant time on... that impression came from the "this is new to version >18.04" warnings in the Ubuntu 18.04 walkthrough ( https://docs.google.com/document/d/1xIcSsoNFp2nHi7r4eQys00s9a0k2sHhu1V5Plant...). See my comment below for more.

Upgrading for me is just a case of running the relevant Pip commands and running the post-update script. I have done it a number of times. As I have done the installation from scratch I am fairly confident I can move to a newer OS without much hassle and identify where problems may occur. The biggest issue for me is getting modules via Pip and having issues therein. For example when I first did this in March I ran into an issue with a Python module having been upgraded and thus the latest version of a package caused an error which took a while to troubleshoot until I wrote to this list and eventually installed an older version.

@JonathanM

My attempt at doing a DigitalOcean package/non-docker based implementation was frustrating. I found a really detailed walkthrough ( https://docs.google.com/document/d/1xIcSsoNFp2nHi7r4eQys00s9a0k2sHhu1V5Plant...), and after the usual hyperkitty authorization problem solving, it got me to a point where everything looked perfect, based on a glance at the web interface. However, a bizarre collection of errors showed up during QA testing, such as the following:

I think the best point is to give us errors if you encounter them and we can try and troubleshoot specifics rather than giving up altogether, however, see below on the Docker part.

So here's my latest (failed) attempt, to see if anyone can spot where I went wrong. Again, I'm just trying to get a dedicated mailman3 server up from scratch. Oh, I should add that I tried the mailman4 AWS Mailman3-as-SaaS <https://aws.amazon.com/marketplace/pp/New-IT-Mailman-4/B089M2PCVV>, and that >worked just fine. However we can't host our data on a SaaS platform, so that's unfortunately not an option for us. I just want to mention it for anyone looking for a "give me mailman services in five minutes for $30/month" solution.

Regarding this marketplace image this would actually run on your VM but its running as an appliance/turnkey solution so may still not qualify for you. I wouldn't go there anyway because troubleshooting it may be hard and I am a bit suspicious of smaller companies posting to Amazon Marketplace like this as to their long-term support.

Phase 1 - Prepare the AWS instance and MTA

Most of the documentation on the Mailman side talks about running these containers on a dedicated VM with an MTA and front-end web server installed on the VM. If you are using a VM to run the containers then the network 172.19.199.0/24 is assumed to be a backend Docker network which is used to allow the different containers to talk to each other and to allow the front-end web server/MTA to communicate. If it were me doing this with this setup I wouldn't create the VPC with the same subnet as it may cause issues and we don't really care of the VPC subnet details. If you look at the Docker Compose file in the Docker-Mailman repo you can see its creating this 172.19.199.0/24 network as a bridge network and in most cases you wouldn't connect to these containers from anything other than the VM.

A typical traffic flow may look something like the following:

• Inbound SMTP to Exim/Postfix running on the VM (inbound access to port 25 and MX delivery arranged).
• Exim/Postfix knows to relay messages for the Mailman domains to 172.19.199.2 on port 8024 (LMTP).
• Mailman services connects to Postgresql DB on 172.19.199.4.
• Mailman Hyperkitty plugin connects to the Hyperkitty web service on 172.19.199.3:8000 to archive the message.
• Mailman core sends email out to Exim/Postfix server running on 172.19.199.1. What Postfix does with the email (i.e sends out via SES) is not Mailman's concern.
• A user wishing to access the web interface connects to the VM directly on port 80 or preferably 443 with necessary inbound NSG rules defined.
• The front-end web server knows to proxy these requests to 172.19.199.3:8000 (or if the front-end server supports Uwsgi then its 172.19.199.3:8080
• The front-end web server knows that the /static path should be served up locally from the local filesystem /opt/mailman/web/static which the Mailman-web container writes files to when it starts up.

I think its best to continue running these containers from the VM in the above setup, you mention ECS later on in this email but that is going to confuse the issue unless you really want to run the containers under ECS.

[...]

1. Tried to follow the standard directions... .I put most of the relevant files below.

Did you create the necessary /opt/mailman/core and /opt/mailman/web directories on the VM and set perms as detailed in the repo README?

docker-compose.yaml

[...]

services: mailman-core: [...] volumes:

• /opt/mailman/core:/opt/mailman/

/opt/mailman/core (or at least /opt/mailman) on the host VM needs to exist. The container will write files to /opt/mailman which then get persistently written to /opt/mailman/core on the host. One of the files that get written in this way is /opt/mailman/core/var/data/postfix_lmtp and /opt/mailman/core/var/data/postfix_domains which is referred to in your Postfix configuration (see later on).

[...]

maillog has some interesting stuff I'm seeing for the first time. Let me know if this suggests any obvious suspects.

[...]

postfix/qmgr[4351]: error: open /opt/mailman/core/var/data/postfix_domains: No such file or directory

Check this file on the VM and see if it exists (or if parent path exists). If parent /opt/mailman/core doesn't exist create it. If it exists but there is no var directory inside it, check the container stdout logs for errors.

If other directories inside /opt/mailman/core/var (especially logs) look at them for more info.

Thanks. Andrew.

ieso@johnwillson.com writes:

Here's an interesting suggestion I received that I'm going to kick around a bit.. has anyone tried using Ansible to assist the installation process?

https://github.com/rivimey/ansible-mailman3

rivimey is very competent. That would undoubtedly be a good place to start. However, her setup may be more complicated than most folks need (IIRC, she has a multi-homed setup with Mailman core, Postorius, and HyperKitty on three separate IPs on a separate subnet in the DMZ, while Mailman was really designed for three Mailman applications running on the same host, along with the database server and MTA).

I hadn't heard of Ansible before, but it looks perfect for this kind of situation.

By the way: Ansible is not the only such application, but a Friend of Mailman used to work there (I think he's since been transferred elsewhere after they got acquired by RedHat), so if people want to work on this kind of thing, we may have more resources vs. Ansible than say Chef or Puppet.

I'm not sure we want to maintain an Ansible configuration, but I imagine we could stick it in contrib as "an example that works for somebody YMMV unsupported NO WARRANTY". :-)

Steve

On 03/01/2021 15:47, Stephen J. Turnbull wrote:

ieso@johnwillson.com writes:

...

Here's an interesting suggestion I received that I'm going to kick around a bit.. has anyone tried using Ansible to assist the installation process?

https://github.com/rivimey/ansible-mailman3

rivimey is very competent. That would undoubtedly be a good place to start. However, her setup may be more complicated than most folks need (IIRC, she has a multi-homed setup with Mailman core, Postorius, and HyperKitty on three separate IPs on a separate subnet in the DMZ, while Mailman was really designed for three Mailman applications running on the same host, along with the database server and MTA).

Thank you for your compliment.

I have only split mailman in two: mailman-core with the email-related parts, and postorius for the UI. As yet, although Hyperkitty "works", I haven't addressed the fact that mails get archived in folders on the email host and so (for me) hyperkitty can't see them. Ideally, they would be on the postorius/hyperkitty host, or possibly network shared

The Ansible role linked to above includes a lot of options but doesn't impose splitting the components as I've said: it merely enables it.

If anyone wants to further refine the ansible role I am happy to consider updates, especially sorting the archive!

In an earlier post on this thread (that I now see was only sent to ieso@ -- sorry!) I linked to the role I used as a starting point for my work, which does indeed do most of the "simple out-of-the-box" implementation of mailman.

the "ansible-mailman3" role by "natefoo": Mailman 3 installation, configuration, and management for Linux

There are other ansible roles which will install mysql etc as needed. If I didn't need to split the host for mailman3-core from mailman3-web, I think it would have worked out of the box.

...

I hadn't heard of Ansible before, but it looks perfect for this kind of situation.

I'm not sure we want to maintain an Ansible configuration, but I imagine we could stick it in contrib as "an example that works for somebody YMMV unsupported NO WARRANTY". :-)

Ansible is very good at describing deployments and I would definitely suggest investigating it if you are doing that sort of thing. One of the nice parts of Ansible is that you do not have to describe whole hosts - it will happily manage a small part without compromise. Another really nice part is that it requires very little of the host. If Ansible is not to your liking, you may find "Salt" and "Saltstack" an improvement, though for me it was not as good.

Ansible has a role archive in the form of the Ansible Galaxy website; I would suggest simply that Mailman docs mention the role's existence. As an Ansible user, that is where I would look first, so the main point of mentioning it in mailman docs is to let people who don't use Ansible know about it.

Regards,

Ruth

-- Software Manager & Engineer Tel: 01223 414180 Blog: http://www.ivimey.org/blog LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/

I am running this on a test environment - a Debian10 VM.

Postorius comes up and I create a domain. All is fine. Then I create a list and see that the list is created, but there is an error below the message:

Something went wrong HTTP Error 500: <html> <head> <title>Internal Server Error</title> </head> <body> <h1><p>Internal Server Error</p></h1> </body> </html>

mailmansuite.log has the following entry:

INFO 2021-01-06 10:31:48,062 4177 hyperkitty.lib.mailman Imported the new list testlist@mm3.washington.home from Mailman ERROR 2021-01-06 10:31:48,511 4177 postorius Un-handled exception: HTTP Error 500: <html> <head> <title>Internal Server Error</title> </head> <body> <h1><p>Internal Server Error</p></h1>

</body> </html> Traceback (most recent call last): File "/opt/mailman/mm/venv/lib/python3.7/site-packages/django/core/handlers/base.py", line 113, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/django/views/generic/base.py", line 71, in view return self.dispatch(request, *args, **kwargs) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/postorius/views/generic.py", line 74, in dispatch return super(MailingListView, self).dispatch(request, *args, **kwargs) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/django/views/generic/base.py", line 97, in dispatch return handler(request, *args, **kwargs) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/postorius/views/list.py", line 264, in get 'hyperkitty' in self.mailing_list.archivers and # noqa: W504 File "/usr/lib/python3.7/_collections_abc.py", line 666, in __contains__ self[key] File "/opt/mailman/mm/venv/lib/python3.7/site-packages/mailmanclient/restbase/base.py", line 146, in __getitem__ return self._get(key) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/mailmanclient/restbase/base.py", line 88, in _get return self.rest_data[key] File "/opt/mailman/mm/venv/lib/python3.7/site-packages/mailmanclient/restbase/base.py", line 74, in rest_data response, content = self._connection.call(self._url) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/mailmanclient/restbase/connection.py", line 112, in call error_msg, response, None) urllib.error.HTTPError: HTTP Error 500: <html> <head> <title>Internal Server Error</title> </head> <body> <h1><p>Internal Server Error</p></h1>

</body> </html>

ERROR 2021-01-06 10:31:48,529 4177 django.request Internal Server Error: /mm3/mailman3/lists/testlist.mm3.washington.home/ ERROR 2021-01-06 10:31:48,529 4177 django.request Internal Server Error: /mm3/mailman3/lists/testlist.mm3.washington.home/

PS: I could probably have caused the error with some weird operation I did: Initially when postorius comes up, it has the domain - *example.com <http://example.com>*. I am not sure where it gets this. Using MySQL, I dumped the DB and s/ example.com/lists.washington.home/g then re-imported the DB, restarted mailman and apache2. Might that be the issue??? I am relying on https://wiki.list.org/DOC/Howto_Install_Mailman3_On_Debian10 as the guide and where it gets the *example.com <http://example.com> *from still remains a mystery for me. I have blown away everything - except the config files and the scripts mentioned in this guide - twice and re-installed and still get the example.com domain as the default. There must be something obvious I am missing.

-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", grep ^[^#] :-)

On Wed, 6 Jan 2021 at 15:36, Andreas Barth <aba@ayous.org> wrote:

• Odhiambo Washington (odhiambo@gmail.com) [210106 12:12]:

...

PS: I could probably have caused the error with some weird operation I did: Initially when postorius comes up, it has the domain - *example.com <http://example.com>*. I am not sure where it gets this.

example.com is the default domain from django. Renaming that via the django (e.g. mailman3/admin/sites/site/1/change/ ) worked for me quite well (without touching anything in the database by hand).

Hi Andi,

I could be missing something still...

1. At what juncture during the installation do you do this renaming?
2. Where is this directory? On my setup, I have no such directory - but I could be missing something in the install process, maybe..

root@debian10:/opt/mailman# pwd /opt/mailmanroot@debian10:/opt/mailman# *find . -type d -name sites* ./mm/venv/lib/python3.7/site-packages/jedi/third_party/django-stubs/django-stubs/contrib/sites ./mm/venv/lib/python3.7/site-packages/django/contrib/sites

Do you find anything amiss with this HOWTO - https://wiki.list.org/DOC/Howto_Install_Mailman3_On_Debian10 ?? I find the guide rather straight and clear. It's the one I am following - almost to the letter - except for the fact that I am using Apache+mod_wsgi+MySQL+Exim instead.

I have configs in place by the time I run 'mailman info' portion. But then again, when I run this command, I don't like what it prints because I see some reference to sqlite.

As it is, I believe my problem lies elsewhere, not possible to solve with your rename option.

-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", grep ^[^#] :-)

On Wed, 6 Jan 2021 at 21:17, Brian Carpenter <brian_carpenter@emwd.com> wrote:

...

On Wed, 6 Jan 2021 at 15:36, Andreas Barth aba@ayous.org wrote:

...

Odhiambo Washington (odhiambo@gmail.com) [210106 12:12]:PS: I could

Odhiambo Washington wrote: probably have caused the error with some weird operation I

...

...

did: Initially when postorius comes up, it has the domain - example.com http://example.com. I am not sure where it gets this.

example.com is the default domain from django. Renaming that via the django (e.g. mailman3/admin/sites/site/1/change/ ) worked for me quite well (without touching anything in the database by hand). Hi Andi, I could be missing something still...

At what juncture during the installation do you do this renaming? Where is this directory? On my setup, I have no such directory - but I could be missing something in the install process, maybe..

root@debian10:/opt/mailman# pwd /opt/mailmanroot@debian10:/opt/mailman# find . -type d -name sites

./mm/venv/lib/python3.7/site-packages/jedi/third_party/django-stubs/django-stubs/contrib/sites

...

./mm/venv/lib/python3.7/site-packages/django/contrib/sites Do you find anything amiss with this HOWTO - https://wiki.list.org/DOC/Howto_Install_Mailman3_On_Debian10 ?? I find the guide rather straight and clear.

...

It's the one I am following - almost to the letter - except for the fact that I am using Apache+mod_wsgi+MySQL+Exim instead. I have configs in place by the time I run 'mailman info' portion. But

That is my work in progress and thank you for the compliment. then

...

again, when I run this command, I don't like what it prints because I see some reference to sqlite.

Can you paste what the mailman info output is and the contents of your mailman.cfg file?

My mailman.cfg file is below:

[mailman] site_owner: odhiambo@gmail.com layout: here [paths.here] var_dir: /opt/mailman/mm/var [database] class: mailman.database.mysql.MySQLDatabase url: mysql+pymysql://mailman3:XXXXXXX@localhost /mailmansuite?charset=utf8&use_unicode=1 [archiver.hyperkitty] class: mailman_hyperkitty.Archiver enable: yes configuration: /opt/mailman/mm/mailman-hyperkitty.cfg [archiver.prototype] enable: yes [shell] history_file: $var_dir/history.py [mta] verp_confirmations: yes verp_personalized_deliveries: yes verp_delivery_interval: 1 incoming: mailman.mta.exim4.LMTP outgoing: mailman.mta.deliver.deliver lmtp_host: localhost smtp_host: localhost lmtp_port: 8024 smtp_port: 25 configuration: python:mailman.config.exim4 [shell] use_ipython: yes

The output of mailman info is:

mailman@debian10:~$ python3 -m venv /opt/mailman/mm/venv mailman@debian10:~$ source /opt/mailman/mm/venv/bin/activate (venv) mailman@debian10:~$ mailman info GNU Mailman 3.3.2 (Tom Sawyer) Python 3.7.3 (default, Jul 25 2020, 13:03:44) [GCC 8.3.0] config file: /opt/mailman/var/etc/mailman.cfg db url: sqlite:////opt/mailman/var/data/mailman.db *<=== I wonder why it's even referring to sqlite...* devmode: DISABLED REST root url: http://localhost:8001/3.1/ REST credentials: restadmin:restpass

...

As it is, I believe my problem lies elsewhere, not possible to solve with your rename option.

To get rid of example.com, I log into Django, create a new site using the main list domain and note the site id. I then edit the settings_local.py file and change the SITE_ID setting to the new site id of the main list domain. You will need to restart mailman and qcluster I believe after making that change.

I hope you will document this additional step of how to get rid of example.com.

-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", grep ^[^#] :-)