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

[MM3-users] SOLVED (was: compress failed...)

by Guillermo Hernandez (Oldno7)

El 30/10/22 a las 12:22, Guillermo Hernandez (Oldno7) via Mailman-users escribió: > > El 28/10/22 a las 9:18, Guillermo Hernandez (Oldno7) via Mailman-users > escribió: >> >> El 27/10/22 a las 21:39, Mark Sapiro escribió: >>>> After that the compress part showed errors... but the postorius web >>>> maintenance was working well except for the CSRF error >>>> verification. I will trace the compress errors and will try to find >>>> the problem later. >>> >>> >>> Do you have `COMPRESS_ENABLED = True` in your settings? If that's >>> not the issue, it may be in the settings for COMPRESS_PRECOMPILERS >> >> While I'm tracing the problem out, this is the configuration I had >> working and the error it shows after upgrade: >> >> <------- snip of settings.py> >> >> # >> COMPRESS_PRECOMPILERS = ( >> ('text/less', 'lessc {infile} {outfile}'), >> ('text/x-scss', 'sassc -t compressed {infile} {outfile}'), >> ('text/x-sass', 'sassc -t compressed {infile} {outfile}'), >> ) >> # On a production setup, setting COMPRESS_OFFLINE to True will bring a >> # significant performance improvement, as CSS files will not need to be >> # recompiled on each requests. It means running an additional "compress" >> # management command after each code upgrade. >> # >> http://django-compressor.readthedocs.io/en/latest/usage/#offline-compression >> #### activo compresion 18/12/20 >> COMPRESS_OFFLINE = True >> ###COMPRESS_OFFLINE = False >> <---------- end snip> >> >> And below is the error it shows: >> >> /usr/local/mailman3 # su -m mailman3 -c "python3 manage.py compress" >> Traceback (most recent call last): >> File "/usr/local/mailman3/manage.py", line 10, in <module> >> execute_from_command_line(sys.argv) >> File >> "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", >> line 446, in execute_from_command_line >> utility.execute() >> File >> "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", >> line 440, in execute >> self.fetch_command(subcommand).run_from_argv(self.argv) >> File >> "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", >> line 279, in fetch_command >> klass = load_command_class(app_name, subcommand) >> File >> "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", >> line 49, in load_command_class >> return module.Command() >> File >> "/usr/local/lib/python3.9/site-packages/django/core/management/base.py", >> line 274, in __init__ >> raise TypeError("requires_system_checks must be a list or tuple.") >> TypeError: requires_system_checks must be a list or tuple. >> >> > After searching around, I've got a hint of what can be happening. It > seems a variable has changed in Django 4.1 its nature from boolean to > a tuple > > https://github.com/painless-software/django-probes/issues/24 > > I've upgraded another server with mailman3 lists, with the same config > listed above, and it shows the same error in the "compress" part. I'm > not sure where to set the requires_system_checks variable as in one of > the comments of the link, and as it doesn't seems to break anything > more, I will wait for more info before trying to avoid it. I'm sure it > will have some repercusion on the performance, but I'll have to live > with it. > > > Thanks again for your supporting advices. I did a pip install --upgrade --force-reinstall Django==4.0.8 downgrading Django from 4.1 and now a su -m mailman3 -c "python3 manage.py compress" worked without pain. > >> >> >> >> >> -- ___________________________________________ Mailman's content filtering has removed the following MIME parts from this message. Content-Type: image/png Name: firma-GHP-emails.png Replaced multipart/alternative part with first alternative.

2 years, 8 months

[MM3-users] Re: Clearing webserver cache - Nginx

by Odhiambo Washington

