Search results for "Postorius" - Mailman-users

Re: Mass un/subscribe optimization?

by Mark Sapiro

On 2/28/22 12:12, Bryan Loniewski wrote: > Hi -- > > We've noticed slowness in mass un/subscribing users; looking through the issue(s) log we see both #419 [1] and #627 [2] open and related. From the cmd line we get better performance, but with the subscriber size on many of our Faculty/Staff/Students ad-hoc lists (think 1k-15K subscribed addresses) and with our number of lists (2600) and unique owners utilizing these actions it would be helpful to optimize the mass actions. We wanted to get some thoughts and guidance on what needs to be optimized/redesigned/fixed? Or is there already something in the works, but needs more time? We may be able to provide resources to encourage and/or assist with any development and/or testing... > > We run a split core/web setup with Apache,mod_wsgi and MySQL backend (AWS hosted). > > [1] - https://gitlab.com/mailman/mailman/-/issues/419 > [2] - https://gitlab.com/mailman/mailman/-/issues/627 Regarding mass removal and #627, that should be fixed as of Postorius 1.3.5. What is your Postorius version. If you want to work on providing a REST endpoint for mass subscribe and supporting it in mailmanclient and Postorius, that would be great. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 3 months

Re: Login confusion

by Markus Grandpré

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(a)uni-konstanz.de> and <Markus.Grandpre(a)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(a)uni-konstanz.de> and <Markus.Grandpre(a)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(a)uni-konstanz.de | t | t | 93 101 | markus.grandpre(a)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(a)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(a)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(a)uni-konstanz.de>. It is most likely that during registration, the user provided <Markus.Grandpre(a)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(a)uni-konstanz.de> and > > <Markus.Grandpre(a)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

4 months

Re: Multi-domain oddities in Hyperkitty and Postorius

by Jeremy Stanley

On 2023-01-30 12:08:10 -0800 (-0800), Mark Sapiro wrote: [...] > Domains can be created via Postorius or via the Mailman Core REST API that > postorius uses or implicitly by the `mailman create` command when creating a > list in a new domain. However, none of this can create a new site. You can > do this through the Django admin site at sites/site/add/. > > See https://docs.djangoproject.com/en/4.1/ref/contrib/sites/ for methods you > can use to do this programmatically. Thanks, I'm still doing my best to wrap my brain around how Django uses database migrations to create sites (seems like a very strange use of a migration, I'm only accustomed to seeing them applied for database schema updates). Once I work out how to script site creation, I'm still not completely finding the explanations I need for how to map them to domains in Mailman though. The Mailman documentation about domains says "Domains are how Mailman interacts with email host names and web host names" but doesn't actually go on to say (that I can find anywhere) how it actually associates them. I can see in the API docs that a POST to the domains endpoint will create a new domain with a specific mail_host FQDN, but there's some association somewhere of that to a web host (Django site), right? How is that set or manipulated through the API? Or is that something which has to be set directly in Django's data structures instead? To recap, on creation of a mailing list server I want to populate it automatically with multiple lists on different domains and have dynamic SITE_ID=0 domain guessing performed so that the correct site name and list filtering is performed depending on which domain name is used in a URL the client requests. I believe I need to have the automation perform the following steps: 1. Instantiate the Mailman installation and run initial migrations with SITE_ID=1 in order to avoid the problem mentioned in the docs about not using SITE_ID=0 until the tables have been populated, then switch the settings.py to use SITE_ID=0 once done. 2. Create the individual sites I need in Django (Mailman web hosts) by creating and applying database migrations. 3. Create the individual domains I need in Mailman (Mailman mail hosts) through its REST API. 4. "Somehow" tell Mailman (or Django?) which mail hosts correspond to what web hosts. As I said, I'm still trying to understand how to make step 2 happen (Django has a steep learning curve for me), but beyond that I'm unsure how to do step 4 at all. I can do all of this through the WebUI of course, and have confirmed that it works as expected when I do, I'm just trying to work out the automation so that our other sysadmins don't have to perform these steps by hand the next time we need to rebuild the server. Thanks again for all the help so far, and for any additional insight anyone may have into how I can correct my mental model of all this. -- Jeremy Stanley

2 years, 3 months

Re: Hiding an ML from a site

by Mark Sapiro

On February 6, 2024 7:45:14 AM PST, Odhiambo Washington <odhiambo(a)gmail.com> wrote: > >I had this set to True in settings_local.py, but False in settings.py. >So it seems to not make a difference in my setup. In a standard setup, anything set in settings_local.py overrides any corresponding setting in settings.py. That said, FILTER_VHOSTS is not perfect. It only works for Postorius if the separate web hosts also have different mail hosts. See lines 1051 et seq at <https://gitlab.com/mailman/postorius/-/blob/master/src/postorius/views/list…> -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 4 months

Re: Postorius & multi domain

by Mark Sapiro

