Dear list,
We've encountered an issue with Postorius after migrating from Mailman 2.1. It appears that Postorius is treating email addresses with differing capitalization as distinct user accounts. For example, <markus.grandpre@uni-konstanz.de> and <Markus.Grandpre@uni-konstanz.de> are being recognized as separate identities.
This is causing significant confusion. Users registered with one capitalization pattern are not seeing the list subscriptions and settings that were previously associated with their account (imported from Mailman v2.1) which used a different capitalization.
Is there a known configuration option or method within Postorius (or Mailman 3 itself) to normalize or unify account identification, effectively treating email addresses as case-insensitive for account matching?
We need a solution that ensures users see their correct list memberships regardless of the capitalization they use when logging in or that was used during the original Mailman 2.1 import.
Thank you in advance Markus
-- Markus Ludwig Grandpré Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre, B803, Tel: ++49 7531 88 4342
Markus Grandpré writes:
We've encountered an issue with Postorius after migrating from Mailman 2.1. It appears that Postorius is treating email addresses with differing capitalization as distinct user accounts. For example, <markus.grandpre@uni-konstanz.de> and <Markus.Grandpre@uni-konstanz.de> are being recognized as separate identities.
That's not true on the systems I've worked with most recently -- those will be recognized as duplicate addresses, both at list import time and at login on Postorius. Those are versions Mailman 3.3.9 and 3.3.11, with corresponding Postorius. As far as I can tell the last case- sensitivity bugs were fixed as of Mailman 3.2.1 (released 2019-02-22). Postorius does not appear to have had any case sensitivity bugs (not surprising since Postorius just passes them through to Mailman).
I guess it's possible that this is a Debianism, or there was a temporary regression around 3.3.8.
Is there a known configuration option or method within Postorius (or Mailman 3 itself) to normalize or unify account identification, effectively treating email addresses as case-insensitive for account matching?
There is no such configuration option because Mailman has treated email addresses as case insensitive for quite a while. All I can recommend is an upgrade.
Steve
Hello,
I guess it's possible that this is a Debianism, or there was a temporary regression around 3.3.8.
That is a problem with older versions of django-allauth. Which happens to be used in the mailman3 version of Debian 12.
You can read all the details in this issue: https://github.com/pennersr/django-allauth/issues/3019
At the end of the issue comments you can find the link to a script written by msapiro to fix/workaround this issue.
Regards, Bernhard
Dear Steve, dear list
That's not true on the systems I've worked with most recently -- those will be recognized as duplicate addresses (...)
You are right. I am sorry for this confusion. Please let me correct my initial posting to this list from yesterday, saying:
(...) <markus.grandpre@uni-konstanz.de> and <Markus.Grandpre@uni-konstanz.de> are being recognized as separate identities.
That is not the case. Meanwhile I discovered an error with logging into Postorius when an account is associated with two semantically identical email addresses that differ in their formatting, e.g.,
<markus.grandpre@uni-konstanz.de>
and
<Markus.Grandpre@uni-konstanz.de>.In this case, the user is unable to log in, and I observed the following error message in the log file:
(...) returned more than one EmailAddress -- it returned 2!Here is the complete stack trace of this error:
ERROR 2025-02-10 14:29:55,599 211159 django.request Internal Server Error: /mailman3/accounts/login/ Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 47, in inner response = get_response(request) ^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 181, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line 70, in view return self.dispatch(request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/utils/decorators.py", line 43, in _wrapper return bound_method(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/views/decorators/debug.py", line 89, in sensitive_post_parameters_wrapper return view(request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/views.py", line 149, in dispatch return super(LoginView, self).dispatch(request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/views.py", line 77, in dispatch response = super(RedirectAuthenticatedUserMixin, self).dispatch( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line 98, in dispatch return handler(request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/views.py", line 105, in post response = self.form_valid(form) ^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/views.py", line 162, in form_valid return form.login(self.request, redirect_url=success_url) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/forms.py", line 196, in login ret = perform_login( ^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/utils.py", line 168, in perform_login response = adapter.pre_login(request, user, **hook_kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/adapter.py", line 411, in pre_login if not has_verified_email(user, email): ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/utils.py", line 130, in has_verified_email emailaddress = EmailAddress.objects.get_for_user(user, email) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/managers.py", line 54, in get_for_user ret = self.get(user=user, email__iexact=email) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/db/models/manager.py", line 85, in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/db/models/query.py", line 439, in get raise self.model.MultipleObjectsReturned( allauth.account.models.EmailAddress.MultipleObjectsReturned: get() returned more than one EmailAddress -- it returned 2! ERROR 2025-02-10 14:29:55,599 211159 django.request Internal Server Error: /mailman3/accounts/login/ Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 47, in inner response = get_response(request) ^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 181, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line 70, in view return self.dispatch(request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/utils/decorators.py", line 43, in _wrapper return bound_method(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/views/decorators/debug.py", line 89, in sensitive_post_parameters_wrapper return view(request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/views.py", line 149, in dispatch return super(LoginView, self).dispatch(request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/views.py", line 77, in dispatch response = super(RedirectAuthenticatedUserMixin, self).dispatch( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line 98, in dispatch return handler(request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/views.py", line 105, in post response = self.form_valid(form) ^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/views.py", line 162, in form_valid return form.login(self.request, redirect_url=success_url) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/forms.py", line 196, in login ret = perform_login( ^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/utils.py", line 168, in perform_login response = adapter.pre_login(request, user, **hook_kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/adapter.py", line 411, in pre_login if not has_verified_email(user, email): ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/utils.py", line 130, in has_verified_email emailaddress = EmailAddress.objects.get_for_user(user, email) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/allauth/account/managers.py", line 54, in get_for_user ret = self.get(user=user, email__iexact=email) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/db/models/manager.py", line 85, in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/django/db/models/query.py", line 439, in get raise self.model.MultipleObjectsReturned( allauth.account.models.EmailAddress.MultipleObjectsReturned: get() returned more than one EmailAddress -- it returned 2!
To resolve the issue, the only solution I found was to manually delete the second email address from the database:
mailman3web-prod=> select * from account_emailaddress where user_id = 93; id | email | verified | primary | user_id -----+---------------------------------+----------+---------+--------- 100 | Markus.Grandpre@uni-konstanz.de | t | t | 93 101 | markus.grandpre@uni-konstanz.de | t | f | 93 (2 rows) mailman3web-prod=> delete from account_emailaddress where id = 100; DELETE 1 mailman3web-prod=> select * from account_emailaddress where user_id = 93 ; id | email | verified | primary | user_id -----+---------------------------------+----------+---------+--------- 101 | markus.grandpre@uni-konstanz.de | t | f | 93 (1 row)
Could I have achieved the same deletion using the REST interface?
After the deletion login with <markus.grandpre@uni-konstanz.de> was possible again, and I set the remaining email address as 'primary' using Postorius.
I am not entirely sure how the duplicate email address came into the system. During the data migration from Mailman 2.1 to Mailman 3, an account was created for <markus.grandpre@uni-konstanz.de>. It is most likely that during registration, the user provided <Markus.Grandpre@uni-konstanz.de> as username or email address, which resulted in both variations of the semantically same email address being stored under the same account.
I apologize again for the incorrect information in my initial message to this list. I should have waited until I had a clearer understanding of this issue.
Best regards, Markus
Am 10.02.25 um 15:32 schrieb Stephen J. Turnbull:
Markus Grandpré writes:
We've encountered an issue with Postorius after migrating from Mailman 2.1. It appears that Postorius is treating email addresses with differing capitalization as distinct user accounts. For example, <markus.grandpre@uni-konstanz.de> and <Markus.Grandpre@uni-konstanz.de> are being recognized as separate identities.
That's not true on the systems I've worked with most recently -- those will be recognized as duplicate addresses, both at list import time and at login on Postorius. Those are versions Mailman 3.3.9 and 3.3.11, with corresponding Postorius. As far as I can tell the last case- sensitivity bugs were fixed as of Mailman 3.2.1 (released 2019-02-22). Postorius does not appear to have had any case sensitivity bugs (not surprising since Postorius just passes them through to Mailman).
I guess it's possible that this is a Debianism, or there was a temporary regression around 3.3.8.
Is there a known configuration option or method within Postorius (or Mailman 3 itself) to normalize or unify account identification, effectively treating email addresses as case-insensitive for account matching?
There is no such configuration option because Mailman has treated email addresses as case insensitive for quite a while. All I can recommend is an upgrade.
Steve
-- Markus Ludwig Grandpré Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre, B803, Tel: ++49 7531 88 4342
Markus Grandpré writes:
Dear Steve, dear list
That's not true on the systems I've worked with most recently -- those will be recognized as duplicate addresses (...)
You are right. I am sorry for this confusion. Please let me correct my initial posting to this list from yesterday, saying:
(...) <markus.grandpre@uni-konstanz.de> and <Markus.Grandpre@uni-konstanz.de> are being recognized as separate identities.
That is not the case. Meanwhile I discovered an error with logging into Postorius when an account is associated with two semantically identical email addresses that differ in their formatting, e.g.,
Yes. Apparently this is a problem of a policy difference between Mailman 3 and the Django allauth package, as Bernhard Lichtinger pointed out in <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...>
allauth takes the point of view that the localpart of an email address is the "property" of the provider of the mailbox, and therefore should be taken verbatim by third parties. Mailman takes the more practical point of view that, in practice, almost all providers treat localparts as case insensitive. (Some -- Gmail, grrrrr -- go farther and ignore whole characters such as periods.) The problem is that users treat email addresses as case insensitive, and aren't very careful about using the same case every time. That's why I think the Mailman approach is appropriate.
To resolve the issue, the only solution I found was to manually delete the second email address from the database:
That will work in the short run, but I'm not sure that's a long-term solution. It's not clear to me that allauth won't do the same thing again.
Could I have achieved the same deletion using the REST interface?
I don't know. I would think not. I suspect Mailman code can only find the lowercase version. Mark has a script that looks for such duplicates using psycopg, not mailmanclient, so it accesses the database via the PostgreSQL API, not Mailman's REST API. It deletes any duplicate that is not all-lowercase:
https://github.com/pennersr/django-allauth/issues/3019#issuecomment-24402316...
I am not entirely sure how the duplicate email address came into the system.
allauth did it. It's explained in the issue where Mark's script is attached. It's not very easy to follow the discussion, though. And there's something weird going on because in your stack trace, it appears that allauth is doing a case insensitive database search. So I would just grab the script and run it, in case there are other users with extra addresses that compare equal when comparison is case insensitive.
I apologize again for the incorrect information in my initial message to this list.
No need to apologize. It's extremely complicated. Of course we're happy if you look around and figure out most of it for us!
Steve
On 2/11/25 01:26, Stephen J. Turnbull wrote:
That will work in the short run, but I'm not sure that's a long-term solution. It's not clear to me that allauth won't do the same thing again.
Allauth since 0.62.0 and better since 0.63.0 no longer does this. See https://codeberg.org/allauth/django-allauth/src/branch/main/ChangeLog.rst#se...
Could I have achieved the same deletion using the REST interface?
I don't know. I would think not.
That's correct. The issue is in the account_emailaddress database table which is an allauth table that Mailman core and hence the REST api know nothing about.
Our latest recommendation is django-allauth>=65.4, but that requires changes, see https://gitlab.com/mailman/django-mailman3/-/merge_requests/316 and https://gitlab.com/mailman/mailman-web/-/merge_requests/58 although the changes only affect testing and a deprecation warning.
Also, installing that django-allauth version may result in upgrading Django to a version which doesn't support django-haystack<3.3.0 and may also require manually upgrading django-haystack.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Running Debian 4.19.316-1 Python 3.7.3
I am unable to start mailman core
mailman@lists:~$ /opt/mailman/mm/bin/mailman start Usage: mailman start [OPTIONS] Try 'mailman start -h' for help.
Error: A previous run of GNU Mailman did not exit cleanly (stale_lock). Try using --force mailman@lists:~$
I try using --force and it did not work. So how do I start it?
Bottom line: I would like for Mailman core to start when I reboot the server. How can this be achieved please?
Christian via Mailman-users wrote on 2025-02-12 09:24:
I would like for Mailman core to start when I reboot the server. How can this be achieved please?
# systemctl enable --now mailman3
or:
$ sudo systemctl enable --now mailman3
That command generates an error.
root@lists:~# systemctl enable --now mailman3 Failed to enable unit: Unit file mailman3.service does not exist. root@lists:~#
-----Original Message----- From: Ron / BCLUG <admin@bclug.ca> Sent: Wednesday, February 12, 2025 9:36 AM To: mailman-users@mailman3.org Subject: [MM3-users] Re: Mailman REST API not available. Please start Mailman core.
Christian via Mailman-users wrote on 2025-02-12 09:24:
I would like for Mailman core to start when I reboot the server. How can this be achieved please?
# systemctl enable --now mailman3
or:
$ sudo systemctl enable --now mailman3
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/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/ RMLYRQY6MWAWELSO6226IT2ELPHGCDJ2/
This message sent to csa@web-analysts.net
Christian wrote on 2025-02-12 10:17:
That command generates an error.
root@lists:~# systemctl enable --now mailman3 Failed to enable unit: Unit file mailman3.service does not exist. root@lists:~#
To find the name of the service file, try:
# systemctl list-units | grep -i mailman
Then, enable --now with the resulting service should work.
If there's no service shown in the output of the grep, the docs have
example service / unit files., see:
https://docs.mailman3.org/en/latest/install/virtualenv.html#starting-mailman...
On 2/12/25 09:24, Christian via Mailman-users wrote:
Running Debian 4.19.316-1 Python 3.7.3
I am unable to start mailman core
mailman@lists:~$ /opt/mailman/mm/bin/mailman start Usage: mailman start [OPTIONS] Try 'mailman start -h' for help.
Error: A previous run of GNU Mailman did not exit cleanly (stale_lock). Try using --force mailman@lists:~$
I try using --force and it did not work. So how do I start it?
In Mailman's var/locks directory (maybe /opt/mailman/mm/var/locks/) you will see at least two files. The ones of interest are:
master.lck
master.lck|<host_name>|<pid>|<random_integer>
First verify that pid is not running or if it is, that it's not
Mailman's master process. Then remove all the files from the
var/locks/ directory and Mailman should start.
Bottom line: I would like for Mailman core to start when I reboot the server. How can this be achieved please?
See https://docs.mailman3.org/en/latest/install/virtualenv.html#starting-mailman...
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
That worked.
Now on https://docs.mailman3.org/en/latest/install/virtualenv.html#starting-mailman -automatically it says
"Pay attention to the config file output above and make sure that you see /etc/mailman3/mailman.cfg there. If the config path is different, you should make sure to create a new config file at /etc/mailman3/mailman.cfg and re-run the command."
Well...mailman info yields
GNU Mailman 3.3.5 (Tom Sawyer) Python 3.7.3 (default, Mar 23 2024, 16:12:05) [GCC 8.3.0] config file: /opt/mailman/mm/mailman.cfg db url: postgres://mailman:5DqTHnv8hUQSdd@localhost/mailman devmode: DISABLED REST root url: http://localhost:8001/3.1/ REST credentials: restadmin:restpass
Should I create a new config file at /etc/mailman3/mailman.cfg ?
Lastly, when I ran this command it says "loaded failed failed"
(venv) mailman@lists:/opt/mailman/mm$ systemctl list-units | grep -i mailman gunicorn.service loaded active running GNU Mailman web interfaces ● mailman.service loaded failed failed GNU Mailing List Manager
Please advise. Thank you.
-----Original Message----- From: Mark Sapiro <mark@msapiro.net> Sent: Wednesday, February 12, 2025 10:33 AM To: mailman-users@mailman3.org Subject: [MM3-users] Re: Mailman REST API not available. Please start Mailman core.
On 2/12/25 09:24, Christian via Mailman-users wrote:
Running Debian 4.19.316-1 Python 3.7.3
I am unable to start mailman core
mailman@lists:~$ /opt/mailman/mm/bin/mailman start Usage: mailman start [OPTIONS] Try 'mailman start -h' for help.
Error: A previous run of GNU Mailman did not exit cleanly (stale_lock). Try using --force mailman@lists:~$
I try using --force and it did not work. So how do I start it?
In Mailman's var/locks directory (maybe /opt/mailman/mm/var/locks/) you will see at least two files. The ones of interest are:
master.lck
master.lck|<host_name>|<pid>|<random_integer>
First verify that pid is not running or if it is, that it's not Mailman's
master process. Then remove all the files from the var/locks/ directory
and Mailman should start.
Bottom line: I would like for Mailman core to start when I reboot the server. How can this be achieved please?
See https://docs.mailman3.org/en/latest/install/virtualenv.html#starting-mailman -automatically
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/ LV5WTFTNRZ455KPDESRQHFV67SJ5VOFH/
This message sent to csa@web-analysts.net
On Wed, Feb 12, 2025 at 11:05 PM Christian via Mailman-users < mailman-users@mailman3.org> wrote:
That worked.
Now on
https://docs.mailman3.org/en/latest/install/virtualenv.html#starting-mailman -automatically <https://docs.mailman3.org/en/latest/install/virtualenv.html#starting-mailman...> it says
"Pay attention to the config file output above and make sure that you see /etc/mailman3/mailman.cfg there. If the config path is different, you should make sure to create a new config file at /etc/mailman3/mailman.cfg and re-run the command."
Well...mailman info yields
GNU Mailman 3.3.5 (Tom Sawyer) Python 3.7.3 (default, Mar 23 2024, 16:12:05) [GCC 8.3.0] config file: /opt/mailman/mm/mailman.cfg db url: postgres://mailman:5DqTHnv8hUQSdd@localhost/mailman devmode: DISABLED REST root url: http://localhost:8001/3.1/ REST credentials: restadmin:restpass
Should I create a new config file at /etc/mailman3/mailman.cfg ?
Lastly, when I ran this command it says "loaded failed failed"
(venv) mailman@lists:/opt/mailman/mm$ systemctl list-units | grep -i mailman gunicorn.service loaded active running GNU Mailman web interfaces ● mailman.service loaded failed failed GNU Mailing List Manager
Please advise. Thank you.
rm -rf /opt/mailman mkdir /opt/mailman chown mailman:mailman /opt/mailman chmod 755 /opt/mailman sudo su mailman cd pwd [should show that you are in /opt/mailman]
Start over again from there.
'mailman info' ideally should say the config file is in /etc/mailman3/mailman.cfg If you follow the manual to the letter, you should have mailman3.service as the filename as per https://docs.mailman3.org/en/latest/install/virtualenv.html#starting-mailman... .
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
On 2/12/25 12:17, Odhiambo Washington via Mailman-users wrote:
rm -rf /opt/mailman mkdir /opt/mailman chown mailman:mailman /opt/mailman chmod 755 /opt/mailman sudo su mailman cd pwd [should show that you are in /opt/mailman]
Start over again from there.
But if you currently have a working Mailman installation, maybe even a Debian package, and you don't want to start over from scratch, especially because you have Python 3.7.3 and current Mailman requires Python >=3.9,<=3.12, just see <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...>
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 2/12/25 12:05, Christian via Mailman-users wrote:
That worked.
Now on https://docs.mailman3.org/en/latest/install/virtualenv.html#starting-mailman -automatically it says
"Pay attention to the config file output above and make sure that you see /etc/mailman3/mailman.cfg there. If the config path is different, you should make sure to create a new config file at /etc/mailman3/mailman.cfg and re-run the command."
Well...mailman info yields
GNU Mailman 3.3.5 (Tom Sawyer) Python 3.7.3 (default, Mar 23 2024, 16:12:05) [GCC 8.3.0] config file: /opt/mailman/mm/mailman.cfg db url: postgres://mailman:5DqTHnv8hUQSdd@localhost/mailman devmode: DISABLED REST root url: http://localhost:8001/3.1/ REST credentials: restadmin:restpass
Should I create a new config file at /etc/mailman3/mailman.cfg ?
You can, but the easiest thing is just replace the line
Environment="MAILMAN_CONFIG_FILE=/etc/mailman3/mailman.cfg"
in /etc/systemd/system/mailman3.service with
Environment="MAILMAN_CONFIG_FILE=/opt/mailman/mm/mailman.cfg"
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
I followed instructions provided here. Well, I rebooted the server and I'm getting the same error again at the web page of
"Mailman REST API not available. Please start Mailman core."
I again found locks in /opt/mailman/mm/var/locks . Once I removed them I could start mailman.
Perhaps I made a boo boo. I want mailman to start without locks upon reboot.
Help! (thanks)
-----Original Message----- From: Mark Sapiro <mark@msapiro.net> Sent: Wednesday, February 12, 2025 1:12 PM To: mailman-users@mailman3.org Subject: [MM3-users] Re: Mailman REST API not available. Please start Mailman core.
On 2/12/25 12:05, Christian via Mailman-users wrote:
That worked.
Now on https://docs.mailman3.org/en/latest/install/virtualenv.html#starting-m ailman -automatically it says
"Pay attention to the config file output above and make sure that you see /etc/mailman3/mailman.cfg there. If the config path is different, you should make sure to create a new config file at /etc/mailman3/mailman.cfg and re-run the command."
Well...mailman info yields
GNU Mailman 3.3.5 (Tom Sawyer) Python 3.7.3 (default, Mar 23 2024, 16:12:05) [GCC 8.3.0] config file: /opt/mailman/mm/mailman.cfg db url: postgres://mailman:5DqTHnv8hUQSdd@localhost/mailman devmode: DISABLED REST root url: http://localhost:8001/3.1/ REST credentials: restadmin:restpass
Should I create a new config file at /etc/mailman3/mailman.cfg ?
You can, but the easiest thing is just replace the line
Environment="MAILMAN_CONFIG_FILE=/etc/mailman3/mailman.cfg"
in /etc/systemd/system/mailman3.service with
Environment="MAILMAN_CONFIG_FILE=/opt/mailman/mm/mailman.cfg"
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/ NYAIOPZ3PLQCPT3QPLLRKMOUY52UORBM/
This message sent to csa@web-analysts.net
On 2/12/25 15:39, Christian via Mailman-users wrote:
I followed instructions provided here. Well, I rebooted the server and I'm getting the same error again at the web page of
"Mailman REST API not available. Please start Mailman core."
I again found locks in /opt/mailman/mm/var/locks . Once I removed them I could start mailman.
Perhaps I made a boo boo. I want mailman to start without locks upon reboot.
If Mailman is properly shut down, it shouldn't leave locks.
How did you reboot? If your /etc/systemd/system/mailman3.service file
contains an appropriate ExecStop, reboot via a reboot or shutdown -r
should stop Mailman appropriately.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (8)
-
'Ron / BCLUG' -
Christian -
Lichtinger, Bernhard -
Mark Sapiro -
Markus Grandpré -
Odhiambo Washington -
Ron / BCLUG
-
Stephen J. Turnbull