Search results for "Postorius" - Mailman-users

[Django] ERROR (EXTERNAL IP): Internal Server Error: /accounts/login/

by Mark Dadgar

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? - Mark ----- mark(a)pdc-racing.net | 408-348-2878 ----------------------------------------------- From: noreply(a)pdc-racing.net Subject: [Django] ERROR (EXTERNAL IP): Internal Server Error: /accounts/login/ Date: May 18, 2021 at 2:38:20 PM PDT To: mark(a)pdc-racing.net Internal Server Error: /accounts/login/ MultipleObjectsReturned at /accounts/login/ get() returned more than one EmailAddress -- it returned 2! Request Method: POST Request URL: https://mail.pdc-racing.net/accounts/login/ Django Version: 3.0.12 Python Executable: /opt/mailman/mm/venv/bin/python Python Version: 3.8.5 Python Path: ['/opt/mailman/mm', '/opt/mailman/mm/', '/opt/mailman/mm/bin', '/usr/lib/python38.zip', '/usr/lib/python3.8', '/usr/lib/python3.8/lib-dynload', '/opt/mailman/mm/venv/lib/python3.8/site-packages'] Server time: Tue, 18 May 2021 14:38:20 -0700 Installed Applications: ('hyperkitty', 'postorius', 'django_mailman3', 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.messages', 'django.contrib.staticfiles', 'rest_framework', 'django_gravatar', 'compressor', 'haystack', 'django_extensions', 'django_q', 'allauth', 'allauth.account', 'allauth.socialaccount') Installed 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.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', 'django.middleware.security.SecurityMiddleware', 'django_mailman3.middleware.TimezoneMiddleware', 'postorius.middleware.PostoriusMiddleware') Traceback (most recent call last): File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/core/handlers/exception.py", line 34, in inner response = get_response(request) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/core/handlers/base.py", line 115, in _get_response response = self.process_exception_by_middleware(e, request) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/core/handlers/base.py", line 113, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/views/generic/base.py", line 71, in view return self.dispatch(request, *args, **kwargs) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/utils/decorators.py", line 43, in _wrapper return bound_method(*args, **kwargs) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/views/decorators/debug.py", line 76, in sensitive_post_parameters_wrapper return view(request, *args, **kwargs) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/allauth/account/views.py", line 146, in dispatch return super(LoginView, self).dispatch(request, *args, **kwargs) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/allauth/account/views.py", line 74, in dispatch response = super(RedirectAuthenticatedUserMixin, self).dispatch( File "/opt/mailman/mm/venv/lib/python3.8/site-packages/django/views/generic/base.py", line 97, in dispatch return handler(request, *args, **kwargs) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/allauth/account/views.py", line 102, in post response = self.form_valid(form) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/allauth/account/views.py", line 159, in form_valid return form.login(self.request, redirect_url=success_url) File "/opt/mailman/mm/venv/lib/python3.8/site-packages/allauth/account/forms.py", line 195, in login ret = perform_login( File "/opt/mailman/mm/venv/lib/python3.8/site-packages/allauth/account/utils.py", line 174, in perform_login if not _has_verified_for_login(user, email): 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

3 years, 6 months

Re: Can "Pre Verified" set to yes by default?

by Mark Sapiro

On 12/19/22 00:21, Stephen J. Turnbull wrote: > > I don't know if there's a way to do this in settings.py, but I > suspect not. Maybe Mark knows a way. Well, I haven't tried this and I don't recommend it, but while the intent of settings.py is to assign values to various known attributes, it is a Python module which is imported and could contain any valid Python code including code to read, modify and rewrite .../site-packages/postorius/forms/list_forms.py. However, my recommendation is to maintain your local patches in a script that you can run following an update to apply them. -- 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

Re: Database deadlock when trying to delete a member.

by Abhilash Raj

