Search results for "Postorius" - Mailman-users

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

5 years, 3 months

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

4 years, 1 month

Re: Postorius confirmation mails shown in uwsgi-error.log but not sent

by Abhilash Raj

On Mon, Mar 30, 2020, at 5:33 AM, Ralph Seichter wrote: > * Mark Sapiro: > > >> $ grep ^EMAIL settings.py > >> EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend' > >> EMAIL_HOST = 'localhost' > >> EMAIL_PORT = 25 > > > > but is this perhaps overridden in a settings_local.py file? > > I don't have a local settings file. I cloned the suite from GitLab[1] > master branch and modified the existing settings.py, based on Mailman's > documentation. > > [1] https://gitlab.com/mailman/mailman-suite.git > > I just verified that EMAIL_BACKEND is not redefined anywhere: > > $ grep -r 'mail\.backends' . > Binary file ./__pycache__/settings.cpython-38.pyc matches > ./settings.py:EMAIL_BACKEND = > 'django.core.mail.backends.smtp.EmailBackend' > ./settings.py:# EMAIL_BACKEND = > 'django.core.mail.backends.filebased.EmailBackend' > > I commented out the "if DEBUG == True" lines, which explains match > number three. As far as I can see, the mail backed definition for Django > is as it should be. > > I could provide the differences between my settings.py and the Git HEAD > version if you think that might help. It definitely would help if you paste the diff of the settings required. Also, can you jump into a django shell and see if you can get any exceptions trying to send emails: $ python manage.py shell >>> from django.core.mail import send_mail >>> send_mail( 'Subject here', 'Here is the message.', 'from(a)example.com', ['to(a)example.com'], fail_silently=False, ) I picked it up from the Django's docs and perhaps fail_silently=False would give some exceptions. Please make sure you tail the logs for any connections. Abhilash > > -Ralph > _______________________________________________ > 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)

5 years, 6 months

Re: Postorius no connection to REST API

by Stephen J. Turnbull

Richard, Thanks for the details and the pointer to the full configs. That makes it possible to take a look, but I can't spend much time on it until next week. I'll see if I can prod Abhilash who is more expert than I on all this stuff (I just use mod_wsgi), but there's some more urgent (sorry, but it's security) stuff going on, and his absence speaks for his $DAYJOB, I guess. Richard Rosner writes: > That is entirely possible @Stephen. You can see the entire apache config a few posts back plus the additions from @Mark and mine from the last post. As I interpret it, apache is reverse proxying to the uwsgi app, now through http instead of the socket. But I have no idea if that's the right way round. I'm not sure is the config file templates for apache, nginx and uwsgi that you get with the Debian packages are added by the Debian team or if they are there any way and just have been modified to the Debian file layout, but I'd guess either way it's not that likely that they wrote it the wrong way around. But I'm not too experienced to be able to translate the nginx config to apache to see if that would result in something different. > > Also, while the nginx config is written as a standalone website, the apache config seems to have been written to just create a /mailman3 site under an existing website, while I use it as a standalone site. So it's entirely possible that I missed something when I modified the website from mailman2 to serve mailman3, but then it shouldn't have been able to show the website at the beginning. > _______________________________________________ > 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/ > >

4 years, 2 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

5 years, 4 months

Re: django request error

by Simon Brown

Are you on Ubuntu 20.04 with Apache2? It looks like the same problem I had, see my message to the list. Try removing the trailing / on localhost on the uwsgi ProxyPass line in apache.conf ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/ becomes ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost Simon On Thursday, 30 September 2021 16:58:09 CEST tibor.molnar(a)waltoninstitute.ie wrote: > I recently got postorius web interface stopped with an error, from web log: > WARNING 2021-09-29 14:46:47,071 39320 django.request Not Found: > /mailman//postorius/lists/ from website: This page either doesn't exist, or > it moved somewhere else. I wonder what would be the source of this error / > anyone else experienced this error since I haven't changed anything. > > Regards, > Tibor > _______________________________________________ > 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/ -- Simon Brown System Engineer EISCAT Scientific Association P. O. Box 812, SE-981 28 Kiruna, Sweden simon.brown(a)eiscat.se

