Search results for "sapiro" - lists.mailman3.org

[MM3-users] Re: Delete Django profiles not signed up to a list

by Allan Hansen

Mark, Will this be part of an upcoming update or micro update to Mailman? Yours, Allan Hansen P.O. Box 2423 Cypress, CA 90630 > On Mar 31, 2023, at 15:49, Mark Sapiro <mark(a)msapiro.net> wrote: > > On 3/31/23 14:17, Andrew Hodgson wrote: >> Hi. >> Has anyone managed to get this script running using the Mailman-Web setup in a venv? It was working when Settings.py was in the /opt/mailman/mm directory but since moving to Mailman-Web has it in /etc/mailman3. I have been trying to import Mailman-Web to get the Django environment running but every time I do this I get a not configured exception raised. > > > First, get the latest version of the script from https://www.msapiro.net/scripts/clean_users.py - not the one in this threat attached to https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > > Then, you need to change `/opt/mailman/mm` in three places to `/etc/mailman3` as in > ``` > --- /opt/mailman/mm/bin/clean_users.py 2021-05-08 20:03:31.657565251 -0700 > +++ clean_users.py 2023-03-31 15:48:31.772383287 -0700 > @@ -2,13 +2,13 @@ > import os > import sys > > -sys.path.insert(0, '/opt/mailman/mm') > +sys.path.insert(0, '/etc/mailman3') > # The above line is required. The next line doesn't hurt, but it doesn't work > # because the PYTHONPATH environment setting is processed by Python's setup > # and must be in the environment when Python starts to be effective. > -os.environ['PYTHONPATH'] = '/opt/mailman/mm' > +os.environ['PYTHONPATH'] = '/etc/mailman3' > os.environ['DJANGO_SETTINGS_MODULE'] = 'settings' > -os.environ['MAILMAN_CONFIG_FILE'] = '/opt/mailman/mm/mailman.cfg' > +os.environ['MAILMAN_CONFIG_FILE'] = '/etc/mailman3/mailman.cfg' > > import django > django.setup() > ``` > Also, look at this > ``` > # If we delete the Django user and there is a Mailman user with no memberships > # shall we delete the Mailman user too. > DELETE_MAILMAN_USER = False > # Shall we delete the Django user if there is a Mailman user with no > # memberships or only if there is no Mailman user. > DELETE_DJANGO_IF_MAILMAN = True > ``` > and consider whether you want to set `DELETE_MAILMAN_USER = True` to also delete the Mailman user if any, and/or set `DELETE_DJANGO_IF_MAILMAN = False` to not delete the django user if there is a Mailman user with no memberships. > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > > _______________________________________________ > 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/ > Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > This message sent to hansen(a)rc.org

2 years, 10 months

[MM3-users] Re: Still unable to get mailman3 working on Ubuntu 20.04 LTS

by Mark Sapiro

