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

[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, 5 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

1 year, 10 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, 3 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.

3 years, 9 months

[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

4 months, 1 week

[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/ >

3 years, 9 months

[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

[MM3-users] Re: digests are created but not sent out

by "Jörg M. Schulz"

Arrgh, you got it. There are messages in the shunt directories. But, also in mailman log. Uncaught runner exception: 'ascii' codec can't encode character '\xdf' in position 157: ordinal not in range(128) Jan 09 12:24:06 2019 (17491) Traceback (most recent call last): File "/usr/lib/python3/dist-packages/mailman/core/runner.py", line 173, in _one_iteration self._process_one_file(msg, msgdata) File "/usr/lib/python3/dist-packages/mailman/core/runner.py", line 266, in _process_one_file keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/lib/python3/dist-packages/mailman/runners/digest.py", line 324, in _dispose mime = mime_digest.finish() File "/usr/lib/python3/dist-packages/mailman/runners/digest.py", line 185, in finish footer = MIMEText(footer_text.encode(self._charset), so the footers may not contain special characters. Will review this one. This is the only thing I hate with python... > Am 09.01.2019 um 18:02 schrieb Mark Sapiro <mark(a)msapiro.net>: > > On 1/9/19 1:37 AM, "Jörg M. Schulz" wrote: >> >> Normal, non-digest messages are sent correctly. Administrative messages as well. >> >> Using GNU Mailman 3.2.0 (La Villa Strangiato) >> >> Where could I look for errors / stuck queues? >> >> /var/lib/mailman3/lists >> /var/lib/mailman3/lists/mailman.unswolke.de >> /var/lib/mailman3/lists/mailman.unswolke.de/digest.2.3.mmdf >> /var/lib/mailman3/lists/mailman.unswolke.de/digest.3.2.mmdf >> /var/lib/mailman3/lists/mailman.unswolke.de/digest.4.2.mmdf >> /var/lib/mailman3/lists/mailman.unswolke.de/digest.2.6.mmdf >> /var/lib/mailman3/lists/mailman.unswolke.de/digest.2.4.mmdf >> /var/lib/mailman3/lists/mailman.unswolke.de/digest.4.1.mmdf >> /var/lib/mailman3/lists/mailman.unswolke.de/digest.3.1.mmdf >> /var/lib/mailman3/lists/mailman.unswolke.de/digest.mmdf >> /var/lib/mailman3/lists/mailman.unswolke.de/digest.4.3.mmdf > > > When a digest is to be sent by 'mailman digests', the digest.mmdf file > is renamed to digest.x.y.mmdf (x and y are the volume and issue numbers) > and an entry placed in queue/digests to send that digest. The digest > runner then picks up that entry, prepares the digest, queues it in > queue/virgin to be sent to the recipients if any and removes the > digest.x.y.mmdf file. > > Since the digest.x.y.mmdf files are not removed, either the digest > runner is not running at all in which case there will still be entries > in queue/digests or it is encountering an error in processing in which > case there should be messages with tracebacks in Mailman's error log and > probably messages in queue/shunt. > > -- > Mark Sapiro <mark(a)msapiro.net <mailto:mark@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 <mailto:mailman-users@mailman3.org> > To unsubscribe send an email to mailman-users-leave(a)mailman3.org <mailto:mailman-users-leave@mailman3.org> > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/>

6 years, 9 months

[MM3-users] Re: new list not working

by Christian

There are no such messages as you describe. After turning on debugging I got this from a test message sent to the new list: Mar 10 04:39:51 2023 (1005) Available AUTH mechanisms: LOGIN(builtin) PLAIN(builtin) Mar 10 04:39:51 2023 (1005) Peer: ('127.0.0.1', 51982) Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) handling connection Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) >> b'LHLO zarathustra.ccalternatives.org' Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) >> b'MAIL FROM:<christian(a)naturalintelligence.us> SIZE=3499' Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) sender: christian(a)naturalintelligence.us Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) >> b'RCPT TO:<redlatinleg(a)lists.ccalternatives.org>' Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) recip: redlatinleg(a)lists.ccalternatives.org Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) >> b'DATA' Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) >> b'QUIT' Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) connection lost Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) Connection lost during _handle_client() -----Original Message----- From: Mark Sapiro <mark(a)msapiro.net> Sent: Thursday, March 9, 2023 7:51 PM To: mailman-users(a)mailman3.org Subject: [MM3-users] Re: new list not working On 3/9/23 13:26, Christian via Mailman-users wrote: > Smtp.log > > ++++++ > > Mar 09 20:57:09 2023 (9401) Available AUTH mechanisms: LOGIN(builtin) > PLAIN(builtin) > > Mar 09 20:57:09 2023 (9401) Peer: ('127.0.0.1', 35982) > > Mar 09 20:57:09 2023 (9401) ('127.0.0.1', 35982) handling connection > > Mar 09 20:57:09 2023 (9401) ('127.0.0.1', 35982) >> b'LHLO zarathustra.ccalternatives.org' > > Mar 09 20:57:09 2023 (9401) ('127.0.0.1', 35982) >> b'MAIL FROM:christian@naturalintelligence.us SIZE=3653' > > Mar 09 20:57:09 2023 (9401) ('127.0.0.1', 35982) sender: > christian(a)naturalintelligence.us > > Mar 09 20:57:09 2023 (9401) ('127.0.0.1', 35982) >> b'RCPT TO:redlatinleg@lists.ccalternatives.org' > > Mar 09 20:57:09 2023 (9401) ('127.0.0.1', 35982) recip: > redlatinleg(a)lists.ccalternatives.org > > Mar 09 20:57:09 2023 (9401) ('127.0.0.1', 35982) >> b'DATA' > > Mar 09 20:57:09 2023 (9401) ('127.0.0.1', 35982) >> b'QUIT' > > Mar 09 20:57:09 2023 (9401) ('127.0.0.1', 35982) connection lost > > Mar 09 20:57:09 2023 (9401) ('127.0.0.1', 35982) Connection lost > during _handle_client() > What else is in the smtp.log? There should be messages like <timestamp> (<pid>) <message-id> smtp to redlatinleg(a)lists.ccalternatives.org for nn recips, completed in n.nnn seconds <timestamp> (<pid>) <message-id> post to redlatinleg(a)lists.ccalternatives.org from christian(a)naturalintelligence.us nnn bytes If there aren't, try setting [logging.smtp] level: debug in mailman.cfg, restarting Mailman core and see what you then get in smtp.log. -- 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/ WPMR4JUQOQ6FMT24V3W6WWJQQU4Q6O7E/ This message sent to csa(a)web-analysts.net

