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

[MM3-users]Re: [Mailman-Users] Mailman3 administration

by Mark Sapiro

On 06/17/2016 12:16 PM, Bill wrote: > Hi, > > I'm looking for some information on Mailman3 administration. I've found > that it's not yet packaged by any of the common Linux distros - Debian, > Ubuntu, Mint, RedHat, Centos, Fedora, Suse, Arch etc so I have some > concerns about the amount of upkeep that running Mailman3 will entail. > > I know that Mailman2 is available as a package on the above distros, but > we would really like to take advantage of the kludge-free, virtual > domains feature on Mailman3. > > I've been asked by a local non-profit provider to assist them in moving > their 200+ mailing lists from an outdated Sympa list server to > Debian8/Postfix/Mailman. One of their chief concerns is the amount of > extra administration, over and above normal list administration, that > Mailman3 will require in the form of manual updates and maintenance. > > We are in the evaluation and design stage right now, but could use any > pertinent advice about supportive distros, available packages, the > amount of extra administration involved or perhaps, in a worst case > scenario, alternate list managers supporting a virtual domains feature > similar to Mailman3. > > Thanks for your help, > > Bill McGrath > President, Vancouver Linux Users Group > https://vanlug.bc.ca I've copied this post and set Reply-To: to the Mailman 3 users list <mailman-users(a)mailman3.org>. Please join at <https://lists.mailman3.org/mailman3/lists/mailman-users@mailman3.org/> before replying there. That said, we are working on packaging for a more turn-key installation, but we aren't there yet. I've installed a couple of instances including the one at lists.mailman3.org, and it does require extra work. Some of the work in my case is because I want to run all the Mailman pieces from the heads of their branches rather than what's in PyPI, but even without that, installation is significantly more work than installing a distro's package. I will be writing up my experiences, but that's not done yet either. I will say that once you have Mailman 3 installed and running, updating (which I do frequently, but which doesn't need to be done unless you want specific updates/fixes) is pretty easy. As far as alternatives are concerned There is an up to date Mailman 2.1 branch with better virtual domain support at <https://code.launchpad.net/~msapiro/mailman/vhost>, but I think in the long run, you'd be better off with Mailman 3. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

10 years, 4 months

[MM3-users] Re: AttributeError: 'MailingList' object has no attribute 'get_requests_count'

by Shashikanth Komandoor

Though you are for sure that the current versions as I am claiming the above one is perfectly without any issue, please also suggest what would be the best previous version which definitely does not have that issue because I even checked out the immediate previous version of mailmanclient but still I am getting the same error. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Wed, Oct 28, 2020 at 12:13 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 10/27/20 11:20 PM, Shashikanth Komandoor wrote: > > Can I go back to any previous version which is felt as working fine ? > > Sure. > > -- > 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 & Regards, Shashi Kanth.K 9052671936

5 years, 11 months

[MM3-users] Re: Mailman 3 on Fedora - Core only ?

by Mark Sapiro

On 6/13/20 2:17 AM, Lars Bjørndal wrote: > I'm about to set up a new list, and want to try out Mailman3. > > The only component available in Fedora, is the Mailman core package. I find that strange as <https://lists.fedoraproject.org/> is Mailman 3 and the core developer who did most of the HyperKitty development works or did work for Fedora. > With the /usr/libexec/mailman3/mailman command, I was able to create a > list, and add a member throug the sub commands create and members. > > How can I read out the list configuration from here, and change > settings? Do I then need to install/use other components, or is there > other possibilities, e.g. using the shell command? You can do anything through `mailman shell`, but it can be cumbersome. You can also do most things via the REST API <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…>, but that too is cumbersome if doing it, e.g., with `curl`. > If I get a message that needs moderation, can I do the decision from cli, > or how do I do that? You should be able to do it via a reply to LIST-confirm+<token>@example.com, but this currently doesn't work. See <https://gitlab.com/mailman/mailman/-/issues/169>. To do it in `mailman shell` is something like: $ bin/mailman shell -l list.example.com Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. The variable 'm' is the list.example.com mailing list >>> from mailman.app.moderator import handle_message >>> from mailman.interfaces.action import Action >>> action = Action.discard # to discard >>> action = Action.reject # to reject >>> action = Action.accept # to accept immediately >>> action = Action.defer # to continue with subsequent tests >>> rq = IListRequests(m) >>> rq.held_requests <generator object ListRequests.held_requests at 0x7f5431dda048> >>> list(rq.held_requests) [] >>> # when you have requests this is a list of (id, type) tuples >>> # type is 1 for message, 2 for subscription and 3 for unsubscription >>> id = 'integer request id from above' >>> handle_message(m, id, action, comment='reason if rejecting') This is obviously not practical, but you could make a script to accept the token that you know and an action and maybe a comment to do the actual handling. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 4 months