On 1/9/22 3:26 AM, Michael Heseltine wrote: >> This isn't your immediate problem, but it is an issue. The above isn't >> too informative. What do you get if you run >> >> /opt/mailman/mm/bin/django-admin qcluster >> >> manually? > > I get the following: > >> # /opt/mailman/mm/bin/django-admin qcluster >> 11:50:41 [Q] INFO Q Cluster autumn-sixteen-tango-march starting. >> 11:50:41 [Q] INFO Process-1:1 ready for work at 3725610 >> 11:50:41 [Q] INFO Process-1:2 ready for work at 3725611 >> 11:50:42 [Q] INFO Process-1:3 ready for work at 3725612 >> 11:50:42 [Q] INFO Process-1:4 ready for work at 3725613 >> 11:50:42 [Q] INFO Process-1:5 monitoring at 3725614 >> 11:50:42 [Q] INFO Process-1 guarding cluster autumn-sixteen-tango-march >> 11:50:42 [Q] INFO Process-1:6 pushing tasks at 3725615 >> 11:50:42 [Q] INFO Q Cluster autumn-sixteen-tango-march running. > > And then nothing until I end the command with Ctrl-C. This is what I would expect. It seems to be working. I'm not sure why it fails when run from systemd. Are you running memcached? systemctl status memcached.service That needs to be installed and running for qcluster. > Sorry, I didn't realize that they were truncated. Here are ( I hope) the full logs from /var/log/syslog: > >> Jan 8 21:24:57 lists systemd[1]: Started GNU Mailman web interfaces. >> Jan 8 21:24:57 lists gunicorn[3707354]: !!! >> Jan 8 21:24:57 lists gunicorn[3707354]: !!! WARNING: configuration file should have a valid Python extension. >> Jan 8 21:24:57 lists gunicorn[3707354]: !!! >> Jan 8 21:24:57 lists gunicorn[3707354]: Traceback (most recent call last): >> Jan 8 21:24:57 lists gunicorn[3707354]: File "/opt/mailman/mm/venv/lib/python3.8/site-packages/gunicorn/arbiter.py", line 209, in run >> Jan 8 21:24:57 lists gunicorn[3707354]: self.sleep() >> Jan 8 21:24:57 lists gunicorn[3707354]: File "/opt/mailman/mm/venv/lib/python3.8/site-packages/gunicorn/arbiter.py", line 357, in sleep >> Jan 8 21:24:57 lists gunicorn[3707354]: ready = select.select([self.PIPE[0]], [], [], 1.0) >> Jan 8 21:24:57 lists gunicorn[3707354]: File "/opt/mailman/mm/venv/lib/python3.8/site-packages/gunicorn/arbiter.py", line 242, in handle_chld >> Jan 8 21:24:57 lists gunicorn[3707354]: self.reap_workers() >> Jan 8 21:24:57 lists gunicorn[3707354]: File "/opt/mailman/mm/venv/lib/python3.8/site-packages/gunicorn/arbiter.py", line 525, in reap_workers >> Jan 8 21:24:57 lists gunicorn[3707354]: raise HaltServer(reason, self.WORKER_BOOT_ERROR) >> Jan 8 21:24:57 lists gunicorn[3707354]: gunicorn.errors.HaltServer: <HaltServer 'Worker failed to boot.' 3> >> Jan 8 21:24:57 lists gunicorn[3707354]: During handling of the above exception, another exception occurred: >> Jan 8 21:24:57 lists gunicorn[3707354]: Traceback (most recent call last): >> Jan 8 21:24:57 lists gunicorn[3707354]: File "/opt/mailman/mm/bin/gunicorn", line 14, in <module> >> Jan 8 21:24:57 lists gunicorn[3707354]: sys.exit(gunicorn.app.wsgiapp.run()) >> Jan 8 21:24:57 lists gunicorn[3707354]: File "/opt/mailman/mm/venv/lib/python3.8/site-packages/gunicorn/app/wsgiapp.py", line 67, in run >> Jan 8 21:24:57 lists gunicorn[3707354]: WSGIApplication("%(prog)s [OPTIONS] [APP_MODULE]").run() >> Jan 8 21:24:57 lists gunicorn[3707354]: File "/opt/mailman/mm/venv/lib/python3.8/site-packages/gunicorn/app/base.py", line 231, in run >> Jan 8 21:24:57 lists gunicorn[3707354]: super().run() >> Jan 8 21:24:57 lists gunicorn[3707354]: File "/opt/mailman/mm/venv/lib/python3.8/site-packages/gunicorn/app/base.py", line 72, in run >> Jan 8 21:24:57 lists gunicorn[3707354]: Arbiter(self).run() >> Jan 8 21:24:57 lists gunicorn[3707354]: File "/opt/mailman/mm/venv/lib/python3.8/site-packages/gunicorn/arbiter.py", line 229, in run >> Jan 8 21:24:57 lists gunicorn[3707354]: self.halt(reason=inst.reason, exit_status=inst.exit_status) >> Jan 8 21:24:57 lists gunicorn[3707354]: File "/opt/mailman/mm/venv/lib/python3.8/site-packages/gunicorn/arbiter.py", line 342, in halt >> Jan 8 21:24:57 lists gunicorn[3707354]: self.stop() >> Jan 8 21:24:57 lists gunicorn[3707354]: File "/opt/mailman/mm/venv/lib/python3.8/site-packages/gunicorn/arbiter.py", line 393, in stop >> Jan 8 21:24:57 lists gunicorn[3707354]: time.sleep(0.1) >> Jan 8 21:24:57 lists gunicorn[3707354]: File "/opt/mailman/mm/venv/lib/python3.8/site-packages/gunicorn/arbiter.py", line 242, in handle_chld >> Jan 8 21:24:57 lists gunicorn[3707354]: self.reap_workers() >> Jan 8 21:24:57 lists gunicorn[3707354]: File "/opt/mailman/mm/venv/lib/python3.8/site-packages/gunicorn/arbiter.py", line 525, in reap_workers >> Jan 8 21:24:57 lists gunicorn[3707354]: raise HaltServer(reason, self.WORKER_BOOT_ERROR) >> Jan 8 21:24:57 lists gunicorn[3707354]: gunicorn.errors.HaltServer: <HaltServer 'Worker failed to boot.' 3> >> Jan 8 21:24:58 lists systemd[1]: gunicorn.service: Main process exited, code=exited, status=1/FAILURE >> Jan 8 21:24:58 lists systemd[1]: gunicorn.service: Failed with result 'exit-code'. I'm not sure about this one either. You might want to look at https://stackoverflow.com/questions/24488891/gunicorn-errors-haltserver-hal… or other hits from https://www.google.com/search?q=gunicorn+worker+failed+to+boot Are your files /etc/systemd/system/gunicorn.service /opt/mailman/mm/bin/gunicorn opt/mailman/mm/gunicorn.conf the same as recommended at https://wiki.list.org/DOC/Mailman%203%20installation%20experience?action=At… https://wiki.list.org/DOC/Mailman%203%20installation%20experience?action=At… https://wiki.list.org/DOC/Mailman%203%20installation%20experience?action=At… -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 1 month

