Hi Mark & all,
Thanks for the response. Just picking up where we are at the moment to provide a bit more info, in case you have ideas. Thanks, Stephen T. as well for the idea of turning on DEBUG. We might resort to that in the end.
This is what our system is running right now:
Mailman Core Version GNU Mailman 3.3.9 (Tom Sawyer) Mailman Core API Version 3.1 Mailman Core Python Version 3.10.12 (main, Jun 11 2023, 05:26:28) [GCC 11.4.0]
As previously noted, we moved this off of an old Ubuntu package-based installation that has delivered mail reliably but many other things haven't worked well, so we're happy to be on something that might improve that situation.
Right now, archiving is not working on the new installation, both building the archive on the new installation after the move and for new messages.
uwsgi-error.log is getting blasted with constant errors along the lines of what follows. I suspect that these errors are why archiving isn't working, but I obviously don't know that:
Message: BadSignature('Signature "ZWBXqQmWZwHTfa390lLIacpp8NQ" does not match') Arguments: ('Traceback (most recent call last): File "/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py", line 356, in pusher task = SignedPackage.loads(task[1]) File "/local/mailman/venv/lib/python3.10/site-packages/django_q/signing.py", line 25, in loads return signing.loads( File "/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py", line 35, in loads base64d = force_bytes(TimestampSigner(key, salt=salt).unsign(s, max_age=max_age)) File "/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py", line 70, in unsign result = super(TimestampSigner, self).unsign(value) File "/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py", line 55, in unsign raise BadSignature(\'Signature "%s" does not match\' % sig) django.core.signing.BadSignature: Signature "ZWBXqQmWZwHTfa390lLIacpp8NQ" does not match',)
What we have in our config files on the old installation and new installation are (the quotes are exactly as they are in the files):
Old installation:
mailman-web.py
SECRET_KEY = 'somerandomstringiaintputtinginmail' MAILMAN_ARCHIVER_KEY = 'somerandomstringiaintputtinginmail'
mailman-hyperkitty.cfg
api_key: somerandomstringiaintputtinginmail
New installation:
settings.py
SECRET_KEY = 'somerandomstringiaintputtinginmail' MAILMAN_ARCHIVER_KEY = 'somerandomstringiaintputtinginmail'
mailman-hyperkitty.cfg
api_key: somerandomstringiaintputtinginmail
All of that says that the value is the same for all three (whether I should have done so or not...) and those settings were carried along to the new installation as well.
Django is a big scary beast as I've not had to manage django apps before. Would it make sense that the error above is because what I _think_ django believes is the SECRET_KEY (in the config files above) is in fact not what django believes? Maybe it was set during installation (which I didn't do)? I don't believe anyone has purposefully changed it.
I suppose I could do something like https://medium.com/django-unleashed/securing-django-applications-best-practi... to reset the secret key, but I'm not doing that on Friday afternoon :)
If anyone has other thoughts, please holler. Wishing you all a good weekend from lighter-by-the-day Sweden.
Cheers,
David
-----Original Message----- From: Mark Sapiro <mark@msapiro.net<mailto:Mark%20Sapiro%20%3cmark@msapiro.net%3e>> To: mailman-users@mailman3.org<mailto:mailman-users@mailman3.org> Subject: [MM3-users] Re: Badsignature on uwsgi-error.log Date: Wed, 20 Mar 2024 18:12:20 -0700
On 3/20/24 14:25, Helio Loureiro wrote: Hi,
I keep receiving a lot of errors like this:
--- Logging error --- Traceback (most recent call last): ... "/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py", line 55, in unsign raise BadSignature('Signature "%s" does not match' % sig) django.core.signing.BadSignature: Signature "F6V0Dr_SvBsx5-cY8vcvLXrX8tA" does not match ...
The api_key on mailman-hypperkitty.cfg, SECRET_KEY and MAILMAN_ARCHIVE_KEY on setting.py are the same.
Of those three, the api_key on mailman-hypperkitty.cfg and MAILMAN_ARCHIVE_KEY must match. SECRET_KEY is different. It is a Django thing and has nothing to do with the others. See https://docs.djangoproject.com/en/5.0/ref/settings/#secret-key
If you changed it, that's the issue. If you know what it was previously, you could set the previous value in SECRET_KEY_FALLBACKS, see https://docs.djangoproject.com/en/5.0/ref/settings/#secret-key-fallbacks