MAILMAN_ARCHIVER_KEY - 401 error
Hi together,
I just updated one of my servers to Debian 11 and that also introduced mailman3 to the system as I was running mailman 2.1 for years before on that server. It took me a while to configure everything but I am convinced that I now have everything done properly. I am able to access the web interface of mailman3 (postorius) and also the archive (hyperkitty). I configured exim to deal with messages send to the lists. But when I try to send a message (as a member of a list) to a list I always get a 401 in mailman.log and the message that I should check if I provided MAILMAN_ARCHIVER_KEY and if it is correct. So far, I can say that the key is the same in mailman-web.py (with single quotes) and mailman-hyperkitty.cfg (without quotes). in mailman-web.py I have: MAILMAN_ARCHIVER_KEY = 'somesecretkeywithlotsofcharacters' and in mailman-hyperkitty I have this: api_key: somesecretkeywithlotsofcharacters
I have some messages in $var_dir/archives/hyperkitty/spool but mailman qfile <messagefile> doesn't show anything that would catch my eye.
So, maybe I need another pair of eyes that could take a look at my configs or someone that is turning me in the right direction and might give some hints where to look and what to check.
Thanks, Torsten
On 4/12/22 03:33, Torsten R. wrote:
But when I try to send a message (as a member of a list) to a list I always get a 401 in mailman.log and the message that I should check if I provided MAILMAN_ARCHIVER_KEY and if it is correct. So far, I can say that the key is the same in mailman-web.py (with single quotes) and mailman-hyperkitty.cfg (without quotes). in mailman-web.py I have: MAILMAN_ARCHIVER_KEY = 'somesecretkeywithlotsofcharacters' and in mailman-hyperkitty I have this: api_key: somesecretkeywithlotsofcharacters
I have some messages in $var_dir/archives/hyperkitty/spool but mailman qfile <messagefile> doesn't show anything that would catch my eye.
The issue is not related to message content.
One possibility is that there is an incompatibility between mailman-hyperkitty >= 1.2.0 and HyperKitty <= 1.3.4. that could cause this. What are your versions?
What is your setting in mailman-hyperkitty.cfg for base_url:
if you append api/ to that and do something like
curl base_url/api/
it should return a page of documentation of the API. If that is the case, the issue is almost certainly communicating the api key between mailman-hyperkitty and HyperKitty
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
The issue is not related to message content. One possibility is that there is an incompatibility between mailman-hyperkitty >= 1.2.0 and HyperKitty <= 1.3.4. that could cause this. What are your versions? Understood, just wanted to mention that as I read it in another thread about the 401. Hyperkitty is 1.3.4 and mailman-hyperkitty is 1.2.0 What is your setting in mailman-hyperkitty.cfg for base_url:
Mark Sapiro wrote: base_url is set to https://www.fqdn.tld/mailman/hyperkitty
if you append api/ to that and do something like curl base_url/api/ it should return a page of documentation of the API. If that is the case, the issue is almost certainly communicating the api key between mailman-hyperkitty and HyperKitty I get some information back when appending /api/ to that URL mentioned above about REST API and some formats and endpoints. So, from your words it looks like there is some issue in the communication between mailman-hyperkitty and HyperKitty. Is there some place I could/should start looking or some log I should be examining (maybe some loglevel to be increased as well)?
On 4/12/22 13:12, Torsten R. wrote:
Mark Sapiro wrote:
The issue is not related to message content. One possibility is that there is an incompatibility between mailman-hyperkitty >= 1.2.0 and HyperKitty <= 1.3.4. that could cause this. What are your versions? Understood, just wanted to mention that as I read it in another thread about the 401. Hyperkitty is 1.3.4 and mailman-hyperkitty is 1.2.0
Those are incompatible versions. You need to either upgrade HyperKitty
= 1.3.5 or downgrade mailman-hyperkitty to 1.1.0 or install the patch from https://gitlab.com/mailman/hyperkitty/-/merge_requests/369
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
= 1.3.5 or downgrade mailman-hyperkitty to 1.1.0 or install the patch
OK, thanks. That improved the situation. The messages are now archived successfully and can be seen in the web interface of HyperKitty.
The only thing left now seems to be some weird message in the mailman.log telling me that it can't connect to the SMTP server listening on localhost port 25. But I think I will find out why Mailman doesn't want to talk to my mail server.
On 4/12/22 23:54, Torsten R. wrote:
The only thing left now seems to be some weird message in the mailman.log telling me that it can't connect to the SMTP server listening on localhost port 25. But I think I will find out why Mailman doesn't want to talk to my mail server.
This issue sometimes is due to templates that can't be accessed. See https://lists.mailman3.org/archives/search?mlist=mailman-users%40mailman3.org&q=Cannot+connect+to+SMTP+server+localhost+on+port+25
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thank you for the link. It wasn't some templates missing but inaccessible (permission denied). Silly me did the migration part as root not as the mailman user (list on Debian). After I removed the list and created it again and did the migration steps as mailman user everything went fine. I can see now that messages are sent out to the members of the list.
Aah, one last question that came just up. Due to the removal of the list and the recreation there are now some message files with the extension psv in the bad queue. Is it safe to just delete them manually or how should they be treated?
On 4/14/22 06:32, Torsten R. wrote:
Aah, one last question that came just up. Due to the removal of the list and the recreation there are now some message files with the extension psv in the bad queue. Is it safe to just delete them manually or how should they be treated?
These are messages that were queued in some queue, but now can't be dequeued after a few retries. In your case, this is probably due to permissions because of incorrect ownership.
Examine the files with mailman qfile. If you don't want to continue
processing the message, just remove the file. If you do, rename it,
changing the extension from .psv to .pck and change the ownership as
needed - probably from root to mailman, and move the file to the
original queue indicated in the metadata - the second object shown by
mailman qfile.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
참여자 (2)
-
Mark Sapiro -
Torsten R.