On Tue, Aug 6, 2024 at 7:18 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 8/6/24 00:24, Odhiambo Washington via Mailman-users wrote: > > > > In any case, here is my virtualhost config: > > It looks OK. > > I suggest you run > > mailman-web collectstatic --clear > mailman-web compress > Done. However, I still see the errors in Nginx logs: ``` root@eu:~# tail -f /var/log/nginx/mm3-lists_error.log 2024/08/06 18:52:54 [error] 37221#37221: *53355 open() "/opt/mailman/mm/static/CACHE/css/output.158acc288604.css" failed (2: No such file or directory), client: 108.162.238.164, server: mm3-lists.kictanet.or.ke, request: "GET /static/CACHE/css/output.158acc288604.css HTTP/2.0", host: " mm3-lists.kictanet.or.ke", referrer: " https://mm3-lists.kictanet.or.ke/archives/list/kictanet@lists.kictanet.or.k… " 2024/08/06 19:11:24 [error] 37221#37221: *54872 open() "/opt/mailman/mm/static/CACHE/css/output.6dab123e4897.css" failed (2: No such file or directory), client: 162.158.170.169, server: mm3-lists.kictanet.or.ke, request: "GET /static/CACHE/css/output.6dab123e4897.css HTTP/2.0", host: " mm3-lists.kictanet.or.ke", referrer: " https://mm3-lists.kictanet.or.ke/archives/list/kictanet@lists.kictanet.or.k… " 2024/08/06 19:11:24 [error] 37224#37224: *54875 open() "/opt/mailman/mm/static/CACHE/css/output.158acc288604.css" failed (2: No such file or directory), client: 162.158.171.16, server: mm3-lists.kictanet.or.ke, request: "GET /static/CACHE/css/output.158acc288604.css HTTP/2.0", host: " mm3-lists.kictanet.or.ke", referrer: " https://mm3-lists.kictanet.or.ke/archives/list/kictanet@lists.kictanet.or.k… " 2024/08/06 19:12:27 [error] 37228#37228: *54974 open() "/opt/mailman/mm/static/CACHE/css/output.6dab123e4897.css" failed (2: No such file or directory), client: 162.158.106.81, server: mm3-lists.kictanet.or.ke, request: "GET /static/CACHE/css/output.6dab123e4897.css HTTP/2.0", host: " mm3-lists.kictanet.or.ke", referrer: " https://mm3-lists.kictanet.or.ke/archives/list/kictanet@lists.kictanet.or.k… " 2024/08/06 19:12:27 [error] 37228#37228: *54975 open() "/opt/mailman/mm/static/CACHE/css/output.158acc288604.css" failed (2: No such file or directory), client: 162.158.106.14, server: mm3-lists.kictanet.or.ke, request: "GET /static/CACHE/css/output.158acc288604.css HTTP/2.0", host: " mm3-lists.kictanet.or.ke", referrer: " https://mm3-lists.kictanet.or.ke/archives/list/kictanet@lists.kictanet.or.k… " 2024/08/06 19:27:27 [error] 37228#37228: *56500 open() "/opt/mailman/mm/static/CACHE/css/output.6dab123e4897.css" failed (2: No such file or directory), client: 172.70.188.20, server: mm3-lists.kictanet.or.ke, request: "GET /static/CACHE/css/output.6dab123e4897.css HTTP/2.0", host: " mm3-lists.kictanet.or.ke", referrer: " https://mm3-lists.kictanet.or.ke/archives/" 2024/08/06 19:27:27 [error] 37228#37228: *56501 open() "/opt/mailman/mm/static/CACHE/css/output.158acc288604.css" failed (2: No such file or directory), client: 172.70.188.84, server: mm3-lists.kictanet.or.ke, request: "GET /static/CACHE/css/output.158acc288604.css HTTP/2.0", host: " mm3-lists.kictanet.or.ke", referrer: " https://mm3-lists.kictanet.or.ke/archives/" 2024/08/06 19:29:18 [error] 37221#37221: *56722 open() "/opt/mailman/mm/static/CACHE/css/output.6dab123e4897.css" failed (2: No such file or directory), client: 172.68.1.156, server: mm3-lists.kictanet.or.ke, request: "GET /static/CACHE/css/output.6dab123e4897.css HTTP/2.0", host: " mm3-lists.kictanet.or.ke", referrer: " https://mm3-lists.kictanet.or.ke/archives/" 2024/08/06 19:29:18 [error] 37224#37224: *56724 open() "/opt/mailman/mm/static/CACHE/css/output.158acc288604.css" failed (2: No such file or directory), client: 172.68.3.81, server: mm3-lists.kictanet.or.ke, request: "GET /static/CACHE/css/output.158acc288604.css HTTP/2.0", host: " mm3-lists.kictanet.or.ke", referrer: " https://mm3-lists.kictanet.or.ke/archives/" 2024/08/06 19:29:19 [error] 37221#37221: *56728 open() "/opt/mailman/mm/static/CACHE/js/output.3aaa7705d68a.js" failed (2: No such file or directory), client: 172.68.2.67, server: mm3-lists.kictanet.or.ke, request: "GET /static/CACHE/js/output.3aaa7705d68a.js HTTP/2.0", host: " mm3-lists.kictanet.or.ke", referrer: " https://mm3-lists.kictanet.or.ke/archives/" ``` And the archives page is still br0ken, -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

11 months, 1 week

[MM3-users] Re: moving lists to another server

by Odhiambo Washington