[MM3-users] Re: Hyperkitty no longer archiving

by Hirayama, Pat

Hi Mark! > -----Original Message----- > From: Mark Sapiro <mark(a)msapiro.net> > Sent: Tuesday, November 22, 2022 12:19 PM > To: mailman-users(a)mailman3.org > Subject: [MM3-users] Re: Hyperkitty no longer archiving > > First, my apologies for not taking note of your MAILMAN_ARCHIVER_FROM > setting in your OP. No worries. I tried to include everything that might be needed for you and the other frequent posters to be able to give me an answer, and all of you respond to a LOT of posts. > On 11/22/22 08:52, Hirayama, Pat wrote: > > Steve wrote: > >> 2. Does settings.py have "from settings_local import *" in it? > > > > Yes. I assume that overrides the MAILMAN_ARCHIVER_FROM and other > related settings defined at the top of the settings.py file? Or should I update > settings.py based on what is in settings_local.py? > > > Assuming the `from settings_local import *` is at the end of > settings.py, anything defined in settings_local.py will override the > definition in settings.py. There's no need to change settings.py. This is the end of settings.py: # # HyperKitty-specific # # Only display mailing-lists from the same virtual host as the webserver FILTER_VHOST = False POSTORIUS_TEMPLATE_BASE_URL = 'http://localhost:8000' try: from settings_local import * except ImportError: pass I'm assuming that is close enough to the end? <snip> > > The > ``` > ERROR 2022-11-22 00:25:40,365 7 hyperkitty.views.mailman Access to the > archiving API endpoint was forbidden from IP 172.31.0.1, your > MAILMAN_ARCHIVER_FROM setting may be misconfigured > ``` > message comes from > https://urldefense.com/v3/__https://gitlab.com/mailman/hyperkitty/- > /blob/master/hyperkitty/views/mailman.py*L62__;Iw!!GuAItXPztq0!hLVF14 > B0x45qVgO6PBHbLDw0TH9RiV8rrAVWDBuswab7QFb56LlCxdyihoc- > 2F4ZHdqDTdXzj4YgcLM$ > which only occurs if '172.31.0.1' is not in MAILMAN_ARCHIVER_FROM. Given > that it is in MAILMAN_ARCHIVER_FROM as defined in settings_local.py, the > only thing I can conclude is that the Django settings actually used is > not the settings.py you think it is. > > I don't know offhand even what wsgi service is used in the docker > container or how it is configured, but it needs to set its working > directory to the directory containing settings.py. > So, looking at the Django container, I see this process popping up periodically. I think that means that it is running from the directory specified by "--pythonpath"" (which is where settings.py and settings_local.py are located). I am further assuming that "--settings settings" is ok without a .py extension. 53972 mail 0:00 {django-admin} /usr/local/bin/python /usr/local/bin/django-admin runjobs quarter_hourly --pythonpath /opt/mailman/mailman-suite/mailman-suite_project/. --settings settings 53978 mail 0:00 {django-admin} /usr/local/bin/python /usr/local/bin/django-admin runjobs minutely --pythonpath /opt/mailman/mailman-suite/mailman-suite_project/. --settings settings > -- > 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

[MM3-users] Re: Updating from Ubuntu-20.04 LTE installation

by Abhilash Raj

