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

[MM3-users] Re: Active archivers and archiving and thread question.

by Mark Sapiro

On 3/31/22 04:39, bob B via Mailman-users wrote: > Thanks, that make sense, Also is there any way to turn that off via command line for a bunch of lists or just in the GUi, I looked at "'mailman shell --details:" but could not find a command to turn it off. > > I had archives off on my lists in mailman 2, and when I import they stayed off, but the archiver is enabled. The HyperKitty and Prototype archivers are enabled by default for new and imported lists. To change that, add ``` [archiver.hyperkitty] enable: no [archiver.prototype] enable: no ``` to mailman.cfg. > I have a script that pulls all the list configs > "curl --user *******:******* http://127.0.0.1:##/3.1/lists/"$i"/config | python3 -m json.tool >> ${OUTPUT_DATA_DIR}/listconfigs.txt > > Then I look to see if any list has changed this setting "archive_policy": "never", so I know if any list admin has enabled archives... > > But is there a setting in the config that shows if the archiver got turned on? I want to know if anyone turns it on after I turn it off You can do the following in `mailman shell` ``` $ mm/bin/mailman shell 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. >>>for mlist in getUtility(IListManager): ... print(mlist.display_name) ... print(f' ArchivePolicy was {mlist.archive_policy}') ... if mlist.archive_policy != ArchivePolicy.never: ... mlist.archive_policy = ArchivePolicy.never ... print(' set to ArchivePolicy.never') ... aset = IListArchiverSet(mlist) ... for ar in aset.archivers: ... if ar.is_enabled: ... ar.is_enabled = False ... print(f' Archiver {ar.name} was enabled; set disabled') ... >>> commit() ``` -- 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: Error while mass operation, no progress display while mass operation is running

by Mark Sapiro

On 2/6/25 04:53, Markus Grandpré wrote: > > At the University of Konstanz we have mailing list administrators who > frequently add and remove up to 10000 (and sometimes more) list members. > I have therefore tested the “Mass subscription” and “Mass removal” > operations and found that both the “Remove ALL members” operation and > the “Mass subscription” operation report an internal server error on the > website, but continue to run in the background until all new members > have been successfully added or deleted. The internal server error is probably due to the wsgi server timing out waiting for a response. See https://docs.gunicorn.org/en/stable/settings.html#timeout for Gunicorn or https://uwsgi-docs.readthedocs.io/en/latest/Options.html#harakiri for uWSGI > Unfortunately, I have not found > any error message in the log files. If you are using uWSGI, a harakiri timeout should be logged in uWSGI's log. > I also tested that mass operations > “Remove listed users” and “Remove Selected” ran successfully and without > any errors. You may want to increase the appropriate timeout and see if that helps. > Regardless of whether a mass operation process runs without errors or > continues to run despite an error, I find it hard that Postorius does > not display the progress of such a mass operation in order to monitor > the process, as mass operations with more than 1000 members are very > time-consuming. Perhaps this could be changed in a future version of > Postorius? This is a reasonable request. The best place for such a request is https://gitlab.com/mailman/postorius/-/issues/new Requests and suggestions on the mailing list, no matter how reasonable, get lost over time. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 months, 1 week

[MM3-users] Re: Strange issue with bounce processing

by Mark Sapiro

On 12/25/20 6:36 PM, Brian Carpenter wrote: > Dear List, > > First of all Merry Christmas to those of you that are observing it. > > I have an issue on one of my Mailman 3 servers. The bounce runner is not > running, even after restarting mailman core. All the other runners are > working fine. Here is the problem, after restarting it, a number of > messages show up in queue/bounces from a single list. What happens if instead of restating core, you stop and then start it? > However the bounce > runner is still not running. So I remove these messages from > queue/bounces folder and restart mailman core. The same messages show up > from the same single list again in queue/bounces. In the > var/logs/bounce.log file, addresses from this list are being logged as > being removed after starting mailman core. They correlate with the > messages showing up in queue/bounces. Bounce runner doesn't actually do much with received/queued bounces. It just gets the bounce and stores a bounce event in in the bounceevent table in the database. It then periodically processes the unprocessed events in the bounceevent table. See <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/model/docs…>. > I assume these "cached" bounces are what is interfering with the running > of the bounce runner. I don't see anything in the mailman or > mailmansuite log that would explain this behavior. How can I fix this? I don't really understand what's going on. The only messages which get queued in queue/bounces/ are messages to the LIST-bounces address delivered from the MTA, unless possibly they are somehow in queue/retry/ and being retried. What do you see in the MTA logs? -- 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

