Search results for "Postorius" - Mailman-users

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, 7 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

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

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, 10 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, 9 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, 7 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

3 years, 11 months

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, 3 months

Re: Postorius fails to show list because of a large message being held

by Mark Sapiro

On 7/14/20 3:54 AM, Brian Carpenter wrote: > On 7/14/20 6:49 AM, Gilles Filippini wrote: >> Mailman Core logs: >> [2020-07-14 10:41:21 +0000] [36] [CRITICAL] WORKER TIMEOUT (pid:49) >> [2020-07-14 10:41:21 +0000] [49] [INFO] Worker exiting (pid: 49) >> [2020-07-14 10:41:22 +0000] [50] [INFO] Booting worker with pid: 50 > > I am pretty sure that timeout is related to gunicorn. If it is, then > increasing the worker out timeout setting for gunicorn should work. You > tend to get such errors when doing an export of a large membership > roster. This is the first time I have seen it related to a held message. It seems weird that a gunicorn worker would run for more that the default 30 seconds because of a 23MB message, but I think Brian is correct. > I have this in my setup: > > mailman.cfg: > > [webservice] > configuration: /opt/mailman/mm/gunicorn.cfg > > gunicorn.cfg: > > [gunicorn] > workers = 4 > timeout = 900 > > You will need to restart gunicorn after adjusting the timeout setting. It's confusing, but after adjusting that setting, you need to restart Mailman core, not gunicorn. If you are running a gunicorn service, that is what is providing WSGI support for Django (Postorius and/or HyperKitty). You may be using gunicorn for this or uWSGI or Apache mod_wsgi, but is any case, that is not the gunicorn we are considering here. Regardless of what you use to provide WSGI support for Django, Mailman core uses gunicorn to support the REST API, and that is the gunicorn affected by the settings in the gunicorn.cfg pointed to by [webservice] configuration: /opt/mailman/mm/gunicorn.cfg If, with the above configuration, you do `ps -fwwA|grep runner=rest` you will see something like: mailman 20582 20561 0 01:21 ? 00:00:16 /opt/mailman/mm/venv/bin/python /opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/deployment/mailman.cfg --runner=rest:0:1 mailman 20722 20582 0 01:21 ? 00:01:19 /opt/mailman/mm/venv/bin/python /opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/deployment/mailman.cfg --runner=rest:0:1 mailman 20725 20582 0 01:21 ? 00:01:18 /opt/mailman/mm/venv/bin/python /opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/deployment/mailman.cfg --runner=rest:0:1 mailman 20726 20582 0 01:21 ? 00:01:18 /opt/mailman/mm/venv/bin/python /opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/deployment/mailman.cfg --runner=rest:0:1 mailman 20727 20582 0 01:21 ? 00:01:50 /opt/mailman/mm/venv/bin/python /opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/deployment/mailman.cfg --runner=rest:0:1 The first of these, pid 20582, is Mailman's actual REST runner. The other 4 with parent pid 20582 are the 4 gunicorn worker processes forked from the REST runner. It's the REST runner or Mailman core that needs to be restarted to pick up that change. -- 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

Re: Upgrading other python packages than the mailman ones in a venv results in dependency conflicts

by Odhiambo Washington

On Mon, Dec 16, 2024 at 1:39 PM Ulf R. <ulf.rapphahn(a)offis.de> wrote: > Hello, > I know this should be the way to upgrade: > https://docs.mailman3.org/en/latest/upgrade-guide.html > I have 3.3.10 installed. > I saw that some python packages are outdated an tried this which install > all outdated packages in a row: > pip list --outdated --format=json | jq '.[].name' | xargs -n1 pip install > -U > One outdated package was django and this part happened: > ------------------------------- > vDownloading Django-5.1.4-py3-none-any.whl (8.3 MB) > Installing collected packages: Django > Attempting uninstall: Django > Found existing installation: Django 4.2.16 > Uninstalling Django-4.2.16: > Successfully uninstalled Django-4.2.16 > ERROR: pip's dependency resolver does not currently take into account all > the packages that are installed. This behaviour is the source of the > following dependency conflicts. > hyperkitty 1.3.12 requires django<5.1,>=4.2, but you have django 5.1.4 > which is incompatible. > mailman-web 0.0.9 requires django<4.3,>=4.0, but you have django 5.1.4 > which is incompatible. > postorius 1.3.13 requires django<5.1,>=4.2, but you have django 5.1.4 > which is incompatible. > django-mailman3 1.3.15 requires django<5.1,>=4.2, but you have django > 5.1.4 which is incompatible. > Successfully installed Django-5.1.4 > ------------------------------- > > So I made a roll back. > > Is this really the only secure way to update the venv?: > pip install -U mailman postorius django-mailman3 hyperkitty mailman-web > Correct! > May be yes and I have to ignore the rest? ;-) > Yes. Let them pull their own versions of dependencies. -- 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]

1 year, 9 months

Mailman-users search results for query "Postorius"