[MM3-users] Re: The MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header.

by Mark Sapiro

On 10/23/21 12:43 AM, Marco Marinello wrote: > Dear Mark, > > I upgraded the pypi packages as you suggested but the problem remains the same. > Tried also installing from git heads but always get > > ==> /opt/hyperkitty_django/hyperkitty.log <== > ERROR 2021-10-23 09:42:42,523 30765 hyperkitty.views.mailman The MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. > WARNING 2021-10-23 09:42:42,523 30765 django.request Unauthorized: /hyperkitty/api/mailman/urls > WARNING 2021-10-23 09:42:42,523 30765 django.request Unauthorized: /hyperkitty/api/mailman/urls > > ==> /var/log/mailman/mailman.log <== > Oct 23 07:42:42 2021 (30888) HyperKitty failure on http://127.0.0.1:8080/hyperkitty/api/mailman/urls: <html><title>Auth required</title><body> > <h1>Authorization Required</h1><p>The archiver key must be > sent over the Authorization HTTP header. > </p></body></html> (401) Those messages look correct for HyperKitty 1.3.5, if mailman-hyperkitty is not sending the key as expected. The particular condition causing those messages is there is no "Authorization" header in the headers of the request from mailman-hyperkitty and there is also no "key" parameter in the request as there would have been with mailman-hyperkitty 1.1.0 This would seem to say that both HyperKitty 1.3.5 and mailman-hyperkitty 1.2.0 are doing the right thing, but somehow the request headers are not getting through in the http request from mailman-hyperkitty to HyperKitty. What is your setting for base_url in mailman-hyperkitty.cfg? Is there some redirect or other situation going on in serving the request to HyperKitty that could cause headers to get lost? > For information, how does your release cycle work? I prefer installing from a source rather than pypi. Is the master normally stable? When a packages lands on pypi? We are a small, all volunteer project and we don't have a fixed release schedule. We make releases when we feel enough change has been accumulated to warrant on or when there is a serious issue to fix. The heads of the gitlab branches are generally usable. There was actually a situation briefly where the mailman-hyperkitty changes for this issue were merged before the HyperKitty changes. See https://gitlab.com/mailman/hyperkitty/-/merge_requests/354#note_693162778 but situations like this are rare. The servers at lists.mailman3.org and mail.python.org run the heads of the gitlab branches (I update them regularly) so you can generally be confident that they work. > I'll stick on 1.3.4 / 1.1.0 for the moment. There are several changes in HyperKitty 1.3.5. See https://docs.mailman3.org/projects/hyperkitty/en/latest/news.html#news-1-3-5 -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 11 months

[MM3-users] Re: Splitting hosts: mta&core vs postorius

by Mark Sapiro