Hi Simon, > On Mar 17, 2021, at 10:16 PM, Simon Coggins <s.coggins(a)cqu.edu.au> wrote: > > Hi, > > I’ve got a strange error. I migrated from mailman 2.1 to 3 using the migration guide on the website and things have been working fine. But I’m in the process of testing the new syncmembers command to replace some inhouse mailman API code we wrote. I’ve tracked my problem down to what appears to be a deadlock in the postgresql database. When trying to delete certain users the SQL query hangs and never returns. > > After doing some tracing and tracking it down to the database, I enabled DB logging of all queries and saw that the following query was never returning: > > DELETE FROM member WHERE member.id = 166814 > > If I try to run it manually I get the same issue, in psql it never returns. > mailman=# explain analyze DELETE FROM member WHERE member.id = 166814; > [… 60 seconds passes…] > ^CCancel request sent > ERROR: canceling statement due to user request > CONTEXT: while deleting tuple (2998,72) in relation "member" > I’m just wondering if there are any commands or scripts I can run to verify the database and it’s constraints to see if there is some error in the database data? Or where you’d recommend I go from here? It only impacts the user on this specific list. If I add this user to another list and remove them, everything works fine. Are you able to retrieve that Member object using API? This[1] the Python code which would try to delete a Member object and I am assuming is being called from syncmembers command. I am not entire sure about what would cause the database to hang, if there was some database constraint that failed, I would imagine some error to be returned. [1]: https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/model/member.p… One thing you can try is see if you can unsubscribe the user using the API or `mailman shell` command. You can unsubscribe from API by calling a `DELETE` method at http://localhost:9001/3.1/members/<member_id> This would give us some indication about whether there is some bug in the implementation of syncmembers command or if there is something else going on. > > This is on a test system so I can do various testing. I’m trying to find the root cause so that I can verify my production system isn’t impacted by the same thing. > > > Setup Details: > OS: Oracle Linux 7 (Redhat) > Installed using pip via virtualenv talking to a local pgsql database on the same box. > Data was migrated from a mailman 2.1 install into mailman3 using migration instructions on the website. > > PIP Modules versions: > django-mailman3 1.3.5 > mailman 3.3.3 > mailman-hyperkitty 1.1.0 > mailmanclient 3.3.2 > postorius 1.3.4 > psycopg2-binary 2.8.5 What is the version of sqlalchemy package? There is a new 1.4.0 version that came out recently and is incompatible with Core right now. There are backwards incompatible changes which might need some changes in Core to add support. > > RPM packages: > postgresql12-12.6-1PGDG.rhel7.x86_64 > postgresql12-server-12.6-1PGDG.rhel7.x86_64 > postgresql12-libs-12.6-1PGDG.rhel7.x86_64 > postgresql12-devel-12.6-1PGDG.rhel7.x86_64 > > > -Simon > > > _______________________________________________ > 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/ -- thanks, Abhilash Raj (maxking)

3 years, 8 months

Fwd: [Django] ERROR (EXTERNAL IP): Internal Server Error: /archives/search

by Johannes Rohr

Hello everyone! below is a "permission denied" error I get when trying to perform a fulltext search. -------- Weitergeleitete Nachricht -------- Betreff: [Django] ERROR (EXTERNAL IP): Internal Server Error: /archives/search Datum: Mon, 23 Jan 2023 10:30:14 -0000 Von: johannes(a)rohr.org An: johannes(a)rohr.org Internal Server Error: /archives/search PermissionError at /archives/search [Errno 13] Permission denied: 'fulltext_index' Request Method: GET Request URL: http://lists.*****.org/archives/search?mlist=pinnwand%40lists.*****&q=medit… Django Version: 4.1.5 Python Executable: /opt/mailman/venv/bin/uwsgi Python Version: 3.10.6 Python Path: ['.', '', '/etc/mailman3', '/usr/lib/python310.zip', '/usr/lib/python3.10', '/usr/lib/python3.10/lib-dynload', '/opt/mailman/venv/lib/python3.10/site-packages'] Server time: Mon, 23 Jan 2023 11:30:14 +0100 Installed Applications: ['hyperkitty', 'postorius', 'django_mailman3', 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.messages', 'django.contrib.staticfiles', 'rest_framework', 'django_gravatar', 'compressor', 'haystack', 'django_extensions', 'django_q', 'allauth', 'allauth.account', 'allauth.socialaccount'] Installed 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.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', 'django.middleware.security.SecurityMiddleware', 'django_mailman3.middleware.TimezoneMiddleware', 'postorius.middleware.PostoriusMiddleware') Traceback (most recent call last): File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/handlers/exception.py", line 55, in inner response = get_response(request) File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/handlers/base.py", line 197, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/opt/mailman/venv/lib/python3.10/site-packages/hyperkitty/views/search.py", line 88, in search emails = paginate( File "/opt/mailman/venv/lib/python3.10/site-packages/django_mailman3/lib/paginator.py", line 71, in paginate objects = paginator.page(page_num) File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/paginator.py", line 75, in page number = self.validate_number(number) File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/paginator.py", line 53, in validate_number if number > self.num_pages: File "/opt/mailman/venv/lib/python3.10/site-packages/django/utils/functional.py", line 57, in __get__ res = instance.__dict__[self.name] = self.func(instance) File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/paginator.py", line 102, in num_pages if self.count == 0 and not self.allow_empty_first_page: File "/opt/mailman/venv/lib/python3.10/site-packages/django/utils/functional.py", line 57, in __get__ res = instance.__dict__[self.name] = self.func(instance) File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/paginator.py", line 96, in count return c() File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/query.py", line 527, in count return len(self) File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/query.py", line 82, in __len__ self._result_count = self.query.get_count() File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/backends/__init__.py", line 658, in get_count self.run() File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/backends/__init__.py", line 593, in run results = self.backend.search(final_query, **search_kwargs) File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/backends/__init__.py", line 32, in wrapper return func(obj, query_string, *args, **kwargs) File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/backends/whoosh_backend.py", line 412, in search self.setup() File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/backends/whoosh_backend.py", line 133, in setup os.makedirs(self.path) File "/usr/lib/python3.10/os.py", line 225, in makedirs mkdir(name, mode) Exception Type: PermissionError at /archives/search Exception Value: [Errno 13] Permission denied: 'fulltext_index' Raised during: hyperkitty.views.search.search I don't understand what the cause for the "permission denied" could be. The directory "fulltext_index" is owned by mailman:mailman Does anyone have a hint? I did some googling for the error, but to no avail, unfortunately. Thanks! Johannes

