Search results for "Postorius" - Mailman-users

Re: unique key violation because of case sensitivity of email address

by Mark Sapiro

On 6/15/24 11:47, Jörg Schulz wrote: > After updating to the most recent version of mailman-web, the migrations > script issued an error: > > > Apply all migrations: account, admin, auth, contenttypes, > django_mailman3, django_q, hyperkitty, postorius, sessions, sites, > socialaccount > mailman-web | Running migrations: > mailman-web | Traceback (most recent call last): > mailman-web | File > "/usr/lib/python3.12/site-packages/django/db/backends/utils.py", line > 89, in _execute > mailman-web | return self.cursor.execute(sql, params) > mailman-web | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > mailman-web | psycopg2.errors.UniqueViolation: duplicate key value > violates unique constraint > "account_emailaddress_user_id_email_987c8728_uniq" > mailman-web | DETAIL: Key (user_id, email)=(27, > John.Doe(a)mynicedomain.de) already exists. > mailman-web |(...) Presumably you upgraded django-allauth to a version >=0.62. Beginnin then, email addresses were no longer stored case-sensitively and the migration was dealing with that. There were other issues when addresses were store case sensitively. See https://github.com/pennersr/django-allauth/issues/3019 > Digging into the db, I found the duplicate to result from a duplicate > entry using john.doe(a)mynicedomain.de > > > Obviously, the process that originally created the entry, took case > sensitivity literally which doesn't seem to be the case any longer for > the migration script. > > I fixed this by removing one of the duplicates hoping no further errors > will come up.... > > > What would have been the better approach? Removing one of the duplicates is the solution, and beginning with django-allauth>=0.62, duplicates should no longer occur. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

11 months, 3 weeks

Re: using SSH/TLS with external MTA

by Roland Giesler

On 2024/07/28 15:42, Roland Giesler via Mailman-users wrote: > > On 2024/07/28 15:26, Roland Giesler via Mailman-users wrote: >> On 2024/07/28 00:39, Mark Sapiro wrote: >>> On 7/27/24 15:16, Roland Giesler via Mailman-users wrote: >>>> >>>> The server runs power-mailinabox, which uses Postfix indeed. All my >>>> mail, and quite a few others' mail is sent from the using SMTP-Auth >>>> on port 465. Actually, this message is sent via that server too. >>>> So it's clear to me that MM3 is not authenticating for some reason. >>> >>> What do you see in Mailman's smtp.log and in the mail.log on the >>> mail server? >> >> The smtp log is in syslog... > > I also see this in /var/log/mailman3/web/mailman-web.log The /etc/mailman3/mailman3-web.py file contains inter alia these lines: # Set default domain for email addresses. EMAILNAME = 'fast.za.net' # If you enable internal authentication, this is the address that the emails # will appear to be coming from. Make sure you set a valid domain name, # otherwise the emails may get rejected. # https://docs.djangoproject.com/en/1.8/ref/settings/#default-from-email # DEFAULT_FROM_EMAIL = "mailing-lists(a)you-domain.org" DEFAULT_FROM_EMAIL = 'postorius@{}'.format(EMAILNAME) # If you enable email reporting for error messages, this is where those emails # will appear to be coming from. Make sure you set a valid domain name, # otherwise the emails may get rejected. # https://docs.djangoproject.com/en/1.8/ref/settings/#std:setting-SERVER_EMAIL # SERVER_EMAIL = 'root(a)your-domain.org' SERVER_EMAIL = 'root@{}'.format(EMAILNAME) fast.za.net was giesler.za.net before, so I changed it.

10 months, 1 week

Re: Trying to configure a list (hosted)

by paul＠arenson.org

