On 9/8/21 17:56, Richard Rosner wrote:

...

I don't use uwsgi and know little about it so I don't know what the Unix domain socket /run/mailman3-web/uwsgi.sock connection is for, but this appears to be some miscunfiguration between apache and uwsgi. Normally, in an apache/uwsgi configuration, apache proxies to uwsgi via tcp port 8000 and uwsgi is configured with [uwsgi] uwsgi-socket = 0.0.0.0:8000

I have the apache24 and uwsgi working together. I did this way:

For the apache24 part I decided to use the mod-wsgi (and uswgi binary). did a

pip install mod-wsgi (with "mod_wsgi-express module-config" it shows the conf needed.)

after that a

pip install uwsgi

In my systems the mailman3 files are located at /usr/local/mailman3, and the apache24 config path is /usr/local/etc/apache24 (I'm running FreeBSD)

• Included these lines in the "loadmodule" part of /usr/local/etc/apache24/httpd.conf

Watch out the correct path of your python

##### begin of added lines LoadModule wsgi_module "/usr/local/lib/python3.7/site-packages/mod_wsgi/server/mod_wsgi-py37.so" WSGIPythonHome "/usr/local" WSGIDaemonProcess hyperkitty threads=25 python-path=/usr/local/mailman3 user=mailman3 group=mailman WSGIProcessGroup hyperkitty ##### end of added lines

• Added this line in the correct places of my /usr/local/etc/apache24/extra/httpd-vhosts.conf (in the listen 80 and 443 servers) Include "/usr/local/mailman3/apache24.uwsgi.conf" ( my apache24.uwsgi.conf is copied below)

Then all you have to do is a

• service apache24 restart

and initiate the uwsgi with a /usr/local/bin/uwsgi --ini /usr/local/mailman3/uwsgi.ini & (beware the "&" backgrounding it)

####### start of /usr/local/mailman3/uwsgi.ini # uwsgi.ini # [uwsgi] # Port on which uwsgi will be listening. http-socket = 0.0.0.0:8000 # Move to the directory wher the django files are. chdir = /usr/local/mailman3/ # Use the wsgi file provided with the django project. wsgi-file = wsgi.py # Setup default number of processes and threads per process. master = true process = 2 threads = 2 # Drop privielges and don't run as root. uid = www gid = www # Setup the django_q related worker processes. attach-daemon = ./manage.py qcluster # Setup the request log. req-logger = file://usr/local/mailman3/logs/uwsgi.log # Log cron seperately. logger = cron file://usr/local/mailman3/logs/uwsgi-cron.log log-route = cron uwsgi-cron # Log qcluster commands seperately. logger = qcluster file://usr/local/mailman3/logs/uwsgi-qcluster.log log-route = qcluster uwsgi-daemons # Last log and it logs the rest of the stuff. logger = file://usr/local/mailman3/logs/uwsgi-error.log ####### end of /usr/local/mailman3/uwsgi.ini

####### start of /usr/local/mailman3/apache24.uwsgi.conf

Alias /favicon.ico /usr/local/mailman3/static/hyperkitty/favicon.ico Alias /static      /usr/local/mailman3/static ######### # for hyperkitty Alias /static/admin               /usr/local/mailman3/static/admin Alias /static/CACHE               /usr/local/mailman3/static/CACHE Alias /static/django_extensions /usr/local/mailman3/static/django_extensions Alias /static/hyperkitty /usr/local/mailman3/static/hyperkitty Alias /static/mailman3 /usr/local/mailman3/static/hyperkitty Alias /static/django-mailman3 /usr/local/mailman3/static/django-mailman3 Alias /static/rest_framework /usr/local/mailman3/static/rest_framework # for postorius Alias /static/postorius /usr/local/mailman3/static/postorius Alias /static/archives /usr/local/mailman3/static/postorius #####

###ErrorLog /var/log/httpd/hyperkitty_error.log ###CustomLog /var/log/httpd/hyperkitty_access.log combined

<Directory "/usr/local/mailman3/static"> Require all granted </Directory>

######## end  of /usr/local/mailman3/apache24.uwsgi.conf

On 8/9/21 10:14 AM, Guillermo Hernandez (Oldno7) via Mailman-users wrote:

I have the apache24 and uwsgi working together. I did this way:

For the apache24 part I decided to use the mod-wsgi (and uswgi binary). did a

pip install mod-wsgi (with "mod_wsgi-express module-config" it shows the conf needed.)

after that a

pip install uwsgi

mod_wsgi and uwsgi are two different, incompatible ways of doing the same thing.

It appears from the rest of your post(s) that you are actually using mod_wsgi and (hopefully) not running uwsgi at all.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 8/9/21 8:56 AM, Richard Rosner wrote:

Mark Sapiro wrote:

...

...

The REST API is apparently not listening on the host/port this is trying to connest to.

Apparently. The question is why.

You are in a better position to answer that than am I.

What does sudo netstat -lntp show?

What does ps -fwwa|grep rest show?

...

...

What is executing the manage.py command to start Django. Is it user list?

Probably. It depends on who is calling it. I understand too little of the new architecture. But mailman3.service is run as list, mailman3-web.service as root.

mailman3-web.service must also run as list.

...

...

I don't use uwsgi and know little about it so I don't know what the Unix domain socket /run/mailman3-web/uwsgi.sock connection is for, but this appears to be some miscunfiguration between apache and uwsgi. Normally, in an apache/uwsgi configuration, apache proxies to uwsgi via tcp port 8000 and uwsgi is configured with [uwsgi] uwsgi-socket = 0.0.0.0:8000

I too have no experience in the combination ow apache and uwsgi. The only other uwsgi app I'm running is on another server and running under nginx.

So, what do you have in your apache config for proxying to uwsgi and what's your uwsgi configuration.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 8/11/21 4:18 AM, Richard Rosner wrote:

Mark Sapiro wrote:

...

...

You are in a better position to answer that than am I. What does sudo netstat -lntp show?

A lot. But since most of that isn't relevant here: Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN 20241/master tcp 0 0 127.0.0.1:8024 0.0.0.0:* LISTEN 14076/python3 tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 20241/master tcp 0 0 127.0.0.1:8001 0.0.0.0:* LISTEN 14080/python3

So some python3 process is listening on port 8001

tcp 0 0 0.0.0.0:587 0.0.0.0:* LISTEN 20241/master tcp6 0 0 :::80 :::* LISTEN 13882/apache2 tcp6 0 0 :::465 :::* LISTEN 20241/master tcp6 0 0 :::25 :::* LISTEN 20241/master tcp6 0 0 :::443 :::* LISTEN 13882/apache2 tcp6 0 0 :::587 :::* LISTEN 20241/master

...

What does ps -fwwa|grep rest show?

root 15055 14843 0 12:58 pts/1 00:00:00 grep rest

So whatever it's supposed to find, it's not there

But whatever is listening on port 8001 is apparently not Mailman's rest server. What does

ps -fww 14080

or whatever PID is currently listening on port 8001 show.

...

...

mailman3-web.service must also run as list.

I changed that. It didn't like it.

OK.

Perhaps instead you should have

uid: list gid: list

in your uwsgi configuration if you don't already.

...

...

So, what do you have in your apache config for proxying to uwsgi and what's your uwsgi configuration.

lists-ssl.conf: <VirtualHost *:443> ServerAdmin admin@domain.de ServerName lists.domain.de

Alias /mailman3/favicon.ico /var/lib/mailman3/web/static/postorius/img/favicon.ico Alias /mailman3/static /var/lib/mailman3/web/static

<Directory "/var/lib/mailman3/web/static"> Require all granted </Directory>

<IfModule mod_proxy_uwsgi.c> ProxyPass /mailman3/favicon.ico ! ProxyPass /mailman3/static ! ProxyPass "/mailman3" "unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost:8001/"

I'm not familiar enough with this form of ProxyPass using sockets to understand what the localhost:8001 does in this context, but uwsgi should not be doing anything with port 8001. In a configuration using TCP, it would listen on port 8000. Port 8001 is where Mailman's REST API server listens. uwsgi should receive connects in your case via the unix socket and then pass them to Django via the application in wsgi.py

Also, you may want other paths proxied to uwsgi, namely at least some of hyperkitty, postorius, archives, accounts, admin and user-profile.

</IfModule> ... I guess with uwsgi config you mean the /etc/mailman3/uwsgi.ini file? [uwsgi] # Port on which uwsgi will be listening. uwsgi-socket = /run/mailman3-web/uwsgi.sock

#Enable threading for python enable-threads = true

# Move to the directory wher the django files are. chdir = /usr/share/mailman3-web

# Use the wsgi file provided with the django project. wsgi-file = wsgi.py

# Setup default number of processes and threads per process. master = true process = 2 threads = 2

# Drop privielges and don't run as root. uid = www-data gid = www-data

These should be 'list', not 'www-data'. That's your permissions issue on settings.py

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 8/12/21 12:01 AM, Richard Rosner wrote:

Mark Sapiro wrote:

...

...

But whatever is listening on port 8001 is apparently not Mailman's rest server. What does ps -fww 14080 or whatever PID is currently listening on port 8001 show.

UID PID PPID C STIME TTY STAT TIME CMD list 15972 15963 0 Aug11 ? Sl 0:13 /usr/bin/python3 /usr/lib/mailman3/bin/runner -C /etc/mailman3/mailman.cfg --runner=rest:0:1

I had asked "What does ps -fwwa|grep rest show?" and it didn't find this. That was my error. I meant 'ps -fwwA|grep rest'

...

...

OK. Perhaps instead you should have uid: list gid: list in your uwsgi configuration if you don't already.

Tried that while also switching mailman3-web.service to list:list, exactly the same error. Also, I have /run/mailman3-web/uwsgi.sock owned by list:list now instead of www-data:www-data.

All the mailman processes should run as list and all mailman related things should be readable and writable by list.

...

...

I'm not familiar enough with this form of ProxyPass using sockets to understand what the localhost:8001 does in this context, but uwsgi should not be doing anything with port 8001. In a configuration using TCP, it would listen on port 8000. Port 8001 is where Mailman's REST API server listens. uwsgi should receive connects in your case via the unix socket and then pass them to Django via the application in wsgi.py Also, you may want other paths proxied to uwsgi, namely at least some of hyperkitty, postorius, archives, accounts, admin and user-profile.

Ok, I removed that port again, now it's exctly like in the automatically generated config file. And you mean like

<IfModule mod_proxy_uwsgi.c> ProxyPass /mailman3/favicon.ico ! ProxyPass /mailman3/static ! ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/ ProxyPass /hyperkitty unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/ ProxyPass /postorius unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/ ProxyPass /admin unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/ ProxyPass /archives unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/ ProxyPass /accounts unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/ ProxyPass /user-profile unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/ </IfModule>

Yes, I meant if you want those URLs to work, you have to pass them to uwsgi. You don't need all of them. mailman2 and postorius are synonyms as are archives and hyperkitty

However, you could try using TCP to communicate with uwsgi rather than a Unix socket.

This means replacing

uwsgi-socket = /run/mailman3-web/uwsgi.sock

with

uwsgi-socket = 0.0.0.0:8000

in your uwsgi.ini file and using directives like

 ProxyPass "/postorius" "http://127.0.0.1:8000/postorius"
 ProxyPass "/hyperkitty" "http://127.0.0.1:8000/hyperkitty"
 ProxyPass "/accounts" "http://127.0.0.1:8000/accounts"
 ProxyPass "/django" "http://127.0.0.1:8000/django"
 ProxyPass "/user-profile" "http://127.0.0.1:8000/user-profile"
 ProxyPass "/mailman3" "http://127.0.0.1:8000/mailman3"
 ProxyPass "/archives" "http://127.0.0.1:8000/archives"

in apache.

I am not familiar enough with apache/uwsgi configuration to be of more help. Have you seen https://wiki.list.org/x/12812344 and have you asked Debian for help with their package. They are the ones who should be supporting it <https://www.debian.org/support>.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 8/13/21 7:18 AM, Richard Rosner wrote:

I set them all to https. which solved the https error. But I still get Error 500.

...

From apache log: [Fri Aug 13 15:47:58.833305 2021] [mpm_event:notice] [pid 26720:tid 139986206332032] AH00489: Apache/2.4.48 (Debian) OpenSSL/1.1.1d mod_wsgi/4.6.5
Python/3.7 configured -- resuming normal operations [Fri Aug 13 15:47:58.833436 2021] [core:notice] [pid 26720:tid 139986206332032] AH00094: Command line: '/usr/sbin/apache2' [Fri Aug 13 15:49:41.673108 2021] [ssl:error] [pid 26722:tid 139985899259648] [remote 127.0.0.1:8000] AH01961: SSL Proxy requested for lists.fsmuw.
rwth-aachen.de:443 but not enabled [Hint: SSLProxyEngine] [Fri Aug 13 15:49:41.905868 2021] [proxy:error] [pid 26722:tid 139985899259648] AH00961: https: failed to enable ssl support for 127.0.0.1:8000 (12
7.0.0.1) [Fri Aug 13 15:59:25.049708 2021] [ssl:error] [pid 26722:tid 139985899259648] [remote 127.0.0.1:8000] AH01961: SSL Proxy requested for lists.fsmuw.
rwth-aachen.de:443 but not enabled [Hint: SSLProxyEngine] [Fri Aug 13 15:59:25.059217 2021] [proxy:error] [pid 26722:tid 139985899259648] AH00961: https: failed to enable ssl support for 127.0.0.1:8000 (12
7.0.0.1)

You need

SSLProxyEngine on

and possibly one or more of the

SSLProxyMachineCertificate*

directives in your apache config to proxy via https. See <https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslproxymachinecertificatechainfile> et seq.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Hi, Richard,

I don't recall the details, so I could be way off base, but this

[Sun Aug 15 09:19:52.318582 2021] [core:notice] [pid 19706:tid 140315143705728] AH00094: Command line: '/usr/sbin/apache2' [Sun Aug 15 09:19:52.732381 2021] [proxy_http:error] [pid 19707:tid 140314912167680] (20014) Internal error (specific information not available): client 37.201.214.82:9292] AH01102: error reading status line from remote server 127.0.0.1:8000

