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

[MM3-users] Re: Clean-up of non-members

by Odhiambo Washington

On Mon, Dec 23, 2024 at 8:58 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 12/23/24 02:16, Odhiambo Washington via Mailman-users wrote: > > On Mon, Dec 23, 2024 at 1:37 AM Mark Sapiro <mark(a)msapiro.net> wrote: > > > >> Isn't this just `mailman members --role nonmember LISTSPEC`? > >> > > > > I didn't know that the option was right in front of me, but it seems > there > > is a problem: > > GNU Mailman 3.3.10 (Tom Sawyer), Mailman Core API Version 3.1 > ... ^^^^^^^^^^^^^^^^^^^^^^^^ > > AttributeError: 'NoneType' object has no attribute 'display_name' > > > I saw that too. Reported > https://gitlab.com/mailman/mailman/-/issues/1187 and fixed > https://gitlab.com/mailman/mailman/-/merge_requests/1297 It isn't clear to me what I should do to mitigate the error. -- 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]

1 year, 1 month

[MM3-users] Re: [ERROR] Error handling request List archivers

by Mark Sapiro

On 7/23/20 12:39 AM, Shashikanth Komandoor wrote: > Thank you Mark for guiding me to the benefit of putting the list and so I > have added the list. > > Along with the [archiver.hyperkitty], [mta] and [database], few lines of my > mailman.cfg look like below: > > > > [webservice] > workers = 4 > timeout = 900 > > The above block of webservice is added yesterday for testing or trail as I > am getting the above issue. > > And there is no line that is calling *gunicorn* in my mailman.cfg. As I tried to explain to you in an off-list reply: You can't configure Mailman's REST gunicorn workers directly in the [webservice] section of mailman.cfg. The only thing you can configure there is: configuration: /path/to/gunicorn.cfg That file, which is separate from your web server gunicorn.cfg, is where you put things like [gunicorn] timeout = 900 It also will not work to put a gunicorn section in mailman.cfg. It must be in a separate file pointed to by webservice.configuration. Increasing the number of workers won't help this issue. > Apart from that I tried to locate and see the content of the gunicorn.cfg > file as below : > > *(venv3) [root@lsmgr mailman]# cat /var/lib/mailman/mailman/src/mailman/config/gunicorn.cfg > [gunicorn] > # All the options that can be put here are available at > # http://docs.gunicorn.org/en/stable/settings.html#settings > > # No of seconds to wait before killing the worker processes. > graceful_timeout = 30 > > Please confirm the time I have to change is *graceful_timeout *in > *gunicorn.cfg* and if I have changed how do I restart the *gunicorn*. I > have never used or never known about this *gunicorn* but still running the > service in production. First, the file you reference above is the default gunicorn configuration for the REST server. You don't want to edit this file because your changes will be overridden in an upgrade. You want to create your own gunicorn.cfg file and point to it by adding configuration: /path/to/your/gunicorn.cfg to the webservice section in your mailman.cfg. Your gonicorn.cfg does not need to contain the graceful_timeout = 30 setting as that is a gonicorn default, and that is not what you need to increase. What you need is [gunicorn] timeout = 900 (actually 900 seconds is probably way overkill. 90 seconds would probably be enough.) -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 7 months

[MM3-users] Re: member appears twice in list - how?

by Mark Sapiro

