Search results for "Postorius" - Mailman-users

Re: Error -- postorius Un-handled exception

by Mark Sapiro

On 4/10/24 03:42, admin(a)bclug.ca wrote: > > After `systemctl restart mailman3.service mailman3-web.service` I'm still getting: > >> ERROR 2024-04-10 10:19:19,739 104735 postorius Un-handled exception: HTTP Error HTTP Error 500: {"title": "500 Internal Server Error"} >> File "/opt/mailman/venv/lib/python3.10/site-packages/mailmanclient/restbase/connection.py", line 161, in call >> raise HTTPError(params.get('url'), response.status_code, >> urllib.error.HTTPError: HTTP Error 500: {"title": "500 Internal Server Error"} >> ERROR 2024-04-10 10:19:19,744 104735 django.request Internal Server Error: /mailman3/lists/new_test.domain.tld/ >> ERROR 2024-04-10 10:19:19,744 104735 django.request Internal Server Error: /mailman3/lists/new_test.domain.tld/ >> ERROR 2024-04-10 10:19:19,745 104735 django.server "GET /mailman3/lists/new_test.domain.tld/ HTTP/1.0" 500 8667 > > > Anyone have suggestions? What's in var/logs/mailman.log? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 1 month

Re: Postorius 1.2.3 and MailmanClient 3.2.1 is now out

by Abhilash Raj

On Sat, Jan 26, 2019, at 5:10 AM, Jonas Meurer wrote: > Hey Abhilash, > > Thanks a lot for your work on mailman3! > > Abhilash Raj: > > I am very pleased to announce (a bit late) that Postorius 1.2.3 and MailmanClient 3.2.1 is now out. > > > > The full set of changelog can be found in the documentation[1][2]. The most notable feature that > > I can think of is non-member management in Postorius. > > > > New releases are available on PyPI[3][4]. > > For earlier releases, you provided GnuPG signature files to > cryptographically verify that the release files were not tampered with. > > I couldn't find such signature files for the two latest releases. Would > you mind adding them? When packaging for Debian, I prefer to check the > GnuPG signatures before uploading new releases. Also, the signature > files get uploaded to the Debian archive as well so they can be checked > by everybody. That way we can cryptographically proof that the Debian > package is based on the original tarball that got packaged and signed by > upstream. Ah, sorry about that. I completely forgot about that. I am not sure if I can upload signatures after uploading the tarballs, I'll try to find out if that is possible. -- thanks, Abhilash Raj (maxking)

6 years, 4 months

Re: [Django] ERROR (EXTERNAL IP): Internal Server Error:

by Mark Sapiro

On 11/18/19 9:26 AM, Wolfgang Bock via Mailman-users wrote: > > Hello, > > I got an errormessage via mail to root@[domain-01]. > > The complete text is attached in a utf-8-text-file. > > In the lines ...6, 8, 12, 119, 138, 141, 149, 150, 151, 155, 161, 162, > 165, 166, 169, 187, 247, 251, 321 ....you can find links to different > domains anonymised as [domain-01], [domain-02], [domain-03], [domain-04]. You attempted to delete testliste02.[domain-01] via Postorius and Mailman's REST API returned a 500 status. You may find more information in mailman.log. I'm only guessing, but possibly this is because you posted to the URL <https://[domain-02]/mailman3/postorius/lists/testliste02.[domain-01]/delete>. I.e., you were accessing Postorius at https://[domain-02]/mailman3/postorius/ (domain-02) and deleting a domain-01 list. -- 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

Re: Separating Lists by Domain

by Abhilash Raj

On Sun, Dec 23, 2018, at 4:42 PM, brian(a)emwd.com wrote: > I have successfully setup a second domain with my Mailman3 setup. I > also created a list using the second domain. So I have two domains with > one list each. The issue I see at this point is all of the lists are > shown via Postorius regardless of the list domain used. Is it possible > to have only the lists to show that are part of the domain being used > to access? For example: > > http://domaina.com/postorius/lists/ > > Only listnames(a)domaina.com show up. > > http://domainb.com/postorius/lists/ > Only listnames(a)domainb.com show up. > > Right now both domaina AND domainb lists showup regardless of the > domain being used to access Postorius. The same goes for Hyperkitty as > well. You can do that this in Hyperkitty. Setting FILTER_VHOSTS = True in Django's settings.py (or settings_local.py, if you are using container images) will filter the lists for the current "Host:" header in the request. Postorius doesn't have this ability yet, but wouldn't be too much work to add that. Pull requests are welcome :) > > Brian > _______________________________________________ > 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)

6 years, 5 months

Re: Pck files stuck in out queue

by Mark Sapiro

