April 2018 - Mailman-users - lists.mailman3.org

Upgrade
by Darren Smith April 16, 2018

April 16, 2018

Hello all, I'm working on upgrading our mailman3 instance. The current running instance is 3.1.0, and I am attempting to move to 3.2.0a1. Partially because La Villa Strangiato is a better song than Between the Wheels, but mostly because we want some of the bug fixes, and we are nailing down our upgrade process for the future. Initially after updating when I ran the "mailman info" command, I got this: Traceback (most recent call last): File "/opt/mailman3/conda/bin/mailman", line 7, in <module> from mailman.bin.mailman import main File "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/bin/mailman.py", line 19, in <module> import click ModuleNotFoundError: No module named 'click' So I went and installed click - easy enough to do. But then I get this error: "Traceback (most recent call last): File "/opt/mailman3/conda/bin/mailman", line 11, in <module> sys.exit(main()) File "/opt/mailman3/conda/lib/python3.6/site-packages/click/core.py", line 722, in __call__ return self.main(*args, **kwargs) File "/opt/mailman3/conda/lib/python3.6/site-packages/click/core.py", line 696, in main with self.make_context(prog_name, args, **extra) as ctx: File "/opt/mailman3/conda/lib/python3.6/site-packages/click/core.py", line 621, in make_context self.parse_args(ctx, args) File "/opt/mailman3/conda/lib/python3.6/site-packages/click/core.py", line 1018, in parse_args rest = Command.parse_args(self, ctx, args) File "/opt/mailman3/conda/lib/python3.6/site-packages/click/core.py", line 880, in parse_args value, args = param.handle_parse_result(ctx, opts, args) File "/opt/mailman3/conda/lib/python3.6/site-packages/click/core.py", line 1404, in handle_parse_result self.callback, ctx, self, value) File "/opt/mailman3/conda/lib/python3.6/site-packages/click/core.py", line 78, in invoke_param_callback return callback(ctx, param, value) File "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/bin/mailman.py", line 93, in initialize_config initialize(value) File "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/core/initialize.py", line 219, in initialize initialize_2(propagate_logs=propagate_logs) File "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/core/initialize.py", line 178, in initialize_2 config.db = getUtility(IDatabaseFactory, utility_name).create() File "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/database/factory.py", line 54, in create database.initialize() File "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/database/base.py", line 107, in initialize url, isolation_level='READ UNCOMMITTED', pool_pre_ping=True) File "/opt/mailman3/conda/lib/python3.6/site-packages/sqlalchemy/engine/__init__.py", line 387, in create_engine return strategy.create(*args, **kwargs) File "/opt/mailman3/conda/lib/python3.6/site-packages/sqlalchemy/engine/strategies.py", line 160, in create engineclass.__name__)) TypeError: Invalid argument(s) 'pool_pre_ping' sent to create_engine(), using configuration PGDialect_psycopg2/QueuePool/Engine. Please check that the keyword arguments are appropriate for this combination of components." Anyone able to point me where to go to look for a solution for this? We're running postgresql as the database, and psycopg2 has been installed. Thoughts? -Darren

2 7

Question regarding serve_from_domain
by Alexander Klotz April 13, 2018

April 13, 2018

Hello, we're currently unsure in which file the serve_from_domain-entry described in the readme.md regarding mailman-web. We just updated the docker and encounter the following error, which might correspond to the missing entry: OSError: [Errno 13] Permission denied: '/opt/mailman-web/fulltext_index' Any help would be appreciated - thanks! -- Regards, Alex Klotz (culturebase editorial staff)

1 0

Starting from scratch
by Benjamin Ragheb April 12, 2018

April 12, 2018

Hello! Over the weekend, I attempted to install the Mailman Suite on Debian Stretch. My goal is to set up some low volume mailing lists for family and friends. I ran into some problems, and I'm hoping to get some feedback on my overall approach before I make my second attempt. :-) I figured the safest thing to do would be to use pip to install the latest released version of all the components (core, postorius, hyperkitty, etc.). I copied the files from the [mailman-suite repository][1] to set up a Django project and got it mostly working with Apache and mod_wsgi. [1]: https://gitlab.com/mailman/mailman-suite Unfortunately, I was unable to log into the web interface; when I tried, I got a server error like this: > Exception Type: TypeError at /accounts/login/ > Exception Value: authenticate() takes exactly 0 arguments (3 given) Some research leads me to believe this is happening because authenticate() was changed in Django 1.10, and so I must be using a newer version of Django than the app expects. Given that I installed via Pip, I assumed the right version of Django would automatically be installed... I'm open to the possibility that I am misunderstanding how Pip works, or that postorius's and/or hyperkitty's dependency information is incorrect. The two alternatives I am weighing right now are: 1. Stay the course, and see if I can fix this by learning more about Python, Pip, Django and tinkering with the configuration. 2. Ride the bleeding edge, and install postorius and hyperkitty from git. (I'll probably stick with Mailman Core from Pip, since that seemed to work just fine.) Right now I'm leaning toward #2, because it means I'll be in a better position to patch things if I need to, and it seems like Mailman 3 is still rough enough that I will need to. Also, it looks like the master branches of both postorius and hyperkitty are now Python 3 compatible, which could save me from managing two different versions of Python. Which is the least crazy option? -- Ben

2 2

Log rotation
by Darren Smith April 11, 2018

April 11, 2018

Hey everyone, So I have a question about log rotation... Our mailman.log has grown to over 5 gigs. It's time to add this to log rotation. We added what we thought might work to the /etc/logrotate.d/mailman script, but when we ran it with a -f, we learned that the -f flag doesn't keep old logs. That in itself is fine - a normal scheduled log rotation won't have that problem. My problem is that doing the rotation caused the mailman not to be able to write to the log anymore. It appears that it no longer has a handle to the file. To overcome this with, say, nginx, there is a command in logrotate that you can add that restarts the service. I have found, however, that restarting the mailman service can be VERY problematic. There is so much going on that it takes a very long time to stop, and I have seen several instances where the service never shuts down cleanly - even after 3-4 minutes. The service thinks it is shut down, but there are several threads that haven't yet completed. If they are killed, then you have to go clean up the master.lck files etc. It seems like a bad way of doing things and a good way to somehow corrupt data. Anyway - after rambling... 1) Has anyone come up with a good log rotation strategy that doesn't necessitate a restart of the service? 2) Has anyone seen problems stopping and restarting the service? Is there a way to help with this problem? Thanks, Darren

3 5

"Approved:" header from mailman2 times
by Dmitry Makovey April 10, 2018

April 10, 2018

Hi, is there any equivalent to "Approved" header that was present in MM2 in MM3 land? Google is not very helpful in that. -- Sr System and DevOps Engineer SoM IRT

3 3

update_index
by Darren Smith April 3, 2018

April 3, 2018

Hello, If I'm reading the docs correctly, when we run manage.py update_index, it should be an incremental index of new emails that have been added since the last time update_index was run - can anyone confirm that this is the expected behavior? Or is there another command line option that I am missing? Right now we are indexing EVERYTHING every time that this is run. Probably this wouldn't be much of a problem except that we are importing all of our old archives (they go back to 1998 and comprise over 40.5 million emails) into the new system. As of now we have around 700,000 emails imported into hyperkitty, and since it is indexing everything it is taking around 1 hour and 10 minutes. Obviously we can't run that once a minute. Right now we're doing once a day, meaning that new emails won't be indexed until the next day. Fast forward to when we have all 40 million imported...the full index process will take (we estimate) around 4 days or so. So...can anyone help with how to get the update_index to do only emails added since the last time the update_index was run? Thanks! Darren

2 4