Search results for "Postorius" - Mailman-users

[Django] ERROR (EXTERNAL IP): Service Unavailable

by dancab＠caltech.edu

I've imported a list from Mailman2 and had the owner send a message for testing purposes. His message are moderated per the list configuration. The message is delivered to Mailman3 and shows that it's being held. However if we attempt to view the message in Postorius web UI then an error is thrown. In the web interface the error is simply "Mailman REST API not available. Please start Mailman core." But Mailman Core is running and we can do other functions just fine. Our superuser account receives a much more detailed message with the subject below. [Django] ERROR (EXTERNAL IP): Service Unavailable: /postorius/lists/cpa-announcement.caltech.edu/held_messages Does "Service Unavailable" mean I'm missing something in the configuration? Thanks for your help. ---- Dan Caballero

4 years, 3 months

Re: Help request, almost got it going, but ....

by Claus-Justus Heine

I think I found the bug; I have posted a comment to the issue mentioned by Mark https://gitlab.com/mailman/postorius/issues/58 Regards Claus Am 02.09.2017 um 01:20 schrieb Claus-Justus Heine via Mailman-users: > Oh well. > > Am 01.09.2017 um 23:44 schrieb Mark Sapiro: >> On 09/01/2017 02:33 PM, Claus-Justus Heine via Mailman-users wrote: >>> >>> Seemingly, at some point in the deep dungeons of the source code the >>> "Acceptable aliases" Text-Box is not interpreted correctly. >>> >>> Specifically, at the start it contains the string >>> >>> [] >> >> >> See <https://gitlab.com/mailman/postorius/issues/58>. > > there they talk about fancy "uni-code thinks" (email addresses?) where > the task is to convert a new-line separated text-field into an array. Oops. > > Kind thanks anyway. > >> >> In order to set things on this page, you need to clear the Acceptable >> aliases box before submitting changes. You can't actually set Acceptable >> aliases via Postorius until this is fixed. > > The issue seems not to be overly active. I thought -- coming from > Mailman v2 -- that the configuration of acceptable submitters to an > email list (e.g. keep everyone moderated?) would be a central and > prominent and important configuration issue. Seems not to be a central > point. Mmmh. > > Thanks > > Claus > > -- Claus-Justus Heine himself(a)claus-justus-heine.de http://www.claus-justus-heine.de/ Schatzmeister der Camerata Academica Freiburg e.V. --- www.cafev.de

7 years, 9 months

Re: Unable to update templates

by Mark Sapiro

On 5/27/25 18:54, Mark wrote: > > However when I update the template, the databases are updated correctly > but the Welcome message is still sent with the old template content. > > mailman.templates > mailmanweb.postorius_emailtemplate > > Additionally, if I delete the template and create a new one the old > content still gets sent. > > I cannot find where this content is written or is being cached. The content is stored in the mailmanweb.postorius_emailtemplate table. As far as Mailman core and Postorius are concerned, that's the only place. I'm guessing, but my guess is it's cached in your wsgi server. I.e., upon initial creation an entry is made in the mailman.template table with a uri like https://example.com/mailman3/api/templates/list/list.example.com/list:user:… and when Mailman core wants the template, it gets that uri which I'm guessing is then cached in the wsgi server. Then, if the content is changed, the GET returns the old cached value instead of getting the new value from Postorius. If the template is deleted, the mailman.template table entry is deleted and at that point Mailman core will get the template from the file system following it's normal search rules, but if the template is recreated in Postorius, a new table entry is made with the same uri which may still get a cached template from the wsgi server. If this is correct, restarting mailman-web or whatever controls the wsgi server should fix it. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 weeks

Re: Postorius no connection to REST API

by Abhilash Raj

> On Aug 20, 2021, at 2:53 AM, Richard Rosner <rrosner5(a)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 here[1], but it depends on where did you install from and what the url patterns are. [1]: https://gitlab.com/mailman/mailman-web/-/blob/master/mailman_web/urls.py#L25 > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ -- thanks, Abhilash Raj (maxking)