1 year, 10 months

Re: spanish localization

by Guillermo Hernandez (Oldno7)

On 13/2/21 9:04, Stephen J. Turnbull wrote: > Victoriano Giralt writes: > > > Thanks Stephen for reminding me that sometimes I write what looks like > > proper English on the surface, but the meaning of it comes from the > > deep corners of my mind in some long forgotten dialect :-) > > Your English is fine, it was just my lack of imagination: on February > 12, I couldn't conceive of February 3 being even a little "old"! But... here is a thing that I can not understand: If the source (the .po file) is from november 7th, it doesn't matter how many times you recompile it: the result will be the same. I did what Mark recommended. Before that: /usr/local/lib/python3.7/site-packages/mailman/messages/es/LC_MESSAGES # ls -la total 192 drwxr-xr-x 2 root wheel 512 Feb 8 12:00 . drwxr-xr-x 3 root wheel 512 Feb 8 12:00 .. -rw-r--r-- 1 root wheel 80700 Feb 3 02:47 mailman.mo -rw-r--r-- 1 root wheel 102963 Nov 7 01:50 mailman.po Then... /usr/local/lib/python3.7/site-packages/mailman/messages/es/LC_MESSAGES # msgfmt -o mailman.mo mailman.po And that is: the same .mo file just with different date /usr/local/lib/python3.7/site-packages/mailman/messages/es/LC_MESSAGES # ls -la total 192 drwxr-xr-x 2 root wheel 512 Feb 13 11:09 . drwxr-xr-x 3 root wheel 512 Feb 13 11:09 .. -rw-r--r-- 1 root wheel 80700 Feb 13 11:09 mailman.mo -rw-r--r-- 1 root wheel 102963 Nov 7 01:50 mailman.po I'm not trying to diminish the effort and the excelent work that are indeed making all of you. I appreciate that so much. But is evident to me that something fails in the translation path chain of upgrades. If you access the postorius web to manage subscriptions you can see a full mixed language words. It's not a life or death item... but it has not to be that way as the terms, as far as I know, are 100% translated (at least in spanish). And the subscriptors complain. If that is not a thing that the release manager can do, well... We are stucked, isn't it? I don think it has to be a matter of "automate production of pip'able packages containing only new translations": a new version has just released and the localization languages, at least spanish, were not merged into it for the last Weblate updates. I will wait untill the next update, this thread is closed to me. Thanks, again, for all your good work. > > More important, as long as the .mo file is more recent than the .po > file, that's the best the release manager can do. I haven't been > involved in the release process, so I can't swear to it personally, > but if Mark says that new translations generate a merge request > automatically, and we make sure that the translations are merged > before release, I believe him. That's optimal as far I am concerned. > > Perhaps some enterprising soul would be willing to automate production > of pip'able packages containing only new translations, but without > that, I don't see how to beat our current procedures. (I wouldn't > want to use such a thing, though, I'd be too afraid that one day all > the translations would be replaced with Dril tweets!) > _______________________________________________ > 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/ >