On 11/5/24 11:09, Jose Bernal via Mailman-users wrote: > I've got a list member showing up twice in a list (same email address). > Can't use the GUI to remove the member from this list (get a 503 error) > Screenshots attached, underlying database query reveals no duplicates. > Wondering how this is possible or where else I should be looking to resolve > this duplicate before I simply remove their entry from the members table > altogether. I'm not sure how this could have happened, I need more info for that, but to deal with this use `mailman shell` as in ``` $ mailman shell -l list(a)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(a)example.com mailing list >>> x = m.memberships('user(a)example.com') This should set x to a list of that users memberships You can then examine x[0] and x[1] to determine which to delete. e.g. >>> dir(x[0]) ['__abstract__', '__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getstate__', '__gt__', '__hash__', '__implemented__', '__init__', '__init_subclass__', '__le__', '__lt__', '__mapper__', '__module__', '__ne__', '__new__', '__providedBy__', '__provides__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__table__', '__tablename__', '__weakref__', '_address', '_lookup', '_mailing_list', '_member_id', '_reset', '_sa_class_manager', '_sa_instance_state', '_sa_registry', '_user', 'acknowledge_posts', 'address', 'address_id', 'bounce_score', 'delivery_mode', 'delivery_status', 'display_name', 'id', 'last_bounce_received', 'last_warning_sent', 'list_id', 'mailing_list', 'member_id', 'metadata', 'moderation_action', 'preferences', 'preferences_id', 'preferred_language', 'receive_list_copy', 'receive_own_postings', 'registry', 'role', 'subscriber', 'subscription_mode', 'total_warnings_sent', 'unsubscribe', 'user', 'user_id'] This gives the list of attributes which can be examined with, e.g. >>> x[0].delivery_mode <DeliveryMode.regular: 1> You can then remove the one you don't want, e.g. >>> x[0].unsubscribe() >>> commit() ``` Just to be sure, you should ensure that x[0].member_id and x[1].member_id are different. These are the _member_id column in the member table in the database. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 3 months

[MM3-users] Re: Installing mailman 3

by Rafael Mora

Ok, I screwed the mailman install ..... I reinstalled mailman core. How do I do a Python2 virtualenv? Thanks El vie., 21 jul. 2017 a las 15:03, Mark Sapiro (<mark(a)msapiro.net>) escribió: > On 07/21/2017 12:44 PM, Rafael Mora wrote: > > I did this: > > > > (env) [mailman@localhost mailman-suite_project]$ pip install Django > > Requirement already satisfied: Django in > > /var/lib/mailman/env/lib/python3.6/site-packages > > Requirement already satisfied: pytz in > > /var/lib/mailman/env/lib/python3.6/site-packages (from Django) > > > > > > Does Django is already installed?? with python3.6 ??? > > > Your 'env' vitrualenv is a Python 3 virtualenv. You need this for > Mailman core, but Django and mailman-suite are Python 2. They need to be > installed and run in a Python 2 virtualenv. > > -- > 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 > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > -- Atentamente / Best Regards Ing. Rafael Mora

8 years, 7 months

[MM3-users] Re: Hyperkitty 1.1.1 to HyperKitty 1.2.1

by Thomas G

I tried all job, without result. (and they are correctly in the crontab) [image: image.png] If I try to find my list in the form, hyperkitty can find it: [image: image.png] Le mer. 3 oct. 2018 à 17:59, Mark Sapiro <mark(a)msapiro.net> a écrit : > On 10/03/2018 02:30 AM, Thomas G wrote: > > > I have just a problem with statistics not available. > > > If cron is running all the periodic django jobs, this gets fixed > eventually. The one thing you may need to run manually is > > manage.py runjob thread_order_depth > > as that helps with some things and is a 'yearly' job. I think the > 'hourly' and 'daily' jobs fix most other issues. See > > manage.py runjob --list > > -- > 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/ >

7 years, 4 months

[MM3-users] Re: re-sending confirmation mails (was Re: Re: pending subscriptions lost?)

by Mark Sapiro

On 3/15/22 03:04, IEM Network Operation Center (IOhannes m zmölnig) wrote: > > afaiu, this snippet allows me to purge outdated pending subscriptions. > > modifying it slightly, also allows me to just list the pending > subscriptions along with their tokens and print them out. That is correct. > is it still possible to just use these tokens to confirm the pending > subscription (even though it is long overdue)? Yes. > while investigating this a bit, i also noticed that it seems that with > mailman3 the only option to confirm a pending subscription is via email > ("leaving the subject intact") - at least that is the only option that > is listed in the confirmation mail. > > now i would like to massage this into what i think is a bit more > user-friendly. > first of all: most email confirmation systems allow me to either "reply > by email" or "click this link". > is there a way to do this for mailman3? that is: is there a (hidden) URL > that would accept the token in order to confirm a subscription? See https://gitlab.com/mailman/mailman/-/issues/901 You can add something like ``` Alternatively, you can confirm by going to the URL https://$domain/mailman3/lists/$list_id/confirm/?token=$token ``` to the list:user:action:subscribe template. Note that `$domain` may not be appropriate here because it is the email domain which may not be the web domain. > also: the confirmation mail says that the subject must be kept intact. > however, i noticed that the actual "From" address of the confirmation > mail already contains the token. The current template https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/templates/en/l… doesn't say that. > would it be enough if people just sent an email to this special > email-address (that contains the token), regardless of the subject? Yes. > i'm thinking of sending a rather personalized email that has a more > attractive subject than "confirm flkdsajfsalkjflsajfsoisjdl". The current mail has Subject: Your confirmation is needed to join the <fqdn_listname> mailing list > finally: what else is required to approve the confirmation? will the > sender's email-address be taken into account? (e.g. if they subscribed > "foo+mylist(a)example.com" but send the confirmation-reply from > "foo(a)example.com", will that still work? Yes. Only the token is required. -- 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: Huge performance issue: Mailman doesn't (seem to) receive any mails.