3 years, 9 months

Error: Module "django.contrib.sessions.serializers" does not define a "PickleSerializer" attribute/class

by Torge Riedel

Dears, I just upgraded my Server from Ubuntu 22.04 to 24.04 and I get the following error when accessing the web page. Django is 5.0.10 Postorius is 1.3.13 Any help is welcome. Thank you and kind regards Torge Internal Server Error:/mailman3/lists/ ImportError at/mailman3/lists/ Module "django.contrib.sessions.serializers" does not define a "PickleSerializer" attribute/class Request Method: GET Request URL:https://lists.lsv-pinneberg.de/mailman3/lists/ Django Version: 5.0.10 Python Executable: /usr/bin/uwsgi-core Python Version: 3.12.3 Python Path: ['.', '', '/usr/lib/python312.zip', '/usr/lib/python3.12', '/usr/lib/python3.12/lib-dynload', '/opt/mailman/web/venv/lib/python3.12/site-packages'] Server time: Sun, 22 Dec 2024 11:05:00 +0100 Installed Applications: ('hyperkitty', 'postorius', 'django_mailman3', 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.messages', 'django.contrib.staticfiles', 'rest_framework', 'django_gravatar', 'compressor', 'haystack', 'django_extensions', 'django_q', 'allauth', 'allauth.account', 'allauth.socialaccount') Installed Middleware: ('django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.middleware.locale.LocaleMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', 'django.middleware.security.SecurityMiddleware', 'django_mailman3.middleware.TimezoneMiddleware', 'postorius.middleware.PostoriusMiddleware', 'allauth.account.middleware.AccountMiddleware') Traceback (most recent call last): File "/opt/mailman/web/venv/lib/python3.12/site-packages/django/utils/module_loading.py", line 30, in import_string return cached_import(module_path, class_name) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/web/venv/lib/python3.12/site-packages/django/utils/module_loading.py", line 16, in cached_import return getattr(module, class_name) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ The above exception (module 'django.contrib.sessions.serializers' has no attribute 'PickleSerializer') was the direct cause of the following exception: File "/opt/mailman/web/venv/lib/python3.12/site-packages/django/core/handlers/exception.py", line 55, in inner response = get_response(request) ^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/web/venv/lib/python3.12/site-packages/django/utils/deprecation.py", line 133, in __call__ response = self.process_request(request) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/web/venv/lib/python3.12/site-packages/django/contrib/sessions/middleware.py", line 20, in process_request request.session = self.SessionStore(session_key) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/web/venv/lib/python3.12/site-packages/django/contrib/sessions/backends/db.py", line 16, in __init__ super().__init__(session_key) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/web/venv/lib/python3.12/site-packages/django/contrib/sessions/backends/base.py", line 47, in __init__ self.serializer = import_string(settings.SESSION_SERIALIZER) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/web/venv/lib/python3.12/site-packages/django/utils/module_loading.py", line 32, in import_string raise ImportError( ^^^^^^^^^^ Exception Type: ImportError at/mailman3/lists/ Exception Value: Module "django.contrib.sessions.serializers" does not define a "PickleSerializer" attribute/class Raised during: postorius.views.list.list_index

5 months, 3 weeks

Re: Database running VERY hot

by Darren Smith

Well, we haven't tackled the issue if importing old archives yet - we're trying to stabilize things first, trying to get the 504 gateway timeouts to stop happening. Once that happens, we have over 40 million old emails to import. (some of the emails date back to 1987 I think.) We'll see how it goes. :) -Darren On Fri, Mar 9, 2018 at 10:20 AM, Abhilash Raj <maxking(a)asynchronous.in> wrote: > On Fri, Mar 9, 2018, at 9:11 AM, Darren Smith wrote: > > Abhilash, > > Thanks for the response. I'm going over to lists.fedoraproject.org to see > if they have done any fine tuning. > > Our installation is at https://lists.rootsweb.ancestry.com, if you're > interested in seeing an installation with over 32,000 mailing lists. As I > mentioned, it was big enough that we have disabled the browse experience in > Postorius and are hosting our own pages for browsing to a new list. > > > Please keep us posted if you have other unique challenges for operating > this high number of lists, other than this particular one. We'd love to be > able to support high number of lists efficiently :) > > If we get time to work on this we will certainly create a pull request. :) > > > On Thu, Mar 8, 2018 at 11:49 AM, Abhilash Raj <maxking(a)asynchronous.in> > wrote: > > Hi Darren, > > > On 3/8/18 9:43 AM, Darren Smith wrote: > > Hello all, > > We had an old installation of Mailman 2.1 across three servers with over > 32,000 mailing lists on them. Due to circumstances beyond my control, we > had to shut them down and quickly set up Mailman 3 on a new server. > > We have Mailman3 set up on a single server this time, as we were having > problems with a 3-server setup and Hyperkitty and archives. Long story > short, it is up and running, and our users are starting to come back. > > However, we do not have very many users hitting Postorius and Hyperkitty > yet, and we are seeing a distressing number of 504 gateway timeouts. > > We noticed that there is a significant number of queries to the API > whenever hitting Postorius's front page to load the mailing lists, and then > on every load. It looks as if it makes a single call to the API to get > information about a single list, and does this 10 times - once for each > list - to render the page. This gets much worse when users set the view to > 200 per page, as they are inclined to do with 32,000 mailing lists... > > What we've done, actually, is to override the front page and point the > users to a different set of static pages where we have all of our lists > categorized and searchable, and when they find the list they are looking > for, we have a link back to postorius. It has taken a lot of the stress off > of the server. > > However, I still see where the database at times can run VERY hot. > > We have set up this server to run with PostgreSQL. When I do a ps aux | > grep postgres, I find a lot of processes that have been spawned to take > care of mailman - a dozen or so. However, one of the threads is taking up > about 85% of the load, another thread about 14%, and little dribbles here > and there from the rest of the threads. > > Here are the questions: > > 1) Has anyone run into problems like these? I would think that maybe this > is an issue having so many mailing lists, but honestly there aren't that > many people using the system yet. It is going to ramp up as the users > realize that we are live again, but we aren't getting that much traffic. > > > I can say that in general, Postorius doesn't really optimize REST API > queries and so loading a single page can sometimes make things bad. > > Currently, the largest installation of Mailman 3 that we know of runs at > lists.fedoraproejct.org and the administrators of the list would know how > well does our Web UI scale. > > However, I don't think we have anyone actively working on trying to fix > this particular issue. Pull Requests and fixes are welcome :) > > > 2) Is there any configuration that I can set, especially with regards to > the database, so that it can be used more efficiently and not throttle > through one or two threads? > > > There isn't any configuration that would change how databases are used in > Mailman Core. Django *may* have some, but I don't know about any of them of > the top of my head. > > thanks, > Abhilash > > > -- > Abhilash Raj > maxking(a)asynchronous.in > > >

7 years, 3 months

Re: Mailman upgrade results in page not found error

by Abhilash Raj

On 11/3/22 18:30, Andrew Hodgson wrote: > I think this is a problem with the new urls.py I downloaded, what is the best way to restore the old behaviour of having https://lists.hodgsonfamily.org going to the correct place? > urlpatterns = [ > path( > '', > RedirectView.as_view(url=reverse_lazy('list_index'), permanent=True), > ), > path('mailman3/', include('postorius.urls')), You _probably_ had DOMAIN/postorius as your URL? If that's the case, replace the 'mailman3/' above with your old 'posotorius/' in your new urls.py. That should fix the problem you are having with 404 because you browser probably remembers the old URL and tries to auto-redirect root path to /postorius. -- thanks, Abhilash Raj (maxking)

2 years, 7 months

Re: Mailman 3 Web Application Startup Time or Availability - 502 Bad Gateway and Postorius

by summersan＠nclack.k12.or.us

Hi Mark, Thank you for your quick response! When setting up Mailman 3, I went through much of this "how to" guide here: https://wiki.list.org/DOC/Howto_Install_Mailman3_On_Debian10. As far as I can tell, my current setup appears to be proxying from Nginx to Gunicorn, according to the related Nginx and mailman3-project-specific Gunicorn config files. Specifically, I checked the local address:port being used in the Nginx file and compared that to the mailman3-project-specific Gunicorn bind address. It looks like I might have "separated out" the REST API to a different server block in the Nginx config file, so I think I'm looking at the correct server block with this conclusion. For what it's worth, I don't recall this type of "slow first visit startup" issue happening in the past when using web applications with uwsgi, and I've had the opportunity to use uwsgi with a variety of programs. I think Gunicorn is fairly new to me. I do, however, remember that something like this might have happened in the past when using Passenger (https://www.phusionpassenger.com/) a long time ago, but that might have been setting related on my part. Okay, thanks for the encouragement about the potential solution to periodically accessing the related "example.mailman.site/mailman3/lists/" type location (from my earlier email). Wanted to check on that and was also hoping that there might be some setting I'm missing in the overall Mailman 3 project setup related to the "slow first visit startup" issue. Thank you!

4 years, 1 month

Re: Turn off social logins?

by Abhilash Raj

On Sun, Feb 10, 2019, at 6:54 PM, Nick Wynja wrote: > On 02/10/19 at 08:57, brian(a)emwd.com <brian(a)emwd.com> wrote: > > > "In your `settings_local.py` copy the whole INSTALLED_APPS section from [default settings](https://github.com/maxking/docker-mailman/blob/master/web/mailman… and add/remove the auth providers you want/don't want. Notice the `allauth.socialaccount.providers.<provider>` in the list below." > > Another option, which seems more future-proof, is to strictly remove > the account providers you don't want from INSTALLED_APPS rather than > defining INSTALLED_APPS locally. > > First, you have to access INSTALLED_APPS by importing settings into > settings_local.py: > > ``` > from settings import * > ``` > > Then, you can set INSTALLED_APPS to everything it already is minus the > social providers: > > ``` > INSTALLED_APPS = [a for a in INSTALLED_APPS if not > a.startswith('allauth.socialaccount.providers') and not > a.startswith('django_mailman3.lib.auth.fedora')] > ``` > > This way if Postorius ever adds any apps you won't need to update your > local settings. Anyone see any downsides to doing it this way? Please don't do that, it will create a circular import since settings_local.py is imported by settings. Postorius (actually, allauth) adding more providers won't affect the INSTALLED_APPS list, which is a static setting defined in the container images. Unless the image changes that list, it won't affect you. Having the list customized is actually good for you, since there is some extra configuration required for adding a new provider, so you don't want something to just show up without you knowing. -- thanks, Abhilash Raj (maxking)

6 years, 4 months

Re: installing a new instance of mm3

by Mark Sapiro

On 10/22/21 6:37 AM, Christian Stalberg via Mailman-users wrote: > Is this document that Brian Carpenter wrote still valid? > > https://wiki.list.org/DOC/Howto_Install_Mailman3_On_Debian10 As Steve said, it should be. > Brian installed my instance. Now its broken. My lists are down. I'm getting > nowhere with diagnostics and troubleshooting (which was easier with mailman > 2). What's broken? Postorius, Hyperkitty, mail delivery, all of them? Do you find any clues in the logs at /opt/mailman/mm/var/logs/? Particularly mailman.log for core and mailmansuite.log for Postorius and Hyperkitty. We will try to help if we have information to help identify the problem. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 7 months

Mailman-users search results for query "Postorius"