Search results for "Postorius" - Mailman-users

Re: Hipperkitty failing to archive messages in a list

by Guillermo Hernandez (Oldno7)

On 4/1/22 12:27, Guillermo Hernandez (Oldno7) via Mailman-users wrote: > First of all, best wishes and Happy New Year for everybody. > > Two days ago I had to reinstall all mailman3 related apps in a mailman > 3 server (I tried to upgrade just hipperkitty, but it went bad). At > first, all seemed running as before, but I just noted that the > messages are not being archived. I've found some information that can be related to the problem I had: In https://docs.mailman3.org/projects/hyperkitty/en/latest/news.html yo can see that in the security notes for 1.3.5 "Pass the secret archiver key in a HTTP Authorization header instead of a GET query parameter so it doesn’t appear in logs. (CVE-2021-35058, Closes #387)" As the lack of any clue persists on how to solve the problem, I've just reproduced step by step upgrade process. I've just executed a (being "mailman3" the user configured for all of this) pip install --upgrade --force-reinstall --no-deps --no-cache-dir django-mailman3 mailman mailman-hyperkitty mailmanclient postorius django hyperkitty su -m mailman3 -c "python3 manage.py collectstatic" su -m mailman3 -c "python3 manage.py migrate" In this last point I've received some warnings of this kind: *-*-*-*-*-*-* WARNINGS: account.EmailAddress: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the AccountConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. account.EmailConfirmation: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. ... HINT: Configure the DEFAULT_AUTO_FIELD setting or the SocialAccountConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. Operations to perform: Apply all migrations: account, admin, auth, contenttypes, django_mailman3, django_q, hyperkitty, postorius, sessions, sites, socialaccount Running migrations: No migrations to apply. Your models in app(s): 'postorius' have changes that are not yet reflected in a migration, and so won't be applied. Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them. *-*-*-*-*-*-* Running a 'su -m mailman3 -c "python3 manage.py makemigrations" shows the same warning listed before and some new errors: *-*-*-*-*-*-* Migrations for 'postorius': /usr/local/lib/python3.7/site-packages/postorius/migrations/0017_alter_emailtemplate_name.py - Alter field name on emailtemplate Traceback (most recent call last): File "manage.py", line 10, in <module> execute_from_command_line(sys.argv) File "/usr/local/lib/python3.7/site-packages/django/core/management/__init__.py", line 419, in execute_from_command_line utility.execute() File "/usr/local/lib/python3.7/site-packages/django/core/management/__init__.py", line 413, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/usr/local/lib/python3.7/site-packages/django/core/management/base.py", line 354, in run_from_argv self.execute(*args, **cmd_options) File "/usr/local/lib/python3.7/site-packages/django/core/management/base.py", line 398, in execute output = self.handle(*args, **options) File "/usr/local/lib/python3.7/site-packages/django/core/management/base.py", line 89, in wrapped res = handle_func(*args, **kwargs) File "/usr/local/lib/python3.7/site-packages/django/core/management/commands/makemigrations.py", line 190, in handle self.write_migration_files(changes) File "/usr/local/lib/python3.7/site-packages/django/core/management/commands/makemigrations.py", line 228, in write_migration_files with open(writer.path, "w", encoding='utf-8') as fh: PermissionError: [Errno 13] Permission denied: '/usr/local/lib/python3.7/site-packages/postorius/migrations/0017_alter_emailtemplate_name.py' *-*-*-*-*-*-* The file '/usr/local/lib/python3.7/site-packages/postorius/migrations/0017_alter_emailtemplate_name.py' does not exist at all Despite the error, I did a 'su -m mailman3 -c "python3 manage.py compress"' and the subsequent "django-admin compilemessages" in /usr/local/lib/python3.7/site-packages/postorius, ../hyperkitty and ../django_mailman3 And the log continues showing the same error when trying archive a new message. ERROR 2022-01-05 12:27:31,406 6988 hyperkitty.views.mailman The MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. ERROR 2022-01-05 12:27:31,418 6988 hyperkitty.views.mailman The MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. ERROR 2022-01-05 12:27:31,685 6988 hyperkitty.views.mailman The MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. ERROR 2022-01-05 12:27:32,045 6988 hyperkitty.views.mailman The MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. ERROR 2022-01-05 12:27:32,070 6988 hyperkitty.views.mailman The MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. ERROR 2022-01-05 12:27:32,093 6988 hyperkitty.views.mailman The MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. The odd thing is that you can see the archived messages previous to a few days ago, when I tried to upgrade hyperkitty. Only the new messages are "disappearing" (but they are being distributed). Some guide on what to look for, please? This server manages just a few lists with very low traffic, but I don't want to screw it all when upgrading other servers with normal traffic and much more lists. TIA > I did not change any config. Now the log is showing > > ERROR 2022-01-03 12:22:15,654 7165 hyperkitty.views.mailman The > MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. > ERROR 2022-01-03 12:22:15,674 7165 hyperkitty.views.mailman The > MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. > ERROR 2022-01-03 12:22:15,791 7165 hyperkitty.views.mailman The > MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. > ERROR 2022-01-03 12:22:16,208 7165 hyperkitty.views.mailman The > MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. > ERROR 2022-01-04 11:44:55,644 30518 hyperkitty.views.mailman The > MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header > ERROR 2022-01-04 11:44:55,664 30518 hyperkitty.views.mailman The > MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header > ERROR 2022-01-04 11:44:56,478 30518 hyperkitty.views.mailman The > MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header > ERROR 2022-01-04 11:44:56,620 30518 hyperkitty.views.mailman The > MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header > ERROR 2022-01-04 11:44:56,647 30518 hyperkitty.views.mailman The > MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header > > (it's a very low traffic list: just two messages in two days) > > I do believe I did the upgrade/reinstall procedure as in previous > upgrades (using pip: it's a system wide installation, not using > dockers or venv), but seems that I did something wrong > > The messages are being delivered normally, but it fails archiving > > Before I make a bigger hole for myself, where to look for? > > Versions installed: > > HyperKitty 1.3.5 > > mailman 3.3.5 > mailman-hyperkitty 1.2.0 > mailmanclient 3.3.3 > > postorius 1.3.6 > > uWSGI 2.0.19.1 > > > Mailman Core Version GNU Mailman 3.3.5 (Tom Sawyer) > Mailman Core API Version 3.1 > Mailman Core Python Version 3.7.9 (default, Nov 30 2020, 10:49:53) > [Clang 10.0.1 (git@github.com:llvm/llvm-project.git > llvmorg-10.0.1-0-gef32c611a > > > -- ___________________________________________ Mailman's content filtering has removed the following MIME parts from this message. Content-Type: image/png Name: firma-GHP-emails.png Replaced multipart/alternative part with first alternative.

