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

[MM3-users]New Mailman 3 users list

by Mark Sapiro

I'm happy to announce a new list for Mailman 3 users and others interested in Mailman 3. This list is running on a new Mailman 3 installation at lists.mailman3.org. The list's posting address is <mailman-users(a)mailman3.org>. The list's info page is <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/> and its archives are at <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/>. The top level Postorius page is <https://lists.mailman3.org/mailman3/> and the HyperKitty archiver is at <https://lists.mailman3.org/archives/>. You can subscribe by email by sending a blank message to <mailman-users-join(a)mailman3.org> and responding to the resulting confirmation request. You can also subscribe by going to the info page at <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/>, logging in and subscribing. Log in offers three options. There are Google and Facebook OAuth2 login links on the log in page to log in with a Google or Facebook account, and there is a 'Login by email' link to login via Persona with any address you register and confirm with Persona. This is a new installation of Mailman 3 so there are still kinks to work out, and any issues can be discussed on the list or reported to the trackers at <https://gitlab.com/mailman/postorius/issues>, <https://gitlab.com/mailman/hyperkitty/issues> or <https://gitlab.com/mailman/mailman/issues> as appropriate. Enjoy! -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

10 years, 2 months

[MM3-users] Re: [EXTERNAL] Re: Database deadlock when trying to delete a member.

by Mark Sapiro

On 3/22/21 9:53 PM, Simon Coggins wrote: > Ok after bit tracking I’ve worked out that the bouncer is dangling transactions when it’s sending warning messages. When https://gitlab.com/mailman/mailman/-/blob/3.3.4/src/mailman/model/bounce.py… is called and it get to update last_warn_sent it does the following in the DB: > > 2021-03-23 14:42:50.622 AEST [11693] LOG: statement: UPDATE member SET last_warning_sent='2021-03-23T04:42:50.622015'::timestamp, total_warnings_sent=1 WHERE member.id = 169331 > > But it never COMMITs this transaction. So all write operations are now hung waiting for the transction to be closed as the member record has been modified. As a test I added config.db.commit() after https://gitlab.com/mailman/mailman/-/blob/3.3.4/src/mailman/model/bounce.py… and restarted. And my mailman syncmembers worked perfectly and I didn’t have any hangs it correctly removed everyone it should have. In the database logs I can see the COMMIT. > > I’m pretty sure this is not the right spot for a config.db.commit() but hopefully this helps point to what might be going wrong. Thank you for all the research on this. It is extremely helpful. Instead of adding a commit after line 277 please try adding the @transactional decorator to the send_warnings_and_remove method at line 210 @transactional @dbconnection def send_warnings_and_remove(self, store): I think that is the proper fix. Let us know if that works. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 3 months

[MM3-users] Re: Messages hold for moderation - compared to mailman2 it appears that there are fewer options: missing option(?)

by Mark Sapiro

On 3/8/24 11:29 AM, Wikinaut wrote: > Is there a possibility to > > > - to discard the present mail ; and > - accept this sender (non-member) for further mails ? > > The reason: > - Member has sent from their office mail (= not yet known address) - mail 1 on hold and > - sent successfully mail 2 (copy of mail 1) from the known address > > So I want to discard the mail #1 (because the copy mail #2 was sent already) but I want to add his office address as member or to the whitelist. > > Can this be done in one step? It would be nice, at least. This was answered in the message to which you replied, found at <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…>. To reiterate, go to the held messages view. Click the subject of the message, pull down the `--- Set member moderation ---` dropdown and select `Default processing` or if you really want to bypass additional checks, `Accept immediately (bypass other rules)`, and click the `Discard` button. It doesn't matter that the address wasn't known beforehand. The post itself created a non-member record for the sender, and the above will set that non-member's moderation action. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 3 months

[MM3-users] Re: Hyperkitty tracebacks: possible DB corruption?

by Mark Sapiro