[MM3-users] Re: new list not working

by Mark Sapiro

On 3/10/23 05:07, Christian via Mailman-users wrote: > There are no such messages as you describe. > > After turning on debugging I got this from a test message sent to the new > list: > > Mar 10 04:39:51 2023 (1005) Available AUTH mechanisms: LOGIN(builtin) > PLAIN(builtin) > Mar 10 04:39:51 2023 (1005) Peer: ('127.0.0.1', 51982) > Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) handling connection > Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) >> b'LHLO > zarathustra.ccalternatives.org' > Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) >> b'MAIL > FROM:<christian(a)naturalintelligence.us> SIZE=3499' > Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) sender: > christian(a)naturalintelligence.us > Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) >> b'RCPT > TO:<redlatinleg(a)lists.ccalternatives.org>' > Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) recip: > redlatinleg(a)lists.ccalternatives.org > Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) >> b'DATA' > Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) >> b'QUIT' > Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) connection lost > Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) Connection lost during > _handle_client() Again, that's only the post being delivered to Mailman. What comes after that in the log? And have you checked if Mailman's out runner is running? Note that if it died for some reason and wasn't restarted or used up its restarts, restarting Mailman core won't start it. You need to stop Mailman core and then start it. Are there files in mailman's var/queue/out/ or var/queue/shunt/ directories? You say that only the new list and one other have this issue, but I wonder if the issue is not with specific lists, but rather with posts after a certain time. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 6 months

[Test]What does HyperKitty do with HTML and images

by Mark Sapiro

8 years, 2 months

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

by Mark Sapiro

I've created https://gitlab.com/mailman/mailman/-/issues/735 for this and I've also done an experiment and found what I think is a workaround. If you set ``` [webservice] hostname: greyarea-post.cam.ivimey.org ``` or maybe just `greyarea-post` would do, and then add to `/etc/hosts` on `greyarea-post` ``` 0.0.0.0 greyarea-post.cam.ivimey.org ``` or whatever name you used for `hostname` this will get gunicorn to bind to the public interface and will include the proper hostname in the `self_link` responses.

5 years, 2 months

[MM3-users] Re: digest summary heavily cluttered with hrml code

by Mark Sapiro

There was some off list back and forth about this, but this is actually a known issue, <https://gitlab.com/mailman/mailman/-/issues/473>. The avoidance is to subscribe to MIME format digests or to adjust the list's content filtering so filtered messages are plain text only.

4 years, 10 months

[MM3-users] Re: troubleshooting hyperkitty

by Mark Sapiro

Morris Jones wrote: > So this part is all set, it would seem ... > [archive.hyperkitty] > class: mailman_hyperkitty.Archiver > enable: yes > configuration: /opt/mailman/var/etc/mailman-hyperkitty.cfg That should be [archiver.hyperkitty], not [archive.hyperkitty]. Is that the issue or a typo in your email?

4 years, 9 months

[MM3-users] Re: Footer

by Eric Broens

Thanks Mark! Best Regards,Eric On Saturday, February 6, 2021, 10:01:22 PM GMT+1, Mark Sapiro <mark(a)msapiro.net> wrote: On 2/6/21 12:50 PM, Eric Broens via Mailman-users wrote: > > Do I need to install/configure something additionally to get a process listening on port 8000? No, you need to set POSTORIUS_TEMPLATE_BASE_URL to a url that works to get to Postorius. -- 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/

4 years, 7 months

[MM3-users] Re: Postorius upgrade issue

by Mark Sapiro

I neglected to mention `migrate`. All 4 Django management commands, `collectstatic`, `compress`, `compilemessages` and `migrate` should be run after any upgrade.

4 years, 7 months

Search results for query "sapiro"