by Mark Sapiro

On 9/20/19 1:54 AM, Henrik Rasmussen wrote: > Mark Sapiro wrote: >> What other log entries relate to attempts to send to 172.19.199.2:8024? >> You may have to go back to when this first started to see them. > > Docker deleted it's log when restaring, as the container is deleted and removed, but the starte of the current log says: > ``` > Sep 18 13:28:57 postfix rsyslogd: [origin software="rsyslogd" swVersion="7.4.7" x-pid="20" x-info="http://www.rsyslog.com"] start > Sep 18 13:29:00 postfix postfix/postfix-script[94]: starting the Postfix mail system > Sep 18 13:29:00 postfix postfix/master[96]: daemon started -- version 2.10.1, configuration /etc/postfix > Sep 18 13:29:02 postfix postfix/smtpd[102]: connect from incoming.gateway.example.com[192.168.111.222] > Sep 18 13:29:04 postfix postfix/smtpd[102]: EFF017E9D65AE: client=incoming.gateway.example.com[192.168.111.222] > Sep 18 13:29:04 postfix postfix/cleanup[106]: EFF017E9D65AE: message-id=<2E40950170CA0A4A8D0F0C0CF1C0630601B8B9F412(a)P1KITMBX03WC02.unicph.domain> > Sep 18 13:29:04 postfix opendkim[19]: EFF017E9D65AE: incoming.gateway.example.com [192.168.111.222] not internal > Sep 18 13:29:04 postfix opendkim[19]: EFF017E9D65AE: not authenticated > Sep 18 13:29:04 postfix postfix/smtpd[102]: disconnect from incoming.gateway.example.com[192.168.111.222] > Sep 18 13:29:18 postfix postfix/qmgr[98]: 0E53F7E9D7D8D: from=<>, size=212010, nrcpt=1 (queue active) > Sep 18 13:29:18 postfix postfix/qmgr[98]: C51DE7E9920B8: from=<>, size=212004, nrcpt=1 (queue active) > Sep 18 13:29:18 postfix postfix/qmgr[98]: 2923A7E99B41F: from=<>, size=212040, nrcpt=1 (queue active) > Sep 18 13:29:18 postfix postfix/qmgr[98]: D0A1E7E981E26: from=<quarantine(a)messaging.microsoft.com>, size=14542, nrcpt=1 (queue active) > Sep 18 13:29:18 postfix postfix/qmgr[98]: 95FA77E9815A5: from=<>, size=211977, nrcpt=1 (queue active) > Sep 18 13:29:18 postfix postfix/qmgr[98]: 208777E993635: from=<sender(a)example.com>, size=9826184, nrcpt=1 (queue active) > Sep 18 13:29:18 postfix postfix/qmgr[98]: 757C27E9BD45C: from=<>, size=211997, nrcpt=1 (queue active) > Sep 18 13:29:18 postfix postfix/qmgr[98]: 738C87E9B94BE: from=<>, size=212141, nrcpt=1 (queue active) > [SLIP] > Sep 18 13:32:24 postfix postfix/anvil[103]: statistics: max cache size 1 at Sep 18 13:29:02 > Sep 18 13:43:48 postfix postfix/smtpd[992]: connect from gateway[172.19.199.1] > Sep 18 13:43:48 postfix postfix/smtpd[992]: 9E0D37E9D65AF: client=gateway[172.19.199.1] > Sep 18 13:43:48 postfix postfix/cleanup[996]: 9E0D37E9D65AF: message-id=<3e08121bcdf5b0ebeb779a26ab2fe6ef(a)mailing.einnews.com> > Sep 18 13:43:48 postfix opendkim[19]: 9E0D37E9D65AF: DKIM-Signature field added (s=default, d=sendergateway.example.com) > Sep 18 13:43:48 postfix postfix/smtpd[992]: disconnect from gateway[172.19.199.1] > Sep 18 13:43:48 postfix postfix/qmgr[98]: 9E0D37E9D65AF: from=<sender(a)example.com>, size=59393, nrcpt=1 (queue active) > Sep 18 13:43:48 postfix postfix/qmgr[98]: warning: mail for [172.19.199.2]:8024 is using up 7863 of 7863 active queue entries > Sep 18 13:43:48 postfix postfix/qmgr[98]: warning: you may need to reduce lmtp connect and helo timeouts > Sep 18 13:43:48 postfix postfix/qmgr[98]: warning: so that Postfix quickly skips unavailable hosts > Sep 18 13:43:48 postfix postfix/qmgr[98]: warning: you may need to increase the main.cf minimal_backoff_time and maximal_backoff_time > Sep 18 13:43:48 postfix postfix/qmgr[98]: warning: so that Postfix wastes less time on undeliverable mail > Sep 18 13:43:48 postfix postfix/qmgr[98]: warning: you may need to increase the master.cf lmtp process limit > Sep 18 13:43:48 postfix postfix/qmgr[98]: warning: please avoid flushing the whole queue when you have > Sep 18 13:43:48 postfix postfix/qmgr[98]: warning: lots of deferred mail, that is bad for performance > Sep 18 13:43:48 postfix postfix/qmgr[98]: warning: to turn off these warnings specify: qmgr_clog_warn_time = 0 So we see that Postfix is trying to send 9E0D37E9D65AF, but the subsequent log entries are only the "warning: mail for [172.19.199.2]:8024 is using up 7863 of 7863 active queue entries" ones. If this happens again, look in the log before restarting the container for connection refused, lost or timed out types of entries. You verified that Postfix could connect and receive the greeting from Mailman's LMTP runner, but that was after the queue was full. Maybe when it started and the queue filled up, this wasn't the case, but then if Postfix can connect, the queue should eventually drain. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 5 months

