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

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

5 months, 1 week

[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, 2 months

[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, 11 months

[MM3-users] Re: Where to configure 'hostname' used in 'From:'-header?

by Mark Sapiro

On 3/10/23 01:55, Dmitri Heerdegen wrote: > > I've recently installed MM3 with Exim4 on, say, subdomain.myhost.tld > and configured MM3 to use lists.someotherdomain.tld as web host and mail > host. > Thus, the mailman.cfg contains: > > [mta] > smtp_host: lists.someotherdomain.tld > > When I send a message to test(a)lists.someotherdomain.tld it gets > delivered, however the 'From:'-header becomes "test(a)subdomain.myhost.tld". The From: should be unchanged from the incoming post unless the list is anonymous or DMARC mitigations are applied. In the case of anonymous lists, the From should be the list's address and in the case of DMARC mitigations it should be something like User Name via listname <list-address>. In either case, the list address should be list-name@list-domain where list-domain is the list's email domain. If the address is being rewritten as test(a)subdomain.myhost.tld it is probably Exim doing it. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 3 months

[MM3-users] Re: A poll: "Delete this thread"

by Mark Sapiro

On 6/21/24 07:45, Sam Darwin via Mailman-users wrote: > Thanks for the replies. Not yet a close match to what I have installed. Jeremy is using Dockerfiles. Marc is running mailman3-web from 4 years ago "20200530". I may need to dig into the code and attempt to debug, line by line. "Oh, of course, in your settings refresh_cache needs to be set to 1, you have it set to 0", or something obscure like that. Or who knows. I manage 3 production mailman 3 servers and a development server. All 4 are running the current (as of today) heads of the GitLab branches installed in a venv. The versions of some dependencies probably vary, but all use django_q2-1.6.2 one uses Django-4.2.11, two use Django-4.2.6 and one uses Django-4.1.13. They all use memcached as the cache backend. I don't know what you mean by the refresh_cache setting as I have no information about such setting. All 4 servers are able to delete threads in HyperKitty with no issues. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 11 months

[MM3-users] Re: Installation -- error on mailman-web migrate

by Mark Sapiro

On 9/16/21 7:27 PM, Mark Dale via Mailman-users wrote: > > I note that in the sample "settings.py" file, there are lines that have the directory "web" in the file paths ... > > STATIC_ROOT = '/opt/mailman/web/static' > > LOGGING['handlers']['file']['filename'] = '/opt/mailman/web/logs/mailmanweb.log' > > > ... but as yet there is no directory "web". This appears to be an error in the docs. With ``` [paths.here] var_dir: /opt/mailman/mm/var [mailman] layout: here ``` The logs are in `/opt/mailman/mm/var/logs/`, not `/opt/mailman/web/logs/` and `STATIC_ROOT` should probably be `/opt/mailman/mm/static`, but it could also be `/opt/mailman/mm/var/static`. > Was I meant to create the directories "web/logs/" and the "mailmanweb.log" file at some point, or were they meant to get created during the mailman-web install process? They should be created automatically, but in `var_dir` which is `/opt/mailman/mm/var`, not `/opt/mailman/web` > Should the owner/group be "mailman"? Yes -- 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: REST API authorization failed

by Mark Sapiro

On 1/8/22 10:40 AM, Axel Rau wrote: > Hi all, > > I’m going to do a mailman2->3 migration in a FreeBSD jail. > I installed mailman3 in an venv from pypi, along with nginx, uwsgi and exim. > The above error happens when I try to open the base url of my server with a browser > (is redirected to postorius/lists/) > (no errors on admin/ and hyperkitty urls) > > Same passwords and users in mailman.cfg: > > [webservice] > hostname: localhost > port: 8001 > use_https: no > admin_user: restadmin > admin_pass: ??? > > and in settings.py: > > MAILMAN_REST_API_URL = 'http://localhost:8001' > MAILMAN_REST_API_USER = 'restadmin' > MAILMAN_REST_API_PASS = ??? > > Its a long password, created as secret key by manage.py Is the password unquoted in mailman.cfg as admin_pass: ??? and quoted in settings.py as MAILMAN_REST_API_PASS = '???' Does the `mailman info` command report what you think for REST credentials? To you get an appropriate JSON response from wget -O- --user restadmin --password ??? http://localhost:8001/3.1/lists -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 5 months

[MM3-users] Re: Digests not working correctly

by Mark Sapiro

On 6/13/23 09:42, Joel Lord wrote: > Now I'm on one of the lists in digest mode and I can see that it's a > mess. Periodic digests are definitely NOT working, so I'll lay that out > here. > ... > root@host2:/# grep digests /var/log/cron.log > Jun 11 23:00:01 host2 CRON[1632765]: (lists) CMD (/usr/local/bin/mailman > digests --periodic) > Jun 12 23:00:01 host2 CRON[2177286]: (lists) CMD (/usr/local/bin/mailman > digests --periodic) OK. > root@host2:/home/members/directory# su - lists > lists@host2:~$ /usr/local/bin/mailman digests --periodic > lists@host2:~$ ls var/lists/<list>/ > digest.mmdf If there is nothing in Mailman's mailman.log, I don't know what the issue is unless the list's digest_send_periodic flag is False. > How can I try and track this down? Try manually running ``` /usr/local/bin/mailman digests --periodic --verbose ``` to get more info. Also try ``` /usr/local/bin/mailman digests --send --verbose ``` to see what it reports and whether it sends the digest. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years

Search results for query "sapiro"