On Sat, May 23, 2020, at 8:28 PM, Mark Sapiro wrote: > On 5/23/20 7:02 PM, Peter Adebahr via Mailman-users wrote: > > > > Our installation was done by "apt-get install" in Ubuntu 20, thus still > > running MM 3.2.2 (and python 3.8.2). > > > > Do you have any advise, how to upgrade from there to your current > > version? I know this might be a bit dangerous, but with today's VMs the > > risk is much less than it used to be: > > > It shouldn't be difficult, but I can't give you details because I don't > know exactly how the Debian/Ubuntu package installs things. Also I don't > know whether "current version" refers to the 3.3.1 release or the head > of the https://gitlab.com/mailman/mailman master branch. > > > > Do you think it would be possible, just to replace the code and library > > parts, keeping the database and config files as is? > > > Yes. It should be fairly straightforward. You first need to find where > the Mailman Core package is. You should be able to just replace the > contents of the `mailman` package directory with ours. You may be able > to do this via pip > > pip install --upgrade mailman > > globally or within Mailman's virtualenv if it is installed in a virtualenv. This is probably not a good idea, global install quite often breaks a lot of stuff (Like I broke Yum on my work computer since I wanted something newer than 10yo python packages). A better idea would be to install Mailman from scratch inside a virtualenv somewhere in /opt/mailman and then letting it consume the same configurations. I think Ubuntu/Debian have their configurations in `/etc/mailman3/` and Mailman Core installed anywhere should just pick that up without any special work. Same goes for Postorius/Django stuff. You can switch to a different Django project and just point to Debian/Ubuntu's settings.py (location of which should be in README.debian of the Debian package I presume). > However, there are caveats. There are Debian patches at > <https://sources.debian.org/patches/mailman3/3.2.2-1/>. The big `0002` > patch replaces importlib_resources with importlib.resources because > importlib_resources is not available in Debian. Most of the patches > apply to tests, and for the actual working code, we fixed this > differently as of Mailman 3.3.1, so I don't think you need the Debian > patches. > > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > _______________________________________________ > 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)

5 years, 8 months

[MM3-users] Re: django-allauth failures, but only for some users (independent of browser?)

by Jered Floyd

I'll dig at that; thanks. I've just managed to get one of my Google accounts into this "broken" state, although I'm not entirely sure how I did it (or where the broken state is stored). This happened after I tried using the "Sign In" button on a list info page rather than the one in the upper right corner, but that may just be a red herring. I'll report back if I find anything. --Jered ----- On Dec 6, 2023, at 3:21 PM, Mark Sapiro mark(a)msapiro.net wrote: > On 12/6/23 11:00, Jered Floyd wrote: >> > These errors are generated to me as the admin, and in the elided > environment section SITE_ID is indeed 0, but I'm at a loss to imagine > why this happens only sometimes! > > For me, on a test installation with SITE_ID = 0, this only occurs at > https://example.com/accounts/social/connections/ > > Other URLs such as https://example.com/accounts/password/change/ and > https://example.com/accounts/email/ do not throw this exception. > > Here's the code: > ``` > def get_current(self, request=None): > """ > Return the current Site based on the SITE_ID in the project's > settings. > If SITE_ID isn't defined, return the site with domain matching > request.get_host(). The ``Site`` object is cached the first > time it's > retrieved from the database. > """ > from django.conf import settings > > if getattr(settings, "SITE_ID", ""): > site_id = settings.SITE_ID > return self._get_site_by_id(site_id) > elif request: > return self._get_site_by_request(request) > > raise ImproperlyConfigured( > 'You\'re using the Django "sites framework" without having ' > "set the SITE_ID setting. Create a site in your database and " > "set the SITE_ID setting or pass a request to " > "Site.objects.get_current() to fix this error." > ) > ``` > > I tried patching it from > ``` > if getattr(settings, "SITE_ID", ""): > ``` > to > ``` > if getattr(settings, "SITE_ID", None) is not None: > ``` > but that's even worse. It throws a bunch of > "django.contrib.sites.models.Site.DoesNotExist: Site matching query does > not exist." errors. > > Somehow, get_current is being called without a request object in the > cases where it fails. > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > > _______________________________________________ > 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/ > Archived at: > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > This message sent to jered(a)convivian.com

2 years, 2 months

[MM3-users] Re: A little stuck with installation of MM3 - ModuleNotFoundError: No module named 'flufl.lock'

by Mark Sapiro

