ieso@johnwillson.com writes:
For our purposes, it replaces "how to install mailman3" guides with a single script that aims to actually do the entire thing for you.
If a single script would work, we'd have one already, I'm pretty sure. The problem is that a large proportion (I'm tempted to say "almost all" ;-) Mailman 3 installations need to fit in to an existing system configuration or pre-conceived design. I'd say that that the "standard" Mailman stack is:
- Intel server box (not a VM)
- Linux kernel
- any distro
- Postfix MTA
- Apache webserver with wsgi module enabled
- PostgreSQL database manager
- Python 3 >= 3.6
- Mailman core
- Postorius
- HyperKitty
- All the above on a single host with a single public IP address and canonical domain.
So 2 and 7 brook no controversy (2 because you can't argue with "anything goes", and 7 because, well, if you're arguing about 7, you're not ready to install Mailman nohow!) But every single one of the rest of those is *very* debatable -- there are already people using all of the options mentioned below (and more) in production. VMs and containers are frequently used for 0, BSDs (including MacOS) are fine for 1, Exim4 and Sendmail have varying degrees of support already for 3 (and I'll bet there are people running qmail), people do use other webservers such as nginx for 4, aside from PostgreSQL there are the MyQSL databases that are supported and some crazy folks will try to use SQLite or Oracle in production for 5, Postorius is optional and there is a commercial alternative that is used in production in a hosting service and may eventually be available for installation on your own host for 8, ditto 8 for 9 and there are yet other options such as mailarchive.com, and for 10, some people for either security or performance reasons or both want a multihomed system.
So there are a minimum of 3 MTAs * 3 production-ready RDBMSes (my understanding is that there are Mailman config tweaks for standard MySQL that MariaDB doesn't need or vice-versa) to deal with, and possibly some optional options we'd like to deal with. The alternative is to say: here's the deal, spin up a Linux VM and run this script ... but that's basically what Abhilash's Docker install is (except the obvious that container != VM) -- and even that requires tweaks that are less than obvious to a lot of people to get the necessary network connectivity.
So I don't see Ansible (or any such system) as a panacea. Rather, I see it as a standard language that might help us in systematically tracking variables in provisioning Mailman systems. One Ansible role would be a useful reference, and if that grows into a family of roles that are easy to compare and implement "turn-key" Mailman 3 installations for a ton of users, that would be great. That's my motivation for encouraging research into it. Now, I could be wrong -- Ansible could be more powerful than I'm giving it credit for, or that "standard" configuration might not be merely what several Mailman core devs run, it might actually be the majority of systems new to Mailman. In that case just one script would be a major contribution. So don't let me discourage anybody. But do be aware that you probably do have to make a choice between a quagmire of options and mandating a particular stack (or small set of them) for simplicity.