Thank you for the very quick response, Abhilash Raj. Being non technical (and therefore opting for hosted Mailman 3), I can partly understand your kind response. 1) I can understand that I cannot disable the different ways to sign up. 2) I am still struggling to understand the difference between the two web choices as shown here. WAY # 1 TO GET AN ACCOUNT https://list.tokyoprogressive.org/accounts/signup/?next=%2Fpostorius%2Flist… VS WAY # 2 YOU CAN GET AN ACCOUNT WITHOUT SIGNING UP at the bottom of https://list.tokyoprogressive.org/postorius/lists/discuss.list.tokyoprogres… (I was under the impression making only WAY #1 allows one to post, but are you saying that the bottom option also allows one to post, but only by email?) If I am confused, I know my users will also be confused. I think I understand I can qualify their subscription in the ways you suggest: "Confirm where all users would have to confirm their subscription using an email sent to them. Optionally, you can also enable moderation where each subscription needs explicit approval too." So to put it simply: 1) I want to make it a discussion list. Not available to people who are not signed up? 2) This is dependent on all having access to the archives so they can see what they are responding to 3) What settings do I make to insure that all who sign up via WAY #1 can see the archives and post. 4) What settings do I make to insure that all who sign up via way #2 can do the same? Last, in my account settings what is the difference between a member and a non member? Thanks and sorry I was not clear the first time.

5 years, 9 months

Re: what process creates webui tables (mailmanweb db)?

by Mark Sapiro

On 9/26/22 09:14, tflatley(a)gmail.com wrote: > hello again, running a venv installation i think the tables in 2 databases (mailman/mailmanweb) were initially created by running mailman-web migrate Probably not. First of all, `mailman-web migrate` will only affect the mailmanweb database, not the mailman database, migrations for which are run implicitly when Mailman core is started. Also, migrations will only affect tables for which there are migrations, not all tables. > this wrapper is not available in a package install - so i think i need to run something like this after editing my settings.py file > > python3 manage.py migrate Yes. > 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 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. The above message saying you need to make migrations because of changes to models indicates that your Debian/Ubuntu package is broken as the packager should have created all necessary migrations. > i do see tables in the mailman db but mailmanweb is empty - is there a different flag i need to run to seed the mailmanweb db? I am confused as to why you are trying to run an out of date and possibly broken Debian/Ubuntu package when it appears you have successfully installed the latest PyPI packages in a venv. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 8 months

Re: Mailman REST API not available. Please start Mailman Core.

by Mark Sapiro

On 7/23/20 12:38 AM, Shashikanth Komandoor wrote: > Thank you Mark for your response. > > I understood that gunicorn is a front end that is used like web server like > nginx. > > But I don't think I am using it instead I am using the httpd to redirect > requests to postorius. Steve has addressed this. > So, in this case, do you think configuring gunicorn as below would work: You do need to configure gunicorn timeout to solve your issue. > *calling gunicorn.cfg in mailman.cfg as below * > > *[webservice]* > *configuration: /var/lib/mailman/mailman/src/mailman/config/gunicorn.cfg* Do NOT do this. Make your own gunicorn.cfg outside of /var/lib/mailman/mailman/src/mailman/ and point to that. Otherwise any upgrade will reverse your changes. > > *and content of gunicorn.cfg as below* > > (venv3) [root@lsmgr mailman]# cat /var/lib/mailman/mailman/src/mailman/config/gunicorn.cfg > [gunicorn] > # All the options that can be put here are available at > # http://docs.gunicorn.org/en/stable/settings.html#settings > # No of seconds to wait before killing the worker processes. > > workers = 4 > graceful_timeout = 90 > > Also what is the difference between timeout and graceful_timeout ? graceful_timeout is not what you want. It addresses something different. As it says in the comment, all the gunicorn settings are described at <http://docs.gunicorn.org/en/stable/settings.html#settings>. timeout and graceful_timeout are near the bottom of that page at <https://docs.gunicorn.org/en/stable/settings.html#timeout> and <https://docs.gunicorn.org/en/stable/settings.html#graceful-timeout>. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 10 months

Re: Healthchecks and Django

by Philip Colmer