On 7/25/20 12:54 PM, Odhiambo Washington wrote: > > Finally, I have adapted your init script to get some rudimentary one that I > could use on FreeBSD. > I have to change /opt/mailman to be owned by mailman3:mailman3 (because I > have "live" MLs on this server, using mailman-2.1.34. > I am not sure if they can co-exist. I suppose they could, but what might be > the security implication, if any?? I manage more than one server that supports both Mailman 2.1 and Mailman 3 running as user `mailman`. I'm not aware of any security issues. > This is what the init script looks like (rudimentary!!): > (venv) [root@gw /usr/local/etc/rc.d]# less mailman3 > ### BEGIN INIT INFO > # Provides: GNU Mailman > # Short-Description: Mailman3 Service > # Description: service control for Mailman3 > ### END INIT INFO > > PATH=/opt/mailman/mm/bin:/opt/mailman/mm/venv/bin:/usr/sbin:/usr/bin:/bin:/sbin: > DESC="GNU Mailman service" > DAEMON=/opt/mailman/mm/bin/mailman > NAME=mailman > USER=mailman3 > GROUP=mailman3 > > # Needed by click > export LANG=en_US.UTF-8 > > # Exit if the package is not installed > [ -x "$DAEMON" ] || exit 0 > > # Load the VERBOSE setting and other rcS variables > #. /lib/init/vars.sh > > # Define LSB log_* functions. > # Depend on lsb-base (>= 3.2-14) to ensure that this file is present > # and status_of_proc is working. > #. /lib/lsb/init-functions > > case "$1" in > start) > [ "$VERBOSE" != no ] && echo "Starting $DESC" "$NAME" > # use --force to remove a stale lock. > /usr/local/bin/sudo -u $USER $DAEMON start --force T don't recommend using --force in init scripts. It *shouldn't* matter because even with --force the master shouldn't break the lock if the pip that set it still exists, but I prefer not to use it. > ;; > stop) > [ "$VERBOSE" != no ] && echo "Stopping $DESC" "$NAME" > /usr/local/bin/sudo -u $USER $DAEMON stop > ;; > status) > /usr/local/bin/sudo -u $USER $DAEMON status > ;; > reopen) > /usr/local/bin/sudo -u $USER $DAEMON reopen > ;; > restart) > log_daemon_msg "Restarting $DESC" "$NAME" > /usr/local/bin/sudo -u $USER $DAEMON restart > ;; > *) > echo "Usage: $SCRIPTNAME {start|stop|status|reopen|restart}" >&2 > exit 3 > ;; > esac > > It does start mailman3 for sure, but also complains after a few seconds > with the message: > > (venv) [root@gw /usr/local/etc/rc.d]# > */opt/mailman/mm/venv/lib/python3.7/site-packages/mailman-3.3.2b1-py3.7.egg/mailman/rest/wsgiapp.py:180: > DeprecatedWarning: Call to deprecated function __init__(...). API class may > be removed in a future release, use falcon.App instead.* > * **kws)* Hmm... strange, My various MM 3 installs are running falcon 1.4.0, 2.0.0 and 3.0.0a1 and I don't see this warning, but it is only a deprecation warning. It doesn't mean it won't work. > But: > > (venv) [root@gw /usr/local/etc/rc.d]# ps ax | grep mailman ... It seems Mailman core and the rest runner and its workers are all running. > > Assuming that I am using mod_wsgi with Apache, and that I have configured > apache right using > https://wiki.list.org/DOC/Mailman%203%20installation%20experience?action=At… > .. > should I be able to access the MM3 web UI?? Yes, I think so. > At that point, I am feeling somewhat confused as to what to try next. > > (venv) [root@gw /opt/mailman/mm/var/logs]# less mailman.log > Jul 25 22:53:16 2020 (40670) Master started > Jul 25 22:53:18 2020 (42036) bounces runner started. > Jul 25 22:53:18 2020 (45205) out runner started. > Jul 25 22:53:19 2020 (41191) archive runner started. > Jul 25 22:53:19 2020 (46670) retry runner started. > Jul 25 22:53:19 2020 (44567) nntp runner started. > Jul 25 22:53:19 2020 (43069) in runner started. > Jul 25 22:53:19 2020 (46960) virgin runner started. > Jul 25 22:53:20 2020 (45720) pipeline runner started. > Jul 25 22:53:20 2020 (47326) digest runner started. > Jul 25 22:53:20 2020 (43755) lmtp runner started. > Jul 25 22:53:20 2020 (45922) rest runner started. > [2020-07-25 22:53:20 +0300] [45922] [INFO] Starting gunicorn 20.0.4 > [2020-07-25 22:53:20 +0300] [45922] [INFO] Listening at: > http://127.0.0.1:8001 (45922) > [2020-07-25 22:53:20 +0300] [45922] [INFO] Using worker: sync > [2020-07-25 22:53:20 +0300] [54732] [INFO] Booting worker with pid: 54732 > [2020-07-25 22:53:20 +0300] [55467] [INFO] Booting worker with pid: 55467 > Jul 25 22:53:21 2020 (42743) command runner started. The above is all fine, but it is just Mailman core. > How do I access the web UI for MM3 now? The Apache config points to /opt/mailman/mm/wsgi.py, a sampole of which is at <https://wiki.list.org/DOC/Mailman%203%20installation%20experience?action=At…>. Do you have that? If you installed the Apache config literally, the location for Mailman 3 is defined by <https://wiki.list.org/DOC/Mailman%203%20installation%20experience?action=At…> and the URL would be http(s)://your.server/mm3 - have you tried that? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 6 months

[MM3-users] Re: Held messages: Long time waiating for response of the Mailman API

by Stephan Krinetzki