On 3/12/24 11:12 PM, peter--- via Mailman-users wrote: > FOr the other issue, I changed > https://gitlab.com/mailman/hyperkitty/-/blob/master/hyperkitty/views/thread… > > From: ``` > if request.user.is_authenticated: > last_view_obj, created = LastView.objects.get_or_create( > thread=thread, user=request.user) > if not created: > last_view = last_view_obj.view_date > last_view_obj.save() # update timestamp ``` > to: ``` > if request.user.is_authenticated: > try: > last_view_obj, created = LastView.objects.get_or_create( > thread=thread, user=request.user) > except LastView.MultipleObjectsReturned: > last_view_duplicate, last_view_obj = LastView.objects.filter( > thread=thread, user=request.user).order_by("view_date").all() > last_view_duplicate.delete() > created = False > > if not created: > last_view = last_view_obj.view_date > last_view_obj.save() # update timestamp ``` > > and that seems to have fixed it. Wrapping the last_view_obj, created = LastView.objects.get_or_create() in a try, except seems appropriate, but your code in the except clause assumes there will be exactly 2 objects returned. Something like ``` except LastView.MultipleObjectsReturned: last_view_objects = LastView.objects.filter( thread=thread, user=request.user).order_by("view_date").all() last_view_obj = last_view_objects[-1] for object in last_view_objects[:-1]: object.delete() ``` might be better. > I've been thinking though that it'd be better to fix duplicates in the > LastView class rather than on every get() or get_or_create() call. That might be good, but these exceptions are rare. I'm not sure how they even occur, so catching them on the get() or get_or_create() calls seems OK. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 3 months

[MM3-users] Re: Things I miss about mailman2

by Mark Sapiro

On 3/17/20 1:59 PM, Quanah Gibson-Mount wrote: > >> Click on the subject in the held messages list. At the bottom of the >> dialog that opens, there is a drop down to set the user's moderation. >> Normally, you would set it to 'default processing'. > > I do not see any such option. After clicking on the header the only > options available at the bottom are: > > Accept, Reject, Discard, Show Source, Show Header > > There are zero drop downs anywhere. This was implemented by <https://gitlab.com/mailman/postorius/-/merge_requests/397> and released in Postorius 1.3.0. >> This was not "removed". It just hasn't been implemented in MM 3 yet. > > So in terms of available functionality that was present in MM2, it was > removed. It may need to be re-implemented, but this was a core feature > that was present in the prior version that is no longer available. Yes, we are aware of many things that are not yet exposed/implemented in Postorius and elsewhere. There are currently 580 open issues at <https://gitlab.com/groups/mailman/-/issues>. We are working on these things as we can. We would love to have your help in fixing these. In the mean time, there are really only 2 or 3 core developers working on this and we are all volunteers, so it takes time. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 3 months

[MM3-users] Re: [Django] ERROR (EXTERNAL IP): Internal Server Error: /accounts/login/

by Mark Sapiro