[MM3-users] Re: Reason for Shunting (SOLVED)

by Brian Carpenter

On 2/9/21 6:37 PM, Mark Sapiro wrote: > On 2/9/21 2:57 PM, Brian Carpenter wrote: >> On 2/9/21 5:25 PM, Mark Sapiro wrote: >>> On 2/9/21 2:03 PM, Brian Carpenter wrote: >>>> Is there a way to determine why a message keeps ending up in the shunt >>>> queue? >>>> >>> Look in mailman.log for the `SHUNTING` message and the traceback that >>> immediately preceeds it. >> >> Thanks Mark. The reason was: >> >> Feb 09 16:40:11 2021 (2614) Uncaught runner exception: Multiple rows >> were found for one_or_none() >> >> sqlalchemy.orm.exc.MultipleResultsFound: Multiple rows were found for >> one_or_none() >> >> Feb 09 16:40:11 2021 (2614) SHUNTING: >> 1612906811.2642436+cd8e97a66b6d0c2b73c2adde71a4914108c3e673 >> >> I have no idea what that means. > > See > <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/…> > and <https://gitlab.com/mailman/mailman/-/issues/657> > Thanks Mark, that fixed it. In my case the list had duplicate entries for all 4 archivers in the Mailman database. -- Brian Carpenter Harmonylists.com Emwd.com