Mark Sapiro wrote: > On 1/24/22 15:06, Mark Sapiro wrote: > > On 1/18/22 06:24, Stephan Krinetzki wrote: > > Hello, > > We are using Mailman 3.3.5 with Hyperkitty 1.3.5. Mailman 3 is > > installed in a venv and deployed using Apache and uwsgi. This works > > quite well so far, only withheld messages cause us a problem: 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. We have already adjusted the timeout > > in gunicorn.cfg, but this does not improve the situation. Are there > > any tips on how we can speed up the REST API? Or is it even a > > configuration error? > > There are two steps in handling the POST for a held message. The first > > step is accepting, rejecting or discarding the message. This is > > happening immediately. > > The second step is handling the poster's moderation action based on the > > choice from the Set member moderation dropdown in the view of the held > > message. This is processed by the code at > > https://gitlab.com/mailman/postorius/-/blob/master/src/postorius/views/list…. > > If no selection has been made, the default value POSTed for > > moderation_choice is no-action and that code is skipped. If it is one > > of the choices Hold for moderation, Reject (with notification), > > Discard (no notification), Accept immediately (bypass other rules) > > or Default processing that is processed. So presumably a selection has > > been made and processing is stuck on getting the member or setting the > > member's moderation action. > > Possibly the logs of your database manager will have information. > > Some additional info. > By gunicorn.cfg, do you mean the file at mailman/config/gunicorn.cfg? If > you are using gunicorn as a wsgi server, that is separate from the > gunicorn serving the REST API and its config doesn't affect the REST > API. The relevant config is mailman/config/gunicorn.cfg?. > Also, I doubt the issue is with the REST API per se, but rather it is in > Mailman core's processing of the particular endpoint and if that is > slow, it is most likely some kind of database issue. Hi Mark, yes, we are using a local copy of the gunicorn.cfg. It is in the home directory of our mailman3 instance (like the mailman.cfg, same directory). We will now look into the postgresql database - maybe there is an index missing or something like that. Thank you for help.

4 years

[MM3-users] Re: Creating users via RestAPI / User-Management - a bunch of questions

by Mark Sapiro

On 6/20/25 06:39, Christian Schneider wrote: > Dear Mark and companions, > > somehow I can not cope with the user management... > (I am running a venv-installation, latest stable versions) > > I read this manual: > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/… > and played with the RestAPI calls... > > I know about the fine grained differences between user and member, admin/owner, superuser... > and about the two user databases in PostgreSQL and Django-Framework. I'm not sure what distinction you are making between PostgreSQL and Django-Framework. There are two separate and distinct users, Django users and Mailman core users. Information about both is in the PostgreSQL database. Django users are in the `auth_user` table and Mailman core users are in the `user` table, both in the public schema, although if you split the data into a `mailman` database and a `mailmanweb` database the `auth_user` table is in `mailmanweb` and the `user` table is in `mailman`. > What I stumble upon is the RestAPI calls to create a "working" user (with the ability to login via WebUI). > When I follow the manual (from the url above) I create a user (including password) that appears in the PostgreSQL database. > (And this user is visible on the User-URL (https://example.com/mailman3/users)) > Even when I (via WebUI) set the user as "approved" this user is not able to log in... > I assume this restriction is in accordance to the fact that there is not equivalent Django user. > (There was a mail in the archive of the MM3 user group...stating that one has to use the Django RestAPI to create the appropriate user) The above is correct. The Mailman REST API only deals with Mailman core. Mailman core knows nothing about Django. > When I create the user using the WebUI (https://example.com/accounts/signup/?next=/mailman3/lists/) > the new user is created in the right (complete) way...appearing in the PostgreSQL database and as a user in Django. > How is this sync between the two databases realized? I'm still looking into that, but it isn't the creation of the Django user per se that creates the Mailman user. The process has multiple steps. 1) Sign-up for an account. This creates the Django user and sends an address confirmation email. 2) Click the link in the confirmation email. This takes you to a page with a `Confirm` button to confirm the email address. 3) Click the confirm button. It is not until step 3) that the Mailman user and address records are created. > (The Django user also has the correct status (no staff status / no superuser status / just active status) how is this realized?) Presumably by the sign-up process not setting staff status and superuser status. > As I am not very familiar with python programming (I know Perl/Java/C++ and have an (maybe outdated) concept of OOP), > is there a quick way to implement this kind of sync by copying the register logic from mailman's python action script for registering? I think it must be django-mailman3 that's doing this, but I haven't been able to see how so far. django-mailman3 does override the template for the /accounts/confirm-email page, but this is only to include styling. > Other questions: > Will there be a create_admin_user-script that is callable via CLI (like createsuperuser or create_list)? > (This script ought create a user in PostgreSQL and as Django user) No plans. There are `mailman addmembers` and `mailman admins` commands to add members or admins to a list. Adding an owner or moderator to a list via `mailman admins` will also create a Mailman user for that person if there isn't one already, but it won't create a Django user. > How will a social account provider (like oidc) linkage (in Django) fit in this concept? > Will oidc-accounts be copied to the Django's user database (or PostgreSQL db) or is it an on-the-fly check against the oidc-provider? (I assume second option) > What are the status-flags (staff status/superuser status/active status) of the linked oidc-accounts? (Can I specify the status flags?) I don't offhand know the answers to that, but I think logging in via a social account provider creates a Django user.. > A conceptual thought: > When "user1" (with email user1(a)example.com) is known to django via oidc linkage > and I create "user1" (also with email user1(a)example.com) via RestAPI calls > (following the url https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…) > do I have a "complete" user then? > I mean a user who is able to login and who can be assigned to a list as admin (e.g.) > (In this case I would not have to care about the Django user database... ;-)) If the user can log in to the web UI with an associated email address, if that address is an admin of a list, the logged in user can admin the list. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 months