4 years, 10 months

Re: Apache+mod_wsgi issue

by Mark Sapiro

On 12/24/22 00:00, Odhiambo Washington wrote: > > These are my files: > 1. urls.py > <CUT > > from django.conf.urls import include > from django.urls import re_path > from django.contrib import admin > from django.urls import reverse_lazy > from django.views.generic import RedirectView > > urlpatterns = [ > re_path(r'^$', RedirectView.as_view( > url=reverse_lazy('list_index'), > permanent=True)), > re_path(r'^postorius/', include('postorius.urls')), > re_path(r'^hyperkitty/', include('hyperkitty.urls')), > re_path(r'', include('django_mailman3.urls')), > re_path(r'^accounts/', include('allauth.urls')), > # Django admin > re_path(r'^admin/', admin.site.urls), > re_path(r'^mailman3/', include('postorius.urls')), > re_path(r'^archives/', include('hyperkitty.urls')), > ] > </CUT> You don't need all of those. ^postorius/ and ^mailman3/ are two different ways to access Postorius, and ^hyperkitty/ and ^archives/ are two different ways to access HypereKitty. You only need one of each, but having both is OK. > 2. apache.conf > <CUT> > ... > Alias /static "/opt/mailman/mm/static" > <Directory "/opt/mailman/mm/static"> > Require all granted > </Directory> > # WSGIScriptAlias /mailman3 /opt/mailman/mm/wsgi.py > # WSGIScriptAlias /accounts /opt/mailman/mm/wsgi.py > # WSGIScriptAlias /admin /opt/mailman/mm/wsgi.py > # WSGIScriptAlias /archives /opt/mailman/mm/wsgi.py > # WSGIScriptAlias /user-profile /opt/mailman/mm/wsgi.py > # WSGIScriptAlias /hyperkitty /opt/mailman/mm/wsgi.py > # WSGIScriptAlias /postorius /opt/mailman/mm/wsgi.py > WSGIScriptAlias / /opt/mailman/mm/wsgi.py This will send every http request to mod_wsgi except for requests to /static. This is OK if there are no other web sites on this server and the only http requests are for Django related things. ... > I have tested with creating all those commented out aliases and that ended > up still giving me /mailman3/mailman3/* which I did not > like, although everything appeared to work. > I then ended up with only "WSGIScriptAlias / /opt/mailman/mm/wsgi.py" > and now when I type https://mm3-lists.kictanet.or.ke I end > up at https://mm3-lists.kictanet.or.ke/mailman3/lists/. Of course something > has appended "/mailman3" > So this has resulted in all URLs having /mailman3/ appended, except for the > /archives link. How about https://mm3-lists.kictanet.or.ke/user_profile/ ? > Now my question is about what could be adding the /mailman3. Is it possible > that I installed something out of the ordinary? It's a mod_wsgi thing. I haven't used mod_wsgi for Mailman for some time (I now use gunicorn on all the sites I manage), but when I did I think I had WSGIScriptAlias /mm3 /opt/mailman/mm/wsgi.py and all the URLs were like https://example.com/mm3/mailman3/..., https://example.com/mm3/archives/..., etc. -- 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

Re: Any known limit of number of lists that one can be owner/member of?

by Mark Sapiro

On 5/8/19 3:33 AM, Alan So wrote: > We have just migrated hundreds of lists from Mailman 2 to Mailman 3. It was smooth in most of the cases. However, we just notice that there are some abnormal behaviour of Postorius for particular users who are owner/member of a large number of lists. We further look into a particular user who is owner of 84 lists. When the user login Postorius, only 50 lists are displayed no matter what the number of "Results per page" is chosen. Prev/Next page cannot be clicked as there is only 1 page. See <https://gitlab.com/mailman/postorius/issues/335> > When I use the following mailman client snippet, it also displays the same 50 lists: > > lists = client.find_lists('xxx(a)yyy.com', 'owner') > for m_list in lists: > print(m_list.fqdn_listname) > > Did we hit any limit of find_lists? Is it a bug or are something wrong during the migration? find_lists defaults to count=50. What happens if you do lists = client.find_lists('xxx(a)yyy.com', 'owner', count=100) -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 6 months

Re: Changing subscription address

by Stephen J. Turnbull

Abhilash Raj writes: > Well a couple of stars have to align for it to work unfortunately. I'm not going to wait for the stars; I have backward-incompatible surgery in mind. > Add to that you can’t set an address as primary using just email > commands, you end up with what you are seeing. Right. The idea is that the first time an address is used, a User will be created and that address will be primary for that User. When the person wants to claim that address, they go to Postorius, create a Postorius account, do the address verification dance and set credentials, which links the Postorius account to the User via the Address. This is why the ability to merge Users becomes an urgent need: people who subscribe via email are going to end up with multiple Users. > We don’t necessarily need the flag on user to set an unverified primary > address, we might be able to get away without that. We could set the > address as primary *after* we verify it. We always verify addresses > regardless of the choice of the subscription mode (user or address). I'm not clear what you're saying. In general admins can't read your mail, so they can't verify you on a mass subscribe or an import. > Right now, P is explicit about it. You can choose if you want Primary > Address or one of the explicit addresses added to your account. The > primary address is the pre-selected choice, so if you go and just click > on subscribe button, you get the primary address being subscribed. If > you choose the explicit address then we subscribe the explicit address. > > Is that something you think needs modifying? No. The option to set a subscription to the literal primary address should still be available. I don't see a good reason to complicate the UI logic by comparing primary to literal addresses just to remove that one. I just want the primary address to be populated automatically, and inherit-from-primary be the default subscription address when the subscription address matches primary, *unless* the subscriber explicitly chooses that literal address in Postorius. This is backward-incompatible, but I think it will be overwhelmingly popular with new users and old. > The email join command does the first part you suggested, (if the lookup > succeed and matches primary address, use inherit) but doesn’t do the > second part (it will create a user, add the address to it and then use the > address to subscribe). We can and should fix that. I think that's all we need to do going forward. We do need a better UI for setting options (including address) for a selection of subscriptions, but that's an independent task. Thanks for looking at this, Abhilash! Steve

5 years, 7 months

Re: FILTER_VHOST not working

by Mark Sapiro

On 3/22/21 1:03 PM, Johannes Rohr wrote: > In /etc/mailman3/mailman-web.py I have added > FILTER_VHOST = True > so that only the list for the current domain are shown. > > But this has no effect. The current situation with Postorius >=1.3.3 and Hyperkitty >=1.3.3 is for HyperKitty, FILTER_VHOST = True works. For Postorius, it works only if in the domains view, each mail host has a unique web host. It doesn't work. See this post <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…> and others in that thread for more info. Prior to Postorius 1.3.3 and Hyperkitty 1.3.3 it would only work if the mail host and web host values were identical for the domain. > > What's more, in hyperkitty I see at the top left the lable for the > default domain, even though I am visiting from another domain. That has nothing to do with FILTER_VHOST. The displayed there is the site referenced in the SITE_ID setting. > The web domains are exactly the same as the mail domans > (lists.[domain].[tld]) In that case, I'm not sure what's going on. > In the Nginx config I have added > > location / { > proxy_set_header X-Forwarded-Proto $scheme; > proxy_set_header X-Forwarded-Host $host; > proxy_pass http://localhost:8000/; > [....] > > } > > to make sure that mailman3 knows from which URL it is visited. > > Am I overlooking something? > > I am using the distribution packages on Ubuntu 20.04: > mailman3 3.2.2-1 > mailman3-web 0+20180916-10 > > I see, the mailman3-web package is quite dated. Is it recommended to > install via virtualenv instead? Yes, the issue is at least partially that that mailman3-web package doesn't have any of the FILTER_VHOST fixes. And yes, if you don't want to be stuck with dated packages tha don't include recent fixes, we recommend installation as documented at <https://docs.mailman3.org/en/latest/install/virtualenv.html> -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 7 months

Re: 400 error on held messages

by Dan Caballero

Here is the stack trace from the mailmansuite.log. ERROR 2023-10-04 10:59:03,587 2091 postorius Un-handled exception: HTTP Error 400: invalid literal for int() with base 10: 'oAAAANSUhEUgAACfYAAAiVBORw0KGgoAAAANSUhEUgAACfYAAAYKCAIAAAAQvT9CAAAACXBIWXMAAC4jAAAuIwF4pT92AAAg\r\n' Traceback (most recent call last): File "/opt/mailmanve/lib/python3.9/site-packages/django/core/handlers/base.py", line 197, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/opt/mailmanve/lib/python3.9/site-packages/django/contrib/auth/decorators.py", line 23, in _wrapped_view return view_func(request, *args, **kwargs) File "/opt/mailmanve/lib/python3.9/site-packages/postorius/auth/decorators.py", line 63, in wrapper return fn(*args, **kwargs) File "/opt/mailmanve/lib/python3.9/site-packages/postorius/views/list.py", line 864, in list_moderation held_messages = paginate( File "/opt/mailmanve/lib/python3.9/site-packages/django_mailman3/lib/paginator.py", line 71, in paginate objects = paginator.page(page_num) File "/opt/mailmanve/lib/python3.9/site-packages/django_mailman3/lib/paginator.py", line 47, in page result = self.function(count=self.per_page, page=number) File "/opt/mailmanve/lib/python3.9/site-packages/mailmanclient/restobjects/mailinglist.py", line 164, in get_held_page return Page(self._connection, url, HeldMessage, count, page) File "/opt/mailmanve/lib/python3.9/site-packages/mailmanclient/restbase/page.py", line 37, in __init__ self._create_page() File "/opt/mailmanve/lib/python3.9/site-packages/mailmanclient/restbase/page.py", line 62, in _create_page response, content = self._connection.call(self._build_url()) File "/opt/mailmanve/lib/python3.9/site-packages/mailmanclient/restbase/connection.py", line 160, in call raise HTTPError(params.get('url'), response.status_code, urllib.error.HTTPError: HTTP Error 400: invalid literal for int() with base 10: 'oAAAANSUhEUgAACfYAAAiVBORw0KGgoAAAANSUhEUgAACfYAAAYKCAIAAAAQvT9CAAAACXBIWXMAAC4jAAAuIwF4pT92AAAg\r\n'

3 years, 1 month

Re: Moderate mails from owner

by Malcolm Austen

On Wed, 20 Mar 2019 18:42:10 -0000, Mark Sapiro <mark(a)msapiro.net> wrote: > However, this is apparently not relevant because both the Member and > Non-Member actions are Hold. Thus, the post should be held unless it has > an Approved: header with the list's moderator_password attribute if > there is one, or it matches a Header filter rule with an accept action. At the risk of getting this really wrong - I have only limited MM3 knowledge - I will ask what is, I fancy, a closely related question ... My only experience of MM3 is with Ancestry's 'RootsWeb' installation. From the emails I can see a header "X-Mailman-Version: 3.1.0" but I can't find anything to identify Postorius which is the only interface I have to the system. From symptoms seen and described by others, I have deduced that the Postorius admin-per-user moderation options of "Default processing" and "List default" mean that a user may be set (by default on the rootsweb system!) to use the system default moderation settings rather than the list default settings. Are my deductions correct? And if so, could this be the explanation of the issue detailed in this thread? Apologies if I'm barking up entirely the wrong tree, Malcolm. -- Malcolm Austen <malcolm.austen(a)weald.org.uk>

7 years, 7 months

Re: Postorius no connection to REST API

by Richard Rosner

That is entirely possible @Stephen. You can see the entire apache config a few posts back plus the additions from @Mark and mine from the last post. As I interpret it, apache is reverse proxying to the uwsgi app, now through http instead of the socket. But I have no idea if that's the right way round. I'm not sure is the config file templates for apache, nginx and uwsgi that you get with the Debian packages are added by the Debian team or if they are there any way and just have been modified to the Debian file layout, but I'd guess either way it's not that likely that they wrote it the wrong way around. But I'm not too experienced to be able to translate the nginx config to apache to see if that would result in something different. Also, while the nginx config is written as a standalone website, the apache config seems to have been written to just create a /mailman3 site under an existing website, while I use it as a standalone site. So it's entirely possible that I missed something when I modified the website from mailman2 to serve mailman3, but then it shouldn't have been able to show the website at the beginning.

5 years, 2 months

Re: Mailman 3 deployment: ok to use same database instance for core, web, and hyperkitty tables?

by samuel.d.darwin＠gmail.com

Hi Serban, You may or may not be on the right track, because based on that email message your usage of terminology is not always clear. Consider these three concepts: 1. Database server (a server running PostgreSQL or MySql) 2. A database (one server can host multiple databases) 3. A table (one database contains many tables) When you wrote "And all 3 tables" you probably meant "all 3 apps"? When you wrote "pointing to the same database" you probably meant "pointing to (multiple) databases on the same database server instance"? All the apps (hyperkitty, postorius, core) could share the same database server, as long as they have their own database. Rather, one DB for core, another DB for web. So, two databases. Potentially on the same hardware instance. The new hyperkitty archives are usually stored in the database and not "FS local" (filesystem local). Next, this part "core+web (instance 1) and Hyperkitty (instance 2)." The main division is between Web (postorius, hyperkitty) and Core (mailman3-core). In other words, Hyperkitty is part of the web component. Postorius + Hyperkitty make up the web layer. So you wouldn't usually split up web and hyperkitty separately.

3 years

Re: How to get rid of footer (Mailman3)

by Mark Sapiro

On 2/11/20 11:31 PM, tarmokumar(a)gmail.com wrote: > Hi, I have read multiple posts in this forum that you should be able to get rid of the footer completely but I am unable to. > I have tried: > - adding the footer template to a list and not adding any "Data" to it. Result was a attachment with some "dfgdfgdfgdfg" text in it. Did you add this via Postorius. If so, it would seem to be a Postorius issue. > - adding/creating a blank "list:member:generic:footer" document to /var/templates/site/en, var/templates/lists/LIST.ID/en/ and var/templates/domains/DOMAIN/en/. Result is that the sent e-mail still has the original unsubscribe text in the footer (as an attachment) Did you name the file list:member:generic:footer.txt (with the .txt extension)? Putting a zero-length file of that name in any of those places should work. > - removing all the files from /mailman/src/mailman/templates/en, still no change If you restarted Mailman after doing this, this indicates something (Postorius?) may have set a URI for this template. What do you get from curl -urestadmin:restpass \ http://localhost:8001/3.1/lists/LIST.ID/uris -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 9 months

Mailman-users search results for query "Postorius"