2 years, 7 months

[MM3-users] Re: can't get mail into mailman3 in docker

by matthew＠alberti.us

Sorry for the double-tap. Apparently https://github.com/maxking/docker-mailman/pull/441 changed the behavior that I said was the default. We might need to see your docker-compose.yaml, with sensitive info removed, to know more about your setup. - Matt Alberti -----Original Message----- From: matthew(a)alberti.us <matthew(a)alberti.us> Sent: Saturday, August 7, 2021 8:21 PM To: mailman-users(a)mailman3.org Subject: [MM3-users] Re: can't get mail into mailman3 in docker I use the docker-mailman setup. Below is the partial contents of my mailman-extra.cfg. I think by default, you would use the Docker assigned private network IP addresses for communicating with the containers. In my setup, 172.19.199.1 is the host (where postfix is) and 172.19.199.2 is mailman-core... # EMAIL SERVER / MTA CONFIGURATION [mta] incoming: mailman.mta.postfix.LMTP outgoing: mailman.mta.deliver.deliver lmtp_host: 172.19.199.2 lmtp_port: 8024 smtp_host: 172.19.199.1 smtp_port: 25 configuration: /etc/postfix-mailman.cfg This is all really going to depend on your particular setup. I'm late to the thread; but let me know if that improves the situation. - Matt Alberti -----Original Message----- From: Mark Sapiro <mark(a)msapiro.net> Sent: Saturday, August 7, 2021 2:04 AM To: mailman-users(a)mailman3.org Subject: [MM3-users] Re: can't get mail into mailman3 in docker On 8/6/21 11:28 AM, bob B wrote: > I see nothing for today when the error happens in > /opt/mailman/var/logs/smtp.log > > But the log has a bunch of these, but these stopped around the 4th > > Aug 04 19:46:04 2021 (28) Available AUTH mechanisms: LOGIN(builtin) > PLAIN(builtin) Aug 04 19:46:04 2021 (28) Peer: ('127.0.0.1', 33912) > Aug 04 19:46:04 2021 (28) ('127.0.0.1', 33912) handling connection Aug > 04 19:46:04 2021 (28) ('127.0.0.1', 33912) EOF received Aug 04 > 19:46:04 2021 (28) ('127.0.0.1', 33912) Connection lost during > _handle_client() Aug 04 19:46:04 2021 (28) ('127.0.0.1', 33912) > connection lost These are normal messages from the startup of Mailman's lmtp runner. If you correlate these with mailman.log, you'll probably see the server starting at these times. The fact that there is nothing in this log correlating with the Postfix message 2021-08-06T09:08:41.974225-04:00 dockerhost postfix/lmtp[109783]: D630B3083ED0: to=<test(a)mailman-docker.###.####>, relay=localhost[127.0.0.1]:8024, delay=0.11, delays=0.05/0.02/0.04/0, dsn=4.4.2, status=deferred (lost connection with localhost[127.0.0.1] while receiving the initial server greeting) seems to say that Postfix isn't really connecting to Mailman's lmtp and this is consistent with netstat -l not showing something listening on port 8024. I note you have lmtp_host: localhost in the [mta] section in mailman-extra.cfg. Try changing that to lmtp_host: 127.0.0.1 -- 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/ _______________________________________________ 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, 2 months

Search results for query "sapiro"