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

[MM3-users] Re: after last upgrade I've got a CSRF failed verification

by Mark Sapiro

On 10/26/22 04:33, Guillermo Hernandez (Oldno7) via Mailman-users wrote: > > I did it via pip and all seems to be working, but when I try to discard > or accept any message via postorius it shows a Forbidden 403 error CSRF > verification failed. > > In my settings.py I have commented out these variables: > > # Other security settings > # SECURE_SSL_REDIRECT = True > # If you set SECURE_SSL_REDIRECT to True, make sure the > SECURE_REDIRECT_EXEMPT > # contains at least this line: > # SECURE_REDIRECT_EXEMPT = [ > # "archives/api/mailman/.*", # Request from Mailman. > # ] > # SESSION_COOKIE_SECURE = True > # SECURE_CONTENT_TYPE_NOSNIFF = True > # SECURE_BROWSER_XSS_FILTER = True > # CSRF_COOKIE_SECURE = True > # CSRF_COOKIE_HTTPONLY = True > # X_FRAME_OPTIONS = 'DENY' > > I've been messing with them whith no results. It's like it lacked some > value in some template... It's not an issue with the code per se or the templates. These updates are all installed on mail.python.org and lists.mailman3.org and are working fine. After upgrading did you run django-admin collectstatic --clear django-admin compress django admin migrate If you have and it doesn't help, you probably need to add CSRF_TRUSTED_ORIGINS to your settings.py. See https://docs.djangoproject.com/en/4.1/ref/settings/#csrf-trusted-origins and note the differences between Django <4.0 and >=4.0. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 6 months

[MM3-users] Re: Aborted connection message in log in every 5 minutes

by Mark Sapiro

On 1/31/24 10:12, andrea.janna.unipd(a)gmail.com wrote: > >>From the database debug log I guess that mailman gatenews abruptly terminates the database connections. > For instance this is the database debug log of a connection that doesn't trigger the mariadbd "[Warning] Aborted connection" log entry. > > 70759 Connect mailman3web@localhost on mailman3web using Socket > 70759 Query SET sql_mode='STRICT_TRANS_TABLES' > ... > 240131 18:54:34 70759 Quit > > There is a "Quit" at the end. > While the log entries of the connections that trigger the aborted connection warning (like the one I posted yesterday) do not have "Quit" at the end. You could try the following in `mailman shell` ``` $ 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).mailing_lists: ... print(mlist.fqdn_listname) ... (here should be a list of your mailing lists) >>> ``` Does this produce the expected list of mailing lists and does it produce the error in the database debug log? If it does produce the expected list of mailing lists and the error in the database debug log, I'd say this is some issue between SQLAlchemy and MariaDB, but it seems harmless. -- 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]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, 1 month

[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, 1 month

[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, 2 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, 1 month

[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, 1 month

[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

4 years, 11 months

[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, 3 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, 4 months

Search results for query "sapiro"