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

[MM3-users] Re: Help with fresh debian install

by Mark Sapiro

On 10/5/19 11:30 AM, Mark Dadgar wrote: > > Running the commands as the correct user solved my issues. Specially, I ran the import21 command as the “list” user (created by the debian/ubuntu package) and the hyperkitty import command as the “www-data” user. I had to add login shells to the passwd entries for those users to make it happen as they get installed with nologin. You could just run, e.g., `sudo -u list bin/mailman import21 ...` which will work even if 'list' can't log in. > I imported a 24G archive inbox and something went wrong along the way - the archives for many months consist of just a single identical thread. Re-running the import results in the following in just a few seconds: ... > Any thoughts on how I can re-run the full import to make sure that all the archives are present? As far as reimporting the entire archive, you need the --since option. As it says in hyperkitty_import --help > --since SINCE only import emails later than this date. Defaults to > the date of the newest message in the existing archive > if any. If you run hyperkitty_import --since=1990-01-01, that should do it. As far as "the archives for many months consist of just a single identical thread", were there error messages when you ran the initial import? Were there issues in the imported mbox that you have corrected? Mailman 2.1's bin/cleanarch can help identify unescaped 'From ' lines that cause problems. If unescaped 'From ' lines is the issue and you have fixed them, rerunning the import should import the messages correctly, but it won't delete the bogus threads. You can delete these threads manually in HyperKitty if you are logged in as a Django superuser. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 4 months

