Search results for "Postorius" - Mailman-users

Re: Error -- postorius Un-handled exception

by Odhiambo Washington

On Sat, Jan 27, 2024 at 8:17 AM Mark <imark(a)posteo.net> wrote: > > ----------------------- > > > > > > "/opt/mailman/venv/lib/python3.11/site-packages/mailmanclient/restbase/connection.py", > > > line 160, in call > > > raise HTTPError(params.get('url'), response.status_code, > > > urllib.error.HTTPError: HTTP Error 500: {"title": "500 Internal > > Server > > > Error"} > > > ERROR 2024-01-24 05:41:46,333 51799 django.request Internal Server > > > Error: /postorius/lists/testing.example.com/ > > --------------------------- > > > Try running all the system initializations with "mailman info" and > > "mailman conf". This often will elicit errors if the system is messed > > up. More likely to get this error would be "mailman withlist $LIST" > > (maybe you need an '-l' option to specify the list, I forget). If > > that doesn't elicit the error, then check that Mailman's runners are > > running with ps. Since it's Debian, I guess they should be running as > > the 'list' user. Are Mailman's files and directories owned by 'list' > > or sometimes 'www-data' for log files? > > Debian yes, but venv/pip installation so running as "mailman". > > > > > The log is saying that when Postorius tried to look up that list, it > > tried to call out to Mailman core via HTTP to the API to get the > > information and that access failed with HTTP status 500. I think the > > actual error is likely to be reported in mailman.log (or it might be > > in error.log, "grep '05:41:46' *.log" in Mailman's log directory will > > probably find it). I'm pretty sure there will be relevant log > > entries, probably a matching traceback. > > ---------------------------- > > Hi, > > Thank you Steve, Mark, Odhiambo for your responses. > > After working my way through your suggestions with no joy I discovered > to my embarrassment that I hadn't created the "mailman-hyperkitty.cfg" > file. Once created all was well. > > This was of course after I had begun the installation process again from > scratch. My apologies for the waste of bandwidth and your time. > > Regarding my installation, (following the docs at > https://docs.mailman3.org/en/latest/install/virtualenv.html) I found a > couple of issues that others might also stumble over: > > 1. Installing Xapian needed clang. It didn't like gcc > 2. Being a fresh Debian 12 OS, I needed to also install make, > build-essential > 3. For the user "mailman" to access the databases I needed to change the > owner to mailman (even though all privileges has been granted) ... postgres=# create database mailman; > CREATE DATABASE > postgres=# create database mailmanweb; > CREATE DATABASE > postgres=# create user mailman with encrypted password '<PASSWORD>'; > CREATE ROLE > postgres=# grant all privileges on database mailman to mailman; > GRANT > postgres=# grant all privileges on database mailmanweb to mailman; > GRANT > > psql -d mailman -U mailman -W > $ psql -d mailman -U mailman -W > Password: > > psql: error: connection to server on socket > "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL: Peer authentication > failed for user "mailman" > > sudo -u postgres psql > ALTER DATABASE mailman OWNER TO mailman; > \q > > $ psql -h localhost -d mailman -U mailman -W > Password: > > psql (15.5 (Debian 15.5-0+deb12u1)) > SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, > compression: off) > Type "help" for help. > > ... and same for mailmanweb > > So far, so good. > > Thanks and apologies once again, > Mark > The issue you're dealing with in that case is this change in PostgreSQL-15 discussed in this blog: https://www.cybertec-postgresql.com/en/error-permission-denied-schema-publi… I have never needed to do `psql -d mailman -U mailman -W`. I used the steps documented above to enable mailman user to write to the database. postgres=# \c mailmanweb postgres You are now connected to database "mailmanweb" as user "postgres". mailmanweb=# GRANT ALL ON SCHEMA public TO mailman; GRANT mailmanweb=# \c mailman postgres You are now connected to database "mailman" as user "postgres". mailmanweb=# GRANT ALL ON SCHEMA public TO mailman; GRANT TBH, I am not sure which method is the best although I think this option is :) -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

2 years, 9 months

Mailman 3 Web Application Startup Time or Availability - 502 Bad Gateway and Postorius

by summersan＠nclack.k12.or.us

Hello, I've been setting up a new Mailman 3 installation earlier this year, and I think things have been going okay so far. I've noticed, however, that after a long amount of time passes (for example, a weekend), when I try to visit the local Mailman 3 web application (e.g., example.mailman.site/mailman3/lists/, where it says "Postorius" at the top left corner of the page and shows a list of mailing lists in the body of the page), I sometimes get a 502 Bad Gateway type of error (referenced from my notes). As far as I can tell, this looks like a normal web server (nginx?) error. If I try visiting the Mailman 3 server location again in a web browser shortly thereafter, I still might get a 502 Bad Gateway error. If I wait a while longer (maybe a minute or more?), the Mailman 3 web application appears to load as expected. I've tried looking at the gunicorn documentation (https://docs.gunicorn.org/en/stable/index.html) and searching online (including in this Mailman3 mailing list) to see if there's something that can be done to fix this issue. The closest thing I can find for now is advice for something that, while possibly being technologically unrelated, includes the idea of "warmup requests", which makes me think of simply setting up some sort of script to periodically load a page on the Mailman 3 web application in order to keep it more available for visitors (https://stackoverflow.com/a/57056170) Is there a setting or something in any of the Mailman 3 related programs that could help with keeping the Mailman 3 web application up and running more often without having to resort to making an ongoing, automated request to the Mailman 3 web application? Thank you. * Note: "Mailman 3" terminology is referenced from this page: https://lists.mailman3.org/archives/

5 years, 6 months

Re: Error -- postorius Un-handled exception

by Mark

> On Sat, Jan 27, 2024 at 8:17 AM Mark <imark(a)posteo.net> wrote: >> 3. For the user "mailman" to access the databases I needed to change >> the >> owner to mailman (even though all privileges has been granted) ... ------------------------------------------------------------------------------------------------------- On 2024-01-27 18:51, Odhiambo Washington wrote: > > The issue you're dealing with in that case is this change in > PostgreSQL-15 > discussed in this blog: > https://www.cybertec-postgresql.com/en/error-permission-denied-schema-publi… > > I have never needed to do `psql -d mailman -U mailman -W`. > I used the steps documented above to enable mailman user to write to > the > database. > > postgres=# \c mailmanweb postgres > You are now connected to database "mailmanweb" as user "postgres". > mailmanweb=# GRANT ALL ON SCHEMA public TO mailman; > GRANT > mailmanweb=# \c mailman postgres > You are now connected to database "mailman" as user "postgres". > mailmanweb=# GRANT ALL ON SCHEMA public TO mailman; > GRANT > > TBH, I am not sure which method is the best although I think this > option is > :) > ------------------------------------------------------------------------------------------------------- Thanks for the heads up on that blog Odhiambo. Agreed. it is a better way of doing it. --- SNIP --- In PostgreSQL 14 and in prior versions, by default anybody can create a table. The new table will simply end up in the PUBLIC schema. The problem with this approach is that the public schema can quickly turn into a trash can containing all kinds of used and unused tables – which is neither desirable nor recommended. An even bigger problem is security: almost any privilege escalation attack on a PostgreSQL database requires the attacker to create malicious objects. ... The public schema is the perfect vector for such a privilege escalation attack. Therefore PostgreSQL has made a major leap forward and changed this behavior. In version 15, only the database owner can create objects in the public schema. ---

2 years, 9 months

Re: Template path

by Seth Seeger

> On Sep 17, 2020, at 12:54 PM, Mark Sapiro <mark(a)msapiro.net> wrote: > >> I followed previous emails on this list which told me to set POSTORIUS_TEMPLATE_BASE_URL in /opt/mailman/web/settings_local.py, but that doesn’t seem to make any difference. (I set it to a different value and the error message didn’t change. I also tried setting it in /opt/mailman/core/settings_local.py to no effect. After each change, I restarted mailman-web and mailman-core containers.) > > > How did you create the template? In Postorius or by manually creating a > file somewhere? If by creating a file, POSTORIUS_TEMPLATE_BASE_URL is > not relevant, but ensure that the file is findable and readable by Mailman. I created the template in Postorius. >> From within mailman-web and mailman-core containers, I can reach “mailman-web:8000”. >> >> In the webpage, I see: Mailman REST API not available. Please start Mailman core. > > > The REST APT is normally exposed on port 8001, not 8000 (See `port` in > `mailman conf -s webservice`. Yes, it’s 8001: [webservice] hostname: 172.19.199.2 [webservice] port: 8001 > What is your setting for MAILMAN_REST_API_URL? does the port match? I’m not overriding it: ./postorius/mailman-web/settings.py:MAILMAN_REST_API_URL = os.environ.get('MAILMAN_REST_URL', 'http://mailman-core:8001') > >> In /opt/mailman/core/var/logs/mailman.log, I get: >> >> [17/Sep/2020:16:23:29 +0000] "GET /3.1/lists/xxx.example.com HTTP/1.1" 200 416 "-" "GNU Mailman REST client v3.3.1" > > It appears you are connecting to the REST API, but ... > ... >> urllib3.exceptions.ReadTimeoutError: HTTPConnectionPool(host='mailman-web', port=8000): Read timed out. (read timeout=5) > > > Something appears to be trying to connect to REST on port 8000 Is this a red herring? Is something else wrong? Setting POSTORIUS_TEMPLATE_BASE_URL in settings_local.py doesn’t seem to make any difference. Having set the POSTORIUS_TEMPLATE_BASE_URL, I deleted the template and recreated it. Now, when I approve a pending subscription it goes through, but the welcome email is blank. Seth

6 years, 1 month

Re: Mailman backend maintenance task

by Eugenio Jordan (external)

Dear Steve: I really appreciate you also took your time to provide more insights on how Mailman works, and how their different components interact each other. There are two "minor" tasks and one major task that we would need to accomplish within PostGRESQL, namely rebuilding the index related to hyperkitty_email table primary key, rebuilding also another index on the very same table supporting an uniqueness constraint (these would be the minor); and running vacuum full on the whole database to effectively reduce the size of precisely hyperkitty_email table, which is the largest table in this database, and if possible retrieve back to the SAN the extra space we had to add to cope with that very table size increasing. The way vacuum full locks the tables are, among all the locking mechanisms provided by PostGRESQL to guarantee the transactional integrity, one of the strongest, if not the strongest one (as far as I know, the tables are more ore less recreated when running vacuum full). The idea we were considering was more or less stopping all of the components, then starting up only PostGRESQL, and then performing each one of the mentioned tasks. Actually our PG release allow "online" indices rebuild (drop + rebuild concurrently), but we did not want to assume the risk if, for whatever reason, new records were added to the table breaking the uniqueness of both constraints (fixing this cases turns out to be a real pain in most cases). Alternatively, we could lock the table ourselves to get more or less the same effect, true, although, after all, the final impact on potential connections willing to run DML would be the same. In other words, rather than having lots of transactions coming from whether core component processes or web component processes fail, we prefer to stop everything. But it's got of course the worst downside: we would receive Let me please now go back to your kind explanation to see if I did get things correctly. You mention that regardless the connectivity that Mailman's core processes might have with the database, the emails will be received by and queued until the connection is back again and they can be delivered to the distribution lists' members. Could you please confirm whether this task would be actually delegated to Postfix (or any MTA integrated with Mailman)? If so, this is actually what we need: we could afford delaying the reception a couple of days, whilst we are sure that no mail will be lost. Once more, thanks a lot for your kind help. Best regards. -----"Stephen J. Turnbull" <[1]stephenjturnbull(a)gmail.com> wrote: ----- To: [2]eugenio.jordan(a)esa.int From: "Stephen J. Turnbull" <[3]stephenjturnbull(a)gmail.com> Date: 08/24/2021 05:33PM Cc: [4]mailman-users(a)mailman3.org Subject: [MM3-users] Mailman backend maintenance task Hi, Eugenio, I wrote this earlier but am in the middle of moving my office so my mail has been intermittent. I have been following your discussion with Abhilash, and he's definitely the expert, especially if you are using the containers he creates and distributes. But there's some information here he hasn't mentioned yet. Please consider the following discussion to be background that allows you to understand some of the considerations. I've only run the Mailman 3 suite with all three running constantly on the same host, so I have no experience with this kind of issue. [5]eugenio.jordan(a)esa.int writes: > Our customer is currently using PostGRESQL as backend, and we would > like to perform some maintenance tasks, namely running vacuum full, > or at least trying to rebuild hyperkitty_email primary key related > index. We have been asked on the real impact of putting in place > such initiative. Though the latter is related to archiving, I > haven't found a way to stop just Hyperkitty or Django related > processes other than stopping Mailman's core, hence preventing > mails addressed to distribution lists from being delivered, could > you please confirm if I am correct? Mailman core can certainly run without either Postorius or HyperKitty. Controlling Mailman core (moderation, helping users) without Postorius is annoying, but it can be done. If you stop the HyperKitty process, what should happen, I believe, is that posts for archiving will accumulate in the 'archive' queue until HyperKitty is available again. It's been a while since I studied this so I could be completely wrong, but as I understand it HyperKitty and Postorius are not daemon processes. Rather, they are WSGI applications, which means they are subprocesses spawned by your webserver, and controlled by it. In order to keep them from running, you would reconfigure the webserver to not call those WSGI applications. How that is done is specific to the webserver and the WSGI module. If you are running from Docker containers, most likely, you can just stop their containers. The larger problem is that Mailman core uses a RDBMS. Normally both Django and Mailman are referring to the same RDBMS, PostgreSQL in your case. I'm not familiar with the vaccuum operation; if it requires taking the whole RDBMS down, and Mailman is running on that RDBMS, you're out of luck. Mailman can accept posts and queue them, but it can't deliver them to subscribers without access to the RDBMS tables. If it's just a matter of locking some tables while other are available, then it should work because the tables used by core and HyperKitty are disjoint as far as I know. (I think Postorius and HyperKitty both use Django's user tables for authorization, so at least for those tables both Postorius and HyperKitty will have to be down, but core can continue running because its database is completely separate.) > Regarding the former, as far as I have read, the "mappings" lists > -> addresses are stored just in the database, so if we run some > kind of procedure or task like vacuum which will lock exclusively > tables, or want anyway to have the database stopped for a cold > backup or whatever, Mailman willl not work, that is, again the > mails addressed to the distribution lists will not be > delivered. Will you please confirm this point, too? That depends on how "vacuum" works. If you can tell the RDBMS not to lock Mailman core's tables, it can continue to run. Definitely if the database is not running, Mailman will continue to receive and store the posts, but it won't be able to distribute mail to subscribers until its tables are available again. At that point the queued posts will be processed normally, except that if there's a large backlog, they won't go out in a quick burst, it may take a while. One possible worry, depending on how you are connected to the Internet, is that your provider may interpret the sudden burst of outgoing mail when Mailman comes back on line as spam or some other sort of mischief. Mailman has no way to throttle this: it feeds messages to the MTA until the MTA says "stop". Then it waits until the MTA is ready again. Regards, Steve This message is intended only for the recipient(s) named above. It may contain p roprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropri ate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Prot ection Officer (dpo(a)esa.int) References 1. mailto:stephenjturnbull@gmail.com 2. mailto:eugenio.jordan@esa.int 3. mailto:stephenjturnbull@gmail.com 4. mailto:mailman-users@mailman3.org 5. mailto:eugenio.jordan@esa.int

5 years, 2 months

Re: Templates

by Mark Sapiro

On 11/17/20 1:23 AM, Odhiambo Washington wrote: > On Tue, 17 Nov 2020 at 06:09, Mark Sapiro <mark(a)msapiro.net> wrote: > >> >> How did you create this footer?. If you created it by creating a file in >> Mailman's var/templates directiory, can Mailman read it? >> >> > I went into Postorius and selected the list. It's the only one. > Selected Templates -> New Template. And previously > requests.exceptions.HTTPError: 404 Client Error: Not Found for url: > http://localhost:8000/mm3/mailman3/api/templates/list/kictanet-2.lists.kict… ... > Message: 'Cannot retrieve template at > http://localhost:8000/mm3/mailman3/api/templates/list/kictanet-2.lists.kict… > (<no authorization>)' This is Mailman core trying to get the template from Postorius. What happens if you try to get that URL in a browser? What if you try your domain instead of localhost:8000? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 11 months

Re: list footer web customization procedure

by Mark Sapiro

On 11/30/21 1:11 AM, Stephen J. Turnbull wrote: > > Does Django empty out the "spacetebasket" if it's all white space, or > does spurious whitespace in that box lead to an (apparently) empty > footer being added? Postorius used to remove leading and trailing whitespace from the template, but not since https://gitlab.com/mailman/postorius/-/issues/301 was fixed. > Anway, I recommend to the OP that they make sure there's no whitespace > in the Data box. A good recommendation. While a header or footer template with some whitespace might not be noticeable when added to a text/plain message, it will cause extra mime parts to be added to more complex messages. Also, if the goal in setting an empty footer is to avoid breaking a DKIM signature, even adding a bit of whitespace to a text/plain message is an issue. -- 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

Re: Held messages: Long time waiating for response of the Mailman API

by Stephan Krinetzki

Mark Sapiro wrote: > On 1/24/22 15:06, Mark Sapiro wrote: > > On 1/18/22 06:24, Stephan Krinetzki wrote: > > Hello, > > We are using Mailman 3.3.5 with Hyperkitty 1.3.5. Mailman 3 is > > installed in a venv and deployed using Apache and uwsgi. This works > > quite well so far, only withheld messages cause us a problem: If we > > try to approve them via Postorius, the message is delivered to the > > list immediately, but the success message in Postorius takes a long > > time - on average the process hangs for three minutes until the > > message is no longer displayed. We have already adjusted the timeout > > in gunicorn.cfg, but this does not improve the situation. Are there > > any tips on how we can speed up the REST API? Or is it even a > > configuration error? > > There are two steps in handling the POST for a held message. The first > > step is accepting, rejecting or discarding the message. This is > > happening immediately. > > The second step is handling the poster's moderation action based on the > > choice from the Set member moderation dropdown in the view of the held > > message. This is processed by the code at > > https://gitlab.com/mailman/postorius/-/blob/master/src/postorius/views/list…. > > If no selection has been made, the default value POSTed for > > moderation_choice is no-action and that code is skipped. If it is one > > of the choices Hold for moderation, Reject (with notification), > > Discard (no notification), Accept immediately (bypass other rules) > > or Default processing that is processed. So presumably a selection has > > been made and processing is stuck on getting the member or setting the > > member's moderation action. > > Possibly the logs of your database manager will have information. > > Some additional info. > By gunicorn.cfg, do you mean the file at mailman/config/gunicorn.cfg? If > you are using gunicorn as a wsgi server, that is separate from the > gunicorn serving the REST API and its config doesn't affect the REST > API. The relevant config is mailman/config/gunicorn.cfg?. > Also, I doubt the issue is with the REST API per se, but rather it is in > Mailman core's processing of the particular endpoint and if that is > slow, it is most likely some kind of database issue. Hi Mark, yes, we are using a local copy of the gunicorn.cfg. It is in the home directory of our mailman3 instance (like the mailman.cfg, same directory). We will now look into the postgresql database - maybe there is an index missing or something like that. Thank you for help.

4 years, 9 months

Re: Footer from templates not working - DB issue?

by Mark Sapiro

On 9/25/22 05:26, mailman--- via Mailman-users wrote: > Dear All, > I have a similar issue. Also on Debian 11. Also installed as Debian PKG. It's version GNU Mailman 3.3.3 (Tom Sawyer) > I am using sqlite3. When I do the SQL-query I get an URI which is in multiple reasons wrong > http://localhost/mailman3/postorius/api/templates/list/....../list:member:r… The initial part of that URL is set from the Django setting `POSTORIUS_TEMPLATE_BASE_URL`. If that is set to `http://localhost/mailman3/`, it should probably be just `http://localhost/`. > OK - the hostname could be changed but the path is not existing at all. > There is no file "list:member:regular:footer" on the complete filesystem. It's not a file. It refers to an entry in the postorius_emailtemplate table in the database which is retrieved via the Postorius API. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 1 month

Re: User settings triggers error

by Mark Dadgar

On Jun 16, 2020, at 6:52 PM, Mark Dadgar <mark(a)pdc-racing.net> wrote: >> I wonder why it didn't show up already on our Mailman 3 instances, which also runs postgres. Perhaps, a different version of sqlalchemy triggers this. We'd need to look more into the specific version of sqlalchemy that causes this. > > So one thing I realized: this is the server where I migrated the mm3 databases from sqlite to postgres via pgloader and had the truncated index name warnings that I posted about a while back. > > Don’t know if that’s a factor but I thought I’d mention it. > >> Mark Dadgar, Can you please let us know the version of sqlalchemy installed with your Mailman? > > > python3-sqlalchemy/focal,now 1.3.12+ds1-1ubuntu2 There is definitely something sketchy going on here. As an admin, I am not getting accurate subscription status about people on a list. For example, I search for a list member, find their listing, check the box and click Unsubscribe Selected, and get an error because it turns out that they had already unsubscribed themselves previously. But Postorius thought they were still subscribed. mailman.log errors: -- Jun 18 14:18:47 2020 (1302) 127.0.0.1 - - "GET /3.1/lists/trackjunkies.pdc-racing.net HTTP/1.1" 200 422 Jun 18 14:18:47 2020 (1302) 127.0.0.1 - - "GET /3.1/lists/trackjunkies.pdc-racing.net/roster/owner HTTP/1.1" 200 625 Jun 18 14:18:47 2020 (1302) 127.0.0.1 - - "GET /3.1/lists/trackjunkies.pdc-racing.net/roster/moderator HTTP/1.1" 200 90 Jun 18 14:18:48 2020 (1302) REST request handler error: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1245, in _execute_context self.dialect.do_execute( File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 581, in do_execute cursor.execute(statement, parameters) psycopg2.errors.UndefinedFunction: operator does not exist: text = uuid LINE 4: WHERE member._member_id = '88b9844d-0791-44eb-8cf4-615a03b5c... ^ HINT: No operator matches the given name and argument types. You might need to add explicit type casts. The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/lib/python3.8/wsgiref/handlers.py", line 137, in run self.result = application(self.environ, self.start_response) File "/usr/lib/python3/dist-packages/mailman/database/transaction.py", line 50, in wrapper rtn = function(*args, **kws) File "/usr/lib/python3/dist-packages/mailman/rest/wsgiapp.py", line 218, in __call__ return super().__call__(environ, start_response) File "falcon/api.py", line 232, in falcon.api.API.__call__ File "falcon/api.py", line 229, in falcon.api.API.__call__ File "falcon/api.py", line 582, in falcon.api.API._get_responder File "/usr/lib/python3/dist-packages/mailman/rest/wsgiapp.py", line 165, in find result = attribute( File "/usr/lib/python3/dist-packages/mailman/rest/lists.py", line 216, in member return AMember(member.member_id) File "/usr/lib/python3/dist-packages/mailman/rest/members.py", line 114, in __init__ else service.get_member(member_id)) File "/usr/lib/python3/dist-packages/mailman/database/transaction.py", line 85, in wrapper return function(args[0], config.db.store, *args[1:], **kws) File "/usr/lib/python3/dist-packages/mailman/model/subscriptions.py", line 71, in get_member if members.count() == 0: File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3630, in count return self.from_self(col).scalar() File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3355, in scalar ret = self.one() File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3325, in one ret = self.one_or_none() File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3294, in one_or_none ret = list(self) File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3367, in __iter__ return self._execute_and_instances(context) File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3392, in _execute_and_instances result = conn.execute(querycontext.statement, self._params) File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 982, in execute return meth(self, multiparams, params) File "/usr/lib/python3/dist-packages/sqlalchemy/sql/elements.py", line 287, in _execute_on_connection return connection._execute_clauseelement(self, multiparams, params) File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1095, in _execute_clauseelement ret = self._execute_context( File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1249, in _execute_context self._handle_dbapi_exception( File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1476, in _handle_dbapi_exception util.raise_from_cause(sqlalchemy_exception, exc_info) File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 398, in raise_from_cause reraise(type(exception), exception, tb=exc_tb, cause=cause) File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 152, in reraise raise value.with_traceback(tb) File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1245, in _execute_context self.dialect.do_execute( File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 581, in do_execute cursor.execute(statement, parameters) sqlalchemy.exc.ProgrammingError: (psycopg2.errors.UndefinedFunction) operator does not exist: text = uuid LINE 4: WHERE member._member_id = '88b9844d-0791-44eb-8cf4-615a03b5c... ^ HINT: No operator matches the given name and argument types. You might need to add explicit type casts. [SQL: SELECT count(*) AS count_1 FROM (SELECT member.id AS member_id, member._member_id AS member__member_id, member.role AS member_role, member.list_id AS member_list_id, member.moderation_action AS member_moderation_action, member.address_id AS member_address_id, member.preferences_id AS member_preferences_id, member.user_id AS member_user_id FROM member WHERE member._member_id = %(member_id_1)s) AS anon_1] [parameters: {'member_id_1': UUID('88b9844d-0791-44eb-8cf4-615a03b5cc53')}] (Background on this error at: http://sqlalche.me/e/f405) Jun 18 14:18:48 2020 (1302) 127.0.0.1 - - "DELETE /3.1/lists/trackjunkies.pdc-racing.net/member/XXXXXXXX(a)gmail.com HTTP/1.1" 500 59 — mailman-web.log errors: -- ERROR 2020-06-18 21:21:06,399 1268 django.request Internal Server Error: /mailman3/postorius/lists/trackjunkies.pdc-racing.net/members/member/ Traceback (most recent call last): File "/usr/lib/python3/dist-packages/mailmanclient/restobjects/mailinglist.py", line 321, in unsubscribe self._connection.call(path, method='DELETE') File "/usr/lib/python3/dist-packages/mailmanclient/restbase/connection.py", line 99, in call raise HTTPError(url, response.status, content, response, None) urllib.error.HTTPError: HTTP Error 500: b'A server error occurred. Please contact the administrator.' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 34, in inner response = get_response(request) File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 115, in _get_response response = self.process_exception_by_middleware(e, request) File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 113, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line 71, in view return self.dispatch(request, *args, **kwargs) File "/usr/lib/python3/dist-packages/django/contrib/auth/mixins.py", line 52, in dispatch return super().dispatch(request, *args, **kwargs) File "/usr/lib/python3/dist-packages/django/contrib/auth/mixins.py", line 109, in dispatch return super().dispatch(request, *args, **kwargs) File "/usr/lib/python3/dist-packages/postorius/views/generic.py", line 65, in dispatch return super(MailingListView, self).dispatch(request, *args, **kwargs) File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line 97, in dispatch return handler(request, *args, **kwargs) File "/usr/lib/python3/dist-packages/postorius/views/list.py", line 169, in post return self._member_post(request, role) File "/usr/lib/python3/dist-packages/postorius/views/list.py", line 120, in _member_post self.mailing_list.unsubscribe(member) File "/usr/lib/python3/dist-packages/mailmanclient/restobjects/mailinglist.py", line 324, in unsubscribe raise ValueError('%s is not a member address of %s' % ValueError: XXXXXXX(a)gmail.com is not a member address of trackjunkies(a)pdc-racing.net ERROR 2020-06-18 21:21:06,399 1268 django.request Internal Server Error: /mailman3/postorius/lists/trackjunkies.pdc-racing.net/members/member/ Traceback (most recent call last): File "/usr/lib/python3/dist-packages/mailmanclient/restobjects/mailinglist.py", line 321, in unsubscribe self._connection.call(path, method='DELETE') File "/usr/lib/python3/dist-packages/mailmanclient/restbase/connection.py", line 99, in call raise HTTPError(url, response.status, content, response, None) urllib.error.HTTPError: HTTP Error 500: b'A server error occurred. Please contact the administrator.' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 34, in inner response = get_response(request) File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 115, in _get_response response = self.process_exception_by_middleware(e, request) File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 113, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line 71, in view return self.dispatch(request, *args, **kwargs) File "/usr/lib/python3/dist-packages/django/contrib/auth/mixins.py", line 52, in dispatch return super().dispatch(request, *args, **kwargs) File "/usr/lib/python3/dist-packages/django/contrib/auth/mixins.py", line 109, in dispatch return super().dispatch(request, *args, **kwargs) File "/usr/lib/python3/dist-packages/postorius/views/generic.py", line 65, in dispatch return super(MailingListView, self).dispatch(request, *args, **kwargs) File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line 97, in dispatch return handler(request, *args, **kwargs) File "/usr/lib/python3/dist-packages/postorius/views/list.py", line 169, in post return self._member_post(request, role) File "/usr/lib/python3/dist-packages/postorius/views/list.py", line 120, in _member_post self.mailing_list.unsubscribe(member) File "/usr/lib/python3/dist-packages/mailmanclient/restobjects/mailinglist.py", line 324, in unsubscribe raise ValueError('%s is not a member address of %s' % ValueError: XXXXXXXXX(a)gmail.com is not a member address of trackjunkies(a)pdc-racing.net [pid: 1268|app: 0|req: 18686/18686] 76.102.110.193 () {68 vars in 1625 bytes} [Thu Jun 18 21:21:06 2020] POST /mailman3/postorius/lists/trackjunkies.pdc-racing.net/members/member/ => generated 1156 bytes in 162 msecs (HTTP/1.1 500) 5 headers in 182 bytes (1 switches on core 1) —— Could this somehow be related to my recent migration from sqlite3 to postgres? - Mark ----- mark(a)pdc-racing.net | 408-348-2878

6 years, 4 months

Mailman-users search results for query "Postorius"