indicates that Apache's (?) proxy_http server expects to find something that isn't there running on the same host on port 8000. Since it's not "refused connection" or similar, evidently it's connecting (presumably to Mailman core's REST API) but not getting the "status line" (greeting?) it expects. Now, for a proxy to know what status line to expect, either it's speaking a well-known protocol (such as SMTP or HTTP), or it's part of the same application suite. But Mailman is neither.

So I suspect you have your proxy configured to proxy Apache to Mailman instead of the other way round. Or maybe it's proxying from client 37.201.214.82 to Mailman, but it should be proxying from client to Apache. I guess the latter is more plausible, in the former there'd be some kind of triangular relationship among client, Apache, and Mailman, which doesn't fit the model of "proxy". Is either possible?

HTH, but if it doesn't ring a bell, say so and we'll try something else.

Steve

Richard,

Thanks for the details and the pointer to the full configs. That makes it possible to take a look, but I can't spend much time on it until next week.

I'll see if I can prod Abhilash who is more expert than I on all this stuff (I just use mod_wsgi), but there's some more urgent (sorry, but it's security) stuff going on, and his absence speaks for his $DAYJOB, I guess.

Richard Rosner writes:

That is entirely possible @Stephen. You can see the entire apache config a few posts back plus the additions from @Mark and mine from the last post. As I interpret it, apache is reverse proxying to the uwsgi app, now through http instead of the socket. But I have no idea if that's the right way round. I'm not sure is the config file templates for apache, nginx and uwsgi that you get with the Debian packages are added by the Debian team or if they are there any way and just have been modified to the Debian file layout, but I'd guess either way it's not that likely that they wrote it the wrong way around. But I'm not too experienced to be able to translate the nginx config to apache to see if that would result in something different.

Also, while the nginx config is written as a standalone website, the apache config seems to have been written to just create a /mailman3 site under an existing website, while I use it as a standalone site. So it's entirely possible that I missed something when I modified the website from mailman2 to serve mailman3, but then it shouldn't have been able to show the website at the beginning.

---

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/

Apologies for the top-post in advance.

So, I am still catching up to this and I don’t very well understand apache2 config, so I’ll try to briefly describe what the setup should be and perhaps it can be translated into apache2 config. Since this thread is mostly about Web stuff, I am not going to talk about mail setup, but replacing web server with mta and appropriate port changes are the only major differences in mail setup.

Postorius (using Django library/web framework) speaks WSGI and can be run using a WSGI Server. There are multiple options for choosing a WSGI server like uwsgi, gunicorn etc. There are also some common web server plugins like mod_wsgi, which are essentially WSGI servers implemented as Apache2 plugin.

Web server reverse proxies the WSGI server which runs Postorius/Hyperkitty. You want WSGI Server to be configured to listen on either a socket or a port and then also configure web server to reverse proxy the socket or port.

*Ideally* you want to terminate TLS/SSL at the web server level and proxy the HTTP request to the local WSGI server. You don’t need to do anything special for Mailman for SSL if you do this, just follow the regular Web server documentation for SSL for any domains you are supporting in Mailman.

If you don’t want to terminate TLS at web server and instead want it down to the last step, WSGI server itself, then the setup is something we don’t have any docs for at the moment but if you go to the respective WSGI server’s docs, I think you’ll find some.

uwsgi is a WSGI server implementation, but it is a lot more than that, resulting in a bit more complicated configuration and issues, even though it is stable. The documentation for it exists, but it can be hard to parse if you don’t know a lot about WSGI stuff.

A few notable things about uWSGI that Mailman documentation uses are, (1) Ability to manage a daemon process like systemd and (2) ability to speak a new custom protocol called uWSGI with Web Server instead of HTTP that most other WSGI servers use to talk to Web Servers.

(1): This is specified as a part of the the “attach-daemon” configuration in the uwsgi.ini file. For Mailman, we use

# Setup the django_q related worker processes. attach-daemon = /opt/mailman/venv/bin/mailman-web qcluster

Which will essentially start mailman-web qcluster command which starts and a daemon and manage that daemon. Putting it in the uWSGI makes it easy to manage the lifecycle of this and the WSGI server together. If you were using something else like gunicorn, this would be a separate systemd service which you’d start/stop along with mailman-web.

(2): This is *probably* what is causing the issue for you from what I can gather in this thread, but I am not sure. Web Server <—> uWSGI communication can be either HTTP or (named exactly same as the package name itself, which causes confusion I suppose) uWSGI protocol. Depending on how you configure uWSGI, you want to update your web server configuration to talk the same protocol.

uwsgi-socket = /run/mailman3-web/uwsgi.sock

or 

uwsgi-socket = 0.0.0.0:8000

is the config to talk uwsgi protocol and you want to configure Web server to Proxy using the same protocol. You can find that in the uwsgi docs here: https://uwsgi-docs.readthedocs.io/en/latest/Apache.html You probably need an apache module to speak uwsgi, the docs should have the details.

Notice the URL is uwsgi:// instead of http://.

Other way is to configure uWSGI to speak HTTP, which can be done by replacing "uwsgi-socket" by "http-socket” in the uwsgi.ini configuration. This might be the easiest for you to try, do make sure to restart the mailman-web service after making the change in uwsgi.ini.

Abhilash

On Aug 16, 2021, at 9:34 AM, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:

Richard,

Thanks for the details and the pointer to the full configs. That makes it possible to take a look, but I can't spend much time on it until next week.

I'll see if I can prod Abhilash who is more expert than I on all this stuff (I just use mod_wsgi), but there's some more urgent (sorry, but it's security) stuff going on, and his absence speaks for his $DAYJOB, I guess.

Richard Rosner writes:

...

That is entirely possible @Stephen. You can see the entire apache config a few posts back plus the additions from @Mark and mine from the last post. As I interpret it, apache is reverse proxying to the uwsgi app, now through http instead of the socket. But I have no idea if that's the right way round. I'm not sure is the config file templates for apache, nginx and uwsgi that you get with the Debian packages are added by the Debian team or if they are there any way and just have been modified to the Debian file layout, but I'd guess either way it's not that likely that they wrote it the wrong way around. But I'm not too experienced to be able to translate the nginx config to apache to see if that would result in something different.

Also, while the nginx config is written as a standalone website, the apache config seems to have been written to just create a /mailman3 site under an existing website, while I use it as a standalone site. So it's entirely possible that I missed something when I modified the website from mailman2 to serve mailman3, but then it shouldn't have been able to show the website at the beginning.

---

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/

---

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/

-- thanks, Abhilash Raj (maxking)

On Aug 18, 2021, at 6:44 AM, Richard Rosner <rrosner5@gmail.com> wrote:

Abhilash Raj wrote:

...

is the config to talk uwsgi protocol and you want to configure Web server to Proxy using the same protocol. You can find that in the uwsgi docs here: https://uwsgi-docs.readthedocs.io/en/latest/Apache.html You probably need an apache module to speak uwsgi, the docs should have the details. Notice the URL is uwsgi:// instead of http://. Other way is to configure uWSGI to speak HTTP, which can be done by replacing "uwsgi-socket" by "http-socket” in the uwsgi.ini configuration. This might be the easiest for you to try, do make sure to restart the mailman-web service after making the change in uwsgi.ini.

Thanks, that already helped quite a bit. The website is now loading again, but unfortunately not much else. The site still shows no Connection to REST API.

Is your mailman core systemd service up and running? Have you modified the default host:port for Core in mailman.cfg?

-- thanks, Abhilash Raj (maxking)

On Aug 19, 2021, at 5:11 AM, Richard Rosner <rrosner5@gmail.com> wrote:

Nevermind, it works now, at least for the most parts.

But /mailman3, /accounts, /django and /archives only say "This page either doesn't exist, or it moved somewhere else."

Can you check uwsgi logs and see what exact URLs are returned as 404 there? There might be issues with URL rewrite rules in Apache2’s ProxyPass perhaps causing something important to be stripped or added.

-- thanks, Abhilash Raj (maxking)

On Aug 20, 2021, at 2:53 AM, Richard Rosner <rrosner5@gmail.com> wrote:

WARNING 2021-08-20 11:49:22,941 3975 django.request Not Found: /mailman3 WARNING 2021-08-20 11:49:22,941 3975 django.request Not Found: /mailman3 WARNING 2021-08-20 11:49:22,954 3975 django.request Not Found: /mailman3 WARNING 2021-08-20 11:49:22,954 3975 django.request Not Found: /mailman3 [pid: 3975|app: 0|req: 17/16] 127.0.0.1 () {56 vars in 1208 bytes} [Fri Aug 20 11:49:10 2021] GET /mailman3 => generated 5651 bytes in 13321 msecs
(HTTP/1.1 404) 5 headers in 170 bytes (1 switches on core 0) [pid: 3975|app: 0|req: 17/17] 127.0.0.1 () {56 vars in 1208 bytes} [Fri Aug 20 11:49:07 2021] GET /mailman3 => generated 5651 bytes in 16373 msecs
(HTTP/1.1 404) 5 headers in 170 bytes (1 switches on core 1) WARNING 2021-08-20 11:49:32,820 3975 django.request Not Found: /accounts WARNING 2021-08-20 11:49:32,820 3975 django.request Not Found: /accounts [pid: 3975|app: 0|req: 18/18] 127.0.0.1 () {56 vars in 1208 bytes} [Fri Aug 20 11:49:32 2021] GET /accounts => generated 5651 bytes in 251 msecs (H
TTP/1.1 404) 5 headers in 170 bytes (1 switches on core 0) WARNING 2021-08-20 11:49:43,517 3975 django.request Not Found: /archives WARNING 2021-08-20 11:49:43,517 3975 django.request Not Found: /archives [pid: 3975|app: 0|req: 19/19] 127.0.0.1 () {56 vars in 1208 bytes} [Fri Aug 20 11:49:43 2021] GET /archives => generated 5651 bytes in 99 msecs (HT
TP/1.1 404) 5 headers in 170 bytes (1 switches on core 1)

The proxy pass config is <IfModule mod_proxy_uwsgi.c> ProxyPass /mailman3/favicon.ico ! ProxyPass /mailman3/static ! Proxypass "/mailman3" "http://127.0.0.1:8000/mailman3" ProxyPass "/postorius" "http://127.0.0.1:8000/postorius" ProxyPass "/hyperkitty" "http://127.0.0.1:8000/hyperkitty" ProxyPass "/accounts" "http://127.0.0.1:8000/accounts" ProxyPass "/django" "http://127.0.0.1:8000/django" ProxyPass "/user-profile" "http://127.0.0.1:8000/user-profile" ProxyPass "/archives" "http://127.0.0.1:8000/archives" </IfModule>

There seem to be extra entries in this, depending on where you installed from, there are only some URLs that you need.

You need one of the /postorius and /mailman3, one between /archives or /hyperkitty. /django is probably not useful I think, /accounts looks fine.

Top level URL patterns are basically listed here1, but it depends on where did you install from and what the url patterns are.

---

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/

-- thanks, Abhilash Raj (maxking)

postorius, admin, hyperkitty and user-profile work now, accounts doesn't

WARNING 2021-08-21 10:52:41,931 3975 django.request Not Found: /accounts WARNING 2021-08-21 10:52:41,931 3975 django.request Not Found: /accounts [pid: 3975|app: 0|req: 26/26] 127.0.0.1 () {56 vars in 1208 bytes} [Sat Aug 21 10:52:41 2021] GET /accounts => generated 5651 bytes in 433 msecs (H
TTP/1.1 404) 5 headers in 170 bytes (1 switches on core 0)

pid 3975 is /usr/bin/uwsgi --plugin python3 --ini /etc/mailman3/uwsgi.ini

PS: now I seem to have done something stupid. I wanted to switch everything from example.com to the real domain. So I added it in admin and got rid of example.com. Seems there was some configuration missing, now nothing is working. How do I get everything back and have it use the right domain?

Ah, thanks. That was easier than expected. I think everything is working now. If not I'll come back. The bug report is filed to the Debian devs, but they'll have to see if they make any changes.

On 9/4/23 11:43, markus.laspeyres--- via Mailman-users wrote:

But sudo systemctl restart mailman3 Job for mailman3.service failed because the control process exited with error code. See "systemctl status mailman3.service" and "journalctl -xeu mailman3.service" for details.

And what do those say?

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan