Search results for "Postorius" - Mailman-users

localtime() cannot be applied to a naive datetime

by Freerk Bosscha

Since yesterday I get the following error-message when I go to the webinterface: ValueError at /admin/login/ localtime() cannot be applied to a naive datetime Request Method: GET Request URL: https://mailman.pgtrynwalden.nl/mailman3/admin/login/?next=/mailman3/admin/ Django Version: 2.2.28 Exception Type: ValueError Exception Value: localtime() cannot be applied to a naive datetime Exception Location: /usr/lib/python3/dist-packages/django/utils/timezone.py in localtime, line 207 Python Executable: /usr/bin/uwsgi-core Python Version: 3.9.2 Python Path: ['.', '', '/usr/lib/python39.zip', '/usr/lib/python3.9', '/usr/lib/python3.9/lib-dynload', '/usr/local/lib/python3.9/dist-packages', '/usr/lib/python3/dist-packages', '/usr/lib/python3.9/dist-packages'] Server time: vr, 1 Mrt 2024 11:52:50 +0100 Mailman info: mailman info GNU Mailman 3.3.3 (Tom Sawyer) Python 3.9.2 (default, Feb 28 2021, 17:03:44) [GCC 10.2.1 20210110] config file: /etc/mailman3/mailman.cfg db url: mysql+pymysql://mailman3:xxxxxxx If this issue was posted before, i'm sorry, i haven't found it: Any ideas how to solve this issue would be appreciated Environment: Request Method: GET Request URL: https://mailman.pgtrynwalden.nl/mailman3/admin/login/?next=/mailman3/admin/ Django Version: 2.2.28 Python Version: 3.9.2 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', 'django_mailman3.lib.auth.fedora') 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') Traceback: File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py" in inner 35. response = get_response(request) File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in _get_response 145. response = self.process_exception_by_middleware(e, request) File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in _get_response 143. response = response.render() File "/usr/lib/python3/dist-packages/django/template/response.py" in render 106. self.content = self.rendered_content File "/usr/lib/python3/dist-packages/django/template/response.py" in rendered_content 83. content = template.render(context, self._request) File "/usr/lib/python3/dist-packages/django/template/backends/django.py" in render 61. return self.template.render(context) File "/usr/lib/python3/dist-packages/django/template/base.py" in render 169. with context.bind_template(self): File "/usr/lib/python3.9/contextlib.py" in __enter__ 117. return next(self.gen) File "/usr/lib/python3/dist-packages/django/template/context.py" in bind_template 246. updates.update(processor(self.request)) File "/usr/lib/python3/dist-packages/postorius/context_processors.py" in postorius 38. mailman_day=(timezone.localtime(timezone.now()).day == MAILMAN_DAY), File "/usr/lib/python3/dist-packages/django/utils/timezone.py" in localtime 207. raise ValueError("localtime() cannot be applied to a naive datetime") Exception Type: ValueError at /admin/login/ Exception Value: localtime() cannot be applied to a naive datetime

1 year, 3 months

Re: moving lists to another server

by Odhiambo Washington

On Tue, Nov 7, 2023 at 2:07 PM Stephen J. Turnbull < turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote: > bryan.kartzman(a)yu.edu writes: > > > I have both my mailman lists and django config in postgres > > databases. > > These are Mailman 3 lists? What Django config? Do you mean Postorius > and HyperKitty? Do you intend to use Postorius and HyperKitty on the > new server? > > > If I want to move my lists to another server that is running > > mailman 3, aside from copying the databases to the other server, > > Do you mean the other server is already actively distributing Mailman > list traffic, managing users and archives? Or is it fresh instance? > Hello Stephen et al, Since this topic is relevant to something I am faced with at the moment, I believe it's okay if I piggyback on the thread. I have a server that is already actively distributing Mailman list traffic, and managing users and archives. I have offered to take over another community ML (also using MM3) from another server and host the list on my server. I am scratching my head bald trying to figure out how to bring in this other MM3 site and list into my existing server, especially with regard to the DB backend. The list - let's call it users(a)domainX.name was using MySQL backend and had a separate DB for Mailman core and Mailman web. I believe combining these into one isn't a problem. But getting to merge this DB into my current one is what I am not sure about. Any pointers on how to bring in this new site into my current setup?? -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

1 year, 7 months

Mailman-web showing "An error occurred while processing your request."

by C. Souza

I'm trying to manage 2 held messages in a specific list and I'm getting this error below when I click on /held_messages. It never happened before. My versions are: (venv) [mailman@listas ~]$ pip list -o | grep -E 'posto|hyper|mailma|djang' Package Version Latest Type ------------------- --------- ---------- ----- django-allauth 0.44.0 0.52.0 sdist django-appconf 1.0.4 1.0.5 wheel django-compressor 2.4 4.3.1 wheel django-extensions 3.1.0 3.2.1 wheel django-haystack 3.0 3.2.1 sdist django-mailman3 1.3.5 1.3.9 sdist django-picklefield 3.0.1 3.1 wheel django-q 1.3.4 1.3.9 wheel djangorestframework 3.12.2 3.14.0 wheel mailman 3.3.2 3.3.8 sdist mailman-hyperkitty 1.1.0 1.2.1 sdist mailman-web 0.0.3 0.0.5 wheel mailmanclient 3.3.2 3.3.5 sdist postorius 1.3.3 1.3.8 sdist ==> mailmanweb.log <== ERROR 2023-02-08 16:01:30,149 1516 django.request Internal Server Error: /mailman3/lists/mylist.domain.com/held_messages Traceback (most recent call last): File "/opt/mailman/venv/lib64/python3.6/site-packages/django/core/handlers/exception.py", line 34, in inner response = get_response(request) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/core/handlers/base.py", line 115, in _get_response response = self.process_exception_by_middleware(e, request) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/core/handlers/base.py", line 113, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/contrib/auth/decorators.py", line 21, in _wrapped_view return view_func(request, *args, **kwargs) File "/opt/mailman/venv/lib64/python3.6/site-packages/postorius/auth/decorators.py", line 60, in wrapper return fn(*args, **kwargs) File "/opt/mailman/venv/lib64/python3.6/site-packages/postorius/views/list.py", line 531, in list_moderation return render(request, 'postorius/lists/held_messages.html', context) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/shortcuts.py", line 19, in render content = loader.render_to_string(template_name, context, request, using=using) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/loader.py", line 62, in render_to_string return template.render(context, request) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/backends/django.py", line 61, in render return self.template.render(context) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 171, in render return self._render(context) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 163, in _render return self.nodelist.render(context) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 936, in render bit = node.render_annotated(context) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 903, in render_annotated return self.render(context) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/loader_tags.py", line 150, in render return compiled_parent._render(context) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 163, in _render return self.nodelist.render(context) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 936, in render bit = node.render_annotated(context) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 903, in render_annotated return self.render(context) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/loader_tags.py", line 62, in render result = block.nodelist.render(context) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 936, in render bit = node.render_annotated(context) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 903, in render_annotated return self.render(context) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/defaulttags.py", line 309, in render return nodelist.render(context) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 936, in render bit = node.render_annotated(context) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 903, in render_annotated return self.render(context) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/defaulttags.py", line 209, in render nodelist.append(node.render_annotated(context)) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 903, in render_annotated return self.render(context) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 986, in render output = self.filter_expression.resolve(context) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 697, in resolve new_obj = func(obj, *arg_vals) File "/opt/mailman/venv/lib64/python3.6/site-packages/postorius/templatetags/date_helpers.py", line 30, in datetime_parse return parse_datetime(value) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/utils/dateparse.py", line 107, in parse_datetime match = datetime_re.match(value) TypeError: expected string or bytes-like object

2 years, 4 months

Notes about successfuly upgrade from python 3.7 to 3.9

by Guillermo Hernandez (Oldno7)

I've successfuly upgrade servers with mailman3 lists from FreeBSD 12.3 with python 3.7 to FreeBSD 13.1 with python 3.9 After doing the O.S. and all the python related apps upgraded I did the following steps: (note that my mailman3 installation is system-wide, pip drived and apache24/uwsgi served. The user that owns mailman3 is "mailman3" and all the stuff lies in "/usr/local/mailman3") -> su -> cd /usr/local/mailman3 -> pip install --upgrade django-mailman3 mailman mailman-hyperkitty mailmanclient postorius django hyperkitty uwsgi mod-wsgi -> mod_wsgi-express module-config (it returns the path for the apache24 httpd.conf adjustments. I edited it) -> su -m mailman3 -c "python3 manage.py collectstatic" -> su -m mailman3 -c "python3 manage.py migrate" -> su -m mailman3 -c "python3 manage.py compress" -> cd /usr/local/lib/python3.9/site-packages/ -> cd postorius -> django-admin compilemessages -> cd ../hyperkitty -> django-admin compilemessages -> cd ../django_mailman3 -> django-admin compilemessages I had to edit again /usr/local/lib/python3.9/site-packages/mistune/scanner.py and add this two lines (this is a little bit annoying) from mistune.util import escape_html from mistune.util import escape_url And that was all. Restarted the servers and all is going smoothly All of this steps have been documented in this list by Mark & Stephen whom I'm very grateful. P.S.: As I did some upgrades ago, I didn't have to modify settings.py in the Hyperkitty area to add DEFAULT_AUTO_FIELD = 'django.db.models.AutoField' But if you come from an old mailman/Hyperkitty version, you'll have to include in it. And the it's same if you are using UWSGI, you have to include in your apache config: WSGIPassAuthorization On -- ___________________________________________ 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, 11 months

Re: Mailman3 throws 500 error (unicode encode) when loading held messages in Postorius

by Simon Handfield

Thanks for your advice, Stephen. As I've removed the file from the shunt queue I don't believe that file is causing the 500 error any more. I've confirmed the error is not cached in the browser. If the issue does not reside in the shunt queue (no other files indicate parse errors when checking via command line) are there any other places I should look for data that is addressed by that page? Cheers, Simon. ________________________________ From: Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> Sent: Monday, 31 August 2020 23:51 To: Simon Handfield <simon.handfield(a)sl.nsw.gov.au> Cc: mailman-users(a)mailman3.org <mailman-users(a)mailman3.org> Subject: [MM3-users] Re: Mailman3 throws 500 error (unicode encode) when loading held messages in Postorius Simon Handfield via Mailman-users writes: > I have been able to identify a file in the shunt queue that threw a > matching error when I performed mailman qfile on it. > I have run a loop over all remaining files in the shunt queue and > all the remaining files can be accessed by mailman qfile without > error. Good. But there are still a bunch of problems with those files since they got shunted. > I moved this file out of the queue in the hope that I would then be > able to load the held_messages page successfully. Unfortunately I > am still seeing a 500 error on loading the page. If this is a Mailman problem, I don't understand it. The shunt queue is not the moderation queue. The shunt queue is for messages that Mailman cannot handle without throwing an exception. Once a message is sent to the shunt queue, Mailman ignores it, so it shouldn't cause problems for the moderation page. Have you tried restarting Mailman since moving the qfile? If that doesn't work, and if it's the same error message and traceback, the easy suspect is browser caching (although we should be disabling that, I hope). Try a manual refresh (usually Ctrl-R or in the menu). If that doesn't work, try a private browsing window or another browser if you don't want to clear the cache or restart the browser. > I temporarily reenabled debug logging to confirm that the same > error was being thrown. > > Assuming that file was the cause are there other steps I need to > perform in addition to removing the file from the shunt queue > directory? The only one I can think of is the check for browser-side caching. Unfortunately, Mark's out of town (like, on top of a mountain with no bars on his phone), and I am not going to be able to do much with this until Thursday at the earliest. If you do get a new traceback, post it here (somebody else may have an idea). If you like you may send me the qfile at the address in From. I'll see if I can reproduce the bug, and I'm pretty sure I can tell you what's in the file so at least you'll know whether it's important to somebody who isn't a scammer/spammer. Steve _ [State Library of NSW]<https://www.sl.nsw.gov.au/> Simon Handfield Desktop and Infrastructure Leader simon.handfield(a)sl.nsw.gov.au<mailto:simon.handfield@sl.nsw.gov.au> +61 2 9273 1535 Macquarie Street, Sydney NSW 2000, Australia www.sl.nsw.gov.au<https://www.sl.nsw.gov.au/> This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Views expressed in this message are those of the individual sender, and are not necessarily the views of their organisation.

4 years, 9 months

Can login at /admin, but cannot login at the account/login page.

by pabsta＠gmail.com

Hi All, thanks for your contibution to opensource softwares. I have done the installation walkthrough on the wiki page (thanks to Brian Carpenter) and I am almost there. I can run the three services and they provide the relevant web interfaces (admin, postorius, hyperkitty). In comparison to the walkthrough, I did two changes; First, I used different port numbers , as it would otherwise conflict with other services on the server. Second, I disabled the social accounts authentification mechanisms. I am still running on sqllite, as I am still testing things (one task at a time). Using my "superuser" credentials, I can log to the admin section in a fraction of a second. The server response time is less than one second. Once logged in, I can navigate through all the site as an authenticated user, including in the postorius pages related to list management. The services work normally. However, if logout and attempt to login from the postorius website, I get a « 502 bad gateway » error after roughly 30 seconds. The logs in Systemctl for gunicorn register a "DIGEST-MD5 common mech free" error message and the nginx error logs just show a connection drop: 2021/08/12 18:11:09 [error] 26026#26026: *31 upstream prematurely closed connection while reading response header from upstream, client: [ip redacted], server: [domain redacted], request: "POST /accounts/login/ HTTP/2.0", upstream: "http://127.0.0.1:8006/accounts/login/", host: "[domain redacted]", referrer: "https://[domain redacted]/accounts/login/?next=/mailman3/lists/" Two additional clues may help understanding what is going on: 1- If I attempt to login with improper credentials, the services respond normally, and I get the expected red box with "invalid credentials" message on the postorius page. It is only when proper credentials are given that the connection fails. 2- If I attempt to register a new email adress, the services also fail to respond (although with no DIGEST-MD5 message registered). It thus seems to be a post "POST" problem, but what puzzles me is that it is not an issue for the admin page. Below the relevant sections of my settings.py page. The skipped ([...]) sections are as in the walkthrough files. In particular, the AUTH_PASSWORD_VALIDATORS, the EMAIL_BACKEND are as is and the "USE_X_FORWARDED_HOST" is still commented. ##Settings.py [...] # SECURITY WARNING: keep the secret key used in production secret! SECRET_KEY = '[redacted]' # SECURITY WARNING: don't run with debug turned on in production! DEBUG = False ADMINS = ( ('ME', 'my@email'), ) SITE_ID = 1 # Hosts/domain names that are valid for this site; required if DEBUG is False # See https://docs.djangoproject.com/en/1.8/ref/settings/#allowed-hosts ALLOWED_HOSTS = [ "localhost", # Archiving API from Mailman, keep it. "[domain]", # Add here all production URLs you may have. ] # Mailman API credentials MAILMAN_REST_API_URL = 'http://localhost:8005' MAILMAN_REST_API_USER = '[redacted]' MAILMAN_REST_API_PASS = '[redacted]' MAILMAN_ARCHIVER_KEY = '[redacted]' MAILMAN_ARCHIVER_FROM = ('127.0.0.1', '::1') # Application definition INSTALLED_APPS = ( 'hyperkitty', 'postorius', 'django_mailman3', # Uncomment the next line to enable the admin: 'django.contrib.admin', # Uncomment the next line to enable admin documentation: # 'django.contrib.admindocs', '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', #'django_mailman3.lib.auth.fedora', #'allauth.socialaccount.providers.openid', #'allauth.socialaccount.providers.github', #'allauth.socialaccount.providers.gitlab', #'allauth.socialaccount.providers.google', #'allauth.socialaccount.providers.facebook', #'allauth.socialaccount.providers.twitter', #'allauth.socialaccount.providers.stackexchange', ) [...] # Database # https://docs.djangoproject.com/en/1.8/ref/settings/#databases DATABASES = { 'default': { # Use 'sqlite3', 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'. 'ENGINE': 'django.db.backends.sqlite3', # DB name or path to database file if using sqlite3. 'NAME': os.path.join(BASE_DIR, 'mailmansuite.db'), # The following settings are not used with sqlite3: 'USER': 'XXX', 'PASSWORD': 'XXX', # HOST: empty for localhost through domain sockets or '127.0.0.1' for # localhost through TCP. 'HOST': '', # PORT: set to empty string for default. 'PORT': '', # OPTIONS: for mysql engine only, do not use with other engines. # 'OPTIONS': {'charset': 'utf8mb4'} # Enable utf8 4-byte encodings. } } [...] # Password validation # https://docs.djangoproject.com/en/1.9/ref/settings/#auth-password-validators AUTH_PASSWORD_VALIDATORS = [ { 'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator', }, { 'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator', }, { 'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator', }, { 'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator', }, ] # Internationalization # https://docs.djangoproject.com/en/1.8/topics/i18n/ LANGUAGE_CODE = 'fr' TIME_ZONE = 'America/New_York' [...] # If you enable internal authentication, this is the address that the emails # will appear to be coming from. Make sure you set a valid domain name, # otherwise the emails may get rejected. # https://docs.djangoproject.com/en/1.8/ref/settings/#default-from-email # DEFAULT_FROM_EMAIL = "mailing-lists(a)you-domain.org" DEFAULT_FROM_EMAIL = 'username@domain' # If you enable email reporting for error messages, this is where those emails # will appear to be coming from. Make sure you set a valid domain name, # otherwise the emails may get rejected. # https://docs.djangoproject.com/en/1.8/ref/settings/#std:setting-SERVER_EMAIL # SERVER_EMAIL = 'root(a)your-domain.org' SERVER_EMAIL = 'username@domain' # Change this when you have a real email backend EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend' [...] # # Social auth # AUTHENTICATION_BACKENDS = ( 'django.contrib.auth.backends.ModelBackend', 'allauth.account.auth_backends.AuthenticationBackend', ) # Django Allauth ACCOUNT_AUTHENTICATION_METHOD = "username_email" ACCOUNT_EMAIL_REQUIRED = True ACCOUNT_EMAIL_VERIFICATION = "mandatory" # You probably want https in production, but this is a dev setup file ACCOUNT_DEFAULT_HTTP_PROTOCOL = "https" ACCOUNT_UNIQUE_EMAIL = True # # Asynchronous tasks # Q_CLUSTER = { 'timeout': 300, 'save_limit': 100, 'retry':360, 'orm': 'default', } [...] # Only display mailing-lists from the same virtual host as the webserver FILTER_VHOST = True POSTORIUS_TEMPLATE_BASE_URL = 'http://localhost:8006' ## (End of settings.py) I'm happy to provide additional information if it can help. Best, Pier-André

3 years, 10 months

Re: Template - "You can use these variables in the templates" - The variable for "leave" is missing

by Mark Sapiro

On 11/4/23 06:28, Stephen J. Turnbull wrote: > Wikinaut writes: > > > fxied in merge request > > https://gitlab.com/mailman/postorius/-/merge_requests/852 > > I wish you wouldn't. It's just bloat in the code and in the > docstring. Better to document that the administrative addresses can > be constructed using ${short_listname}. I believe Mailman still > supports both "list-leave" and "list-unsubscribe", as well. Actually, https://gitlab.com/mailman/postorius/-/merge_requests/852 only added documentation of the existing $description replacement which is appropriate, but it duplicates part of https://gitlab.com/mailman/postorius/-/merge_requests/851 which does that and adds a bit more documentation. Also see https://gitlab.com/mailman/mailman/-/issues/1108 and https://gitlab.com/mailman/mailman/-/merge_requests/1153 -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 7 months

Re: Error while mass operation, no progress display while mass operation is running

by Mark Sapiro

On 2/6/25 04:53, Markus Grandpré wrote: > > At the University of Konstanz we have mailing list administrators who > frequently add and remove up to 10000 (and sometimes more) list members. > I have therefore tested the “Mass subscription” and “Mass removal” > operations and found that both the “Remove ALL members” operation and > the “Mass subscription” operation report an internal server error on the > website, but continue to run in the background until all new members > have been successfully added or deleted. The internal server error is probably due to the wsgi server timing out waiting for a response. See https://docs.gunicorn.org/en/stable/settings.html#timeout for Gunicorn or https://uwsgi-docs.readthedocs.io/en/latest/Options.html#harakiri for uWSGI > Unfortunately, I have not found > any error message in the log files. If you are using uWSGI, a harakiri timeout should be logged in uWSGI's log. > I also tested that mass operations > “Remove listed users” and “Remove Selected” ran successfully and without > any errors. You may want to increase the appropriate timeout and see if that helps. > Regardless of whether a mass operation process runs without errors or > continues to run despite an error, I find it hard that Postorius does > not display the progress of such a mass operation in order to monitor > the process, as mass operations with more than 1000 members are very > time-consuming. Perhaps this could be changed in a future version of > Postorius? This is a reasonable request. The best place for such a request is https://gitlab.com/mailman/postorius/-/issues/new Requests and suggestions on the mailing list, no matter how reasonable, get lost over time. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 months, 1 week

Re: Moderator e-mails only going out once a day

by Stephen J. Turnbull

jkoral(a)luc.edu writes: > -Mailman was installed using the virtual environment. > -Mailman info: > -I use systemd to stop and start the services. OK, this is all about as close to the environment most of the Mailman devs run as you can get. On the one hand, it's easiest for us to understand, but it also makes it more mysterious when something doesn't work ... "works for me", you know. > REST credentials: restadmin:restpass You should change this. It just makes it a little more annoying for someone unauthorized who gets access to port 8001, but it's very low cost to change. > -Virgin is running: > Note: Not sure how to check the queue, but when I run mailman3 > notify, the moderator e-mails get sent. Good. The queues are implemented with Python pickle files in the "queue" subtree, probably /opt/mailman/var/queue in your case, or maybe /opt/mailman/mm/var/queue if you use Mark's preferred setup. You're looking for .pck files in subdirectories of that directory which are older than about 5 minutes. I don't have a suggestion why the "notify immediately" option isn't working. Both the 'mailman notify' command and the 'notify immediately' option work the same way, by composing the notification and dropping it in the virgin queue. This should tell you the same thing that Postorius does, but you could try "su - mailman" followed by activating the virtual environment, then type mailman withlist -l list.with.problem and then m.admin_immed_notify expecting the response True according to your setting. If it comes up False, there's your problem but we need to figure out why that's different from what Postorius is telling you. You should be able to change it as well by typing m.admin_immed_notify = True commit() and exiting. Steve

2 months, 3 weeks

Re: Held messages: Long time waiating for response of the Mailman API

by Stephen J. Turnbull

Krinetzki, Stephan writes: > Hi everyone, > > any news here? We are running with Pyton 3.6 - maybe a Python > Upgrade can speed Mailman up? It would help if you provide the original description. I see you're running Apache + uswgi. uwsgi has been pretty finicky, and most of the developers use gunicorn as the WSGI host. I suggest you ask on the uswgi channels as well. (I don't think that's a *better* place to ask, just a relevant place.) You wrote: > If we try to approve them via Postorius, the message is delivered > to the list immediately, but the success message in Postorius takes > a long time - on average the process hangs for three minutes until > the message is no longer displayed. You jump to the conclusion that the REST API is slow, but there's zero evidence to localize to the REST API. If your browser isn't running on the same host as the webserver it could even be some kind of network timeout (reverse DNS?) completely unrelated to Mailman (unlikely, but can't be ruled out with the information provided). 1. What is in the various logs? Mailman core, Django, your backend database, the webserver, the WSGI hosts all may be writing to logs, especially if there's some kind of time out or other error condition. 2. Are all the relevant components running on the same host? Are there other web services running under Apache and/or WSGI? 3. What are the relevant configurations (Apache, uswgi, gunicorn, Mailman, Postorius, Django, database, DNS A/AAAA/CNAME)? This would be anything like port numbers and host names or IP addresses, user names and passwords (we don't need to know these, but you should provide obfuscated versions so we can check syntax, and of course you should check for typos). Steve

3 years, 4 months

Mailman-users search results for query "Postorius"