4 years

Re: Archiver "prototype" and disabling archiving at all

by Abhilash Raj

On Thu, Mar 28, 2019, at 9:18 AM, Torge Riedel wrote: > Am 24.03.19 um 16:49 schrieb Mark Sapiro: > > On 3/24/19 5:40 AM, Torge Riedel wrote: > >> in the settings of a mailing list I can choose two archivers: > >> "Hyperkitty" and "prototype". What is this archive "prototype" and how > >> can I disable/remove/deinstall it? And how can I disable archiving at > >> all, so no archiver can be chosen in the settings. > > > > The prototype archiver stores messages individually in > > var/archives/prototype/LIST_NAME/. > > > > You can disable the prototype archiver by putting > > > > [archiver.prototype] > > enable: no > > > > in your mailman.cfg. To disable all archiving, just remove all the > > [archiver.*] sections from your mailman.cfg or set them to 'enable: no' > > > > > Hi Mark, > > thanks. This disabled the archivers, but there is still the "Archives" > link on top of the page. Is it possible to remove it? Cause there is > nothing to see there. I tried commenting "'hyperkitty'," in > INSTALLED_APPS, but then I got a 500. INSTALLED_APPS = ( 'postorius', 'django_mailman3', # Uncomment the next line to enable the admin: 'django.contrib.admin', # Uncomment the next line to enable admin documentation: # 'django.contrib.admindocs', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.messages', 'django.contrib.staticfiles', 'django_gravatar', 'allauth', 'allauth.account', 'allauth.socialaccount', ) This is how it should look like if you want to remove Hyperkitty. There are a few other settings you should remove. https://gitlab.com/mailman/postorius/blob/master/example_project/settings.py This is a Postorius only configuration for reference. > _______________________________________________ > 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, 6 months

Re: where is manage.py for migration?

by Mark Sapiro

On 11/26/20 6:50 AM, Dan Langille wrote: > Hello, > > I am following https://docs.mailman3.org/en/latest/migration.html and I'm trying to "Migrate the list archives from Mailman 2 to Mailman 3 by running the following command": > > [mailman@mailman ~]$ python manage.py hyperkitty_import -l biking(a)lists.example.org /usr/local/mailman/archives/private/biking.mbox > python: can't open file 'manage.py': [Errno 2] No such file or directory > > Is the documentation correct? I cannot locate manage.py in the code: That refers to the Django manage.py script. It's name and location depends on how you installed Postorius and HyperKitty. Have you installed those and set up a Django project? There are sample manage.py files in both postorius/example_project/ and hyperkitty/example_project/ as well as mailman-suite/mailman-suite_project/, however, depending on how things are installed, the Django admin interface could be named manage.py, django-admin or something else. -- 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: Apache shows No Lists

by Mark Sapiro

On 5/22/23 14:48, ceo(a)sartrack.nz wrote: > Thanks; > There has never been a 'Mailman' user. I do have a www-data user (all Apache2 data' and there is a 'list' user. So what I refer to as the Mailman user (a generic term) is `list` in your case. > I may have run the import fuction as root, but I then used chown() to set the directory tree /var/lib/mailman3/* to user 'list'. OK > So I upgraded Debian 10 to Debian 11. > This also upgraded Apache2 I assume, but I kept the original (single) config file. > > I then installed the whole Mailman3 package with 'apt'. I may also have installed additional missing bits afterwards, as I think it was not complete. I initially tried to use MariaDB but the installation failed completly because it never asked for the MariaDB root password, and as a result of that everyting else failed too. > Then I un-installed 5 times, and then I finally went for the 'default' database system. > > I then edited the file with the recommended settings for Mailman3: > Alias /mailman3/favicon.ico /var/lib/mailman3/web/static/postorius/img/favicon.ico > Alias /mailman3/static /var/lib/mailman3/web/static > > <Directory "/var/lib/mailman3/web/static"> > Require all granted > </Directory> > > <IfModule mod_proxy_uwsgi.c> > ProxyPass /mailman3/favicon.ico ! > ProxyPass /mailman3/static ! > ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/ > </IfModule> > > So clearly Apache2 manages to access the data supplied by Postorius because it sees the lists (at least the empty ones). > -What user should the whole system running under: 'list'? of 'www-data'? > - Is there anything else I should tell Apache2? All the web based stuff is a Django application. Django is run by uWSGI which probably runs as www-data, but Django only accesses hyperkitty, postorius and django-mailman3 and other Django related tables in the database. It doesn't need access to file system files other than things like wsgi.py, urls.py, settings.py and settings_local.py and only read access to these. All the mailman3 file system stuff has to be read/write/searchable by `list`. > Now I tried to use "django-admin createsuperuser". This also fails because of this error: > ImportError: cannot import name 'force_text' from 'django.utils.encoding' (/usr/local/lib/python3.9/dist-packages/django/utils/encoding.py) > And I cannot find where this 'force_text' is called from. It must be removed as it is too old. It seems your Django installation is broken. Do cd /usr/local/lib/python3.9/dist-packages/django grep -r force_text to find where force_text is called, or maybe add def force_text(s, encoding='utf-8', strings_only=False, errors='strict'): return force_str(s, encoding, strings_only, errors) to /usr/local/lib/python3.9/dist-packages/django/utils/encoding.py -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 4 months

New releases

by Abhilash Raj

Hi Everyone, I am pleased to announce new stable releases for: - Postorius: 1.3.3 Changelog: https://docs.mailman3.org/projects/postorius/en/latest/news.html#id1 Download: https://pypi.org/project/postorius/1.3.3/ - Hyperkitty: 1.3.3 Changelog: https://hyperkitty.readthedocs.io/en/latest/news.html#id1 Download: https://pypi.org/project/HyperKitty/1.3.3rc1/ - Mailmanclient: 3.3.1 Changelog: https://docs.mailman3.org/projects/mailmanclient/en/latest/src/mailmanclien… Download: https://pypi.org/project/mailmanclient/3.3.1/ - Django-mailman3: 1.3.3 Changelog: https://gitlab.com/mailman/django-mailman3/-/blob/master/README.rst Download: https://pypi.org/project/django-mailman3/1.3.3 Python 3.6+ and Django 2.0+ is supported for all of them. Django 3.0 support for Hyperkitty requires manually upgrading a dependency (django-haystack>=3.0b2, once a stable version of this has been released, it shouldn't require manually upgrading). There are tons of bug-fixes across the board and some new features. Biggest visible change is switch to Bootstrap 4, which has been long pending for us. Bootstrap 4 completely changes the CSS grid model using the new Flexbox. There might be some small changes or breakages when using on mobile. Please report such issues to us via Gitlab! Some other notable changes are in Postorius, which includes many more list settings exposed include content filtering settings, bounce processing (which was added in the previous release of Mailman Core) settings and some other ones. Settings page is also slightly different with all the sections on the vertical menu on left instead of horizontal tabs. You can now also specify a reason when rejecting held messages. There was also a gnarly bug, which caused the name of some members to be the string "None". For the longest time, I couldn't figure out the reason for it, but it ended up being a simple fix in mailmanclient's json serialization of display_name, which would result in Python's None value being passed as string "None" to Mailman's API for subscription. There is also better support for filtering visible lists based on the current vhost, which I see a few people are already waiting for from mailman-users list. A full changelog has been added to each project in the top. -- thanks, Abhilash Raj (maxking)

5 years, 4 months

Mailman-users search results for query "Postorius"