3 years, 9 months

Re: Confirm on mass subscription

by Mark Sapiro

On 7/5/17 1:48 PM, David Krantz wrote: > > Is there a way of requiring all mass subscribed users to confirm their > email adress? I have an use case where we have a current mail list but > when moving it to mailman I for different reasons would like to > confirm all subscribers. Some very shallow testing suggests that if I > just add them using mass subscribe, they will not have to confirm at > all. > > I have yet to upgrade to 3.1 but I will do so in due time. In MM 2.1, you just send the users invitations rather than subscribing them. In MM3/Postorius, this does not seem to be an option at present. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 4 months

Re: Turn off social logins?

by Torge Riedel

Am 12.02.19 um 17:11 schrieb Stephen J. Turnbull: > Note: I've changed the order of sentences from Torge's post to fit my > responses. > > Torge Riedel writes: > > > I do agree, same here on my side. Lot's of my users are very > > "sensitive" to social media and don't want see them here. > > This is the first I've heard of this. Obviously it's fairly > widespread; *please* speak up if anyone have similar issues that we > haven't addressed. AFAIK all of the currently active Mailman > developers believe that social auth is a GoodThang[tm], so we're > unlikely to DTRT as you see it without your help. Well most of my users are 60+ so social media is some kind of a thing from hell for them ;-) I don't want to blame it, but to ensure acceptance in my scenario it is required to hide them somehow. > > > I need to migrate from mailman2 to mailman3 and was wondering why > > social accounts are enabled by default > > By default Mailman 3 is social media: you have a profile, you can be > searched in the indicies of the archives, and so on. The large auth > providers provide more secure authentication, and a lot of convenience > for users who have such accounts already. They also take some > administrative burden off the list and site managers when people lose > their passwords and forget what their subscription address is, and > similar scenarios. Clearly, these are not universally-valued > features, but I think that they justify the current defaults. Yes, this was a bit unprecise. For my feeling it is better to enable one after another, but it is ok for me to do it the other way. > > > and are difficult to disable. > > They're easy enough to disable (easy to recognize and just add a hash > character in front), since you have to edit settings_local.py to > install anyway. If you're using a packaged version and the package > configuration utility doesn't handle it, there's nothing we can do > about it. The distro will have to deal with that. > > It should be better documented, I imagine (haven't checked yet). > > > I propose something like an additional setting listing the enabled > > social accounts. > > Do you mean in the Postorius administration interface? If so, do you > want it by-site, by-domain, or by-list? ("You" is everybody who wants > to disable social auth, not just Torge!) > > If you mean in settings_local.py, I suggested something similar > earlier. It's not obvious it would be easy to do (sometimes these > things are order-dependent, though that's bad practice). Having the configuration in the UI would be the best solution. So not everything needs to be done by me. A first approach is the mentioned setting, which can be set to an empty value to overwrite the default. Without the risk to break something else. Just to repeat. > > > And if the admin is setting this to an empty value in the > > settings_local.py everything is disabled > > Because the settings are a Python module, this is the way > settings_local.py works anyway. That's why Mark suggested editing > INSTALLED_APPS. > > Thanks so far for going into the discussion.

5 years, 9 months

Problems after Upgrade

by Jeff

Hello, I tried to upgrade to the latest mailman3 version using the following command: pip install -U mailman postorius django-mailman3 hyperkitty mailman-web mailmanclient There didn’t appear to be any problems with this step and I’ve since run it again a few times and only see that the requirements have been satisfied. When first running the command: mailman-web migrate I received several errors dealing with search_text in the package compressor (at least that’s as best as I remember, I wasn’t taking notes). I fixed these manually by changing it to search_str. Eventually "mailman-web migrate” started working and has subsequently worked. When I run the command: mailman-web compress I get the following error: traceback (most recent call last): File "bin/mailman-web", line 8, in <module> sys.exit(main()) File "/usr/local/mailman3/lib64/python3.8/site-packages/mailman_web/manage.py", line 37, in main execute_from_command_line(sys.argv) File "/usr/local/mailman3/lib64/python3.8/site-packages/django/core/management/__init__.py", line 446, in execute_from_command_line utility.execute() File "/usr/local/mailman3/lib64/python3.8/site-packages/django/core/management/__init__.py", line 440, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/usr/local/mailman3/lib64/python3.8/site-packages/django/core/management/__init__.py", line 279, in fetch_command klass = load_command_class(app_name, subcommand) File "/usr/local/mailman3/lib64/python3.8/site-packages/django/core/management/__init__.py", line 49, in load_command_class return module.Command() File "/usr/local/mailman3/lib64/python3.8/site-packages/django/core/management/base.py", line 274, in __init__ raise TypeError("requires_system_checks must be a list or tuple.") TypeError: requires_system_checks must be a list or tuple. I have not been able to fix this and would appreciate any assistance. When I run the command: bin/mailman-web collectstatic It asks me yes or no continue and when I enter “yes” it displays the following which I assume means it worked: 372 static files copied to '/usr/local/mailman3/web/static', 38 unmodified Starting mailman3 seems to work by the status message shows the following: systemctl status -l mailman3 ... Oct 30 14:51:03 mailhost.steele.com mailman[3521451]: return function(args[0], config.db.store, *args[1:], **kws) Oct 30 14:51:03 mailhost.steele.com mailman[3521451]: File "/usr/local/mailman3/lib64/python3.8/site-packages/mailman/model/bounce.py", line 259, in send_warnings_and_remove Oct 30 14:51:03 mailhost.steele.com mailman[3521451]: self._send_warnings() Oct 30 14:51:03 mailhost.steele.com mailman[3521451]: File "/usr/local/mailman3/lib64/python3.8/site-packages/mailman/database/transaction.py", line 85, in wrapper Oct 30 14:51:03 mailhost.steele.com mailman[3521451]: return function(args[0], config.db.store, *args[1:], **kws) Oct 30 14:51:03 mailhost.steele.com mailman[3521451]: File "/usr/local/mailman3/lib64/python3.8/site-packages/mailman/model/bounce.py", line 310, in _send_warnings Oct 30 14:51:03 mailhost.steele.com mailman[3521451]: member.address, Oct 30 14:51:03 mailhost.steele.com mailman[3521451]: File "/usr/local/mailman3/lib64/python3.8/site-packages/mailman/model/member.py", line 121, in address Oct 30 14:51:03 mailhost.steele.com mailman[3521451]: return (self._user.preferred_address Oct 30 14:51:03 mailhost.steele.com mailman[3521451]: AttributeError: 'NoneType' object has no attribute 'preferred_address' lines 13-35/35 (END) I have been receiving admin requests to approve messages. But, I can’t approve them because of the following issue: Starting mailman-web seems to work as expected with no errors. However, when I try to login to the web interface, I get a HTML page with the following error: init__() got an unexpected keyword argument 'providing_args' Request Method: GET Request URL: http://lists.crestwood-dc.org/accounts/login/?next=/mailman3/lists/crestwoo… Django Version: 4.1.2 Exception Type: TypeError Exception Value: __init__() got an unexpected keyword argument 'providing_args' Exception Location: /usr/local/mailman3/lib64/python3.8/site-packages/compressor/signals.py, line 4, in <module> Raised during: allauth.account.views.LoginView Python Executable: /usr/local/mailman3/bin/uwsgi Python Version: 3.8.13 As a result, I cannot login and approve posts. I would greatly appreciate any assistance with these issue. Thanks much!

2 years

Re: Exception with processing subscription confirmation email

by Mark Sapiro

On 4/29/21 7:56 AM, Eric Broens wrote: > Hi, > > A new user tried to subscribe to a mailinglist, received the confirmation > mail, and replied to it. > > The subscriber is however not subscribed and remains listed in the "pending > confirmation" list. > > The following exception appears in the error.log. > > Does anyone knows how to resolve this? In the past we didn't experience any > issues and no changes but security updates have been installed. > > Apr 29 16:15:55 2021 (1581) deque: do_confirm_verify > > Traceback (most recent call last): > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/workflow.py", > line 69, in __next__ > > return step() > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/subscriptions.p > y", line 356, in _step_send_confirmation > > raise StopIteration > > StopIteration Tracebacks like the above are normal and probably shouldn't be logged at all. > Apr 29 16:16:28 2021 (1490) Uncaught runner exception: Expecting ':' > delimiter: line 1 column 256 (char 255) > > Apr 29 16:16:28 2021 (1490) Traceback (most recent call last): > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py", > line 173, in _one_iteration > > self._process_one_file(msg, msgdata) > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py", > line 266, in _process_one_file > > keepqueued = self._dispose(mlist, msg, msgdata) > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/runners/command.py" > , line 208, in _dispose > > mlist, msg, msgdata, parts, results) > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/commands/eml_confir > m.py", line 54, in process > > mlist).confirm(token) > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/subscriptions.p > y", line 578, in confirm > > workflow.restore() > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/workflow.py", > line 146, in restore > > data = json.loads(state.data) > > File "/usr/lib64/python3.6/json/__init__.py", line 354, in loads > > return _default_decoder.decode(s) > > File "/usr/lib64/python3.6/json/decoder.py", line 339, in decode > > obj, end = self.raw_decode(s, idx=_w(s, 0).end()) > > File "/usr/lib64/python3.6/json/decoder.py", line 355, in raw_decode > > obj, end = self.scan_once(s, idx) > > json.decoder.JSONDecodeError: Expecting ':' delimiter: line 1 column 256 > (char 255) > > Apr 29 16:16:28 2021 (1490) SHUNTING: > 1619705788.5856323+57a1a759275c59b732cfa8e2985f76cfcc27dda5 This one is the issue. There was some problem with the user's confirmation reply. View the shunted message with the command ``` mailman qfile path/to/var/queue/shunt/1619705788.5856323+57a1a759275c59b732cfa8e2985f76cfcc27dda5.pck ``` although that probably won't show anything wrong as it appears that the issue is with the saved workflow. You can get the token from the shunted message and then look at the database with something like ``` SELECT data FROM workflowstate WHERE token = '<the token>' ``` but I suspect the issue is because the database is MySQL or MariaDB, your Mailman core is older than 3.3.3 and your database server mode is such that data too long for column results in truncation, and the data in this case is truncated to 255 bytes. In Mailman 3.3.3, this column was changed from VARCHAR(255) to VARCHAR(510) for MySQL. As far as subscribing the user is concerned, you can in Postorius view the subscriptions waiting user confirmation and delete this one and then `mass subscribe` the user. -- 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