On Sat, Nov 18, 2023 at 1:42 AM Mark Sapiro <mark(a)msapiro.net> wrote: > On 11/17/23 00:51, Odhiambo Washington wrote: > > > I am scratching my head bald trying to figure out how to bring in this > > other MM3 site and list into my existing server, especially with regard > to > > the DB backend. > > > > The list - let's call it users(a)domainX.name was using MySQL backend and > > had a separate DB for Mailman core and Mailman web. > > I believe combining these into one isn't a problem. But getting to merge > > this DB into my current one is what I am not sure about. > > This is https://gitlab.com/mailman/postorius/-/issues/13 which is a real > need, but doesn't yet exist. > > I think the easiest thing for the archives is to forget the Mailman web > DB and just export the archive as a mbox from the other site (if it's > large, exporting the entire archive will time out so you have to do it > in pieces). Then you can use hyperkitty_import to import it. > What is the command to export the archive as a mbox from the DB? I can't figure out which option it is by looking at 'mailman-web -h'. > For the list data, it's probably easiest to just create the list > manually and go through the settings in Postorius and make them match, I want to go with the above. although you could dump the mailinglist table entry where list_id = > 'users(a)domainx.name' and load that, but you'd need to edit the id field > in the dump to match the id on your server. Not going with that. > That leaves the members. Given that I have a dump of the two DBs (mailman and mailman-web) I just created one DB and imported them. I have been able to dump the members into a text file. Now importing is not a problem. BTW, how will ' mailman addmembers' treat a file containing: ``` Firstname Lastname <email@address> Onlyname <email2@address> ``` ? > Doing this with a DB dump/load would be very complex because while the > member table has a list_id field which is the id of the list's entry in > the mailinglist table and can be used to select the relevant members, > these records also link to entries in the address, preferences and user > tables and matching them would be an issue. > I am also not taking that path. I think a custom script would be required. If I were doing this, I would > make a separate database on my server with a copy of the data from the > other server and then try to make a script that would extract data from > the other database and add it to mine. Alternatively you could just dump the members from the other servers > with the `mailman members` command perhaps separately for regular and > the different digest types and then add them with the `mailman > addmembers` command. This wouldn't get all their attributes, but it > could work. > I have opted for the simple way to do this: 1. Create the site in Django Admin and create/configure the list in Postorius 2. Add the members from the file dump, with delivery set to regular. 3. Send the members an email informing them that they need to set their delivery preferences. I am stuck on the issue of exporting the archives to mbox file as already stated above. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

1 year, 7 months

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

by Jered Floyd