On 2/10/25 13:45, Lieuallen, Thomas Otis via Mailman-users wrote: > Mark, > > Actually, this is saying cache_life under mailman: > > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/config/doc… > > There is a cache_lifetime under ‘dmarc’. You are correct. I was confused by the dmarc one. > I used your clue about the database to concoct my own solution… 😊. I edited the ‘expires_on’ values in the file_cache table in the database so the files were expired. > > It looks like the times in that table are UTC. > > I’m going to ratchet down my cache_life so anyone that is playing with templates doesn’t go bonkers (like me) with why their changes aren’t honored. I have a small site, so not much performance impact. That really shouldn't be necessary, but I think there is an issue in the code at https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/model/template… which is intended to evict the cache entry for the previous template when a new one is set. If the previous template has a different uri from the one being set, e.g., a mailman:// uri is being replaced by a http(s):// Postorius uri the code will attempt to evict the Postorius uri which is not the cached value. This should not be an issue when just updating a template already in Postorius and should not be an issue when setting a Postorius template to replace one previously the default or in Mailman's var/templates directory as these normally don't have template table entries, but prior to Mailman 3.3.6, the `mailman import21` command would create template table entries for imported lists. This was https://gitlab.com/mailman/mailman/-/issues/988 fixed by https://gitlab.com/mailman/mailman/-/merge_requests/989 > Thank you for your help. You're welcome. I'm glad you solved it.

3 months, 4 weeks

Mailman REST API not available. Please start Mailman core.

by Stephen J. Turnbull

joseverde(a)gmail.com writes: > Okay, so I got the webservice of Mailman3 up and running, It would help to know how you did that. Did you wipe the server and start over? Did you just purge Mailman3 and its configuration files? Something else? > but when I go to mailman3/postorius/lists/, I get the following error: > > Something went wrong > Mailman REST API not available. Please start Mailman core. > > When I logged in to the admin user, it threw a server 500 error, > but I could refresh and see myself logged in. The admin user is a Django concept. There isn't really one for Mailman core; it assumes you have direct access to the REST API. If you do have access to the REST API, you're the admin. So this doesn't prove anything about what core is doing or if it's running. > If I try to go to lists or mailman settings, however, I get the > error above. The webservice is two front ends, Postorius for administration and HyperKitty for list traffic archives. You mention only Postorius. Is HyperKitty running? The problem here could be several different things. Mailman core, Postorius, and HyperKitty are separate processes, communicating over TCP sockets. If Postorius says core isn't running, that just means it was unable to open a socket to connect to core. Core might be running but listening on a different port than the one Postorius expects, or it might not be running, and there are probably arcane reasons it could fail even if it's running and they have the same port configured. You can can check whether Mailman core is running in several ways, depending on what Ubuntu 18.04 uses to control daemons. If it's systemd, then "systemctl status mailman" (or maybe "... mailman3") should do the trick. If core is not running, you need to start it, and figure out how to get that to happen automatically since it didn't happen this time. If core is running, most likely either the webservice(s) or the core are misconfigured as to the port where core is providing the REST API. But we'll cross that bridge when we get to it, as there are a number of configuration files involved.

4 years, 10 months

Login confusion

by Markus Grandpré

Dear list, We've encountered an issue with Postorius after migrating from Mailman 2.1. It appears that Postorius is treating email addresses with differing capitalization as distinct user accounts. For example, <markus.grandpre(a)uni-konstanz.de> and <Markus.Grandpre(a)uni-konstanz.de> are being recognized as separate identities. This is causing significant confusion. Users registered with one capitalization pattern are not seeing the list subscriptions and settings that were previously associated with their account (imported from Mailman v2.1) which used a different capitalization. Is there a known configuration option or method within Postorius (or Mailman 3 itself) to normalize or unify account identification, effectively treating email addresses as case-insensitive for account matching? We need a solution that ensures users see their correct list memberships regardless of the capitalization they use when logging in or that was used during the original Mailman 2.1 import. Thank you in advance Markus -- Markus Ludwig Grandpré Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre, B803, Tel: ++49 7531 88 4342

3 months, 4 weeks

Re: missing graphics in Postorius

by Mark Sapiro

On 12/6/21 10:15 PM, David Newman wrote: > After installing MM3 on Debian 10 using the venv docs, no graphics > appear in the admin or list pages, just broken links. > > The mailmanweb log has lines like this: > > ERROR 2021-12-07 06:04:10,002 18262 django.security.DisallowedHost > Invalid HTTP_HOST header: '127.0.0.1'. You may need to add '127.0.0.1' > to ALLOWED_HOSTS. > > which is odd because there is the line for "localhost" in settings.py, > and /etc/hosts correctly ties this to 127.0.0.1. Add '127.0.0.1' to ALLOWED_HOSTS anyway. > There are entries like this in /var/log/nginx/error.log saying the files > just aren't there: > > 2021/12/06 22:00:30 [error] 18123#18123: *65 open() > "/opt/mailman/web/static/postorius/img/mailman_logo_small_trans.png" > failed (2: No such file or directory), client: x.x.x.x, server: > somehost.example.com, request: "GET > /static/postorius/img/mailman_logo_small_trans.png HTTP/2.0", host: > "somehost.example.com", referrer: > "https://somehost.example.com/mailman/lists/" > > (I've obfuscated names and addresses here, but "somehost.example.com" > refers to a valid FQDN in the log.) > > I thought I'd followed all the venv docs, but the > /opt/mailman/web/static/postorius directory doesn't exist. Did I miss > something? Assuming you have ``` STATIC_ROOT = '/opt/mailman/web/static' ``` in your /etc/mailman3/settings.py file, you may need to create that directory if it doesn't exist. You shouldn't need to manually create the /opt/mailman/web/static/postorius directory if the /opt/mailman/web/static directory exists and is writable/searchable by the Mailman user. That should enable ``` (venv)$ mailman-web collectstatic ``` to populate that directory. Be sure you've run all four commands at https://docs.mailman3.org/en/latest/install/virtualenv.html#run-database-mi… et seq. -- 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: customized welcome message