5 years

[MM3-users] Re: ValueError: The ADMINS setting must be a list of 2-tuples.

by David Partain

Hi Mark, Helpful, as always. Thank you. And do I feel silly. That was pretty darned obvious. In any case, it's fixed. Cheers, David ________________________________ From: Mark Sapiro <mark(a)msapiro.net> Sent: Thursday, March 21, 2024 01:46 To: mailman-users(a)mailman3.org <mailman-users(a)mailman3.org> Subject: [MM3-users] Re: ValueError: The ADMINS setting must be a list of 2-tuples. On 3/20/24 13:23, David Partain via Mailman-users wrote: > raise ValueError("The ADMINS setting must be a list of 2-tuples.") > ValueError: The ADMINS setting must be a list of 2-tuples. > > Our ADMINS setting in /etc/mailman3/settings.py has > > ADMINS = ( > ('Mailman Suite Admin', 'someone(a)our.domain', 'someoneelse(a)our.domain'), > ) > > Can someone point me in a direction to correct this? 2-tuples, not triples. E.g. ADMINS = ( ('Mailman Suite Admin1', 'someone(a)our.domain'), ('Mailman Suite Admin2', 'someoneelse(a)our.domain'), ) -- 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: Migration failure (2.1.29 to 3.3.8 on Debian testing)

by Mark Sapiro

On 6/7/23 11:58, {16/7} wrote: > > I have both the mailman and mailman3-full packages installed on my machine and I'm following the migration guide located here: https://docs.mailman3.org/en/latest/migration.html Which is the source of at least one of your issues. The Debian packages are behind and are missing multiple bug fixes and enhancements. > Running the command { mailman import21 mylist(a)mysite.com /var/lib/mailman/lists/mylist/config.pck } completes once I create the list but states that it cannot convert the msg_footer and digest_footer mailing list attributes. (I might also point out that the { mailman create mylist(a)mysite.com } command isn't actually documented on that webpage.) import21 tries to make Mailman 3 compatible versions of your Mailman 2.1 msg_footer and digest_footer. It will put these in Mailman's var/templates/lists/<list-id>/<lc>/ directory as list:member:regular:footer.txt and list:member:digest:footer.txt respectively. You need to examine those files as they probably contain Mailman 2.1 style replacements that haven't been converted. See https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/… for the Mailman 3 replacements which are encoded as dollar strings, e.g. $listname gets replaced with the list's posting address. > I can't seem to find the manage.py script in my $PATH and after searching, I find it as part of the mailman3-web package. As you report in a followup, in the Debian package it's called mailman-web > Next, I changed the file's group back to list and decided to try running the manage.py script as the www-data user. This results in "/usr/lib/python3/dist-packages/django_q/conf.py:139: UserWarning: Retry and timeout are misconfigured." and "System check identified some issues:" followed by a list of "Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'" warnings for a number of Django tables. Recent mailman installed following https://docs.mailman3.org/en/latest/install/virtualenv.html will include ``` DEFAULT_AUTO_FIELD = 'django.db.models.AutoField' ``` in Django's settings which will avoid that warning with Django>=3.2 > > My questions are: > > 1. How do I undo any damage (if any) my efforts may have caused? You probably didn't do any damage as the commands failed before doing anything. > 2. What's the correct way to run manage.py? I see from your follow up that you figured this out. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 8 months

Search results for query "sapiro"