On 6/20/20 5:41 PM, Ruth Ivimey-Cook wrote: > >>> My reason for thinking, in my original post, that the wrong host >>> address is being used is that the ConnectionError above contains >>> 0.0.0.0 in its url for /3.1/domains/... but 0.0.0.0 is only >>> present as >>> the listen address on the core web service and does not appear in >>> the >>> config for postorius. >> The ConnectionError above comes from requests.request (docs at >> <https://requests.readthedocs.io/en/master/>). Client only provides a >> URL in the call to request and the URL is the baseurl + the path and the >> baseurl is MAILMAN_REST_API_URL which you have as >> http://greyarea-post:8870. Entries above have >> http://greyarea-post.cam.ivimey.org:8870/. Is that the correct FQDN? >> >> I suspect a DNS lookup issue. How does greyarea-web1 resolve >> greyarea-post? You could try a FQDN that greyarea-web1 can lookup in DNS >> rather than relying on /etc/resolv.conf and/or /etc/hosts. > > No, ignore that... I edited the FQDN down to the hostname in the email > for simplicity, but even if it was in the log the hostname does map > properly (i.e. host greyarea-post and host greyarea.cam.ivimey.org > return the same thing). Is the above a typo. You are saying greyarea.cam.ivimey.org. Did you mean that or greyarea-post.cam.ivimey.org as in the http://greyarea-post.cam.ivimey.org:8870/3.1/lists?count=10&page=1 log messages? > In referring to the ConnectionError from: > > 'ConnectionError(MaxRetryError("HTTPConnectionPool(host=\'0.0.0.0\', > port=8870): Max retries exceeded with url: /3.1/domains/ch-bc.org.uk > (Caused by NewConnectionError(\'<urllib3.connection.HTTPConnection > object at 0x7f5416db8518>: Failed to establish a new connection: > [Errno 111] Connection refused\',))",),)') > > if you reconstruct the url passed in it was presumably: > > "http://0.0.0.0:8870/3.1/domains/ch-bc.org.uk" I don't think so. I think it was http://greyarea-post:8870/3.1/domains/ch-bc.org.uk and requests.request couldn't resolve that to the correct IP. If you look at Mailman client <https://gitlab.com/mailman/mailmanclient/-/blob/master/src/mailmanclient/re…> you'll see it makes the URL from the baseurl passed to the instantiation of the Connection class which occurs at <https://gitlab.com/mailman/mailmanclient/-/blob/master/src/mailmanclient/cl…> which in turn is called from Postorius at <https://gitlab.com/mailman/postorius/-/blob/master/src/postorius/utils.py#L…> which makes the baseurl argument from '%s/3.1' % settings.MAILMAN_REST_API_URL. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 3 months

[MM3-users] Re: PermissionError: [Errno 1] Operation not permitted

by Mark Sapiro

On 6/21/21 2:28 PM, Sarah H wrote: > The system we are running mailman 3 on crashed, it filled the drive, and when it was restarted and the issue cleared I found that mailman3 will not start, it returns the following: > > Jun 21 14:12:29 mailman[513274]: Traceback (most recent call last): > Jun 21 14:12:29 mailman[513274]: File "/opt/mailman/venv/bin/mailman", line 11, in <module> > Jun 21 14:12:29 mailman[513274]: load_entry_point('mailman==3.3.4', 'console_scripts', 'mailman')() > Jun 21 14:12:29 mailman[513274]: File "/opt/mailman/venv/lib64/python3.6/site-packages/click/core.py", line 829, in __call__ > Jun 21 14:12:29 mailman[513274]: return self.main(*args, **kwargs) > Jun 21 14:12:29 mailman[513274]: File "/opt/mailman/venv/lib64/python3.6/site-packages/click/core.py", line 782, in main > Jun 21 14:12:29 mailman[513274]: rv = self.invoke(ctx) > Jun 21 14:12:29 mailman[513274]: File "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/bin/mailman.py", line 68, in invoke > Jun 21 14:12:29 mailman[513274]: return super().invoke(ctx) > Jun 21 14:12:29 mailman[513274]: File "/opt/mailman/venv/lib64/python3.6/site-packages/click/core.py", line 1259, in invoke > Jun 21 14:12:29 mailman[513274]: return _process_result(sub_ctx.command.invoke(sub_ctx)) > Jun 21 14:12:29 mailman[513274]: File "/opt/mailman/venv/lib64/python3.6/site-packages/click/core.py", line 1066, in invoke > Jun 21 14:12:29 mailman[513274]: return ctx.invoke(self.callback, **ctx.params) > Jun 21 14:12:29 mailman[513274]: File "/opt/mailman/venv/lib64/python3.6/site-packages/click/core.py", line 610, in invoke > Jun 21 14:12:29 mailman[513274]: return callback(*args, **kwargs) > Jun 21 14:12:29 mailman[513274]: File "/opt/mailman/venv/lib64/python3.6/site-packages/click/decorators.py", line 21, in new_func > Jun 21 14:12:29 mailman[513274]: return f(get_current_context(), *args, **kwargs) > Jun 21 14:12:29 mailman[513274]: File "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/commands/cli_control.py", line 91, in start > Jun 21 14:12:29 mailman[513274]: status, lock = master_state() > Jun 21 14:12:29 mailman[513274]: File "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/bin/master.py", line 104, in master_state > Jun 21 14:12:29 mailman[513274]: os.kill(pid, 0) > Jun 21 14:12:29 mailman[513274]: PermissionError: [Errno 1] Operation not permitted > Jun 21 14:12:29 systemd[1]: mailman3.service: Control process exited, code=exited status=1 > Jun 21 14:12:29 systemd[1]: mailman3.service: Failed with result 'exit-code'. > > this is via starting as root with systemctl start mailman3, or as the user mailman using /opt/mailman/venv/bin/mailman start This is probably due to a stale lock. See https://gitlab.com/mailman/mailman/-/issues/913. Assuming mailman is not running, you need to remove Mailman's var/locks/* Similar issues can occur if `bin/mailman start` is run as the mailman user but has previously been run as root. -- 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: Still unable to get mailman3 working on Ubuntu 20.04 LTS

by Mark Sapiro

On 1/3/22 4:01 PM, Michael Heseltine wrote: > Hi Mark, > I tried out "pip install mistune==2.0.0rc1" (as I got hyperkitty via pip) which worked and let me move forward a little further once more, but still I get an error from "mailman-post-update": > >> # /opt/mailman/mm/bin/mailman-post-update >> + '[' False == False ']' >> + mkdir -p /opt/mailman/mm/static >> + /opt/mailman/mm/bin/django-admin collectstatic --clear --noinput --verbosity 0 >> + /opt/mailman/mm/bin/django-admin compress >> Compressing... done >> Compressed 2 block(s) from 104 template(s) for 1 context(s). >> + /opt/mailman/mm/bin/django-admin compilemessages >> Traceback (most recent call last): >> File "/opt/mailman/mm/venv/bin/django-admin", line 8, in <module> >> sys.exit(execute_from_command_line()) >> File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/core/management/__init__.py", line 419, in execute_from_command_line >> utility.execute() >> File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/core/management/__init__.py", line 413, in execute >> self.fetch_command(subcommand).run_from_argv(self.argv) >> File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/core/management/base.py", line 354, in run_from_argv >> self.execute(*args, **cmd_options) >> File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/core/management/base.py", line 398, in execute >> output = self.handle(*args, **options) >> File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/core/management/commands/compilemessages.py", line 113, in handle >> self.compile_messages(locations) >> File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/core/management/commands/compilemessages.py", line 130, in compile_messages >> self.stdout.write( >> File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/core/management/base.py", line 155, in write >> self._out.write(style_func(msg)) >> UnicodeEncodeError: 'latin-1' codec can't encode character '\u201c' in position 5: ordinal not in range(256) This looks like an issue with some message catalog which is declared as character set `latin-1` but contains a unicode left_double_quote character. Unfortunately, `django-admin compilemessages` compiles, at least in my test installation, 1583 message catalogs from 19 different projects, so finding the problem file is difficult and I don't know how to narrow it down. However, this is the next to last step in mailman-post-update and isn't important if your installation is English language only and the last step is optional and runs /opt/mailman/mm/bin/django-admin update_index to rebuild the search index for HyperKitty and you can just run that one step if you want. At this point, you probably have no archives so this should take almost no time. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 9 months

[MM3-users] Re: Mailman3 on python3.13 debian testing package

by Mark Sapiro

On 2/12/25 23:12, Thomas Krichel wrote: > > Feb 13 06:49:56 2025 (857955) Uncaught runner exception: 'pathlib._local.PosixPath' object does > not support the context manager protocol > Feb 13 06:49:56 2025 (857955) Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/mailman/core/runner.py", line 179, in _one_iteration > self._process_one_file(msg, msgdata) > ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^ > File "/usr/lib/python3/dist-packages/mailman/core/runner.py", line 272, in _process_one_file > keepqueued = self._dispose(mlist, msg, msgdata) > File "/usr/lib/python3/dist-packages/mailman/runners/outgoing.py", line 111, in _dispose > self._func(mlist, msg, msgdata) > ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^ > File "/usr/lib/python3/dist-packages/mailman/mta/deliver.py", line 89, in deliver > refused = agent.deliver(mlist, msg, msgdata) > File "/usr/lib/python3/dist-packages/mailman/mta/base.py", line 167, in deliver > callback(mlist, message_copy, msgdata_copy) > ~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > File "/usr/lib/python3/dist-packages/mailman/mta/decorating.py", line 32, in decorate > decorator.process(mlist, msg, msgdata) > ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^ > File "/usr/lib/python3/dist-packages/mailman/handlers/decorate.py", line 250, in process > process(mlist, msg, msgdata) > ~~~~~~~^^^^^^^^^^^^^^^^^^^^^ > File "/usr/lib/python3/dist-packages/mailman/handlers/decorate.py", line 88, in process > header = decorate('list:member:regular:header', mlist, d) > File "/usr/lib/python3/dist-packages/mailman/handlers/decorate.py", line 212, in decorate > template = getUtility(ITemplateLoader).get(name, mlist, **extradict) > File "/usr/lib/python3/dist-packages/mailman/model/template.py", line 211, in get > path, fp = find(default_uri, mlist, code) > ~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^ > File "/usr/lib/python3/dist-packages/mailman/utilities/i18n.py", line 157, in find > for search_path in raw_search_order: > ^^^^^^^^^^^^^^^^ > File "/usr/lib/python3/dist-packages/mailman/utilities/i18n.py", line 117, in search > templates_dir = str(resources.enter_context( > ~~~~~~~~~~~~~~~~~~~~~~~^ > files('mailman').joinpath('templates'))) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > File "/usr/lib/python3.13/contextlib.py", line 528, in enter_context > raise TypeError(f"'{cls.__module__}.{cls.__qualname__}' object does " > f"not support the context manager protocol") from None > TypeError: 'pathlib._local.PosixPath' object does not support the context manager protocol > Feb 13 06:49:56 2025 (857955) SHUNTING: 1739429396.7636604+dba2fc372ce4c206e3bb753c1162bc3b768b7528 > Feb 13 06:49:56 2025 (857955) SHUNTING: 1739429396.7636604+dba2fc372ce4c206e3bb753c1162bc3b768b7528 > > Then there are repeated messages that hyperkitty can't archive the > message. Lots of them. > > No email reaches the list. I did not notice, but now the listowner > has written to me. Because the messages are being shunted because of the above exception which is a Python 3.13 issue https://gitlab.com/mailman/mailman/-/issues/1190 fixed by https://gitlab.com/mailman/mailman/-/merge_requests/1309. Once you fix that issue by either downgrading Python or installing the changes from https://gitlab.com/mailman/mailman/-/merge_requests/1309 you can reprocess those messages with `mailman unshunt` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 8 months

[MM3-users] Re: Re-send subscription response and file permission error in queue

by Mark Sapiro

On 9/8/20 10:56 PM, accounts-mailman(a)holbrook.no wrote: > A user sent subscription request to the `..-join@` address of a list. Email domain wasn't set up properly, so response got rejected. Now, if the user tries to send another request, no reponse comes back. In the log I find a python stack trace saying subscription already pending. > > ``` > Sep 08 10:32:44 2020 (19918) Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/mailman/core/runner.py", line 171, in _one_iteration > self._process_one_file(msg, msgdata) > File "/usr/lib/python3/dist-packages/mailman/core/runner.py", line 264, in _process_one_file > keepqueued = self._dispose(mlist, msg, msgdata) > File "/usr/lib/python3/dist-packages/mailman/runners/command.py", line 196, in _dispose > mlist, msg, msgdata, parts, results) > File "/usr/lib/python3/dist-packages/mailman/commands/eml_membership.py", line 104, in process > ISubscriptionManager(mlist).register(subscriber) > File "/usr/lib/python3/dist-packages/mailman/app/subscriptions.py", line 520, in register > list(workflow) > File "/usr/lib/python3/dist-packages/mailman/app/workflow.py", line 69, in __next__ > return step() > File "/usr/lib/python3/dist-packages/mailman/app/subscriptions.py", line 227, in _step_sanity_checks > raise SubscriptionPendingError(self.mlist, self.address.email) > mailman.interfaces.subscriptions.SubscriptionPendingError > ``` I'll look at this when I get some time. I'm still catching up after being off line for 12 days. > Furthermore I am getting a permission denied error in the attempt of shunting the message, which I don't quite understand because the folder has user `list` group `list` and `700` mode: > > ``` > Sep 08 10:25:29 2020 (19918) SHUNTING: 1599553529.9889646+88be5afa0bf3111a83e68cc97ce2000723ad93fd > Sep 08 10:29:49 2020 (19918) Uncaught runner exception: [Errno 13] Permission denied: '/var/lib/mailman3/queue/command/1599553789.306307+6fee74af69263553b5ffd0e73cc095ab651bd855.pck' > Sep 08 10:29:49 2020 (19918) Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/mailman/core/runner.py", line 156, 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/command/1599553789.306307+6fee74af69263553b5ffd0e73cc095ab651bd855.pck' > ``` > > How can I remove the pending subscription, or re-send the response email? In Postorius, pull down Subscription Requests and select Pending Confirmation and delete the request. > And what could be the cause of the permission error? Mailman can't read the /var/lib/mailman3/queue/command/1599553789.306307+6fee74af69263553b5ffd0e73cc095ab651bd855.pck file. This is strange since it wrote it, but check the modes and user/group of all the directories in the path and the file itself. Could it be a SELinux or apparmor issue? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 1 month

[MM3-users] Re: Error 500 on held_messages page

by Mark Sapiro

On 2/3/22 08:01, Stephan Krinetzki wrote: > Hello all, > > we now have at least one mailing list (there may be more affected) that generates a 500 error when calling the held_messages page. After looking at the held messages via the mailman shell, we have identified three mails that have neither a subject nor a message body. How can we remove these three mails from the database? This shouldn't be an issue, at least with Mailman core 3.3.5, unless I don't understand. Note that there are 3 tables involved. The request (IListRequests), the pendings (IPended and IPendedKeyValue), and the held message (IMessageStore). > This is the mailman shell command we used: > > mailman shell -l listname(a)lists.example.com > <removed> > Welcome to the GNU Mailman shell > Use commit() to commit changes. > Use abort() to discard changes since the last commit. > Exit with ctrl+D does an implicit commit() but exit() does not. > Die Variable 'm' ist die listname(a)lists.example.com Mailingliste > >>> msg_db = getUtility(IMessageStore) > >>> req_db = IListRequests(m) > >>> reqs = list(req_db.held_requests) > >>> for req in reqs: > ... print('{}: {}'.format(req.id, req.request_type)) > ... > 32598: 1 > [...] > 107656: 1 > 107737: 1 > 107758: 1 OK, you have requests. > >>> from mailman.app.moderator import handle_message > >>> handle_message(m, 107758, Action.discard) > >>> reqs = list(req_db.held_requests) > >>> for req in reqs: > ... print('{}: {}'.format(req.id, req.request_type)) > ... > 32598: 1 > [...] > 107656: 1 > 107737: 1 OK, you discarded the message held with request id 107758. > >>> handle_message(m, 92927, Action.discard) > Traceback (most recent call last): > File "<console>", line 1, in <module> > File "/opt/mailman/mailman-venv/lib64/python3.6/site-packages/mailman/app/moderator.py", line 112, in handle_message > key, msgdata = requestdb.get_request(id) > TypeError: 'NoneType' object is not iterable > >>> There is no request with id 92927. Why do you think there should be? If by remove them from the database, you mean just from the messagestore, you can do (using your above) msg_db.delete_message('the_message_id') To delete a pending request for which there is no request id, e.g. the id 92927 above, you could do ``` pendings = getUtility(IPendings) for token, data in pendings.find(pend_type='held message'): if data and data['id'] == 92927: pendings.confirm(token, expunge=True) ``` Mailman core 3.3.5 has a lot of changes to address this issue. Also see https://gitlab.com/mailman/mailman/-/issues/946 -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 8 months

Search results for query "sapiro"