On Tue, 4 Jan 2022 at 09:36, Stephen J. Turnbull <stephenjturnbull(a)gmail.com> wrote: > Philip Colmer writes: > > > For the MM3 servers, we're probing "/mailman3/lists/". > > You could create a path in urls.py called "250" that does nothing but > respond with a 250 status (and maybe a hello-world page). The issue > with /mailman3/lists/ is that it queries core for the lists (which, if > successful, proves that core is up as a side effect). > > > Is there another URL we could use to check the health of a MM3 server > > What does this mean to you? Our Mailman 3 suite consists of three > applications, core, Postorius, and HyperKitty, which might or might > not be installed, and if installed might or might not be running on > the same host. Core in turn depends on the MTA and starts a bunch of > qrunners. Any of the above might fall over on its own. (I don't > think there's any way to check on the health of a particular qrunner > from the net, though.) > That's a very good point. It would be nice if, at some point, an actual healthcheck endpoint could be included that returned some information about the state of the different applications as a JSON blob. It is increasingly useful to try and spot application problems before users do :) > > > Or, if not, is there a way of stopping Django from sending out the > > emails? > > There probably is, but I don't know it. Mark might, but if not asking > on a Django list would be a better place. > > Thank you. Regards Philip

3 years, 5 months

Re: Post-installation documentation?

by Mark Sapiro

On 11/25/21 10:56 AM, David Newman wrote: > > Thanks for this. After setting these variables and restarting mailman3 > and mailmanweb, the mailman user still cannot find a hyperkitty_import > command (neither can root, btw). Again, I installed MM3 and > Django/Postorius/Hyperkitty using the venv and web docs previously > referenced. Don't run mailman or django admin commands as root. This causes issues when files are created by root and can't be read by mailman. What django admin command are you running? If you don't set DJANGO_SETTINGS_MODULE in the environment and you have activated your virtualenv and run `mailman-web` as the django admin command it will set /etc/mailman3/settings.py as the settings. > On the plus side, all lists now appear in the admin web page. However, > lists created from the admin page do not appear in a site list page, > even though all lists are in the same site/domain. By default, only lists that you are owner, moderator or subscriber for are shown. What if you click Filter by Role and select All? > Finally, how to make these exports permanent? I did not see this covered > in the migration doc above. This is on a Debian system where the mailman > user's shell is bash. Is this simply a matter of adding environment > variables in the mailman user's .bashrc file? You can do that but as I note above, if you run `mailman-web` you shouldn't need to. You can add a `source /opt/mailman/venv/bin/activate` command as mentioned at https://docs.mailman3.org/en/latest/install/virtualenv.html#activate-virtua…. -- 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

admin/login/ cannot be accessed

by jean-christophe manciot

Ubuntu 20.04 python3-django 2:2.2.6-1ubuntu1 python3-django-hyperkitty 1.3.1 (built from sources) mailman3-full 3.2.2-1 Nginx server configuration: ``` ... ######## # Static ######## location /favicon.ico { alias <mysite_dir>/static/hyperkitty/img/favicon.ico; } location /static/favicon.ico { alias <mysite_dir>/static/postorius/img/favicon.ico; } location /static/ { alias <mysite_dir>/static/; } ####################### # Upstream uwsgi server ####################### location / { include /etc/nginx/uwsgi_params; uwsgi_pass 127.0.0.1:<uwsgi_server_port>; } ... ``` where: - <mysite_dir> is a symlink to <django_dir>/static - <uwsgi_server_port> matches the one defined in ```/etc/mailman3/uwsgi.ini```: ``` [uwsgi] # Port on which uwsgi will be listening. uwsgi-socket = 127.0.0.1:<uwsgi_server_port> ``` All 3 systemd services run fine: - mailman3 - mailman3-web - qcluster I'm trying to login to the django administration pages. I get the django administration login page at: https://mysite/admin/login/ Logging in with the admin credentials leads to: ``` This site can’t be reached The webpage at https://mysite/admin/login/ might be temporarily down or it may have moved permanently to a new web address. ERR_HTTP2_PROTOCOL_ERROR ``` This is very strange because it is the URL which I used to get the login page in the first place. If I launch a test web server at another port with: ``` <django_dir># python3 manage.py runserver <mysite_ip_address>:8080 Performing system checks... System check identified no issues (0 silenced). December 11, 2019 - 17:50:48 Django version 2.2.6, using settings 'settings' Starting development server at http://<mysite_ip_address>:8080/ Quit the server with CONTROL-C. ``` and access it at ```http://<mysite_ip_address>:8080/admin/login/``` to login with the same credentials as before, I get through and all the django administration lines appear, although in a degraded layout: ``` Site administration Accounts Email addresses Add Change Authentication and Authorization Groups Add Change Users Add Change Django Mailman 3 Mail domains Add Change Profiles Add Change ... ``` Any idea what could be happening here?