On 5/18/21 4:06 PM, Mark Dadgar wrote: > I have a user attempting to access the list archives and he’s generating this login error. I have verified that he does have a django account. I’ve never seen this one before and I didn’t find anything relevant in the lit archives. > > Any ideas what’s going on here? ... > File "/opt/mailman/mm/venv/lib/python3.8/site-packages/allauth/account/utils.py", line 134, in _has_verified_for_login > emailaddress = EmailAddress.objects.get_for_user(user, email) > File "/opt/mailman/mm/venv/lib/python3.8/site-packages/allauth/account/managers.py", line 54, in get_for_user > ret = self.get(user=user, email__iexact=email) > File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/db/models/manager.py", line 82, in manager_method > return getattr(self.get_queryset(), name)(*args, **kwargs) > File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/db/models/query.py", line 419, in get > raise self.model.MultipleObjectsReturned( > > Exception Type: MultipleObjectsReturned at /accounts/login/ > Exception Value: get() returned more than one EmailAddress -- it returned 2! > Request information: > USER: AnonymousUser Go to the Django admin users page - something like http(s)://example.com/admin/auth/user/ - and search for the email address. This search is case-insensitive and I'm guessing it will find two users differing in case. In any event, django allauth is trying to find this user and is finding multiple EmailAddress.objects for this address or username. -- 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: Hyperkitty

by Mark Sapiro

On 1/30/23 13:17, Onyeibo wrote: > > The mails don't have that header. I suspect I may have to investigate > SELinux. I think it's unlikely a SELinux issue unless you mean it's an issue writing the log, but if there are any entries at all in mailman.log, that should be OK. what does `mailman conf -s archiver.hyperkitty -k configuration` show? The default is `/etc/mailman3/mailman-hyperkitty.cfg`. Whatever it is, what's in that file. It should be something like ``` [general] base_url: http://127.0.0.1:8000/archives/ api_key: some_key ``` some_key needs to match ``` MAILMAN_ARCHIVER_KEY = 'some_key' ``` in /etc/mailman3/settings.py and the base_url setting needs to access hyperkitty. It could be as above or it could be the URL that accesses HyperKitty externally as in ``` base_url: http:://example.com/archives/ ``` Is all of that correct? To verify base_url, you can do ``` curl http://127.0.0.1:8000/archives/api/ ``` where the initial part of that is the base_url setting. That should return the html for a page of documentation. Look at https://gitlab.com/mailman/mailman-hyperkitty/-/blob/master/mailman_hyperki…. This is Mailman Core's interface to the archiver. If any of the methods there fail to connect to HyperKitty or get an appropriate response, they all log errors. In particular, the archive_message() method at line 171 is saving the message in the spool queue. Immediately before that at lines 164 and 167 it is writing log messages. You should be seeing them. -- 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: troubleshooting hyperkitty

by Mark Sapiro

On 12/9/20 5:01 PM, Morris Jones wrote: > > did that as well ... > > base_url: https://mailman.whiteoaks.com/hyperkitty/ > > (Though the configuration comment on this suggests it should not be > publicly accessible, I don't see any alternative endpoint that's private.) The comments in mailman-hyperkitty/mailman-hyperkitty.cfg say in part # ... It does not need to be publicly available, in fact it's # better if it is not. but they add # However, if your Mailman installation is accessed via HTTPS, the URL needs # to match your SSL certificate (e.g. https://lists.example.com/hyperkitty) > I added both my public IP address and my domain name to > MAILMAN_ARCHIVER_FROM. > > 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 > > [logging.archiver] > path: /opt/mailman/var/logs/archiver.log api_key What is api_key? Is your setting for api_key somehow garbled. Note it needs to be set in the general section of mailman-hyperkitty.cfg and not in mailman.cfg > My archiver log continues empty > > The API keys match in settings_local.py MAILMAN_ARCHIVER_FROM and > mailman-hyperkitty.cfg The key in settings_local.py is MAILMAN_ARCHIVER_KEY, not MAILMAN_ARCHIVER_FROM, a typo in your mail or ?? Anyway, in settings_local.py the key is a python string and must be quoted, but the api_key setting in mailman-hyperkitty.cfg is not quoted. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 6 months

[MM3-users] Re: Wrong info in moderation mail when held due to match of a header rule

by Mark Sapiro

On 10/17/20 10:39 AM, Torge Riedel wrote: > > The message is being held because: > > Header "Yes" matched a header rule > > At your convenience, visit your dashboard to approve or deny the > request. > > I think this is wrong, it should read 'Header "x-spam" matched a header > rule'. Cause the header rule is configured for header "x-spam" and > pattern "Yes". The message is defined as 'Header "{}" matched a header rule' where {} is replaced with the value of the matching header. I agree it would be better if it were something like 'Header value "{}" matched a header rule for {}:' with {}s replaced with the header value and name. That would make it in your case 'Header value "Yes" matched a header rule for x-spam:' > I haven't found a bug report for this yet on gitlab. If someone of the > developers confirm this is wrong, I will file a bug on gitlab for it. Please do file a bug. It won't be fixed until after the upcoming 3.3.2 final release because we not making i18n changes between the candidate and final releases. Also, if you don't like my suggestion, feel free to suggest something else. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 8 months

[MM3-users] Re: Upgrade to 3.3.2 fails

by Mark Sapiro

On 12/26/20 11:28 AM, Joel Lord wrote: > innodb_page_size of 16384 is the default, so that is what I'm working > with as well. The row size limit is half the page size minus some > overhead, so it comes out to 8126 and I bet that is yours as well. > > Yes, I am utf8mb4 at the database and table levels, and I bet you are > right. Just to confirm, between 3.2.1 and 3.2.2 the column archive_rendering_mode was added to the mailinglist table. This column is type - integer (4 bytes), but could be enough to push the row over the limit. As far as utf8mb4 vs. utf8 is concerned. There will be issues with the hyperkitty_email table subject and content columns in particular and maybe others if email messages contain 4-byte utf-8 unicodes. However, as I read the MySQL docs, for columns like VARCHAR(255) and VARCHAR(510), the difference affects only the number of characters that can be stored in the column and not the actual column width. I.e., a VARCHAR(255) column is actually up to 256 bytes wide (1 byte for length and up to 255 butes of data) and can thus hold up to 85 3-byte utf-8 encodings or up to 63 4-byte utf-8 encodings, but since any string normally contains only a few if any (probably none in the case of the mailinglist table) the actual limit is much closer to 85. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 5 months

Search results for query "sapiro"