This was a related issue. See https://github.com/pennersr/django-allauth/pull/3554 --Jered --- a/allauth/socialaccount/models.py +++ b/allauth/socialaccount/models.py @@ -144,7 +144,7 @@ class SocialAccount(models.Model): return provider def get_provider_account(self): - return self.get_provider().wrap_account(self) + return self.get_provider(context.request).wrap_account(self) class SocialToken(models.Model): ----- On Dec 6, 2023, at 7:57 PM, Mark Sapiro mark(a)msapiro.net wrote: > On 12/6/23 14:49, Jered Floyd wrote: >> >> The difference in behavior was using social login buttons for an existing >> account vs. creating a new account. >> >> This is another damn django-allauth regression, starting in 0.57.0. It seem to >> be this commit that is to blame: >> https://github.com/pennersr/django-allauth/commit/be779dfee5a328a3a42edc2c9… >> >> In allauth/socialaccount/models.py:lookup(self):285 there is an attempt to look >> up the social account as one that already exists. If that fails, this commit >> calls self.account.get_provider() without passing the request object, which >> leads to the eventual error. >> >> I believe this is a django-allauth bug, and have submitted a pull request to fix >> it here: >> https://github.com/pennersr/django-allauth/pull/3548 > > Thanks for all your work on this. It is much appreciated. However, your > patch doesn't fix my issue with the URL > https://example.com/accounts/social/connections/ which still produces > the following: > ``` > ERROR 2023-12-07 00:05:55,032 169452 django.request Internal Server > Error: /accounts/social/connections/ > Traceback (most recent call last): > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/core/handlers/exception.py", > line 55, in inner > response = get_response(request) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/core/handlers/base.py", > line 220, in _get_response > response = response.render() > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/response.py", > line 114, in render > self.content = self.rendered_content > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/response.py", > line 92, in rendered_content > return template.render(context, self._request) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/backends/django.py", > line 61, in render > return self.template.render(context) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 175, in render > return self._render(context) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 167, in _render > return self.nodelist.render(context) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 1005, in render > return SafeString("".join([node.render_annotated(context) for node > in self])) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 1005, in <listcomp> > return SafeString("".join([node.render_annotated(context) for node > in self])) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 966, in render_annotated > return self.render(context) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/loader_tags.py", > line 157, in render > return compiled_parent._render(context) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 167, in _render > return self.nodelist.render(context) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 1005, in render > return SafeString("".join([node.render_annotated(context) for node > in self])) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 1005, in <listcomp> > return SafeString("".join([node.render_annotated(context) for node > in self])) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 966, in render_annotated > return self.render(context) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/loader_tags.py", > line 157, in render > return compiled_parent._render(context) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 167, in _render > return self.nodelist.render(context) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 1005, in render > return SafeString("".join([node.render_annotated(context) for node > in self])) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 1005, in <listcomp> > return SafeString("".join([node.render_annotated(context) for node > in self])) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 966, in render_annotated > return self.render(context) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/loader_tags.py", > line 157, in render > return compiled_parent._render(context) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 167, in _render > return self.nodelist.render(context) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 1005, in render > return SafeString("".join([node.render_annotated(context) for node > in self])) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 1005, in <listcomp> > return SafeString("".join([node.render_annotated(context) for node > in self])) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 966, in render_annotated > return self.render(context) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/loader_tags.py", > line 63, in render > result = block.nodelist.render(context) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 1005, in render > return SafeString("".join([node.render_annotated(context) for node > in self])) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 1005, in <listcomp> > return SafeString("".join([node.render_annotated(context) for node > in self])) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 966, in render_annotated > return self.render(context) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/loader_tags.py", > line 63, in render > result = block.nodelist.render(context) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 1005, in render > return SafeString("".join([node.render_annotated(context) for node > in self])) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 1005, in <listcomp> > return SafeString("".join([node.render_annotated(context) for node > in self])) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 966, in render_annotated > return self.render(context) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/defaulttags.py", > line 321, in render > return nodelist.render(context) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 1005, in render > return SafeString("".join([node.render_annotated(context) for node > in self])) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 1005, in <listcomp> > return SafeString("".join([node.render_annotated(context) for node > in self])) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 966, in render_annotated > return self.render(context) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/defaulttags.py", > line 238, in render > nodelist.append(node.render_annotated(context)) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 966, in render_annotated > return self.render(context) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/defaulttags.py", > line 539, in render > values = {key: val.resolve(context) for key, val in > self.extra_context.items()} > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/defaulttags.py", > line 539, in <dictcomp> > values = {key: val.resolve(context) for key, val in > self.extra_context.items()} > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 715, in resolve > obj = self.var.resolve(context) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 847, in resolve > value = self._resolve_lookup(context) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/template/base.py", > line 914, in _resolve_lookup > current = current() > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/allauth/socialaccount/models.py", > line 147, in get_provider_account > return self.get_provider().wrap_account(self) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/allauth/socialaccount/models.py", > line 141, in get_provider > provider = self._provider = adapter.get_provider( > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/allauth/socialaccount/adapter.py", > line 204, in get_provider > app = self.get_app(request, provider=provider) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/allauth/socialaccount/adapter.py", > line 284, in get_app > apps = self.list_apps(request, provider=provider, client_id=client_id) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/allauth/socialaccount/adapter.py", > line 231, in list_apps > db_apps = SocialApp.objects.on_site(request) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/allauth/socialaccount/models.py", > line 27, in on_site > site = get_current_site(request) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/contrib/sites/shortcuts.py", > line 16, in get_current_site > return Site.objects.get_current(request) > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django/contrib/sites/models.py", > line 63, in get_current > raise ImproperlyConfigured( > django.core.exceptions.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. > ``` > > -- > 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, 7 months

[MM3-users] GNU Mailman condemns reinstatement of RMS

by Abhilash Raj

To the Mailman community, The GNU Mailman Steering Committee condemns the reinstatement of Richard M. Stallman (RMS) to the Board of the Free Software Foundation (FSF), and has taken the following actions: 1. On behalf of the GNU Mailman project, signed the letter on GitHub[1] calling for the removal of the entire FSF Board, as well as RMS himself. 2. Started exploring ways to move our financial assets, for decades managed by the FSF, to new management. The management fees are small, but this is an important symbolic protest. 3. Started exploring how to leave the GNU Project. On the one hand, if we leave but GNU wants to maintain a "GNU Mailman" project, we cannot stop them, confusing users. On the other hand, RMS is leader of the GNU Project, and has intervened in Mailman affairs on many occasions. We should forestall this in the future. We wish to explain our actions to the community. Although free exchange of software among users is a practice that goes back to days of the earliest general purpose computers, RMS was the first to propose a complete free software distribution, and is the acknowledged founder of the Free Software movement. Even leaders of the Berkeley Software Distribution (BSD) acknowledge this. We all owe him a debt for this. Nevertheless, the movement has matured and thrived, spawning the competitive open source movement, with whose philosophy Mailman is more closely aligned. While we acknowledge our debt to RMS, we don't need him any longer. And unfortunately, he has become both a symbol and a source of the toxicity in tech communities. The FSF Board did the right thing by accepting RMS's resignation. They did the wrong thing by reinstating him. RMS has a long history of abusive behavior and toxic political positions. A small part of it is described in the open letter on GitHub[1] and its references[2], and several members of the Steering Committee have observed it directly. All of us have heard stories directly from those who were abused or observed it directly. His political positions are public, for example his support of pedophiles. He claims that he in no way supports abusive relationships with children, yet refuses to acknowledge that children are generally in no position to provide consent, an evasive and highly toxic position. There is no question: RMS is toxic. We came for mailing list management, but we stayed for the community. We have a right to protect our community by dissociating it from toxic influences. We do not want our project associated with such a person, nor to provide economic resources to organizations that promote him to leadership positions. We are taking these actions to protect our community, both the narrow community of Mailman developers and users, and the broader open source community, from his toxic behavior and from the reputational damage that will come from helping to enable him. While we have no information suggesting that other members of the FSF Board are similarly toxic as individuals, as a group they enabled RMS for decades, and now have taken an explicit step in enabling him again. If they want to regain their position of respect and acceptance in our community, they must acknowledge their error, and we don't see -- given their reinstatement of RMS himself -- how they can do so convincingly while maintaining their positions on the Board. They must resign, and a new Board composed, to demonstrate their sincerity. What they do is up to them, of course, but if they do not take radical steps, we will continue to consider association with the FSF a threat to our community. For the Mailman community, Abhilash Raj (project leader) Mark Sapiro Stephen J. Turnbull Aurélien Bompard Terri Oda Barry Warsaw John Viega (founder) [1] Text and signatures: https://rms-open-letter.github.io [2] Appendix to the letter: https://rms-open-letter.github.io/appendix Related statements: https://rms-open-letter.github.io/statements