[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, 10 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

1 year

[MM3-users] Re: Cannot Run Web Frontend

by Mark Sapiro

On 12/24/25 08:14, dap1--- via Mailman-users wrote: > How do I tell if mailman-web is running? There is no such service. In this case, the mailman-web service is gunicorn. > /etc/mailman3/gunicorn.py (recall I had to use py rather than conf to get it to work under Ubuntu): It should have worked as gunicorn.conf despite the warning (not error) that it didn't have a .py extension. > # /etc/mailman3/gunicorn.conf > # # > bind = ['127.0.0.1:8000'] > proc_name = "mailman-web" > # # If you are having response issues you can tune the number of workers. > # # The suggested starting point is (2 x $num_cores) + 1 > # # See https://docs.gunicorn.org/en/latest/design.html#how-many-workers > workers = 3 > chdir = "/opt/mailman/mm" > pidfile = "/opt/mailman/mm/var/gunicorn.pid" > accesslog = "/opt/mailman/mm/var/logs/access.log" > errorlog = "/opt/mailman/mm/var/logs/error.log" > loglevel = 'debug' > > I did notice one thing in the access.log that is wrong: > > 127.0.0.1 - - [24/Nov/2025:16:02:55 +0000] "GET /archives/api/mailman/urls?mlist=lllllllllll%40dddddd.net&msgid=705caa > ab-afcc-4249-8d1d-cc48050d02d1%40bellsouth.net HTTP/1.1" 200 113 "-" "python-requests/2.32.5" This request came from HyperKitty. > The mlist name is wrong. It should be lllllllllll%40gmail.com. I don't know where that is coming from but I'm sure it is left over from before I changed the list name. To you have a hyperkitty list named lllllllllll%40dddddd.net. What does SELECT name FROM hyperkitty_mailinglist; show? > When I include the port in the URL I get an unable to connect page. So nothing is listening on 127.0.0.1:8000 (localhost:8000 assuming the `localhost` is 127.0.0.1 in /etc/hosts and not an IPv6 fe00::0 address) What if any does `netstat -lntp` show is listening on 127.0.0.1:8000? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 months

[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

5 years, 1 month

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

[Test] Re: mailman-users@mailman3.org

by Mark Sapiro

On 04/05/2016 09:09 AM, Simon Hanna wrote: > There are a couple of issues that would be nice to fix first. Most of them have merge requests > pending with fixes that I think are ready for merging. I agree it would be 'nice' to have everything fixed first, but we've been promising this list since last year and it's time to eat our own dog food. > Postorius: > > https://gitlab.com/mailman/postorius/issues/70 > All non ascii input shows up garbled upon saving in postorius. > The fix is in mailmanclient and I have a mr pending: > https://gitlab.com/mailman/mailmanclient/merge_requests/10 > > > https://gitlab.com/mailman/postorius/issues/93 > Isn't really a bug, but it looks weird and has a merge request pending > > > This one doesn't affect users (admins only) but already has a merge request: > https://gitlab.com/mailman/postorius/issues/117 I have the patch from this MR installed. > https://gitlab.com/mailman/postorius/issues/20 > Not important if all lists will have public archives, otherwise this should be fixed first It will have public archives. > And Hyperkitty: > > https://gitlab.com/mailman/hyperkitty/issues/23 > This will affect users, the bug has a merge request pending I've patched this one too. > https://gitlab.com/mailman/hyperkitty/issues/76 > Just found it, shouldn't be caused by normal navigation though so it's not that important > > https://gitlab.com/mailman/hyperkitty/issues/29 > It's a nasty bug but we can live without fixing it for now Yes, and I've looked into it some per my comments on the issue, but we'll live with it. > https://gitlab.com/mailman/hyperkitty/issues/65 > It's not important if all lists that are created are sent an email immediately There is an archive. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

9 years, 10 months

[MM3-users] Re: What is result of planned MM3 integrated installation at Pycon?

by Mark Sapiro

On 6/9/18 5:11 PM, Tom Browder wrote: > > Thanks, Mark. Will the release be pretty much a one-step affair for us > older folks without much energy? Probably not, but it depends at least in part on what you are currently running. There is a major change in that everything is now Python 3. This means that you now must run Django under Python 3 which probably entails changes to how the web server runs wsgi apps to support Python 3. Also, You can run Django versions 1.11.x, or 2.0.x, but Django 2.0.x requires you make changes to the Django config as in this diff. > --- a/mailman-suite_project/settings.py > +++ b/mailman-suite_project/settings.py > @@ -94,13 +94,12 @@ INSTALLED_APPS = ( > ) > > > -MIDDLEWARE_CLASSES = ( > +MIDDLEWARE = ( > 'django.contrib.sessions.middleware.SessionMiddleware', > 'django.middleware.common.CommonMiddleware', > 'django.middleware.csrf.CsrfViewMiddleware', > 'django.middleware.locale.LocaleMiddleware', > 'django.contrib.auth.middleware.AuthenticationMiddleware', > - 'django.contrib.auth.middleware.SessionAuthenticationMiddleware', > 'django.contrib.messages.middleware.MessageMiddleware', > 'django.middleware.clickjacking.XFrameOptionsMiddleware', > 'django.middleware.security.SecurityMiddleware', > --- a/mailman-suite_project/urls.py> +++ b/mailman-suite_project/urls.py > @@ -19,7 +19,7 @@ > > from django.conf.urls import include, url > from django.contrib import admin > -from django.core.urlresolvers import reverse_lazy > +from django.urls import reverse_lazy > from django.views.generic import RedirectView > > urlpatterns = [ > @@ -31,5 +31,5 @@ urlpatterns = [ > url(r'', include('django_mailman3.urls')), > url(r'^accounts/', include('allauth.urls')), > # Django admin > - url(r'^admin/', include(admin.site.urls)), > + url(r'^admin/', admin.site.urls), > ] I.e., the name MIDDLEWARE_CLASSES is changed to MIDDLEWARE and the obsolete django.contrib.auth.middleware.SessionAuthenticationMiddleware has to be removed; the reverse_lazy import is changed and include(admin.site.urls) becomes just admin.site.urls -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 8 months

[MM3-users] Re: non-members issue with held email

by Mark Sapiro

On 7/20/21 2:09 AM, Lars Schimmer wrote: > > We created a new mailinglist, added 3 owner and several members. > Now we want some email addresses to post to that list but not receive > mails from the list. So I added those to the "non-member" area of the > mailinglist and checked every non-member to "acceppt at once". > > But on a test, a email address, which is owner AND non-member, cannot > send to mailinglist, always get a "HOLD: ...... The message is not from > a list member" See https://gitlab.com/mailman/mailman/-/issues/659 If you read through the comment thread, you'll see that the issue is when setting moderation action for an address which is both an owner and a nonmember, it is the owner's action that actually gets set, so that the nonmember's action remains set to list default. You need to set the moderation action for the nonmember via `mailman shell`. If all the non-members are the ones you added, you can do ``` $ mailman shell -l your.list.id 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 ... mailing list >>> for nonmember in m.nonmembers.members: ... nonmember.moderation_action = Action.accept ... >>> commit() ``` If there are other nonmembers whose action you don't want to set to accept, you need to do something like ``` >>> emails = ['first(a)example.com', 'second(a)example.com', <more emails>, ] >>> for nonmember in m.nonmembers.members: ... if nonmember.address.email in emails: ... nonmember.moderation_action = Action.accept ... >>> commit() ``` to only do the ones you want. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 7 months

[Test]What does HyperKitty do with HTML and images

by Mark Sapiro

8 years, 7 months

Search results for query "sapiro"