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

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

by Mark Sapiro

On 8/5/24 10:30, Odhiambo Washington via Mailman-users wrote: > > Actually, what I mean is that CF is proxying requests to the host named > m3-lists.kictanet.or.ke. > I do not have any configuration other than DNS proxying at CF. ``` dig a mm3-lists.kictanet.or.ke ... mm3-lists.kictanet.or.ke. 300 IN A 172.67.167.73 mm3-lists.kictanet.or.ke. 300 IN A 104.21.11.217 ``` Both of those are cloudflare IPs, and why 2? > So when you talk to m3-lists.kictanet.or.ke via a browser, it's CF IP who > you talk to and it in turn talks to the host directly. And how is that configured? > So the IP address you see in the logs is CF's IP address, not yours, not > mine and CF are doing some caching. That's why > they are requesting for expired files. Why is cloudfare trying to access /opt/mailman/mm/static/CACHE/css/output.6dab123e4897.css locally if all it is doing is proxying the request to the actual mailman server? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 9 months

[MM3-users] Re: Login confusion

by Mark Sapiro

On 2/11/25 01:26, Stephen J. Turnbull wrote: > > That will work in the short run, but I'm not sure that's a long-term > solution. It's not clear to me that allauth won't do the same thing > again. Allauth since 0.62.0 and better since 0.63.0 no longer does this. See https://codeberg.org/allauth/django-allauth/src/branch/main/ChangeLog.rst#s… > > Could I have achieved the same deletion using the REST interface? > > I don't know. I would think not. That's correct. The issue is in the account_emailaddress database table which is an allauth table that Mailman core and hence the REST api know nothing about. Our latest recommendation is django-allauth>=65.4, but that requires changes, see https://gitlab.com/mailman/django-mailman3/-/merge_requests/316 and https://gitlab.com/mailman/mailman-web/-/merge_requests/58 although the changes only affect testing and a deprecation warning. Also, installing that django-allauth version may result in upgrading Django to a version which doesn't support django-haystack<3.3.0 and may also require manually upgrading django-haystack. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 2 months

[MM3-users] Re: clearing pending db

by Mark Sapiro

On 8/8/25 09:59, Morris Jones wrote: > > But pendingdb.evict() doesn't seem to clear the list. For example, on > one of my lists: > > >>> from mailman.interfaces.pending import IPendings > >>> > >>> from zope.component import getUtility > >>> > >>> pendingdb = getUtility(IPendings) > >>> pendingdb.count() > 5040 > >>> pendingdb.evict() > >>> pendingdb.count() > 5040 > >>> pendingdb.evict() only deletes expired pendings, but by default subscriptions pending confirmation expire after 3 days, but this is set by pending_request_life in the [mailman] section of mailman.cfg. Have you set that to a long time? On the other hand in Mailman 3.3.2, subscriptions pending approval were pended with a 10 year lifetime. This was changed in 3.3.5 to a new moderator_request_life setting (default 180 days). If you just want to delete all pendings you could do ``` pendingdb = getUtility(IPendings) for pending in pendingdb: pendingdb.confirm(pending[0], expunge=True) # and if doing this in mailman shell commit() ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

9 months

[MM3-users] Re: How to separate bans for sending emails to lists and subscribing to them

by Mark Sapiro

On 5/29/19 9:29 AM, Nathan Dixon wrote: > Hi, > Our requirements for using Mailman are that we can have non-members send an > email to a list from any domain name, but only people who's email addresses > match a list of specific domains should be able to actually subscribe to > those lists. > > I can't seem to find any way of doing this. Any ideas? > > I have tried using the bans (global and on each list) but these appear to > stop all subscriptions and emails being sent to or from a list if the > address matches a ban. Right. The default posting rules chain includes 'banned-address' which discards posts from banned addresses. You can work around this by creating a new chain based on mailman/chains/builtin.py but without the 'banned-address' rule and setting the list's posting_chain to use it. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 11 months

[MM3-users] Re: If you delete a list but not the HyperKitty archive

by Mark Sapiro

On 1/4/22 6:45 AM, Philip Colmer wrote: > > So ... should the archive be deleted when the list is deleted and it is a > bug that it isn't? Or is it expected that access to the archive is "frozen" > once a list is deleted? It is often desired to have a public archive available after the corresponding list has been deleted. Even for a private archive, it may be desirable for site admins to have access. Furthermore, a list might not even have a HyperKitty archive in the first place. Thus, what to do about a HyperKitty archive (or prototype archive or ...) when a list is deleted is an administrative decision and is best left up to the site admins to do it or not. As you note with a private archive, former members no longer have access when the list is gone, but unless an attempt throws some uncaught exception, that is not a bug. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 4 months

[MM3-users] Re: Apache+mod_wsgi issue

by Mark Sapiro