4 years, 3 months

[MM3-users] Custom templates (was: Re: Re: nginx configuration on a multitasking server)

by David Newman

On 12/23/21 10:39 AM, Mark Sapiro wrote: > On 12/23/21 9:57 AM, David Newman wrote: >> >> The task-pending message that MM3 sends to list owners and moderators >> just says generically to check the dashboard, without providing a URL. >> >> Can that be modified to provide an explicit URL, something like this? >> >> https://lists.example.com/mailman3/lists/listname > > > Yes, That particular message is built from the list:admin:action:post > template. You may wish to make custom versions of that and other > templates. The templates and their default values are at > https://gitlab.com/mailman/mailman/-/tree/master/src/mailman/templates/en > > You can make custom versions of templates in two ways. You can create if > necessary a /opt/mailman/mm/var/templates directory (it probably already > exists). Within that directory, sitewide English templates are put in > the site/en/ directory, domain specific English templates are put in the > domains/<domain_name>/en/ directory and list specific English templates > are put in the lists/<list_id>/en/ directory. > > For templates like this, you probably want sitewide ones. E.g., > site/en/list:admin:action:post.txt > --------------------------------------------------------------- > As list administrator, your authorization is requested for the > following mailing list posting: > > List: $listname > From: $sender_email > Subject: $subject > > The message is being held because: > > $reasons > > At your convenience, visit > https://lists.example.com/mailman3/lists/$list_id/held_messages > to approve or deny the request. > --------------------------------------------------------------- > > The other way to create custom templates is via Postotrius, but > Postorius only creates list and domain specific templates. Also, if you > create a template in Postorius, it overrides any in > /opt/mailman/mm/var/templates/ until you delete it in Postorius. > > Info about templates and what substitution variables can be used is at > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/… Following up on this thread from a few weeks ago, a custom subscribe template I defined is not getting sent out. I created a pending subscription request on a test list. Here is the text I'm using in a file called 'list:admin:action:subscribe.txt' (minus the rows of hypens): ---------- As list administrator, your authorization is required for a mailing list subscription request approval: For: $member List: $listname At your convenience, visit: https://${domain}/mailman/admindb/lists/${short_listname}.${domain}/ to approve or deny the request. ---------- Instead the message that goes out at midnight daily reads like this: ---------- The test(a)lists.domain.tld list has 1 moderation requests waiting. Held Subscriptions: User: letmein(a)domain.tld Please attend to this at your earliest convenience. ---------- On successive nights I have placed copies of the 'list:admin:action:subscribe.txt' file above in these locations: mm/var/templates/lists/test.lists.domain.tld/en /opt/mailman/mm/var/templates/site/en and then in Postorius, with the same contents as above. The file versions are owned by the mailman user, and have 0644 permissions. Not sure this is necessary but I've restarted the mailman3 and mailmanweb services each time after a change. There is no sign of trouble in the MM3 or web logs. The only thing I see is in the Postfix log, where the shorter and less helpful message goes out each night. I don't see anything in the template docs about this. Questions: 1. What to do to get the custom message working? 2. Is there a way to trigger a subscribe reminder for one list only? Asking because there are other lists on this server with other requests pending, and I don't want to bother other moderators with multiple reminders per day. Not a big deal, but it would be nice to test this with one list rather than waiting up to 24 hours after each change. Thank you! dn

3 years, 6 months