[MM3-users] Re: Newbie hyperkitty question

by Stephen Daniel

Thanks. Very helpful. On Tue, Jan 11, 2022 at 2:03 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 1/11/22 8:27 AM, Stephen Daniel wrote: > > Mailman users -- > > > > I am setting up a new mailman3 installation, and this is my first > > experience with the suite. All of the software is up and running, but I > > cannot tell if hyperkitty is actually running. > > > In Postorius, in the list's `info` view can you click the Archives > button and see archived messages? That's HyperKitty. > > If the messages aren't there with the hyperkitty archiving option > enabled, check `mailman.log` for why. > > Also do messages from the list have an Archived-At: header? > > > > When I look at my test mailing list, two archive options are available, > > hyperkitty and "prototype", and both are enabled. I can see that my > email > > is being archived, but I think "prototype" is what is doing the > archiving. > > I see that a test message will end up in > > > /opt/mailman/mm/var/archives/prototype/<LISTNAME>@<LISTDOMAIN.org>/new/164.... > > and nowhere else. This suggests that "prototype" is archiving, but > > hyperkitty is not. > > > No this says the prototype archiver is working. It says nothing about > Hyperkitty. > > > > So, this opens up a raft of questions on hyperkitty: > > > David Newman has answered some of this, but ... > > > > - How do I tell if hyperkitty is actually running? > > > It doesn't actually run. it is a Django web UI and a web API that serves > things on request. > > > > - Does hyperkitty have a web-UI for admins or users? How would I > access > > it? > > See above. > > > > - I can not find any documentation on hyperkitty, other than > > installation instructions and change logs. Does documentation exist? > > No, not really. > > > > - How do I set policies on how long archives are kept? > > - Assuming I want to back up my archives, what do I need to back up? > > > Messages are kept forever unless you do something to delete them. > HyperKitty's messages are stored in the database configured in the > DATABASES setting in your Django settings. How you backup the database > depends on the database manager. You already found the prototype > archiver's messages. > > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > _______________________________________________ > 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/ >

4 years, 1 month

[MM3-users] Re: debian's 3.2.1 mailman package too unreliable in production - Mail held occasionally causes server errors, and unexplained queue/bad messages -

by Mark Sapiro

