Re: multiple sites on a mailman3 server question
by David Newman
> On Dec 29, 2021, at 08:49, William Oliver <billo(a)billoblog.com> wrote:
>
> On Tue, 2021-12-28 at 18:23 -0800, David Newman wrote:
>>>
>>> [snip]
>>> I'm using nginx
>> I'd asked about this a few weeks ago for a MM3 host running Ngnix
>> with a
>> few virtual domains, one of which runs Roundcubemail as its default.
>>
>> Mark Sapiro suggested the following, and it seems to be working OK.
>> You'll need these lines in the Nginx config file for each virtual
>> host
>> you define.
>>
>> # begin mailman3 stuff
>>
>> location /static/ {
>> alias /opt/mailman/web/static/;
>> }
>>
> [snip]
>
>
>
> No joy. This just makes it kind of work as the mailman interface when
> it gets rewritten.
>
> My problem is that the url is getting referred to
> domainname/mailman3/lists even when I don't want it to.
That sounds like an nginx configuration problem, not a Mailman3 issue.
One assumption in the MM3 web setup docs is that MM3/Django/Postorius/Hyperkitty are the only web services running. If they’re not, and there are other services running, you’ll need to tell Nginx where they are.
The setup I provided is an excerpt and covers only how to point to MM3 in such a scenario. It does not cover how to point to something else as root at, say, www.domain.tld.
This is off-topic for a Mailman3 list, but maybe check your default files in the sites-available directory, and also anything they point to, paying particular attention to where / points and which root directory you’re using. Same thing with any other config files in that directory.
dn
> Adding these
> changes just (partially) loads the mailman3 interface when it gets
> rewritten.
>
> What I'm trying to figure out is where uwsgi yanks control from nginx
> and does the rewriting. Pulling that proxypass stuff out will stop
> mailman3 from coming up, and adding it allows mailman3 to show its
> interface, but the address gets referred regardless.
>
> Somehow I need to tell uwsgi to ignore www.domain.com *or* somehow tell
> nginx not to push it to port 8000. But I don't see where nginx is
> getting told to go to 8000 in the www.domain.com section.
>
> billo
>
>
>
>
>
>
> _______________________________________________
> 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/
3 years, 6 months
Re: [Django] ERROR (EXTERNAL IP): Internal Server Error: /hyperkitty/list/direttivo@catania.linux.it/top-threads
by Abhilash Raj
On Sun, Feb 28, 2021, at 10:17 AM, blackout69 wrote:
> Hello everybody,I received this error message and from that moment the
> maiilan3 has stopped working.I restarted the following services mailman3
> and mailman3-web and everything started working fine.Can you tell me
> what is the problem my django server has encountered?
What version of Hyperkitty are you running? It might be useful to include the versions of all the related Mailman packages, including: hyperkitty, django-mailman3, mailmanclient.
> Internal Server Error:
> /hyperkitty/list/direttivo(a)catania.linux.it/top-threads
>
> DoesNotExist at /hyperkitty/list/direttivo(a)catania.linux.it/top-threads
> Thread matching query does not exist.
>
> Request Method: GET
> Request URL:
> https://lists.catania.linux.it/hyperkitty/list/direttivo@catania.linux.it/t…
> Django Version: 1.11.29
> Python Executable: /usr/bin/uwsgi-core
> Python Version: 3.7.3
> Python Path: ['.', '', '/usr/lib/python37.zip', '/usr/lib/python3.7',
> '/usr/lib/python3.7/lib-dynload',
> '/usr/local/lib/python3.7/dist-packages',
> '/usr/lib/python3/dist-packages']
> Server time: Ven, 26 Feb 2021 20:10:53 +0100
> Installed Applications:
> ('hyperkitty',
> 'postorius',
> 'django_mailman3',
> 'django.contrib.admin',
> 'django.contrib.auth',
> 'django.contrib.contenttypes',
> 'django.contrib.sessions',
> 'django.contrib.sites',
> 'django.contrib.messages',
> 'django.contrib.staticfiles',
> 'rest_framework',
> 'django_gravatar',
> 'compressor',
> 'haystack',
> 'django_extensions',
> 'django_q',
> 'allauth',
> 'allauth.account',
> 'allauth.socialaccount')
> Installed Middleware:
> ('django.contrib.sessions.middleware.SessionMiddleware',
> 'django.middleware.common.CommonMiddleware',
> 'django.middleware.csrf.CsrfViewMiddleware',
> 'django.middleware.locale.LocaleMiddleware',
> 'django.contrib.auth.middleware.AuthenticationMiddleware',
> 'django.contrib.messages.middleware.MessageMiddleware',
> 'django.middleware.clickjacking.XFrameOptionsMiddleware',
> 'django.middleware.security.SecurityMiddleware',
> 'django_mailman3.middleware.TimezoneMiddleware',
> 'postorius.middleware.PostoriusMiddleware')
>
>
> Traceback:
>
> File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py"
> in inner
> 41. response = get_response(request)
>
> File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in
> _get_response
> 187. response =
> self.process_exception_by_middleware(e, request)
>
> File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in
> _get_response
> 185. response = wrapped_callback(request,
> *callback_args, **callback_kwargs)
>
> File "/usr/lib/python3/dist-packages/hyperkitty/lib/view_helpers.py" in
> inner
> 134. return func(request, *args, **kwargs)
>
> File "/usr/lib/python3/dist-packages/hyperkitty/views/mlist.py" in
> overview_top_threads
> 196. 'threads': mlist.top_threads,
>
> File "/usr/lib/python3/dist-packages/hyperkitty/models/mailinglist.py"
> in top_threads
> 157. return self.cached_values["top_threads"]()
>
> File "/usr/lib/python3/dist-packages/hyperkitty/models/common.py" in
> __call__
> 59. return self.get_or_set(*args, **kwargs)
>
> File "/usr/lib/python3/dist-packages/hyperkitty/models/mailinglist.py"
> in get_or_set
> 365. return [Thread.objects.get(pk=pk) for pk in thread_ids]
>
> File "/usr/lib/python3/dist-packages/hyperkitty/models/mailinglist.py"
> in <listcomp>
> 365. return [Thread.objects.get(pk=pk) for pk in thread_ids]
>
> File "/usr/lib/python3/dist-packages/django/db/models/manager.py" in
> manager_method
> 85. return getattr(self.get_queryset(), name)(*args,
> **kwargs)
>
> File "/usr/lib/python3/dist-packages/django/db/models/query.py" in get
> 380. self.model._meta.object_name
>
> Exception Type: DoesNotExist at
> /hyperkitty/list/direttivo(a)catania.linux.it/top-threads
> Exception Value: Thread matching query does not exist.
> Request information:
> USER: blackout69
>
> GET: No GET data
>
> POST: No POST data
>
> FILES: No FILES data
>
> COOKIES:
> csrftoken =
> 'tqNIiLrMWyYNHYhkmnmQfjRdd0AtCeCAAW46VOL24wk2g7Opl5LSZWB2dZ2p79Sb'
> sessionid = 'brhb9jd3ko9blnluuc6bz3c1627u6h22'
>
> META:
> CONTENT_LENGTH = ''
> CONTENT_TYPE = ''
> CSRF_COOKIE =
> 'tqNIiLrMWyYNHYhkmnmQfjRdd0AtCeCAAW46VOL24wk2g7Opl5LSZWB2dZ2p79Sb'
> DOCUMENT_ROOT = '/usr/share/nginx/html'
> HTTPS = 'on'
> HTTP_ACCEPT = 'text/html, */*; q=0.01'
> HTTP_ACCEPT_ENCODING = 'gzip, deflate, br'
> HTTP_ACCEPT_LANGUAGE = 'it-IT'
> HTTP_COOKIE =
> 'csrftoken=tqNIiLrMWyYNHYhkmnmQfjRdd0AtCeCAAW46VOL24wk2g7Opl5LSZWB2dZ2p79Sb;
> sessionid=brhb9jd3ko9blnluuc6bz3c1627u6h22'
> HTTP_HOST = 'lists.catania.linux.it'
> HTTP_REFERER =
> 'https://lists.catania.linux.it/hyperkitty/list/direttivo@catania.linux.it/'
> HTTP_TE = 'trailers'
> HTTP_USER_AGENT = 'Mozilla/5.0 (Android 11; Mobile; rv:86.0) Gecko/86.0
> Firefox/86.0'
> HTTP_X_REQUESTED_WITH = 'XMLHttpRequest'
> PATH_INFO = '/hyperkitty/list/direttivo(a)catania.linux.it/top-threads'
> QUERY_STRING = ''
> REMOTE_ADDR = '2.38.155.170'
> REMOTE_PORT = '39208'
> REQUEST_METHOD = 'GET'
> REQUEST_SCHEME = 'https'
> REQUEST_URI = '/hyperkitty/list/direttivo(a)catania.linux.it/top-threads'
> SCRIPT_NAME = ''
> SERVER_NAME = 'lists.catania.linux.it'
> SERVER_PORT = '443'
> SERVER_PROTOCOL = 'HTTP/2.0'
> uwsgi.core = 1
> uwsgi.node = b'glugct.catania.linux.it'
> uwsgi.version = b'2.0.18-debian'
> wsgi.errors = <_io.TextIOWrapper name=2 mode='w' encoding='UTF-8'>
> wsgi.file_wrapper = ''
> wsgi.input = <uwsgi._Input object at 0x7f0e65582f00>
> wsgi.multiprocess = False
> wsgi.multithread = True
> wsgi.run_once = False
> wsgi.url_scheme = 'https'
> wsgi.version = '(1, 0)'
>
>
> Thank you in advance
>
> --
> blackout69
>
> _______________________________________________
> 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)
4 years, 4 months
Re: The future is here?
by Abhilash Raj
On Thu, Jan 7, 2021, at 8:18 PM, Stephen J. Turnbull wrote:
> Jonathan M writes:
> > On 6 Jan 2021, at 04:25, Stephen J. Turnbull
> <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote:
> > >
> > > But do be aware that you probably do have
> > > to make a choice between a quagmire of options and mandating a
> > > particular stack (or small set of them) for simplicity.
> >
> >
> > It would be good if Mailman could do what Discourse do here.
>
> Discourse is a different kettle of fish. They concentrate on the much
> more straightforward (from a network and interapp communication
> configuration standpoint) web service because that's what their users
> expect. Mail is a lot more baroque from that standpoint.
>
> We shouldn't hope to successfully "encourage" hosts to do things our
> way. Eg, I run Exim4 because that's what I've always done and because
> I'm familiar with its spam-filtering, performance-tuning, and security
> controls: I'm not going to switch to Postfix just because that's the
> most common configuration. Similar considerations apply to webserver
> and RDBMS (for other people; I'm comfortable with Apache and
> PostgreSQL). It's not just a matter of "tweaking the expert options".
>
> As far as I can see, the best we can do is what Abhilash has already
> done: provide a full turnkey system in a container or a Vagrant-style
> VM. But that has its issues, too.
The containers are a good way to get Mailman Running, but it does require some additional setup including web servers and mta. There is scope for a lot of improvement in the container setup to be more "turnkey" and my time has been split between maintaining Mailman itself and $work that container setup hasn't gotten much attention beyond version updates for new releases.
If someone familiar with Containers would like to help out, there are open issues[1] that could make lives of some people installing a bit easy.
[1]: https://github.com/maxking/docker-mailman/issues
>
> If somebody wants to prove me wrong, feel free. But my assessment is
> that there are much better uses of core developer time than chasing a
> one-size-fits-all configuration. A suite of scripts or better yet
> Ansible (etc) roles is a better fit for Mailman's audience, I think.
>
> Steve
> _______________________________________________
> 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)
4 years, 5 months
Re: Error on timeout vs retry values
by Robert Moody
Thanks I will give that a go a bit later today and see what happens.
Get BlueMail for Android
On 19 Jul 2021, 07:34, at 07:34, Abhilash Raj <maxking(a)asynchronous.in> wrote:
>
>
>On Sat, Jul 17, 2021, at 11:23 PM, Robert Moody wrote:
>> Hi everyone,
>>
>> I have recently setup a new mailman3 service using the venv method.
>> Everything is functionally working however I keep getting an error
>sent
>> to the mailman email every min which I can not seem to figure out
>why.
>>
>> /opt/mailman/venv/lib/python3.7/site-packages/django_q/conf.py:142:
>> UserWarning: Retry and timeout are misconfigured. Set retry larger
>than
>> timeout,
>> failure to do so will cause the tasks to be retriggered
>before
>> completion.
>> See
>> https://django-q.readthedocs.io/en/latest/configure.html#retry for
>details.
>> See https://django-q.readthedocs.io/en/latest/configure.html#retry
>
>> for details."""
>>
>> I have edited the timeout and retry values in the
>> /opt/mailman/venv/lib/python3.7/site-packages/django_q/conf.py file
>and
>> restarted both mailman and mailman-web however this still keeps
>repeating.
>
>You shouldn't edit files in `site-packages` directory as they are part
>of the package itself and could cause issues.
>
>What you want to do is override it in your settings.py (or
>settings_local.py) file
>for Django. I am not sure which guide you followed to install Mailman,
>but it
>should be somewhere in /opt/mailman/ I suppose (not in venv/ for sure).
>
>
>It should look something like this
>
>https://mailman-web.readthedocs.io/en/latest/settings.html#mailman_web.sett…
>
>Just the value of retry should be just > than timeout as the error
>says, so
>not necessarily same values, but so far 300 and 360 has been working
>good for us and I haven't seen any report to increase them.
>
>
>>
>> Any ideas?
>>
>> Regards,
>>
>> Robert
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>> _______________________________________________
>> 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)
>_______________________________________________
>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/
3 years, 11 months
Re: Internal server errors after upgrade
by Seth Seeger
On Oct 28, 2021, at 6:45 PM, Abhilash Raj <maxking(a)asynchronous.in> wrote:
>
>> On Oct 26, 2021, at 10:33 AM, Seth Seeger <seth(a)tofutavern.com> wrote:
>>
>> Hello community,
>>
>> I'm running the Docker version of MM3. I've just run:
>>
>> docker-compose stop
>> docker-compose pull
>> docker-compose up -d
>>
>> I am now at versions:
>>
>> mailman-core: 3.3.4
>> mailman-web: 2.2.20
>
> You probably want to look at instructions on updating to newer versions:
>
> https://asynchronous.in/docker-mailman/news/#upgrading-to-040-release
I shall - thank you. Interestingly, my system is running just fine without any of those changes, but I will carefully look through them.
> Also, not sure how you got mailman-web 2.2.20, the latest version is 0.0.5[1] and docker image doesn’t use the mailman-web package at all.
>
> [1]: https://pypi.org/project/mailman-web/
$ sudo docker exec -u mailman mailman-web ./manage.py version
2.2.20
>> I am running a 2-core, 4GB RAM VM on Linode.
>>
>> The web interface mostly works. However, sometimes/regularly I get a 500 Internal Server Error. In /opt/mailman/core/var/logs/mailman.log I see the errors, but they are usually different. The common thread seems they are always about some sort of database call. Reloading the page is usually successful.
>>
>> Did anything change with the latest upgrade in terms of database timeouts? Before this upgrade, I was never getting it. (htop does not show anything unusual.)
>
> Can you share the actual errors you are seeing? If there are a lot of them, perhaps two three of them?
The errors have settled down to less than one-per-day. I'm guessing that my system was not quite powerful enough to handle web traffic on top of the start up process (that may have involved upgrade commands).
Each of the errors below was accompanied by an email. The error messages are from /opt/mailman/core/var/logs/mailman.log. (I'm happy to provide any more details of any of this.) The second one was more common (particularly the "'NoneType' object has no attribute '_getter'".
Seth
2021-10-28 14:45:02 [FALCON] [ERROR] GET /3.1/lists/xxx(a)xxxx.net => Traceback (most recent call last):
File "/usr/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 2336, in _wrap_pool_connect
return fn()
File "/usr/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 364, in connect
return _ConnectionFairy._checkout(self)
File "/usr/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 809, in _checkout
result = pool._dialect.do_ping(fairy.connection)
File "/usr/lib/python3.8/site-packages/sqlalchemy/engine/default.py", line 575, in do_ping
cursor.execute(self._dialect_specific_select_one)
psycopg2.DatabaseError: error with status PGRES_TUPLES_OK and no message from the libpq
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/lib/python3.8/site-packages/falcon/app.py", line 341, in __call__
responder, params, resource, req.uri_template = self._get_responder(req)
File "/usr/lib/python3.8/site-packages/falcon/app.py", line 886, in _get_responder
route = self._router_search(path, req=req)
File "/usr/lib/python3.8/site-packages/mailman/rest/wsgiapp.py", line 126, in find
result = attribute(context, segments)
File "/usr/lib/python3.8/site-packages/mailman/rest/root.py", line 227, in lists
return AList(list_identifier), segments
File "/usr/lib/python3.8/site-packages/mailman/rest/lists.py", line 189, in __init__
self._mlist = manager.get(list_identifier)
File "/usr/lib/python3.8/site-packages/mailman/database/transaction.py", line 85, in wrapper
return function(args[0], config.db.store, *args[1:], **kws)
File "/usr/lib/python3.8/site-packages/mailman/model/listmanager.py", line 64, in get
return (self.get_by_fqdn(list_spec)
File "/usr/lib/python3.8/site-packages/mailman/database/transaction.py", line 85, in wrapper
return function(args[0], config.db.store, *args[1:], **kws)
File "/usr/lib/python3.8/site-packages/mailman/model/listmanager.py", line 77, in get_by_fqdn
return store.query(MailingList).filter_by(
File "/usr/lib/python3.8/site-packages/sqlalchemy/orm/query.py", line 3429, in first
ret = list(self[0:1])
File "/usr/lib/python3.8/site-packages/sqlalchemy/orm/query.py", line 3203, in __getitem__
return list(res)
File "/usr/lib/python3.8/site-packages/sqlalchemy/orm/query.py", line 3535, in __iter__
return self._execute_and_instances(context)
File "/usr/lib/python3.8/site-packages/sqlalchemy/orm/query.py", line 3556, in _execute_and_instances
conn = self._get_bind_args(
File "/usr/lib/python3.8/site-packages/sqlalchemy/orm/query.py", line 3571, in _get_bind_args
return fn(
File "/usr/lib/python3.8/site-packages/sqlalchemy/orm/query.py", line 3550, in _connection_from_session
conn = self.session.connection(**kw)
File "/usr/lib/python3.8/site-packages/sqlalchemy/orm/session.py", line 1142, in connection
return self._connection_for_bind(
File "/usr/lib/python3.8/site-packages/sqlalchemy/orm/session.py", line 1150, in _connection_for_bind
return self.transaction._connection_for_bind(
File "/usr/lib/python3.8/site-packages/sqlalchemy/orm/session.py", line 433, in _connection_for_bind
conn = bind._contextual_connect()
File "/usr/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 2302, in _contextual_connect
self._wrap_pool_connect(self.pool.connect, None),
File "/usr/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 2339, in _wrap_pool_connect
Connection._handle_dbapi_exception_noconnection(
File "/usr/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 1583, in _handle_dbapi_exception_noconnection
util.raise_(
File "/usr/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 182, in raise_
raise exception
File "/usr/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 2336, in _wrap_pool_connect
return fn()
File "/usr/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 364, in connect
return _ConnectionFairy._checkout(self)
File "/usr/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 809, in _checkout
result = pool._dialect.do_ping(fairy.connection)
File "/usr/lib/python3.8/site-packages/sqlalchemy/engine/default.py", line 575, in do_ping
cursor.execute(self._dialect_specific_select_one)
sqlalchemy.exc.DatabaseError: (psycopg2.DatabaseError) error with status PGRES_TUPLES_OK and no message from the libpq
(Background on this error at: http://sqlalche.me/e/13/4xp6)
=============================================
2021-10-26 19:39:54 [FALCON] [ERROR] GET /3.1/users/xxxx(a)xxx.com => Traceback (most recent call last):
File "/usr/lib/python3.8/site-packages/sqlalchemy/engine/result.py", line 779, in _getter
getter = self._metadata._getter
AttributeError: 'NoneType' object has no attribute '_getter'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/lib/python3.8/site-packages/falcon/app.py", line 361, in __call__
responder(req, resp, **params)
File "/usr/lib/python3.8/site-packages/mailman/rest/users.py", line 208, in on_get
if self._user is None:
File "/usr/lib/python3.8/site-packages/mailman/rest/users.py", line 195, in _user
return user_manager.get_user(self._user_identifier)
File "/usr/lib/python3.8/site-packages/mailman/database/transaction.py", line 85, in wrapper
return function(args[0], config.db.store, *args[1:], **kws)
File "/usr/lib/python3.8/site-packages/mailman/model/usermanager.py", line 85, in get_user
address = self.get_address(email)
File "/usr/lib/python3.8/site-packages/mailman/database/transaction.py", line 85, in wrapper
return function(args[0], config.db.store, *args[1:], **kws)
File "/usr/lib/python3.8/site-packages/mailman/model/usermanager.py", line 141, in get_address
return store.query(
File "/usr/lib/python3.8/site-packages/sqlalchemy/orm/query.py", line 3459, in one_or_none
ret = list(self)
File "/usr/lib/python3.8/site-packages/sqlalchemy/orm/loading.py", line 100, in instances
cursor.close()
File "/usr/lib/python3.8/site-packages/sqlalchemy/util/langhelpers.py", line 68, in __exit__
compat.raise_(
File "/usr/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 182, in raise_
raise exception
File "/usr/lib/python3.8/site-packages/sqlalchemy/orm/loading.py", line 58, in instances
*[
File "/usr/lib/python3.8/site-packages/sqlalchemy/orm/loading.py", line 59, in <listcomp>
query_entity.row_processor(query, context, cursor)
File "/usr/lib/python3.8/site-packages/sqlalchemy/orm/query.py", line 4422, in row_processor
_instance = loading._instance_processor(
File "/usr/lib/python3.8/site-packages/sqlalchemy/orm/loading.py", line 421, in _instance_processor
getter = result._getter(col, False)
File "/usr/lib/python3.8/site-packages/sqlalchemy/engine/result.py", line 781, in _getter
return self._non_result(None, err)
File "/usr/lib/python3.8/site-packages/sqlalchemy/engine/result.py", line 1236, in _non_result
util.raise_(
File "/usr/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 182, in raise_
raise exception
sqlalchemy.exc.ResourceClosedError: This result object does not return rows. It has been closed automatically.
3 years, 8 months
Re: Struggle on upgrading mailman3-web to new version - Not Found: /mailman//
by Eggert Ehmke
Hello Stefan,
I had the same problem. While I did not find the reason for this strange
behavior, I found a workaround. I changed the lines in the apache vhost file
like this:
<IfModule mod_proxy_uwsgi.c>
ProxyPass /mailman3/favicon.ico !
ProxyPass /mailman3/static !
ProxyPass /mailman unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/
</IfModule>
Note I only changed the single ProxyPass line from mailman3 to mailman. The
url to access the web gui also changes like this:
https://my.mailinglistserver.local/mailman/postorius/lists/
This works for me, tell us your success. Would be nice when the problem could
be solved finally, this happened to a few people.
Cheers, Eggert
Am Montag, 25. Oktober 2021, 10:45:50 CEST schrieb Stefan Bauer:
> Dear Users,
>
> I recently upraded mailman3 from Ubuntu 18 to 20. After accessing the
> web-interface via
>
> https://my.mailinglistserver.local/mailman3/postorius/lists/
>
> I receive
>
> Not Found: /mailman//postorius/lists/
> [pid: 1346851|app: 0|req: 4/4] 10.254.253.12 () {70 vars in 1369 bytes}
> [Mon Oct 25 10:39:59 2021] GET /mailman3/postorius/lists/ => generated 2821
> bytes in 12 msecs (HTTP/1.1 404) 5 headers in 155 bytes (1 switches on core
> 1)
>
> Where does the wrong path come from (mailman vs. mailman3)
>
> After enabling Debug, i see in the browser the following:
>
>
> Page not found (404)
> Request Method: GET
> Request URL: https://my.mailinglistserver.local/mailman//postorius/lists/
>
> Using the URLconf defined in urls, Django tried these URL patterns, in this
> order:
>
> ^$
> ^postorius/
> ^hyperkitty/
> ^user-profile/delete$ [name='mm_user_account_delete']
> ^user-profile/$ [name='mm_user_profile']
> ^accounts/
> ^admin/
>
> The current path, /postorius/lists/, didn't match any of these.
>
> You're seeing this error because you have DEBUG = True in your Django
> settings file. Change that to False, and Django will display a standard 404
> page.
>
> My apache configuration is very simply:
>
> # more /etc/apache2/conf-enabled/mailman3.conf
> 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>
>
> I dont see where the path gets traversed in the wrong way. Any help is
> greatly appreciated.
>
> thank you.
>
> Stefan
> _______________________________________________
> 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/
3 years, 8 months
Re: Installing mailman3 from Ubuntu 20.04 repository
by Matthew Alberti
I went thru this thought process when upgrading a midsized Mailman2 instance to Mailman3. It was a long and somewhat painful learning experience.
I recommend using the docker-mailman method and never looking back. A bug report was filed to the Ubuntu maintainer team for Mailman over a year ago. It hasn't been fixed. And even if it was to be fixed, it isn't known if it would apply to LTS versions.
I believe Debian was patched, but Ubuntu doesn't automatically pull from there.
Use docker-mailman. Or if you are very comfortable with python, perhaps the manual pip method.
Just my two cents.
- Matt Alberti
Get BlueMail for Android
On Aug 24, 2021, 8:31 AM, at 8:31 AM, Abhilash Raj <maxking(a)asynchronous.in> wrote:
>
>
>> On Aug 23, 2021, at 10:48 AM, Andy Cravens <acravens(a)uen.org> wrote:
>>
>> I’m testing Mailman3 on Ubuntu 20.04 and installing the packages from
>the default Ubuntu repo. I’m not sure I’ll perform the install this
>way once we move to production. I don’t know what group is responsible
>for keeping the Mainlam3 package in the Ubuntu repository up to date
>but I’d like to find out how committed that groups is to keeping the
>package current. We patch often and it would be convenient if the
>Mailman3 package is kept updated and current. If there is going to be
>some significant lag time I may decide to install manually when we go
>to production. Any thoughts on this?
>
>This isn’t responsible for maintaining Ubuntu packages, I am not sure
>who does. I may be completely wrong on this, but my understanding is
>that Ubuntu uses the packages from Debian directly and the Debian
>packaging team handles the packaging of Mailman which you can find the
>contact for here the package details [3].
>
>You can compare the current version in Ubuntu repos[1] with Mailman
>releases[2] to get an idea, but they usually lag behind a couple of
>versions.
>
>Having said that, from what I understand, the Debian packages for new
>versions of Mailman packages are built and made available pretty soon
>(unless there is an issue with a missing dependency or required a patch
>to get into Debian) after the release, even if they aren’t included in
>the Debian releases immediately.
>
>
>[1]: https://packages.ubuntu.com/focal/mailman3
>[2]: https://pypi.org/project/mailman/#history
>[3]: https://packages.debian.org/sid/mailman3-full
>
>
>--
>thanks,
>Abhilash Raj (maxking)
>
>
>_______________________________________________
>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/
3 years, 10 months
Re: missing graphics in Postorius
by David Newman
On 12/7/21 11:17 AM, Mark Sapiro wrote:
> On 12/6/21 10:15 PM, David Newman wrote:
>> After installing MM3 on Debian 10 using the venv docs, no graphics
>> appear in the admin or list pages, just broken links.
>>
>> The mailmanweb log has lines like this:
>>
>> ERROR 2021-12-07 06:04:10,002 18262 django.security.DisallowedHost
>> Invalid HTTP_HOST header: '127.0.0.1'. You may need to add '127.0.0.1'
>> to ALLOWED_HOSTS.
>>
>> which is odd because there is the line for "localhost" in settings.py,
>> and /etc/hosts correctly ties this to 127.0.0.1.
>
>
> Add '127.0.0.1' to ALLOWED_HOSTS anyway.
Done, thanks.
Given that DNS works fine on this host, with localhost and 127.0.0.1
resolving backward and forward, this seems like a bug. Shouldn't the
resolver be able to recognize localhost without hard-coding an address?
Particularly this address, since the IETF is considering what is IMO a
crazy idea to unreserve 127/8?
https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
>
>
>> There are entries like this in /var/log/nginx/error.log saying the
>> files just aren't there:
>>
>> 2021/12/06 22:00:30 [error] 18123#18123: *65 open()
>> "/opt/mailman/web/static/postorius/img/mailman_logo_small_trans.png"
>> failed (2: No such file or directory), client: x.x.x.x, server:
>> somehost.example.com, request: "GET
>> /static/postorius/img/mailman_logo_small_trans.png HTTP/2.0", host:
>> "somehost.example.com", referrer:
>> "https://somehost.example.com/mailman/lists/"
>>
>> (I've obfuscated names and addresses here, but "somehost.example.com"
>> refers to a valid FQDN in the log.)
>>
>> I thought I'd followed all the venv docs, but the
>> /opt/mailman/web/static/postorius directory doesn't exist. Did I miss
>> something?
>
> Assuming you have
> ```
> STATIC_ROOT = '/opt/mailman/web/static'
> ```
> in your /etc/mailman3/settings.py file, you may need to create that
> directory if it doesn't exist. You shouldn't need to manually create the
> /opt/mailman/web/static/postorius directory if the
> /opt/mailman/web/static directory exists and is writable/searchable by
> the Mailman user.
Yes, that was it. Thanks.
Previously you'd pointed out what you considered an error in the venv
docs, with the workaround to manually create the /opt/mailman/web
directory [1]. I think the same issue applies here, and also that
/opt/mailman/web and subdirectories need to be owned by the mailman user.
Thanks again.
dn
>
> That should enable
> ```
> (venv)$ mailman-web collectstatic
> ```
> to populate that directory. Be sure you've run all four commands at
> https://docs.mailman3.org/en/latest/install/virtualenv.html#run-database-mi…
> et seq.
>
3 years, 6 months
Re: Postorius no connection to REST API
by Richard Rosner
Mark Sapiro wrote:
> > But whatever is listening on port 8001 is apparently not Mailman's rest
> server. What does
> ps -fww 14080
> or whatever PID is currently listening on port 8001 show.
UID PID PPID C STIME TTY STAT TIME CMD
list 15972 15963 0 Aug11 ? Sl 0:13 /usr/bin/python3 /usr/lib/mailman3/bin/runner -C /etc/mailman3/mailman.cfg --runner=rest:0:1
> > OK.
> Perhaps instead you should have
> uid: list
> gid: list
> in your uwsgi configuration if you don't already.
Tried that while also switching mailman3-web.service to list:list, exactly the same error. Also, I have /run/mailman3-web/uwsgi.sock owned by list:list now instead of www-data:www-data.
What the logs say:
*** Starting uWSGI 2.0.18-debian (64bit) on [Thu Aug 12 08:46:37 2021] ***
compiled with version: 8.2.0 on 10 February 2019 02:42:46
os: Linux-4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19)
nodename: mail
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 2
current working directory: /
detected binary path: /usr/bin/uwsgi-core
chdir() to /usr/share/mailman3-web
your processes number limit is 3831
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
error removing unix socket, unlink(): Permission denied [core/socket.c line 198]
bind(): Address already in use [core/socket.c line 230]
Not sure if that means the two directories need to be owned by list, currently they are owned by root
> > I'm not familiar enough with this form of ProxyPass using sockets to
> understand what the localhost:8001 does in this context, but uwsgi
> should not be doing anything with port 8001. In a configuration using
> TCP, it would listen on port 8000. Port 8001 is where Mailman's REST API
> server listens. uwsgi should receive connects in your case via the unix
> socket and then pass them to Django via the application in wsgi.py
> Also, you may want other paths proxied to uwsgi, namely at least some of
> hyperkitty, postorius, archives, accounts, admin and user-profile.
Ok, I removed that port again, now it's exctly like in the automatically generated config file.
And you mean like
<IfModule mod_proxy_uwsgi.c>
ProxyPass /mailman3/favicon.ico !
ProxyPass /mailman3/static !
ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/
ProxyPass /hyperkitty unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/
ProxyPass /postorius unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/
ProxyPass /admin unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/
ProxyPass /archives unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/
ProxyPass /accounts unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/
ProxyPass /user-profile unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/
</IfModule>
> > These should be 'list', not 'www-data'. That's your permissions issue on
> settings.py
3 years, 10 months
Re: Hipperkitty failing to archive messages in a list
by Guillermo Hernandez (Oldno7)
On 5/1/22 21:50, Mark Sapiro wrote:
First, thanks a lot Mark for your guidance.
>>
>> HINT: Configure the DEFAULT_AUTO_FIELD setting or the
>> SocialAccountConfig.default_auto_field attribute to point to a
>> subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
>
> This is from Django >=3.2 can be fixed by adding
>
> DEFAULT_AUTO_FIELD = 'django.db.models.AutoField'
>
> to your settings. This has been done in HyperKitty's
> example_project/settings.py for the not yet released 1.3.6 version.
>
> These warnings are only warnings, they aren't fatal.
I thought so. I've added it in the settings.py file.
In the last part of your suggestions you wrote:
"I suggest you do
pip install --upgrade hyperkitty mailman-hyperkitty
and ensure it installs hyperkitty 1.3.5 and mailman-hyperkitty 1.2.0"
But this is exactly what made me fall in this mess: I realized that the
versions of hiperkitty and mailman-hiperkitty in that server were
outdated.. and I tried update them separately, forgetting the saying
"if it works, don't touch it" (si funciona, no lo toques).
In my first message I listed the versions of all the items, but to
refresh it, as they are now:
(from pip list)
...
gunicorn 20.1.0
HyperKitty 1.3.5
...
mailman 3.3.5
mailman-hyperkitty 1.2.0
mailmanclient 3.3.3
...
mistune 2.0.1
...
mod-wsgi 4.7.1
...
postorius 1.3.6
(end of pip list)
I did the upgrade of all of it.
The "migration" process output the same warning as before about to doing
a "makemigration" (I did not this time)
Thinking that the problem in the "migrate" and "makemigration" process
could be that I touched the mistune/scanner.py to add escape and
escape_html imports, I deleted that two lines.
Then all went bad: the postorius list page didn't show anymore. The
error.log form the apache server shows
django.template.library.InvalidTemplateLibrary: Invalid template library
specified.
ImportError raised when trying to load 'hyperkitty.templatetags.decorate':
cannot import name 'escape_html' from 'mistune.scanner'
(/usr/local/lib/python3.7/site-packages/mistune/scanner.py)
So I tried to put them back (but I had problems with, I believe, the
__pychache__). I had to reinstall mistune and write back this lines that
I found in a previous thread from William Oliver last 12/28/21
I've finally came back to administering the lists via postorius.
I created a new list to do the tests without disturbing the rest. And
now I am at the exact same point: No message is archived and the log shows:
ERROR 2022-01-06 12:38:45,574 39059 hyperkitty.views.mailman The
MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header.
ERROR 2022-01-06 12:38:45,586 39059 hyperkitty.views.mailman The
MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header.
ERROR 2022-01-06 12:38:45,801 39059 hyperkitty.views.mailman The
MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header.
ERROR 2022-01-06 12:38:45,832 39059 hyperkitty.views.mailman The
MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header.
ERROR 2022-01-06 12:38:45,847 39059 hyperkitty.views.mailman The
MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header.
ERROR 2022-01-06 12:38:45,867 39059 hyperkitty.views.mailman The
MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header.
ERROR 2022-01-06 12:38:46,075 39059 hyperkitty.views.mailman The
MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header.
As this server has very low traffic, the emails are distributing well,
and the only thing that fails is the archiving of new messages, I will
wait until a more complete upgrading process is needed for mailman,
postorius or hiperkitty.
Thanks, again, for your support.
P.S.: One thing that make me curious is the "mistune" package... I don't
see it installed in the other servers that are working flawlessly with
mailman3.
>
> ...
>> Running a 'su -m mailman3 -c "python3 manage.py makemigrations" shows
>> the same warning listed before and some new errors:
>>
>> *-*-*-*-*-*-*
>>
>> Migrations for 'postorius':
>> /usr/local/lib/python3.7/site-packages/postorius/migrations/0017_alter_emailtemplate_name.py
>>
>> - Alter field name on emailtemplate
>> Traceback (most recent call last):
>> File "manage.py", line 10, in <module>
>> execute_from_command_line(sys.argv)
>> File
>> "/usr/local/lib/python3.7/site-packages/django/core/management/__init__.py",
>> line 419, in execute_from_command_line
>> utility.execute()
>> File
>> "/usr/local/lib/python3.7/site-packages/django/core/management/__init__.py",
>> line 413, in execute
>> self.fetch_command(subcommand).run_from_argv(self.argv)
>> File
>> "/usr/local/lib/python3.7/site-packages/django/core/management/base.py",
>> line 354, in run_from_argv
>> self.execute(*args, **cmd_options)
>> File
>> "/usr/local/lib/python3.7/site-packages/django/core/management/base.py",
>> line 398, in execute
>> output = self.handle(*args, **options)
>> File
>> "/usr/local/lib/python3.7/site-packages/django/core/management/base.py",
>> line 89, in wrapped
>> res = handle_func(*args, **kwargs)
>> File
>> "/usr/local/lib/python3.7/site-packages/django/core/management/commands/makemigrations.py",
>> line 190, in handle
>> self.write_migration_files(changes)
>> File
>> "/usr/local/lib/python3.7/site-packages/django/core/management/commands/makemigrations.py",
>> line 228, in write_migration_files
>> with open(writer.path, "w", encoding='utf-8') as fh:
>> PermissionError: [Errno 13] Permission denied:
>> '/usr/local/lib/python3.7/site-packages/postorius/migrations/0017_alter_emailtemplate_name.py'
>>
>>
>> *-*-*-*-*-*-*
>>
>> The file
>> '/usr/local/lib/python3.7/site-packages/postorius/migrations/0017_alter_emailtemplate_name.py'
>> does not exist at all
>
>
> makemigrations is trying to create that migration and you don't have
> permission to create the file. I don't know why it's trying to do
> that. Postorius 1.3.6 has migrations through
> 0016_auto_20210810_2157.py and shouldn't need more. To you have
> modificationd to Postorius?
>
>
>> Despite the error, I did a 'su -m mailman3 -c "python3 manage.py
>> compress"' and the subsequent "django-admin compilemessages" in
>>
>> /usr/local/lib/python3.7/site-packages/postorius, ../hyperkitty and
>> ../django_mailman3
>>
>> And the log continues showing the same error when trying archive a
>> new message.
>>
>> ERROR 2022-01-05 12:27:31,406 6988 hyperkitty.views.mailman The
>> MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header.
>> ERROR 2022-01-05 12:27:31,418 6988 hyperkitty.views.mailman The
>> MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header.
>> ERROR 2022-01-05 12:27:31,685 6988 hyperkitty.views.mailman The
>> MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header.
>> ERROR 2022-01-05 12:27:32,045 6988 hyperkitty.views.mailman The
>> MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header.
>> ERROR 2022-01-05 12:27:32,070 6988 hyperkitty.views.mailman The
>> MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header.
>> ERROR 2022-01-05 12:27:32,093 6988 hyperkitty.views.mailman The
>> MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header.
>
>
> These messages come from some HyperKitty version between commit
> b415d29d6cc59b3270c35b03ba3313dd03450271 Mon Jun 21 00:11:48 2021
> -0700 and
> commit c6272f3ef8375865382d0741d3d371a0dc41508a Fri Oct 8 06:32:06
> 2021 +0000
>
> They do not come from HyperKitty 1.3.5 but from something later than
> 1.3.4 which makes be think your mailman-hyperkitty version is not
> 1.2.0 either.
>
> I suggest you do
>
> pip install --upgrade hyperkitty mailman-hyperkitty
>
> and ensure it installs hyperkitty 1.3.5 and mailman-hyperkitty 1.2.0
>
>
--
___________________________________________
Mailman's content filtering has removed the
following MIME parts from this message.
Content-Type: image/png
Name: firma-GHP-emails.png
Replaced multipart/alternative part with first alternative.
3 years, 6 months