[MM3-users] Re: Mails are not archived at all -- how to check if Hyperkitty is running or not?

by Tamas HOLCZER

Hi Franklin, when I installed mailman3 on Debian I had some issues. One was about MAILMAN_ARCHIVER_FROM. It turned out, that the request to Hyperkitty was sent from one of the real IPs of the machine (not from localhost). This depends on the interfaces and the routing of that machine. In my case the solution was something like: MAILMAN_ARCHIVER_FROM = ('127.0.0.1', '::1', '1.2.3.4', '1.2.3.5') , where 1.2.3.4 and 1.2.3.5 are the IP addresses of the machine running mailman3 (I have not debugged if it is using .4 or .5 in reality I left both of them there). Give it a try with your IPs. Tamás 2019. 10. 30. 8:52 keltezéssel, Franklin Weng írta: > Hi, > > It looks like to have some clues now. > > Mark Sapiro <mark(a)msapiro.net> 於 2019年10月30日週三 13:07 寫道： > >> On 10/29/19 8:21 PM, Franklin Weng wrote: >>> Yes, it is checked. >> Have you checked Mailman's logs - Mailman's var/logs/mailman.log in >> particular? >> > I found some hyperkitty URL error: > > The default settings of base_url in mailman-hyperkitty.cfg is defined as > > base_url: http://localhost/mailman/hyperkitty/ > > In the mailman.log there are messages like: > > Oct 30 13:53:43 2019 (14259) HyperKitty failure on > http://localhost/mailman3/hyperkitty/api/mailman/archive: <!DOCTYPE HTML > PUBLIC "-//IETF// > DTD HTML 2.0//EN"> > <html><head> > <title>404 Not Found</title> > </head><body> > <h1>Not Found</h1> > <p>The requested URL was not found on this server.</p> > > I changed it to > > base_url: https://localhost/mailman3/hyperkitty/ > > then the log became > > File "/usr/lib/python3/dist-packages/requests > /adapters.py", line 514, in send > raise SSLError(e, request=request) > requests.exceptions.SSLError: HTTPSConnectionPool(host='localhost', > port=443): Max retries exceeded with url: > /mailman3/hyperkitty/api/mailman/archive?key=xxx (Caused by > SSLError(SSLCertVerification Error("hostname 'localhost' doesn't match ' > lists.slat.org'"))) > > which makes sense because the SSL certificate applied from Letsencrypt is > for lists.slat.org. > > If I use > > base_url: https://lists.slat.org/mailman3/hyperkitty/ > > The log became > > Oct 30 15:25:50 2019 (6256) HyperKitty failure on > https://lists.slat.org/mailman3/hyperkitty/api/mailman/urls: > <html><title>Auth required</title><body> > > <h1>Authorization Required</h1> > </body></html> (401) > > In my mailman-web.py: > > MAILMAN_ARCHIVER_KEY = 'my-key,same as in mailman-hyperkitty.cfg' > MAILMAN_ARCHIVER_FROM = ('127.0.0.1', '::1') > > Not sure what to change here. > > >> Do messages received from the list have an Archived-At: header? >> > Yes, but it's empty > > > List-Id: 測試論壇 <slat-list.lists.slat.org> > Archived-At: <> > List-Archive: <> > List-Help: <mailto:slat-list-request@lists.slat.org?subject=help> > List-Post: <mailto:slat-list@lists.slat.org> > List-Subscribe: <mailto:slat-list-join@lists.slat.org> > List-Unsubscribe: <mailto:slat-list-leave@lists.slat.org> > > > >> What's in /etc/mailman3/mailman-hyperkitty.cfg? In particular does the >> [general] setting base_url define a URL that accesses hyperkitty > > It seems to be the question… > > > and >> does the [general] setting api_key match the MAILMAN_ARCHIVER_KEY >> setting in /etc/mailman3/mailman-web.py, but note that the >> MAILMAN_ARCHIVER_KEY setting is quotes because it is a Python string >> assignment and the api_key setting is not quoted >> > Yes, it's single quoted. > > > Thanks for all your help! > > > Franklin > _______________________________________________ > 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/

5 years, 8 months

[MM3-users]Re: mailman 2 vs. mailman 3: what happened to multipart/digest?

by John Hein