by Mark Sapiro

On 12/7/23 03:01, Nils wrote: > Hi, > > I've created a template "The notice sent to a member when they are > subscribed to the mailing list.". > When I subscribe to the list, I don't get the message I've created. > Instead I get a plain text message, containing the html source of the > parent domain. These messages are sent with `Content-Type: text/plain`. Any html included in a template will be rendered as plain text. I.e., you can't include html in templates. > When I try to change the value of Settings > Automatic Responses > URI > for the welcome message in postorius frontend, I always get this error > message: I see no URI setting in Postorius Settings > Automatic Responses. What Postorius version is this? Any local mods? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 6 months

Re: Splitting hosts: mta&core vs postorius

by Mark Sapiro

On 6/24/20 2:10 PM, Ruth Ivimey-Cook wrote: > Mark, > >> You need to set hostname: in mailman.cfg to the actual external IP >> address of the Mailman host machine or to a name which resolves to that >> IP both internally and externally, and also set that host name/IP in the >> MAILMAN_REST_API_URL setting on the Postorius machine. > > I've done that, but there is no observed change in the browser (still > get same 404 error). > > Specifically, I reset hostname to be a newly-added CNAME of the actual > host address, and ensured that the 0.0.0.0 addresses were no longer there. OK, So setting hostname: to this CNAME which resolves to the external IP on the Mailman core host allows the REST interface to listen on that external interface and solves that issue without patching the rest runner. Correct? > A tcpdump now shows the GET of > > /3.1/domains/mailman-web.ivimey.org/lists&advertised=true&count=0&page=1 > > directed at mailman-core and the reply being 404 not found. > > The extract from core's mailman.log is now: > > [24/Jun/2020:20:41:11 +0000] "GET > /3.1/domains/mailman-web.ivimey.org/lists?advertised=true&count=0&page=1 > HTTP/1.1" 404 26 "-" "GNU Mailman REST client v3.3.1" > > And the entry for postorius in mailmansuite.log: > > ERROR 2020-06-24 21:41:11,191 13310 postorius Un-handled exception: > HTTP Error 404: {"title": "404 Not Found"} > Traceback (most recent call last): > File > "/opt/mailman3/lib/python3.6/site-packages/django/core/handlers/base.py", line > 113, in _get_response > response = wrapped_callback(request, *callback_args, > **callback_kwargs) > [snip] > File > "/opt/mailman3/lib/python3.6/site-packages/mailmanclient/restbase/page.py", > line 37, in __init__ > self._create_page() > File > "/opt/mailman3/lib/python3.6/site-packages/mailmanclient/restbase/page.py", > line 62, in _create_page > response, content = self._connection.call(self._build_url()) > File > "/opt/mailman3/lib/python3.6/site-packages/mailmanclient/restbase/connection.py", > line 116, in call > error_msg, response, None) > urllib.error.HTTPError: HTTP Error 404: {"title": "404 Not Found"} > > Note that the mailman-web.ivimey.org address is the newly-added CNAME of > greyarea-web1, mailman-core is likewise the CNAME of greyarea-post. > > There is nothing I can see in the other logs that looks out of the > ordinary. > > I guess this indicates that my earlier wondering if I had something left > over from a past install is dispelled, as that name didn't exist until > today. OK, but you still haven't reported whether you looked at the domains in Django. These are in the Django database on the Postorius server, and I don't know what's there, but if there is a domain there which is not known to core, that could cause this 404. Further if that domain is not fully qualified, something could just be appending the hostname: to it causing that name to be the one requested. Some of this is guesswork and possibly overreaching on my part, but I would like to be assured that there are no extraneous domains in Django's database. I wrote in the post at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > Go to your Django admin web UI and look at your Django Mailman 3 Mail > domains. This will be at a URL like > https://greyarea-web1.cam.ivimey.org/admin/django_mailman3/maildomain/ Have you done that? I want to help resolve this issue, but right now I want to rule out the possibility that there are domains known to Django that aren't known to core. -- 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

Mailman-users search results for query "Postorius"