On 10/20/20 6:30 PM, Alex Schuilenburg via Mailman-users wrote: > We have an issue where a mailing list has had a message sent to it from > a non-member, so the message has been held, but when the list owner or > I attempt to list the held messages for the list we get a Server Error: > "An error occurred while processing your request.". Details of the server error should be in Django's log which I think in the Debian package is named mailmansuite.log. > I see the mail being held in the mailman log with the non-subscriber > reason, and followed the suggestions in > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… > which worked to look at and discard that held message. The problem > is, there are more and we have over 900 mailing lists > > FYI, we are running:Mailman Core VersionGNU Mailman 3.2.1 (La Villa > Strangiato)Mailman Core API Version3.0Mailman Core Python Version3.7.3 > (default, Jul 25 2020, 13:03:44) [GCC 8.3.0] > > So we are looking at setting up a virtualenv to run the latest mailman3 > 3.3.1 as the 3.2.1 package from debian is looking unstable - barely > usable. Actually, the latest Mailman core is 3.3.2rc2 with the final due by the end of October. While I would never discourage people from installing Mailman from our source distributions, without more understanding of your actual errors, it is difficult to know if that will help. > For example, while poking around I found 641 messages in > queue/bad , but when I inspect them they look fine. If, as mentioned > elsewhere, I rename them to .pck, put them in queue/shunt, and "mailman > unshunt" the mail finally gets delivered. Why work now? Some kind of > transient bug? If they are in queue/bad because of permissions errors, it is not surprising that moving them to .pck files in queue/shunt is successful. > Is 3.3.1 the way to go? > > On that last error, I've now enabled debug and hope to catch why > messages are being dropped into queue/bad instead of being delivered. > Already I have found errors in the mailman log such as: > > PermissionError: [Errno 13] Permission denied: > '/var/lib/mailman3/queue/out/1603233694.919073+d907eb9512ce11fda515c19d > 723537fc4cb15da2.pck'Oct 20 23:41:35 2020 (9793) Skipping and > preserving unparseable message: > 1603233694.919073+d907eb9512ce11fda515c19d723537fc4cb15da2Oct 20 > 23:41:35 2020 (9787) Uncaught runner exception: [Errno 13] Permission > denied: > '/var/lib/mailman3/queue/archive/1603233694.9209244+a0c1f3aab51d3d202aa > 37911ab453f094b50b450.pck'Oct 20 23:41:35 2020 (9793) Uncaught runner > exception: [Errno 13] Permission denied: > '/var/lib/mailman3/queue/out/1603233694.9260252+138142eeb15b16b5da16934 > 954d1d3aeb1331198.pck'Oct 20 23:41:35 2020 (9793) Traceback (most > recent call last): File "/usr/lib/python3/dist- > packages/mailman/core/runner.py", line 158, in _one_iteration msg, > msgdata = self.switchboard.dequeue(filebase) File > "/usr/lib/python3/dist-packages/mailman/core/switchboard.py", line 150, > in dequeue with open(filename, 'rb') as fp:PermissionError: [Errno > 13] Permission denied: > '/var/lib/mailman3/queue/out/1603233694.9260252+138142eeb15b16b5da16934 > 954d1d3aeb1331198.pck'Oct 20 23:41:35 2020 (9790) Uncaught runner > exception: [Errno 13] Permission denied: > '/var/lib/mailman3/queue/in/1603233694.9129462+8be9ab12e5dfeab086a1ab8b > 3917550aea313505.pck'Oct 20 23:41:35 2020 (9793) Skipping and > preserving unparseable message: > 1603233694.9260252+138142eeb15b16b5da16934954d1d3aeb1331198Oct 20 > 23:41:35 2020 (9793) Uncaught runner exception: [Errno 13] Permission > denied: > '/var/lib/mailman3/queue/out/1603233694.9269004+5f8572edfb07e0e28b9f0b7 > 928a1184b8c8048ba.pck'Oct 20 23:41:35 2020 (9793) Traceback (most > recent call last): File "/usr/lib/python3/dist- > packages/mailman/core/runner.py", line 158, in _one_iteration msg, > msgdata = self.switchboard.dequeue(filebase) File > "/usr/lib/python3/dist-packages/mailman/core/switchboard.py", line 150, > in dequeue with open(filename, 'rb') as fp:PermissionError: [Errno > 13] Permission denied: > '/var/lib/mailman3/queue/out/1603233694.9269004+5f8572edfb07e0e28b9f0b7 > 928a1184b8c8048ba.pck'Oct 20 23:41:35 2020 (9793) Skipping and > preserving unparseable message: > 1603233694.9269004+5f8572edfb07e0e28b9f0b7928a1184b8c8048ba Were the runners all running as user `list` when the above errors occur. > The mailman3 user, "list", owns and has full rights all the way down: > # ls -ld /var/lib/mailman3/queue/*drwxrwx--- 2 list list 4096 Oct 21 > 01:45 /var/lib/mailman3/queue/archivedrwxrwx--- 2 list list 77824 Oct > 21 00:15 /var/lib/mailman3/queue/baddrwxrwx--- 2 list list 4096 Oct 19 > 10:44 /var/lib/mailman3/queue/bouncesdrwxrwx--- 2 list list 4096 > Oct 5 17:18 /var/lib/mailman3/queue/commanddrwxrwx--- 2 list > list 4096 Oct 21 00:00 /var/lib/mailman3/queue/digestdrwxrwx--- 2 list > list 4096 Oct 21 00:20 /var/lib/mailman3/queue/indrwxrwx--- 2 list > list 4096 Aug 11 18:44 /var/lib/mailman3/queue/nntpdrwxrwx--- 2 list > list 4096 Oct 21 01:45 /var/lib/mailman3/queue/outdrwxrwx--- 2 list > list 4096 Oct 21 01:45 /var/lib/mailman3/queue/pipelinedrwxrwx--- 2 > list list 4096 Aug 11 18:44 /var/lib/mailman3/queue/retrydrwxrwx--- 2 > list list 69632 Oct 21 01:45 /var/lib/mailman3/queue/shuntdrwxrwx--- 2 > list list 4096 Oct 21 00:20 /var/lib/mailman3/queue/virgin > so I'm kinda running out of options why this particular problem is > happening. Any pointers? Or just toss the mailman 3.2.1 debian > package out and go for a virtualenv 3.3.1 mailman? Unexplained permissions errors are often SELinux issues. Is SELinux enabled? If so, have you tried disabling it? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 4 months

Search results for query "sapiro"