Here's an '02 reference in git to the some heritage for multipart/digest ========== commit 63d2568fe58333f8ca0b7582f74b43e775c581cd Author: bwarsaw <> Date: Thu Jul 11 22:14:25 2002 +0000 send_i18n_digests(): Let's generate MIME digests the correct way, by wrapping each message inside the multipart/digest in a MIMEMessage instance. We also no longer need to initialize the mimedigest instance's payload to the empty list. Also, when sending the digests, be sure to include isdigest=1 in the metadata, otherwise SMTPDirect will try to tack on another footer. ========== John wrote at 16:46 -0600 on May 12, 2016: > Mark Sapiro wrote at 12:18 -0700 on May 12, 2016: > > On 5/12/16 9:16 AM, John wrote: > > > Digest delivery in mailman 2 encapsulated the individual message/rfc822 messages in a multipart/digest container. This allowed email clients to show the messages in the particular digest in a threaded view. > > > > > > This format vs. plain text digests was a user option in Mailman 2. > > > > > > > It seems like the various digest options that I have tried [1] in mailman 3.1.0 (as implemented for the fedora-users mailing list) no longer encapsulate messages in multipart/digest. > > > > > > The core still supports the same plain text and MIME format digests and > > the same individual subscriber and per-list default formats as did > > Mailman 2. The issue is none of these things are exposed in Postorius. > > > > If you subscribe to digests on this list, you will receive the > > 'encapsulated' MIME format because the lists mime_is_default_digest > > setting is True, but currently that has to be set through the > > bin/mailman shell tool. > > > > > > > Is this intentional? Is it a bug - feature that was lost in translation from 2 to 3? Is there a delivery option I'm missing that will turn that back on? > > Thanks for the info - and Barry's reply as well. I understand that > MIME digests are supported in Mailman 3 - that's what I'm using (and > thanks, Barry, for the info that Summary Digests is the same right > now). My quibble is that the multipart/digest encapsulation level is > gone. > > Barry Warsaw wrote at 15:16 -0400 on May 12, 2016: > > The MIME format of MIME digests should roughly be: > > > > multipart/mixed > > text/plain (the digest heading) > > text/plain (the TOC) > > message/rfc822 > > message-1 > > message/rfc822 > > message-2 > > ... > > text/plain (footer) > > > But mm 2 had: > > multipart/mixed > text/plain (the digest heading) > text/plain (the TOC) > multipart/digest <--- this is the part that's gone in mm3 > message/rfc822 > message-1 > message/rfc822 > message-2 > ... > text/plain (footer) > > So was that removal intentional, a bug or ?? > > Maybe you're saying there is definitely an unexposed (in Postorius) > knob for that in mm3. > > > > > It is the intent that Postorius will eventually expose all these > > settings. We're not there yet. At present you could possibly do this by > > interacting with mailmanclient, although I'm not certain the settings > > are exposed there. You can do it via bin/mailman shell if you have > > access and know what you're doing (see > > <http://mailman.readthedocs.io/en/release-3.0/src/mailman/runners/docs/diges…>) > > > > If you file an issue at > > <https://gitlab.com/mailman/postorius/issues/new>, it might help > > expedite this. > > Okay. > _______________________________________________ > Mailman-users mailing list > mailman-users(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/

9 years, 2 months

[MM3-users] Re: Wrong info in moderation mail when held due to match of a header rule

by tlhackque

On 17-Oct-20 18:40, Mark Sapiro wrote: > On 10/17/20 1:31 PM, tlhackque via Mailman-users wrote: >> I might also add the rule number or config filename:line, as in >> >> Header "{name}": rule in {file}:{n} matched value "{value}" >> >> This would be helpful when backtracking from a rejected message to the >> cause. >> >> A sample expansion might be: >> >> Header "X-Spam": rule in foo.conf:83 matched value "yes" > > These rules are not in a configuration file. They are in the headermatch > table in the database and the rules for a particular list are exposed on > the Header filters tab in Postorius or at the REST > lists/LISTNAME/header-matches endpoint. > > Perhaps something like > > {name}: header match rule, pattern "{pattern}" matched value "{value}" > > example: > > subject: header match rule, pattern "sex|long|list|of|other|bad|words" > matched value "This is a post about filtering based on words like sex in > the subject." > > but that could be just adding more clutter. > I considered including the regex in each message, but that seemed redundant - and potentially long. Thus the pointer. Perhaps number the rules for each list, and use that index? The ROWID would seem to be a candidate for the number. Then Postorius could simply number the rules in its tab; the REST API can add the ROWID as a rule_ID field in the returned JSON. (The fact that it's a ROWID rather than an index or unique name is an implementation detail.) If many rules are anticipated, it might want an endpoint or option to fetch a rule by ID. Then it would be easy to drill down on a specific event for diagnosis. e.g. shunt_reason: (or whatever) { cause: "header_match" header: "subject" header_value: "This is a post about filtering based on words like sex in the subject." rule_id: 47 /* or pattern_id? */ } displays as subject: header match rule 47, matched value "This is a post about filtering based on words like sex in the subject." and lists/LISTNAME/header-matches/47 returns { rule_id: 47 pattern: "sex|long|list|of|other|bad|words" position: 3 /* Whatever else is in your table... I haven't looked since I postponed using MM3. eg */ comment:"Required by policy 869.202" last_updated_by: "Corporate Prude" last_updated_on: "1-Apr-1762" }, while lists/LISTNAME/header-matches returns an array of those structures, presumably as today. With those capabilities, the UI can be enhanced so that clicking on a shunted message gives the summary reason, and clicking on the summary gives the regex. I expect that the header and value will be sufficient for understanding an issue most of the time. Looking at the regex is less common, and only necessary when it needs to be updated... I still think that it is more readable and less verbose to order the message as a declarative sentence: Header "subject": rule 47 matched value "sex" but that may be a matter of personal taste. The UI can sort that out... Note that from your description, using ROWID may cause rules in a particular list to have gaps in the rule numbering. I don't think that's a big issue, though Postorious could paper that over - perhaps use the position attribute. Doesn't seem worth doing something more complex. The advantage is that it doesn't require any DB change now. But aliasing it to "rule_id" allows for any future demand to name the rules or use some other numbering scheme. I may have some details wrong - I found mm3 not ready for my needs and am thus out of date - but I hope the high level approach that I outlined is useful.