On 12/26/22 07:08, Odhiambo Washington wrote: > > So it seems your WSGIDaemonProcess is defined somewhere outside the VHOST, > right? Or it wasn't necessary? > And what does your urls.py look like? Eggert's configuration is for uWSGI. This is completely different from Apache mod_wsgi. Background: Python PEP 333 defines the Python Web Server Gateway Interface (WSGI) which is a protocol for communication between web servers and applications. Django is one such WSGI application. Basic web servers typically do not support WSGI directly but need some kind of intermediary. Apache mod_wsgi is an Apache module that extends Apache to communicate with WSGI applications. Both uWSGI and gunicorn are separate applications that can receive http requests via proxy from a web server and communicate them to a WSGI application and receive responses from the application and return them to the web server. Thus Apache mod_wsgi, uWSGI ang gunicorn are three separate ways of providing the connection between the web server and Django (or other WSGI applications), each with their own separate configuration requirements. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 4 months

[MM3-users] Re: Archive search failing on one list

by Mark Sapiro

On 9/23/23 19:19, Mark wrote: > > Yes, the query returns a result and the case in "name" matches that in > the query ... > > select * from hyperkitty_mailinglist where name like 'listname(a)domain.com' > > id | 91 > name | listname(a)domain.com > display_name | Listname > description | ... > subject_prefix | [Listname] > archive_policy | 1 > created_at | 2023-09-21 08:55:36.385239+2 > list_id | listname(a)domain.com Is that really what you get for list_id? It should have a dot, not at as listname.domain.com. What if you do something like the following where django-admin is whatever command you use for the Django admin command. ``` $ django-admin shell Python 3.9.16 (main, Dec 11 2022, 12:49:23) [GCC 9.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> from hyperkitty.models.mailinglist import MailingList >>> mlist_name = 'listname(a)domain.com' >>> mlist = MailingList.objects.get(name=mlist_name) >>> mlist <MailingList listname(a)domain.com (listname.domain.com)> >>> ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 7 months

[MM3-users] Re: Change Member's Address

by Mark Sapiro

On 1/13/26 11:30 AM, alain williams wrote: > > Like it or not it is sometimes easier for me to do that sort of thing than try > to explain it to them. I understand. > So: it would be really useful if the list manager were able to do this via the > web interface. As you indicate, a list admin can use the mass subscribe/removal UI to remove the old address subscription and add a new address subscription, but as you probably know, this doesn't preserve the user's other settings, and for a user with multiple subscriptions, it needs to be done list by list, so this really isn't a satisfactory way for an admin to change a user's address. There is a current issue at https://gitlab.com/mailman/postorius/-/issues/399 to simplify the process for a user to change their address and one at https://gitlab.com/mailman/postorius/-/issues/194 to allow an admin to change a user's address. Merge requests are welcome. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 months, 3 weeks

[MM3-users] Re: out queue backlog and delivery rate

by Mark Sapiro

On 4/8/22 09:47, dancab(a)caltech.edu wrote: > For anyone coming across this thread. It seems increasing the runners did the job for us. The smtp.log is now showing smaller lists being completely processed while larger lists are still in progress of sending out to members. > > We edited the mailman.cfg to include the following and the mailman stop; mailman start > > [runner.in] > class: mailman.runners.incoming.IncomingRunner > instances: 2 There's probably no issue that would be helped by increasing in runner instances. > [runner.out] > class: mailman.runners.outgoing.OutgoingRunner > instances: 2 I would suggest larger, 4 or even 8. This is not a single queue/multiple server setup. It is multiple queue/multiple server. I.e. The queue entries are named based on a hash of the message and each instance processes its own slice of the hash space. So, with 2 slices and a large recipient message being processed, there's a 50% chance that the next message will wind up waiting. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years

[MM3-users] Re: FYI: Django security releases issued: 4.0.6 and 3.2.14

by Mark Sapiro

On 7/8/22 6:34 AM, Stephen J. Turnbull wrote: > David Newman writes: > > > Interesting -- that does produce two directories with names starting > > with a tilde: > > > > /opt/mailman/venv/lib/python3.9/site-packages/~jango: > > /opt/mailman/venv/lib/python3.9/site-packages/~jango-3.0.14.dist-info: > > I would guess that those are the previous versions before the upgrade, > moved out of the way in case a revert-to-previous was needed. Again, > guessing, they should have been removed by the upgrade process once > the new package was fully installed. Was there an interrupted or > partially successful upgrade in the past? When pip is doing an upgrade of the xyz package, it renames the existing package as ~yz and then ultimately deletes the old ~yz package after successfully installing the new xyz. In this case, the upgrade was aborted because of the Django<3.1 constraint in mailman-web and apparently pip then installed Django<3.1 and left the ~jango* directories behind. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 10 months

Search results for query "sapiro"