5 years, 5 months

Re: Configuring the List-Archive and Archived-At headers

by Mark Sapiro

On 3/20/19 5:43 PM, Ralph Seichter wrote: > With archiving enabled, mail is sent with headers like the following: > > Archived-At: <https://example.com/hyperkitty/list/foo-users@lists.example.com/message/ABC/> > List-Archive: <https://example.com/hyperkitty/list/foo-users@lists.example.com/> > List-Post: <mailto:foo-users@lists.example.com> > List-Subscribe: <mailto:foo-users-join@lists.example.com> > > The 'mailto:' entries are fine, but I need all 'https:' links to be > prefixed with https://lists.example.com instead of https://example.com . > > Does Mailman extract CN parts from the SSL certificate to populate the > header values (that would explain 'example.com' in my tests), or is this > something I can influence using configuration parameters? I searched the > docs for Mailman Suite and HyperKitty, but did not find an answer. It has nothing to do with the ssl certificate. It comes from _get_url in hyperkitty/views/mailman.py > def _get_url(mlist_fqdn, msg_id=None): > # We can't use HttpRequest.build_absolute_uri() because the mailman API may > # be accessed via localhost. > # https://docs.djangoproject.com/en/dev/ref/request-response/#django.http.Htt… > # https://docs.djangoproject.com/en/dev/ref/contrib/sites/#getting-the-curren… > # result = urljoin(public_url, urlunquote( > # reverse('hk_list_overview', args=[mlist_fqdn]))) > # We use the MailDomain association from django_mailman3 to find out the > # proper domain. What that means is the lists.example.com domain must first be known to Django at <https://lists.example.com/admin/sites/site/ Then at https://lists.example.com/postorius/domains/, the Web Host for the example.com domain needs to be lists.example.com -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 2 months

Issues with migrating from Mailman2 to Mailman 3

by Uwe Grasshoff

Hello all, I'm currently trying to convert a Debian based mailman2 installation to a docker based mailman3 installation. I successfully running the mailman-web and mailman-core containers together with the database container but I'm struggling with the import of the old mailing lists. In the core container I'm running this two commands for every mailing list: mailman create mailman(a)example.com mailman import21 mailman(a)example.com /oldmailman/lists/mailman/config.pck Then I'm switching over to the mailman-web container and running this two commands: python3.6 manage.py hyperkitty_import -l mailman(a)example.com /oldmailman/archives/private/mailman.mbox/mailman.mbox python3.6 manage.py update_index_one_list mailman(a)example.com I'm getting no errors or something else which could indicate a problem. After that I'm looking into the web interface http://example.com/postorius/lists/ There I can only see the public mailing list and the private ones are not shown there (as expected). When I then try to login with the List Manager credentials of the lists (from mailman2) I can't login in. So I thought maybe I have to "register" myself again to than get access to the list management. So I tried that but when I filled out the form and click "Register" I'm presented with an error page which titles "Serverfehler" (Server error in german) and the message "An error occurred while processing your request." When I then go back a step and try to register again I got the error message that the username is already taken. When I then try to login I can't login I always get the "An error occurred while processing your request." page. Does anyone have an idea what point I'm missing? -- With best Regards Uwe Grasshoff

5 years, 8 months

Mailman-users search results for query "Postorius"