Re: MM3 Docker

by Abhilash Raj

On Tue, Jan 8, 2019, at 5:52 AM, Odhiambo Washington wrote: > On Tue, 8 Jan 2019 at 03:29, Mark Sapiro <mark(a)msapiro.net> wrote: > > > On 1/7/19 1:18 AM, Odhiambo Washington wrote: > > > On Sun, 6 Jan 2019 at 23:39, Mark Sapiro <mark(a)msapiro.net> wrote: > > >> > > >> Please help me understand what steps are missing and I will try to > > >> provide the information. > > > > > > > > > Okay. > > > > > > At the installation stage, you say the following: > > > "I already had some things set up in /opt/mailman including a git > > > subdirectory containing clones of the GitLab mailman, mailmanclient, > > > mailman-hyperkitty, hyperkitty, django-mailman3 and > > > postorius projects. On the third server I have added mailman-suite > > > because I use the settings.py from that project as the basis for mine." > > > > > > Please assume that the reader is a newbie to python3 virtualenv and give > > the > > > details of the commands they need to execute to (a) clone all the > > projects > > > needed > > > and (b) create the virtualenv. > > > > > > The next steps are: > > > mkdir /opt/mailman/mm > > > > > > Then you say "I then created a /opt/mailman/mm directory and within that > > a > > > Python 3.6 virtualenv" > > > What happens here is something that needs clarification, because you are > > > specific about "python3.6". > > > I have googled and realized that one has to be specific about the python > > > version they want to use in their virtualenv > > > as shown here -> > > > > > https://stackoverflow.com/questions/45293436/how-to-specify-python-version-… > > > > > > exact command to execute to create the /opt/mailman/mm/venv > > > exact command to execute to activate virtualenv > > > > > > I have added a comment to the page which I hope gives you what you want. > > > > I also added a section on templates instead of referring to a prior > > version of the page. > > > > That makes it better. > However, as a newbie, something is not yet clear: > > "When active in a particular shell, it can be deactivated with the command > > deactivate > or by exiting that shell." > > HI am trying to understand the effect of detaching from a venv. I am > assuming that a virtualenv is a container that is supposed to be always > active for the services within to be accessible. Is that right? So, how do > I ensure it's always running/up, or that does not matter as the scripts > which run the services will always refer to the files? virtualenv is not actually a container that is supposed to be active. It is merely a set of settings that are applied to your SHELL when you are in the virtual environment. It is not supposed to be always active, only when you actually want to run commands in that virtual environment. The services will keep on running after you deactivate your shell and would function like other normal services on your machine. -- thanks, Abhilash Raj (maxking)

5 years, 10 months

Mailman-users search results for query "Postorius"