On 4/22/20 11:37 AM, Gelpi Andrea wrote: > > I'm not a python programmer so I ask you if it'd be long to implement a > workaround like this. > > If the web server is a.example.com and the email domain is example.com > > It'd be possible to drop the "a" and send the email domain only in the > query? > > It's a workaround. Can you help me in this? I'm currently working on a better fix. I'll post here on my progress. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 1 month

Re: Postorius endless loading on Sign in / Register then "Internal Server Error"

by Mark Sapiro

On 6/9/20 12:16 PM, Jacob Bargery wrote: > Pre-cursor, I am in a new position to learn on the go and new to Linux but have been tasked with setting up a List Serv and they wanted Mailman 3 with Postorius and HyperKitty. Running on Ubuntu 20.04 LTS using Postfix and MySQL. I can open up the initial pages. With no Lists created yet. I can open up Register, Login, and Forgot Password but when I submit anything it spins the loading icon for a long time then reads" > > "Internal Server Error > The server encountered an internal error or misconfiguration and was unable to complete your request. Apache/2.4.41 (Ubuntu) Server at groups.smccme.edu Port 80" ... > This is a traceback I could find from another attempt: > > Traceback (most recent call last): ... > File "/usr/lib/python3/dist-packages/mailmanclient/restbase/connection.py", line 109, in call > raise MailmanConnectionError('Could not connect to Mailman API') > mailmanclient.restbase.connection.MailmanConnectionError: Could not connect to Mailman API What are your Django settings for MAILMAN_REST_API_URL = 'http://localhost:8001' MAILMAN_REST_API_USER = 'restadmin' MAILMAN_REST_API_PASS = 'restpass' Those match the defaults defined in mailman/config/schema.cfg [webservice] # The hostname at which admin web service resources are exposed. hostname: localhost # The port at which the admin web service resources are exposed. port: 8001 # Whether or not requests to the web service are secured through SSL. use_https: no # The administrative username. admin_user: restadmin # The administrative password. admin_pass: restpass If all that seems to match, what happens if you try telnet localhost 8001 If that doesn't work, but telnet 127.0.0.1 8001 works, there is some issue with `localhost` involving /etc/resolv.conf or /etc/hosts, most likely an ipv6 definition like ::1 localhost in the latter. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years

after last upgrade I've got a CSRF failed verification

by Guillermo Hernandez (Oldno7)

I did upgrade one of my mailman3 server after Abhilasj announcement: "I am pleased to announce several new releases for GNU Mailman project. 1. Mailman Core 3.3.6 1 <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/NEWS.…> 2. Postorius 1.3.7 2 <https://docs.mailman3.org/projects/postorius/en/latest/news.html#section-2> 3. Hyperkitty 1.3.6 [3] 4. Mailmanclient 3.3.4 [4] 5. Django-mailman3 1.3.8 [5]" I did it via pip and all seems to be working, but when I try to discard or accept any message via postorius it shows a Forbidden 403 error CSRF verification failed. In my settings.py I have commented out these variables: # Other security settings # SECURE_SSL_REDIRECT = True # If you set SECURE_SSL_REDIRECT to True, make sure the SECURE_REDIRECT_EXEMPT # contains at least this line: # SECURE_REDIRECT_EXEMPT = [ # "archives/api/mailman/.*", # Request from Mailman. # ] # SESSION_COOKIE_SECURE = True # SECURE_CONTENT_TYPE_NOSNIFF = True # SECURE_BROWSER_XSS_FILTER = True # CSRF_COOKIE_SECURE = True # CSRF_COOKIE_HTTPONLY = True # X_FRAME_OPTIONS = 'DENY' I've been messing with them whith no results. It's like it lacked some value in some template... Can someone, please, point me in the right direction? Thanks in advance -- ___________________________________________ Mailman's content filtering has removed the following MIME parts from this message. Content-Type: image/png Name: firma-GHP-emails.png Replaced multipart/alternative part with first alternative.

2 years, 7 months

Re: When mass subscribing using format John Doe <john.doe@example.com>, "Members" show some with real name, others without.

by Mark Sapiro

