Error -- postorius Un-handled exception
Hi All,
I've just installed MM3 on a fresh Debian 12 using the Virtualenv method.
(venv)...$ mailman info GNU Mailman 3.3.9 (Tom Sawyer) Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0]
Postorius Version 1.3.10
After creating a couple of lists, the lists are shown in the table on the "Mailing lists" webpage as they should, but clicking on any of the listnames returns an error page:
Something went wrong
HTTP Error 500: {"title": "500 Internal Server Error"}And the Mailman log is a mystery to me, and no error is reported in the Nginx log ...
# tail -f /opt/mailman/web/logs/mailmanweb.log
ERROR 2024-01-24 05:41:46,327 51799 postorius Un-handled exception: HTTP Error 500: {"title": "500 Internal Server Error"} Traceback (most recent call last): File "/opt/mailman/venv/lib/python3.11/site-packages/django/core/handlers/base.py", line 197, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/django/views/generic/base.py", line 103, in view return self.dispatch(request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/postorius/views/generic.py", line 76, in dispatch return super(MailingListView, self).dispatch(request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/django/views/generic/base.py", line 142, in dispatch return handler(request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/postorius/views/list.py", line 359, in get and 'hyperkitty' in archivers # noqa: W504 ^^^^^^^^^^^^^^^^^^^^^^^^^ File "<frozen _collections_abc>", line 780, in __contains__ File "/opt/mailman/venv/lib/python3.11/site-packages/mailmanclient/restbase/base.py", line 146, in __getitem__ return self._get(key) ^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/mailmanclient/restbase/base.py", line 88, in _get return self.rest_data[key] ^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/mailmanclient/restbase/base.py", line 74, in rest_data response, content = self._connection.call(self._url) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/mailmanclient/restbase/connection.py", line 160, in call raise HTTPError(params.get('url'), response.status_code, urllib.error.HTTPError: HTTP Error 500: {"title": "500 Internal Server Error"} ERROR 2024-01-24 05:41:46,333 51799 django.request Internal Server Error: /postorius/lists/testing.example.com/ ERROR 2024-01-24 05:41:46,333 51799 django.request Internal Server Error: /postorius/lists/testing.example.com/
Could anyone steer me in the right direction for fixing this?
Thanks, Mark
Mark writes:
# tail -f /opt/mailman/web/logs/mailmanweb.log
File "/opt/mailman/venv/lib/python3.11/site-packages/mailmanclient/restbase/connection.py", line 160, in call raise HTTPError(params.get('url'), response.status_code, urllib.error.HTTPError: HTTP Error 500: {"title": "500 Internal Server Error"} ERROR 2024-01-24 05:41:46,333 51799 django.request Internal Server Error: /postorius/lists/testing.example.com/
I don't recall seeing this one before, maybe Mark S has some idea.
Try running all the system initializations with "mailman info" and "mailman conf". This often will elicit errors if the system is messed up. More likely to get this error would be "mailman withlist $LIST" (maybe you need an '-l' option to specify the list, I forget). If that doesn't elicit the error, then check that Mailman's runners are running with ps. Since it's Debian, I guess they should be running as the 'list' user. Are Mailman's files and directories owned by 'list' or sometimes 'www-data' for log files?
The log is saying that when Postorius tried to look up that list, it tried to call out to Mailman core via HTTP to the API to get the information and that access failed with HTTP status 500. I think the actual error is likely to be reported in mailman.log (or it might be in error.log, "grep '05:41:46' *.log" in Mailman's log directory will probably find it). I'm pretty sure there will be relevant log entries, probably a matching traceback.
You might also try grepping in your SQL DB logs for that timestamp.
And the Mailman log is a mystery to me,
It's hard to get good exception reporting when you have multiple layers in the stack, and some of them are separated by TCP/IP connections. You'll have to correlate across logs by timestamp.
and no error is reported in the Nginx log ...
Right, this is happening far far away from nginx, much farther down the stack.
Steve
"/opt/mailman/venv/lib/python3.11/site-packages/mailmanclient/restbase/connection.py",
line 160, in call raise HTTPError(params.get('url'), response.status_code, urllib.error.HTTPError: HTTP Error 500: {"title": "500 Internal Server Error"} ERROR 2024-01-24 05:41:46,333 51799 django.request Internal Server Error: /postorius/lists/testing.example.com/
Try running all the system initializations with "mailman info" and "mailman conf". This often will elicit errors if the system is messed up. More likely to get this error would be "mailman withlist $LIST" (maybe you need an '-l' option to specify the list, I forget). If that doesn't elicit the error, then check that Mailman's runners are running with ps. Since it's Debian, I guess they should be running as the 'list' user. Are Mailman's files and directories owned by 'list' or sometimes 'www-data' for log files?
Debian yes, but venv/pip installation so running as "mailman".
The log is saying that when Postorius tried to look up that list, it tried to call out to Mailman core via HTTP to the API to get the information and that access failed with HTTP status 500. I think the actual error is likely to be reported in mailman.log (or it might be in error.log, "grep '05:41:46' *.log" in Mailman's log directory will probably find it). I'm pretty sure there will be relevant log entries, probably a matching traceback.
Hi,
Thank you Steve, Mark, Odhiambo for your responses.
After working my way through your suggestions with no joy I discovered to my embarrassment that I hadn't created the "mailman-hyperkitty.cfg" file. Once created all was well.
This was of course after I had begun the installation process again from scratch. My apologies for the waste of bandwidth and your time.
Regarding my installation, (following the docs at https://docs.mailman3.org/en/latest/install/virtualenv.html) I found a couple of issues that others might also stumble over:
- Installing Xapian needed clang. It didn't like gcc
- Being a fresh Debian 12 OS, I needed to also install make, build-essential
- For the user "mailman" to access the databases I needed to change the owner to mailman (even though all privileges has been granted) ...
postgres=# create database mailman; CREATE DATABASE postgres=# create database mailmanweb; CREATE DATABASE postgres=# create user mailman with encrypted password '<PASSWORD>'; CREATE ROLE postgres=# grant all privileges on database mailman to mailman; GRANT postgres=# grant all privileges on database mailmanweb to mailman; GRANT
psql -d mailman -U mailman -W $ psql -d mailman -U mailman -W Password:
psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL: Peer authentication failed for user "mailman"
sudo -u postgres psql ALTER DATABASE mailman OWNER TO mailman; \q
$ psql -h localhost -d mailman -U mailman -W Password:
psql (15.5 (Debian 15.5-0+deb12u1)) SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off) Type "help" for help.
... and same for mailmanweb
So far, so good.
Thanks and apologies once again, Mark
On Sat, Jan 27, 2024 at 8:17 AM Mark <imark@posteo.net> wrote:
"/opt/mailman/venv/lib/python3.11/site-packages/mailmanclient/restbase/connection.py",
line 160, in call raise HTTPError(params.get('url'), response.status_code, urllib.error.HTTPError: HTTP Error 500: {"title": "500 Internal Server Error"} ERROR 2024-01-24 05:41:46,333 51799 django.request Internal Server Error: /postorius/lists/testing.example.com/
Try running all the system initializations with "mailman info" and "mailman conf". This often will elicit errors if the system is messed up. More likely to get this error would be "mailman withlist $LIST" (maybe you need an '-l' option to specify the list, I forget). If that doesn't elicit the error, then check that Mailman's runners are running with ps. Since it's Debian, I guess they should be running as the 'list' user. Are Mailman's files and directories owned by 'list' or sometimes 'www-data' for log files?
Debian yes, but venv/pip installation so running as "mailman".
The log is saying that when Postorius tried to look up that list, it tried to call out to Mailman core via HTTP to the API to get the information and that access failed with HTTP status 500. I think the actual error is likely to be reported in mailman.log (or it might be in error.log, "grep '05:41:46' *.log" in Mailman's log directory will probably find it). I'm pretty sure there will be relevant log entries, probably a matching traceback.
Hi,
Thank you Steve, Mark, Odhiambo for your responses.
After working my way through your suggestions with no joy I discovered to my embarrassment that I hadn't created the "mailman-hyperkitty.cfg" file. Once created all was well.
This was of course after I had begun the installation process again from scratch. My apologies for the waste of bandwidth and your time.
Regarding my installation, (following the docs at https://docs.mailman3.org/en/latest/install/virtualenv.html) I found a couple of issues that others might also stumble over:
- Installing Xapian needed clang. It didn't like gcc
- Being a fresh Debian 12 OS, I needed to also install make, build-essential
- For the user "mailman" to access the databases I needed to change the owner to mailman (even though all privileges has been granted) ...
postgres=# create database mailman;
CREATE DATABASE postgres=# create database mailmanweb; CREATE DATABASE postgres=# create user mailman with encrypted password '<PASSWORD>'; CREATE ROLE postgres=# grant all privileges on database mailman to mailman; GRANT postgres=# grant all privileges on database mailmanweb to mailman; GRANT
psql -d mailman -U mailman -W $ psql -d mailman -U mailman -W Password:
psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL: Peer authentication failed for user "mailman"
sudo -u postgres psql ALTER DATABASE mailman OWNER TO mailman; \q
$ psql -h localhost -d mailman -U mailman -W Password:
psql (15.5 (Debian 15.5-0+deb12u1)) SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off) Type "help" for help.
... and same for mailmanweb
So far, so good.
Thanks and apologies once again, Mark
The issue you're dealing with in that case is this change in PostgreSQL-15 discussed in this blog: https://www.cybertec-postgresql.com/en/error-permission-denied-schema-public...
I have never needed to do psql -d mailman -U mailman -W.
I used the steps documented above to enable mailman user to write to the
database.
postgres=# \c mailmanweb postgres You are now connected to database "mailmanweb" as user "postgres". mailmanweb=# GRANT ALL ON SCHEMA public TO mailman; GRANT mailmanweb=# \c mailman postgres You are now connected to database "mailman" as user "postgres". mailmanweb=# GRANT ALL ON SCHEMA public TO mailman; GRANT
TBH, I am not sure which method is the best although I think this option is :)
-- 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 Sat, Jan 27, 2024 at 8:17 AM Mark <imark@posteo.net> wrote:
- For the user "mailman" to access the databases I needed to change the owner to mailman (even though all privileges has been granted) ...
On 2024-01-27 18:51, Odhiambo Washington wrote:
The issue you're dealing with in that case is this change in PostgreSQL-15 discussed in this blog: https://www.cybertec-postgresql.com/en/error-permission-denied-schema-public...
I have never needed to do
psql -d mailman -U mailman -W. I used the steps documented above to enable mailman user to write to the database.postgres=# \c mailmanweb postgres You are now connected to database "mailmanweb" as user "postgres". mailmanweb=# GRANT ALL ON SCHEMA public TO mailman; GRANT mailmanweb=# \c mailman postgres You are now connected to database "mailman" as user "postgres". mailmanweb=# GRANT ALL ON SCHEMA public TO mailman; GRANT
TBH, I am not sure which method is the best although I think this option is :)
Thanks for the heads up on that blog Odhiambo.
Agreed. it is a better way of doing it.
--- SNIP --- In PostgreSQL 14 and in prior versions, by default anybody can create a table. The new table will simply end up in the PUBLIC schema. The problem with this approach is that the public schema can quickly turn into a trash can containing all kinds of used and unused tables – which is neither desirable nor recommended. An even bigger problem is security: almost any privilege escalation attack on a PostgreSQL database requires the attacker to create malicious objects. ... The public schema is the perfect vector for such a privilege escalation attack. Therefore PostgreSQL has made a major leap forward and changed this behavior. In version 15, only the database owner can create objects in the public schema.
Odhiambo Washington writes:
The issue you're dealing with in that case is this change in PostgreSQL-15 discussed in this blog: https://www.cybertec-postgresql.com/en/error-permission-denied-schema-public...
Thank you for the reference!
If you have a Mailman-only host, with a Mailman-only PostgreSQL, or The Cabal of equally responsible maintainers are the only people who work on the Postgres cluster, the two approaches are basically equivalent.
My take is that the default "right thing" is to transfer ownership of the 'mailman' database to the 'mailman' user, and use "GRANT ALL ON SCHEMA public TO fred" in the case that you don't want to give "sudo mailman" to Fred.
Rationale: I believe there are a number of things that the 'postgres' user can do that other users cannot, and you probably don't want random contractors or new volunteers to have those privileges. On the principlee that 'postgres' should only do those things that only 'postgres' can do, you want to make the 'mailman' user the owner of the 'mailman' database (and 'mailmanweb' too if you go that route). Then if you have a user 'fred' who may be working on both mailman and non-mailman databases in a session, then instead of giving sudo mailman to Fred, 'mailman' can grant all on schema public in mailman to 'fred'.
It's a really fine difference, and probably will matter to almost nobody running Mailman 3. I do think
user 'mailman' owns the 'mailman' databaseis conceptually simpler than
user 'postgres owns the 'mailman' database and 'mailman' has ALL
privilege on the PUBLIC schemaRight?
Steve
On Sun, Jan 28, 2024 at 11:26 AM Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Odhiambo Washington writes:
The issue you're dealing with in that case is this change in PostgreSQL-15 discussed in this blog:
https://www.cybertec-postgresql.com/en/error-permission-denied-schema-public...
Thank you for the reference!
If you have a Mailman-only host, with a Mailman-only PostgreSQL, or The Cabal of equally responsible maintainers are the only people who work on the Postgres cluster, the two approaches are basically equivalent.
My take is that the default "right thing" is to transfer ownership of the 'mailman' database to the 'mailman' user, and use "GRANT ALL ON SCHEMA public TO fred" in the case that you don't want to give "sudo mailman" to Fred.
Rationale: I believe there are a number of things that the 'postgres' user can do that other users cannot, and you probably don't want random contractors or new volunteers to have those privileges. On the principlee that 'postgres' should only do those things that only 'postgres' can do, you want to make the 'mailman' user the owner of the 'mailman' database (and 'mailmanweb' too if you go that route). Then if you have a user 'fred' who may be working on both mailman and non-mailman databases in a session, then instead of giving sudo mailman to Fred, 'mailman' can grant all on schema public in mailman to 'fred'.
It's a really fine difference, and probably will matter to almost nobody running Mailman 3. I do think
user 'mailman' owns the 'mailman' databaseis conceptually simpler than
user 'postgres owns the 'mailman' database and 'mailman' has ALL privilege on the PUBLIC schemaRight?
Right! That makes more sense.
-- 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]
The issue you're dealing with in that case is this change in PostgreSQL-15 discussed in this blog:
https://www.cybertec-postgresql.com/en/error-permission-denied-schema-public...
If you have a Mailman-only host, with a Mailman-only PostgreSQL, or The Cabal of equally responsible maintainers are the only people who work on the Postgres cluster, the two approaches are basically equivalent.
My take is that the default "right thing" is to transfer ownership of the 'mailman' database to the 'mailman' user, and use "GRANT ALL ON SCHEMA public TO fred" in the case that you don't want to give "sudo mailman" to Fred.
Rationale: I believe there are a number of things that the 'postgres' user can do that other users cannot, and you probably don't want random contractors or new volunteers to have those privileges. On the principlee that 'postgres' should only do those things that only 'postgres' can do, you want to make the 'mailman' user the owner of the 'mailman' database (and 'mailmanweb' too if you go that route). Then if you have a user 'fred' who may be working on both mailman and non-mailman databases in a session, then instead of giving sudo mailman to Fred, 'mailman' can grant all on schema public in mailman to 'fred'.
It's a really fine difference, and probably will matter to almost nobody running Mailman 3. I do think
user 'mailman' owns the 'mailman' databaseis conceptually simpler than
user 'postgres owns the 'mailman' database and 'mailman' has ALL privilege on the PUBLIC schemaRight?
=== From the blog === ...almost any privilege escalation attack on a PostgreSQL database requires the attacker to create malicious objects. ... The public schema is the perfect vector for such a privilege escalation attack. ... In version 15, only the database owner can create objects in the public schema.
The user mailman has its plain text password written into the mailman.cfg file. If that is a potential weakness, would making mailman NOT the owner reduce vulnerability by a degree (in that objects could not be created in the public schema by using mailman's credentials)? Of course I would have a whole world of other problems if those credentials were misused, so I guess it's a bit theoretical anyhow.
Mark writes:
The user mailman has its plain text password written into the mailman.cfg file. If that is a potential weakness,
It is. I may have some answers for that one in a few months (current project has a goal of storing all secrets in a secure vault, so that would mean enabling Mailman 3 to take advantage of such a vault).
would making mailman NOT the owner reduce vulnerability by a degree (in that objects could not be created in the public schema by using mailman's credentials)?
Yes, but I don't really see what attacks that would enable. I guess you could store credit card numbers and malware there almost indetectably, but getting them out still requires host access.
Of course I would have a whole world of other problems if those credentials were misused, so I guess it's a bit theoretical anyhow.
Yes. I can think of many ways to abuse access to the existing data much more easily than how to abuse data that doesn't exist from the point of view of any application on the host. :-)
Mark writes:
After working my way through your suggestions with no joy I discovered to my embarrassment that I hadn't created the "mailman-hyperkitty.cfg" file. Once created all was well.
We really should create a "mailman-lint" utility that checks for things like that.
This was of course after I had begun the installation process again from scratch. My apologies for the waste of bandwidth and your time.
It's not a waste. There are reasons for having these random include files, but they do make configuration more complex, and these stumbles more likely. I did myself in on the postfix-pgsql patch: not using postmap, the postfix.cfg doesn't need a postmap_command setting right? Wrong! "Wasted" my own time there. :-D
Anyway, ask here, somebody probably has done the same before. Maybe it will come up again and you can go, "when I had that error ...." ;-)
couple of issues that others might also stumble over:
- Installing Xapian needed clang. It didn't like gcc
I'm pretty sure that installing Xapian requires the C++ compiler (vendor and version) that was used for the packaged library. With the last year I've definitely compiled a Haystack package for Xapian using GCC, clang didn't work and neither did my existing GCC nor the most recent GCC, I had to look up how Ubuntu had compiled it to find the right version (9.3).
- For the user "mailman" to access the databases I needed to change the owner to mailman (even though all privileges has been granted) ...
Can confirm. This was NOT necessary in November 2022; it is now. Probably a PostgreSQL > 13 thing, but since the change is sane and simple I didn't bother to investigate further.
Steve
Mark wrote:
After working my way through your suggestions with no joy I discovered to my embarrassment that I hadn't created the "mailman-hyperkitty.cfg" file. Once created all was well.
I'm having the exact same error, but I already have a file at "/etc/mailman3/mailman-hyperkitty.cfg".
After systemctl restart mailman3.service mailman3-web.service I'm still getting:
ERROR 2024-04-10 10:19:19,739 104735 postorius Un-handled exception: HTTP Error HTTP Error 500: {"title": "500 Internal Server Error"} File "/opt/mailman/venv/lib/python3.10/site-packages/mailmanclient/restbase/connection.py", line 161, in call raise HTTPError(params.get('url'), response.status_code, urllib.error.HTTPError: HTTP Error 500: {"title": "500 Internal Server Error"} ERROR 2024-04-10 10:19:19,744 104735 django.request Internal Server Error: /mailman3/lists/new_test.domain.tld/ ERROR 2024-04-10 10:19:19,744 104735 django.request Internal Server Error: /mailman3/lists/new_test.domain.tld/ ERROR 2024-04-10 10:19:19,745 104735 django.server "GET /mailman3/lists/new_test.domain.tld/ HTTP/1.0" 500 8667
Anyone have suggestions?
(venv) mailman@mail:~$ GNU Mailman 3.3.9 (Tom Sawyer) Python 3.10.12 (main, Jun 11 2023, 05:26:28) [GCC 11.4.0]
config file: /etc/mailman3/mailman.cfg
On 4/10/24 03:42, admin@bclug.ca wrote:
After
systemctl restart mailman3.service mailman3-web.serviceI'm still getting:ERROR 2024-04-10 10:19:19,739 104735 postorius Un-handled exception: HTTP Error HTTP Error 500: {"title": "500 Internal Server Error"} File "/opt/mailman/venv/lib/python3.10/site-packages/mailmanclient/restbase/connection.py", line 161, in call raise HTTPError(params.get('url'), response.status_code, urllib.error.HTTPError: HTTP Error 500: {"title": "500 Internal Server Error"} ERROR 2024-04-10 10:19:19,744 104735 django.request Internal Server Error: /mailman3/lists/new_test.domain.tld/ ERROR 2024-04-10 10:19:19,744 104735 django.request Internal Server Error: /mailman3/lists/new_test.domain.tld/ ERROR 2024-04-10 10:19:19,745 104735 django.server "GET /mailman3/lists/new_test.domain.tld/ HTTP/1.0" 500 8667
Anyone have suggestions?
What's in var/logs/mailman.log?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
What's in var/logs/mailman.log?
Good question!
2024-04-10 12:42:08 [FALCON] [ERROR] GET /3.1/lists/new_test.domain.tld/arch ivers => Traceback (most recent call last): ... ModuleNotFoundError: No module named 'mailman_hyperkitty'
That has me confused, as the footer says
Powered by HyperKitty version 1.3.9.
On 4/10/24 12:52, admin@bclug.ca wrote:
2024-04-10 12:42:08 [FALCON] [ERROR] GET /3.1/lists/new_test.domain.tld/arch ivers => Traceback (most recent call last): ... ModuleNotFoundError: No module named 'mailman_hyperkitty'
That has me confused, as the footer says
Powered by HyperKitty version 1.3.9.
mailman_hyperkitty is a separate package which is a shim between Mailman core and HyperKitty. In your venv or wherever Mailman is installed, you need
pip install mailman_hyperkitty
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
ModuleNotFoundError: No module named 'mailman_hyperkitty' That has me confused, as the footer says Powered by HyperKitty version 1.3.9. mailman_hyperkitty is a separate package which is a shim between Mailman core and HyperKitty. In your venv or wherever Mailman is installed, you need pip install mailman_hyperkitty
It should be already installed, as it shows in the footer?
(venv) mailman@mail:~$ pip install mailman_hyperkitty Requirement already satisfied: mailman_hyperkitty in ./venv/lib/python3.10/site-pa ckages (1.2.1) ... (venv) mailman@mail:~$
On April 10, 2024 1:15:34 PM PDT, admin@bclug.ca wrote:
It should be already installed, as it shows in the footer?
(venv) mailman@mail:~$ pip install mailman_hyperkitty Requirement already satisfied: mailman_hyperkitty in ./venv/lib/python3.10/site-pa ckages (1.2.1) ... (venv) mailman@mail:~$
I suspect you are not starting the services with your venv active. What's in your mailman3.service and mailman3-web.service files?
-- Mark Sapiro <mark@msapiro.net> Sent from my Not_an_iThing with standards compliant, open source software.
Mark Sapiro wrote on 2024-04-10 14:09:
I suspect you are not starting the services with your venv active. What's in your mailman3.service and mailman3-web.service files?
Thanks for the pointer!
I had my mailman3-web.service starting mailman-web instead of uwsgi
somehow.
I changed that to match the docs, did the systemctl daemon-reload,
etc. but still had similar problems.
I went through all my config files carefully, I wiped the static folder completely and rebuilt it, and I finally have the last piece of the puzzle in place and my web interface is working!
I'm not sure which change actually fixed the issue though.
(When looking at "Available lists" my header has "example.com" in the top-left corner?!?)
Thank you!
I think I need to backup what I have and do a clean re-install so I have a better grasp of what's going on with all these components.
Mailman3 looks quite nice, gotta say!
rb
On 4/11/24 12:59, Ron / BCLUG wrote:
(When looking at "Available lists" my header has "example.com" in the top-left corner?!?)
There are many threads on this in the archives of this list. see for example 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 Thu, Apr 11, 2024 at 11:00 PM Ron / BCLUG <admin@bclug.ca> wrote:
Mark Sapiro wrote on 2024-04-10 14:09:
I suspect you are not starting the services with your venv active. What's in your mailman3.service and mailman3-web.service files?
Thanks for the pointer!
I had my mailman3-web.service starting
mailman-webinstead ofuwsgisomehow.I changed that to match the docs, did the
systemctl daemon-reload, etc. but still had similar problems.I went through all my config files carefully, I wiped the static folder completely and rebuilt it, and I finally have the last piece of the puzzle in place and my web interface is working!
I'm not sure which change actually fixed the issue though.
(When looking at "Available lists" my header has "example.com" in the top-left corner?!?)
See also this: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/... But read it as "example.com", not example.org :-)
I think I need to backup what I have and do a clean re-install so I have
a better grasp of what's going on with all these components.
Way to go! Before I got MM3 working on the sites that I manage, it took me lots of installs and wipes until I could figure out what's going on. I was literally being hand-held by the good developers.
-- 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 1/23/24 21:48, Mark wrote:
And the Mailman log is a mystery to me, and no error is reported in the Nginx log ...
Is there any error and/or traceback reported in /opt/mailman/mm/var/logs/mailman.log?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Wed, Jan 24, 2024 at 8:48 AM Mark <imark@posteo.net> wrote:
Hi All,
I've just installed MM3 on a fresh Debian 12 using the Virtualenv method.
(venv)...$ mailman info GNU Mailman 3.3.9 (Tom Sawyer) Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0]
What is the complete output of this: venv> mailman info
Reduct the passwords.
Also please share the contents of all the files in /etc/mailman3/ - with passwords reducted. I have a Debian 12 setup on a VM (my test platform) and would like to compare your files with mine because it has no difference with what is at https://docs.mailman3.org/en/latest/install/virtualenv.html and all is fine. Well, I use Apache, not Nginx. That's the only deviation.
-- 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]
participants (6)
-
admin＠bclug.ca -
Mark -
Mark Sapiro -
Odhiambo Washington -
Ron / BCLUG
-
Stephen J. Turnbull