4 years, 9 months

[MM3-users] Re: Mailman stopping message distribution because of SMTP errors

by Victoriano Giralt

El mié, 12-02-2020 a las 13:28 -0800, Mark Sapiro escribió: > On 2/11/20 10:28 PM, Victoriano Giralt wrote: > > > > I have recently migrated some lists from Mailman 2 to Mailman 3. Users > > have > > been added using the mailman client as pre-verified addresses so the > > migration happened "silently". Thus, there was a dozen "bad" addresses > > (domains that did not exist anymore). > > > It seems you rolled your own instead of using `mailman import21`. Is > there a reason for this? Yes, no access to the previous server command line. So, to tell the truth it was not a "real" migration, my excuses. > > Unfortunately, Mailman got some of the "bad" addresses in the first > > message > > batch for sending out, so, Postfix closed the connection because of > > "too > > many errors" and this stopped the process completely, i.e. Mailman did > > not > > continue sending messages to the rest of the list over 600 addresses. > > > Is the message shunted? Is there a traceback and a shunting message in > mailman.log? > > Normally, I would expect the message to be queued in Mailman's retry > queue and retried by Mailman Yes, it was being retried every 15 minutes with the same result: stopped distribution after the first attempt with the first address batch. Also reprocessing the "retry" files with mailman command interface. > > There was no more information in the logs than the Postfix error > > messages > > in smtp.log. My bad, the errors where in the system maillog where Postfix complains. > What was in the smtp.log? This (redacted to protect the innocent): Feb 05 16:29:44 2020 (86791) ('127.0.0.1', 51146) recip: listname @example.org Feb 05 16:30:16 2020 (86797) <messageid(a)example.com> smtp to listname @example.org for 634 recips, completed in 29.087315797805786 seconds Feb 05 16:30:16 2020 (86797) <messageid(a)example.com> post to listname @example.org from sender(a)example.com, 4354 bytes, 9 failures Feb 05 16:30:20 2020 (86791) ('127.0.0.1', 51642) Data: b'RCPT TO:<listname -bounces(a)example.org>' Feb 05 16:30:20 2020 (86791) ('127.0.0.1', 51642) recip: listname -bounces(a)example.org Feb 05 16:30:43 2020 (86791) ('127.0.0.1', 51870) Data: b'RCPT TO:<listname -bounces(a)example.org>' Feb 05 16:30:43 2020 (86791) ('127.0.0.1', 51870) recip: listname -bounces(a)example.org ... rinse and repeat every 15 minutes ... > Nothing in mailman.log? Nothing at all about SMTP/LMTP > Nothing in var/queue/shunt? Nothing there, a .psv file in var/spool/mailman/bad/ and two .pck files in retry/ > Once the "bad" addresses were removed, the list started working as > > expected. > > > > I consider this a bug. The bouncing addresses should have been marked > > as > > "non deliverable" and the subscriptions "paused" and the rest should > > have > > been delivered. Or, the list owner should have been notified that there > > was > > a problem with message distribution. None of these happened. > > > The HEAD of the https://gitlab.com/mailman/mailman master branch > implements bounce processing. This will be in 3.3.1 which is not yet > released. > > The place for a bug report is <https://gitlab.com/mailman/mailman/issues> Well, if 3.3.1 has bounce processing, I'd rather wait and test when it is released instead of adding "noise" in the bug tracker, right? My problem was solved with a workaround: find and remove the "bad" addresses. Let's leave this as reference in the archives in case someone hits the same problem. -- Victoriano Giralt CIO University of Malaga +34952131415 SPAIN ================================================================== Note: signature.asc is the electronic signature of present message A: Yes. > Q: Are you sure ? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email ?

5 years, 5 months

Search results for query "sapiro"