On 10/30/19 2:08 AM, Henrik Rasmussen wrote: > > It seems (I’m not certain about this) that the one’s without real name is the one’s already having an account and thus registred in Django (admin/auth/user/), while the ones subscribed with full name associated is the ones not having an account already. That's probably correct, but not the exact reason. > However, as soon as the member (the one with the account) went to Account and changed his real name, the name was immediately associated with the subscription in Members -> Subscribers. > > I expect this to be by design, but why isn’t the name associated with the subscription when mass subscribing in the first place, taken from the account? To understand, you need a bit of background. The basic engine that manages lists, subscriptions, users, etc. is Mailman core. Core does not provide any web UI. It only provides a REST API for use by other components. It is possible to run Mailman core only without any web UI, but management would need to be done directly via the REST API and/or `mailman shell` which is not particularly convenient. Because Mailman would not be too useful without a web management UI and a web based archiver, we provide Postorius and HyperKitty for these functions. These are only one possibility. One could build an entirely different web UI or other application to communicate with core via its REST API, but few if any have done so. Postorius and HyperKitty are Django projects and run under Django. The account that you see (Postorius top right) is a Django account. Core knows nothing about this. Core knows about users and addresses in its own database which is entirely separate from Django's accounts. These user/address records in core is where the user's display_name is kept. So when a user/address is added to a list, if core already knows that user/address, it just links that to the list and doesn't update the display_name, but if it doesn't know the user/address, it creates it and uses the supplies display name. It appears there is a mechanism within Postorius to detect a change in the name associated with a Django user and update core, but this is separate from subscribing. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 7 months

Using REST api to subscribe member

by Brian Carpenter

I have a development server that only has Mailman core installed on it. I used a virtual environment to do the installation but I did not install Postorius or Hyperkitty as I am currently working on developing a custom u.i. for Mailman 3. My programmer said the following: "I have a problem with mailman on development server ... I was trying to add member to a list using REST api, but to no avail. After I tried all possible and impossible things, I finally looked at the logs. Error I found in log file is: IsADirectoryError: [Errno 21] Is a directory: '/opt/mailman/mm/venv/lib/python3.7/site-packages/mailman/templates' I guess mailman was looking for a template for welcome mail, and failed for some reason. I also guess this has something to do with locale or language settings I tried googling, but couldn't find anything" The log that gave the error was /opt/mailman/mm/logs/mailman.log My programmer tried it on another server that has both Postorius and Hyperkitty working and the api call worked, i.e. added the member to the list and sent out a welcome email. So what else do I need to install to be able to use the api to add members to a list using a non-postorius interface? Any assistance would be appreciated. Thanks, Brian

5 years, 3 months

Re: mm3 installation question

by Odhiambo Washington

On Wed, Mar 6, 2024 at 8:53 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 3/6/24 1:33 AM, Odhiambo Washington wrote: > > On Wed, Mar 6, 2024 at 12:13 PM Stephen J. Turnbull < > > turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote: > > > >> Odhiambo Washington writes: > >> > >> > The odd thing is that the HOWTO that he followed never involves the > >> > manipulation of any urls.py at all - it's not even mentioned at any > >> > point. So obviously the issue is caused by something else and I > >> > suspect something within Apache needs to be re-evaluated in the > >> > guide. > > > The HOWTO installs mailman-web which contains a urls.py. > > >> > >> Note that Apache doesn't know about the "/postorius" and "/hyperkitty" > >> URI paths. It is quite unclear to me how this works at all with > >> either the > >> > >> path('mailman3/', include('postorius.urls')), > >> path('archives/', include('hyperkitty.urls')), > >> path('postorius/', include('postorius.urls')), > >> path('hyperkitty/', include('hyperkitty.urls')), > >> > >> version of urls.py or the reverse order version > >> > >> path('postorius/', include('postorius.urls')), > >> path('hyperkitty/', include('hyperkitty.urls')), > >> path('mailman3/', include('postorius.urls')), > >> path('archives/', include('hyperkitty.urls')), > > > This is an issue with Django. I'm not sure of the exact mechanism, but > consider the first of the above two sets. If you go to the mailman3/ URL > that gets redirected to the postorius/ URL. I.e. two paths that > ultimately reference the same thing wind up considering the second path > as the canonical path and redirecting the first path to the second. > > I was not initially aware of this when I added the postorius/ and > hyperkitty/ paths to mailman_web/urls.py. I did this with the intent of > making either set of paths work, and I added those paths after the > mailman3/ and archives/ paths, and this version got released as > mailman-web 0.0.8. That caused the recommended Apache config to fail > because now the mailman3/ and archives/ paths were redirected to the > postorius/ and hyperkitty/ URLs which are not in the recommended Apache > config. > > I have since reordered the paths in mailman_web/urls.py, but that > version isn't yet released. Thus the issue. See > > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > for some background. > > > > My thinking then is that the documentation at > > > https://docs.list.org/en/latest/install/virtualenv.html#apache-configuration > > needs to be fixed by adding the missing bits, > > > What needs to be done is a mailmab-web 0.0.9 release in PyPI. This will > fix the issue. > Hi Mark, Thank you for making it much clearer. Is it possible that an Apache directive like below will fix everything (albeit discreetly with sysadmins driving blindly)? ProxyPass "/" "http://127.0.0.1:8000/" As was suggested by Mr. Turnbull (and previously by you on another thread)? It will be simpler, but leaves almost everyone (except the Devs) blind to the fact there exists a urls.py somewhere that determines the mappings? Maybe a note about it in the documentation will help? -- 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]

1 year, 3 months

Mailman-users search results for query "Postorius"