Re: Database deadlock when trying to delete a member.
by Abhilash Raj
Hi Simon,
> On Mar 17, 2021, at 10:16 PM, Simon Coggins <s.coggins(a)cqu.edu.au> wrote:
>
> Hi,
>
> I’ve got a strange error. I migrated from mailman 2.1 to 3 using the migration guide on the website and things have been working fine. But I’m in the process of testing the new syncmembers command to replace some inhouse mailman API code we wrote. I’ve tracked my problem down to what appears to be a deadlock in the postgresql database. When trying to delete certain users the SQL query hangs and never returns.
>
> After doing some tracing and tracking it down to the database, I enabled DB logging of all queries and saw that the following query was never returning:
>
> DELETE FROM member WHERE member.id = 166814
>
> If I try to run it manually I get the same issue, in psql it never returns.
> mailman=# explain analyze DELETE FROM member WHERE member.id = 166814;
> [… 60 seconds passes…]
> ^CCancel request sent
> ERROR: canceling statement due to user request
> CONTEXT: while deleting tuple (2998,72) in relation "member"
> I’m just wondering if there are any commands or scripts I can run to verify the database and it’s constraints to see if there is some error in the database data? Or where you’d recommend I go from here? It only impacts the user on this specific list. If I add this user to another list and remove them, everything works fine.
Are you able to retrieve that Member object using API?
This[1] the Python code which would try to delete a Member object and I
am assuming is being called from syncmembers command. I am not entire
sure about what would cause the database to hang, if there was some database
constraint that failed, I would imagine some error to be returned.
[1]: https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/model/member.p…
One thing you can try is see if you can unsubscribe the user using the API or
`mailman shell` command.
You can unsubscribe from API by calling a `DELETE` method at
http://localhost:9001/3.1/members/<member_id>
This would give us some indication about whether there is some bug
in the implementation of syncmembers command or if there is something
else going on.
>
> This is on a test system so I can do various testing. I’m trying to find the root cause so that I can verify my production system isn’t impacted by the same thing.
>
>
> Setup Details:
> OS: Oracle Linux 7 (Redhat)
> Installed using pip via virtualenv talking to a local pgsql database on the same box.
> Data was migrated from a mailman 2.1 install into mailman3 using migration instructions on the website.
>
> PIP Modules versions:
> django-mailman3 1.3.5
> mailman 3.3.3
> mailman-hyperkitty 1.1.0
> mailmanclient 3.3.2
> postorius 1.3.4
> psycopg2-binary 2.8.5
What is the version of sqlalchemy package? There is a new 1.4.0 version that came out recently
and is incompatible with Core right now. There are backwards incompatible changes which might
need some changes in Core to add support.
>
> RPM packages:
> postgresql12-12.6-1PGDG.rhel7.x86_64
> postgresql12-server-12.6-1PGDG.rhel7.x86_64
> postgresql12-libs-12.6-1PGDG.rhel7.x86_64
> postgresql12-devel-12.6-1PGDG.rhel7.x86_64
>
>
> -Simon
>
>
> _______________________________________________
> 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, 3 months
Re: upgrading in FreeBSD 13.1-p7: problem with aiosmtpd and lmtp runner
by Guillermo Hernandez (Oldno7)
El 2/4/23 a las 11:12, Odhiambo Washington escribió:
> On Sun, Apr 2, 2023 at 11:35 AM Guillermo Hernandez (Oldno7) via
> Mailman-users<mailman-users(a)mailman3.org> wrote:
>
>> It seems that FreeBSD is handling IPv6 in a way that other OSs dont. It
>> surprise me, because FreeBSD was the first OS where IPv6 was deployed,
>> but it is what it is.
>>
>> Thaks to everybody for your patience, specially Odhiambo and Mark.
>>
> @Guillermo Hernandez (Oldno7)<guillermo(a)querysoft.es>
>
> Thanks for the update. However, I don't think I would entirely blame
> FreeBSD for this. As Mark pointed out, something did not upgrade completely.
I'm NOT blaming any of the parts involved... Sure, most probably is my
fault. But the last upgrade shows that the process that fail is involved
with mailman upgrade. The last server was working smoothly and it has
higher traffic than the first I tried. It cannot be that I missed that
something was not working for weeks (since the last upgrade of the OS)
> This could be some quirk within your FreeBSD ports and you may need to
> ensure everything related to your Python version is updated.
It could be... but since a year ago I configured a poudriere repository
and Im updating from packages, not from ports. But this do not discards
your guess
> Why am I saying this?
> I am running MM3 in a virtualenv on FreeBSD (13.1-p6) and I did upgrade to
> the bleeding-edge MM3 by running all components from git, and I don't have
> this problem you had.
Not the same version exactly though. But similar enough
> Could you possibly fully update your Python libraries by following the
> entry dated 20220626 in /usr/ports/UPDATING? Could you run all the steps,
> do away with the workaround, and see if that fixes the issue?
I switched to python 3.9 in early 2022 (or it could be 2021?), that
updating point is not applicable here. All my python apps are 3.9. And
therefore it would not explain why a server which was working perfectly
before this mailman3 upgrade, was falling in this strange IPv6 problem
after.
>
> PS: I don't even think many people are running MM3 on FreeBSD, leave alone
> from the ports.
Well... leaving FreeBSD for apparently greener paths in my servers is
not something I'm planning to do. They are running some FreeBSD version
since 1993... and then, they are working. I'm not running MM3 from the
ports, I installed every bit of it from python tools.
> I have come to learn that even in Linux, using the distro's
> packages is usually problematic.
Again, I don't install from any distro package
> Running MM3 from virtualenv is quite safe and to be honest, you can migrate
> your setup from where it is now to a virtualenv and you will not lose
> anything.
And I cannot deny it... but I'm already under one layer of
virtualization... the mailman servers run in a jail environment. I don't
want to add more layers if I can avoid it.
Thank you very much for your pointings.
Regards
>
--
___________________________________________
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.
2 years, 3 months
Re: How To Install Mailman 3 on Debian 10 (Complete Guide)
by Lars Schimmer
On 02/03/2021 19:20, Mark Dadgar wrote:
>> As someone who is stuck using the ancient version of mailman3 in debian, I have to disagree. 99.9999% of the time I hit an issue, it turns out it was fixed years ago, but because I use the debian maintained version, I don't have those fixes. It's horrible.
So, why does someone not care about the debian package to fix that bugs?
It is possible, and is done by other packages every day.
> +100
>
> I originally installed mailman3 via the ubuntu packages and I eventually replaced that setup (read: paid Brian to re-install mailman3 “correctly") for 2 key reasons:
>
> 1) The ubuntu (and presumably debian) packages are 1+ years out of date - Quanah is correct in that most of the bugs you hit have been fixed already but haven’t made it through the package maintainer process yet.
Just being 1+ years old does not tell you a software is bad or not
useable. Thats a nonce.
Bugs shoudl be iron out with package fixes, if someone cares about.
New versions are out, needs to be tested.
> 2) The package installs are non-standard with respect to the way the mailman3 community tends to install them, which makes getting support here on this list much, much harder. You can see evidence of that periodically when someone asks a question and Mark’s response starts with “I’m not entirely sure how the <distro> package sets things up, but …”, which is no slight on Mark because he has his hands full with mm3 already and tracking every distro install layout is just not going to happen. It also means that the official mm3 docs don’t match what came out of your package. It’s just not good all the way around.
Sure, every software has its own scheme, but sthats what standards are
for. I still cannot switch easy between fedora, debian and other distros
due to different standards on file path. It is a nightmare.
Thats why I like to stay with 1 standard for all softeare packages on
one system. I do not want to run 20 software distributions with 20 ways
of doing it the right waay (tm).
You are right, the dev of a software should mostly care about fixing
bugs, implementing new features and getting along with the software.
Implementing different ways of installing is just a side topic.
But someone should care about howto get the (useful) software to the
masses for using it. And that position should care about howto implement
the software good into the running distributions worldwide.
And for distributions with a very good way of using packages, it is a
nightmare to work beside the package manager just because the package is
rather not well maintained.
>> Distribution packages tend to be useful for really basic things like libraries. For constantly evolving projects where you need to be current, they're more of a detriment.
>
> So much this.
You do not need a bleeding edge software on production servers. You just
need bug free, whihc is easy done with packages on distributions, if
maintainers do it well enough.
For a testing server bleeing edge maybe fine, but not in production.
> - Mark
> -----
> mark(a)pdc-racing.net | 408-348-2878
>
>
> _______________________________________________
> 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/
>
MfG,
Lars Schimmer
--
-------------------------------------------------------------
TU Graz, Institut für ComputerGraphik & WissensVisualisierung
Tel: +43 316 873-5405 E-Mail: l.schimmer(a)cgv.tugraz.at
Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723
4 years, 4 months
[SOLVED] Re: Re: Newbie question 2: Rewriting issue for bounced emails
by William Oliver
On Mon, 2021-12-27 at 14:36 -0800, Mark Sapiro wrote:
>
> It appears that the MX for billoblog.com is not accepting mail from
> your
> server. Can you send non-mailman mail from this server to this address?
> If not, you need to contact billoblog.com to fin wht they are blocking
> your mail.
>
> > I tried changing the smtp port in mailman.cfg to 587, but that didn't
> > change anything.
>
> because the issue is not in delivery from Mailman to Postfix. It is in
> delivery from Postfix to billoblog.com.
First, thanks so much for talking me through this. I could never have
done it on my own. If you ever decide to go to the Smoky Mountain
National Park or Knoxville, TN, send me an email, and I'll buy you a
drink (I live in the hills between Knoxville and Gatlinburg, TN).
In any case, I did some wandering around the intertubes and it appears
this is an uncommon but well-known problem when using dovecot and
postfix. It has to do with the setting of
smtpd_recipient_restrictions
in master.cf.
It's not clear *which* "reject" command is triggered, but if I set it
to just:
-o smtpd_recipient_restrictions=permit_sasl_authenticated
then it can get through. Er, to the next error, anyway. Sigh.
I have *no* idea why it only shows up with mailman, but not with
regular mail. I got some learnin' to do about that line.
I don't know what the default reject criteria are. I have this
horrible suspicion that I've opened myself up to zillions of evil
emails, but I'll investigate that later.
So, this took care of the Access Denied issue. That opened up the next
error, which was "relay access denied". Again, regular mail worked
just fine.
Here's the syslog when I sent email to testlist from
fp145(a)libertyfp.org:
Here's the rejection to billo(a)billoblog.com:
Dec 27 18:31:52 libertyfp postfix/submission/smtpd[471207]: connect
from mail.libertyfp.org[2.56.57.28]
Dec 27 18:31:52 libertyfp postfix/submission/smtpd[471207]: NOQUEUE:
reject: RCPT from mail.libertyfp.org[2.56.57.28]: 454 4.7.1
<billo(a)billoblog.com>: Relay access denied;
from=<testlist-bounces+billo=billoblog.com(a)libertyfp.org>
to=<billo(a)billoblog.com> proto=ESMTP helo=<mail.libertyfp.org>
Dec 27 18:31:52 libertyfp postfix/submission/smtpd[471207]: disconnect
from mail.libertyfp.org[2.56.57.28] ehlo=1 mail=1 rcpt=0/1 rset=1
quit=1 commands=4/5
But it accepts the email to fp145(a)libertyfp.org
Dec 27 18:31:53 libertyfp postfix/submission/smtpd[471207]: connect
from mail.libertyfp.org[2.56.57.28]
Dec 27 18:31:53 libertyfp postfix/submission/smtpd[471207]: 4FCDD420F5:
client=mail.libertyfp.org[2.56.57.28]
Dec 27 18:31:53 libertyfp postfix/cleanup[471223]: 4FCDD420F5: message-
id=<8d3bf47c5dcd86983e8c01f8baece4e3ac43a1a1.camel(a)libertyfp.org>
Dec 27 18:31:53 libertyfp postfix/cleanup[471223]: 4FCDD420F5: warning:
header Subject: [Testlist] bbbbb from mail.libertyfp.org[2.56.57.28];
from=<testlist-bounces+fp145=libertyfp.org(a)libertyfp.org>
to=<fp145(a)libertyfp.org> proto=ESMTP helo=<mail.libertyfp.org>
Dec 27 18:31:53 libertyfp postfix/qmgr[468573]: 4FCDD420F5:
from=<testlist-bounces+fp145=libertyfp.org(a)libertyfp.org>, size=1870,
nrcpt=1 (queue active)
Dec 27 18:31:53 libertyfp postfix/submission/smtpd[471207]: disconnect
from mail.libertyfp.org[2.56.57.28] ehlo=1 mail=1 rcpt=1 data=1 quit=1
commands=5
Direct mail from fp145(a)libertyfp.org to billo(a)billoblog.com worked fine
also.
Again, a quick DuckDuckGo search reveals that this has come up a couple
of times. It required that I modify /etc/postfix/main.cf to add the
non-localhost ip4 address of the box to the mynetworks line:
mynetworks = 127.0.0.0/8 10.0.0.0/24
to
mynetworks = 127.0.0.0/8 10.0.0.0/24 2.56.57.28
I assume that means that postfix uses localhost for regular mail, but
mailman3 uses the 2.56.57.28 address.
In any case, it now works fine. I am happily receiving the six million
test messages that were queued awaiting delivery to
billo(a)billoblog.com.
Once again, thanks. I owe you.
billo
3 years, 6 months
Re: New Mailman 3 installation issues
by sarah.hartt＠ionica.ca
Hi Mark,
Yes, that is the installation guide that I used. The nginx logs are clear aside from what I have listed and the now resolved permission denied entries from prior to moving static assets.
I am getting new entries in the django logs.
/opt/mailman/web/logs/mailmanweb.log
ERROR 2021-05-18 20:08:38,893 3078109 django.request Internal Server Error: /accounts/login/
Traceback (most recent call last):
File "/opt/mailman/venv/lib64/python3.6/site-packages/django/core/handlers/exception.py", line 34, in inner
response = get_response(request)
File "/opt/mailman/venv/lib64/python3.6/site-packages/django/core/handlers/base.py", line 145, in _get_response
response = self.process_exception_by_middleware(e, request)
File "/opt/mailman/venv/lib64/python3.6/site-packages/django/core/handlers/base.py", line 143, in _get_response
response = response.render()
File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/response.py", line 105, in render
self.content = self.rendered_content
File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/response.py", line 83, in rendered_content
return template.render(context, self._request)
File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/backends/django.py", line 61, in render
return self.template.render(context)
File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 171, in render
return self._render(context)
File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 163, in _render
return self.nodelist.render(context)
File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 936, in render
bit = node.render_annotated(context)
File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 903, in render_annotated
return self.render(context)
File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/loader_tags.py", line 150, in render
return compiled_parent._render(context)
File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 163, in _render
return self.nodelist.render(context)
File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 936, in render
bit = node.render_annotated(context)
File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 903, in render_annotated
return self.render(context)
File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/loader_tags.py", line 150, in render
return compiled_parent._render(context)
File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 163, in _render
return self.nodelist.render(context)
File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 936, in render
bit = node.render_annotated(context)
File "/opt/mailman/venv/lib64/python3.6/site-packages/django/template/base.py", line 903, in render_annotated
return self.render(context)
File "/opt/mailman/venv/lib64/python3.6/site-packages/compressor/templatetags/compress.py", line 143, in render
return self.render_compressed(context, self.kind, self.mode, forced=forced)
File "/opt/mailman/venv/lib64/python3.6/site-packages/compressor/templatetags/compress.py", line 97, in render_compressed
return self.render_offline(context)
File "/opt/mailman/venv/lib64/python3.6/site-packages/compressor/templatetags/compress.py", line 82, in render_offline
'is the original content:\n\n%s' % (key, original_content))
compressor.exceptions.OfflineGenerationError: You have offline compression enabled but key "fa788b08b65fd318d68cfc5afebc18acd3e93cebffadb54d863572ad1754f368" is missing from offline manifest. You may need to run "python manage.py compress". Here is the original content:
<link rel="stylesheet" href="/static/hyperkitty/libs/fonts/icomoon/icomoon.css" type="text/css" media="all" />
<link rel="stylesheet" href="/static/hyperkitty/libs/fonts/droid/droid.css" type="text/css" media="all" />
<link rel="stylesheet" href="/static/django-mailman3/css/main.css" />
<link rel="stylesheet" type="text/x-scss" media="all" href="/static/hyperkitty/sass/hyperkitty.scss" />
SELinux is disabled and when installed via dnf in oracle 8 RHEL it was not creating the postgres user correctly so I used their repo directly to avoid having to do so manually. This was suggested by a much more experienced admin when she took a look at the guide after I encountered issues.
If there is anything else I can provide to help diagnose the issue please let me know. if there are specific tables that I can check to ensure that they are/are not being populated to rule out a DB related issue or anything else you would suggest I try I greatly appreciate any assistance.
Sarah
4 years, 1 month
Re: Help with some 'withlist' configuration changes
by David Partain
Hi!
Thank you, Mark, for giving me something to go on! I'll dig further.
Cheers,
David
On Wed, 2021-06-23 at 06:59 -0700, Mark Sapiro wrote:
On 6/23/21 6:30 AM, David Partain via Mailman-users wrote:
Hi,
Firstly, a repeat that I have a relatively broken (and soon to be fixed, I hope) installation of mailman3 based on Ubuntu 18.04 distrib packages (3.1.1-9) that stumbles along by me dealing with a bunch of things by hand that I hope'll go away once I'm up to the current version.
In this set-up, I get a fair number of items shunted. Since I have this wonky version where stuff isn't always exposed in the web interface, I have to fix these things by hand. An example is that something gets shunted because of too many recipients, where I do:
sudo -u list mailman withlist somemailmanlist
m.max_num_recipients = 0
commit()
sudo -u list mailman unshunt
I've managed to find a number of these, such as m.max_message_size, m.require_explicit_destination, and m.administrivia.
There is some other issue here as these things should only cause a
message to be held, not shunted. Some exception is being thrown in the
process of holding the messgage, and thaty is the real issue. What are
the tracebacks in Mailman's mailman.log for these shunts?
My questions are undoubtedly foolish, but here goes:
1. Is there any way to print the entire 'm' structure? If so, I'd perhaps be able to figure out the answers to my other questions.
dir(m)
or maybe you want
>>> for x in dir(m):
... if not x.startswith('_'):
... print(f'{x}: {m.__getattribute__(x)}')
...
2. Is there a way for me to correct the following shunt-ing issues with 'withlist'? I've been unable to figure out how...
a. 'moderation_reasons': [ 'Message has no subject'] / 'rule_hits': ['no-subject']
b. Some things get caught as 'rule_hits': ['nonmember-moderation']. However, if I look in the (web-based) config, it shows that non-members should be accepted but the messages are shunted nonetheless. I don't know what to look for in 'm' or how I might clear these messages.
As I note above, these things are reasons to hold the message. The
shunting occurs because something is going wrong in the holding process.
Find the errors and tracebacks in Mailman's mailman.log to see what the
real issue might be.
3. I have no idea what these are telling me to do about digest messages. Suggestions? This is the entire info I get from 'mailman qfile':
------------------------------------------------------snip snip----------------------------------------------
[----- start pickle -----]
<----- start object 1 ----->
<----- start object 2 ----->
{ '_parsemsg': False,
'digest_number': 457,
'digest_path': '/var/lib/mailman3/lists/somelist/digest.31.457.mmdf',
'lang': 'en',
'listid': 'somelistid',
'version': 3,
'volume': 31,
'whichq': 'digest'}
[----- end pickle -----]
------------------------------------------------------snip snip----------------------------------------------
That is telling you there was in issue in sending the digest, the
mailbox for which is
/var/lib/mailman3/lists/somelist/digest.31.457.mmdf. Unshunting that
will retry sending that digest.
4. I have some that have 'rule_hits': [] (it's empty) but are shunted nonetheless. I can't see anything weird other than one of the messages has a utf-8 subject. Any ideas?
5. Some messages that were sent to -request addresses (e.g., subscribe messages, confirm, approve messages) are being shunted. What should I do with these?
You need to find the errors in the log and figure out what the
underlying issue is. I'm guessing it's a permissions issue, possibly
because of having at one time rum `mailman start` as root causing files
to be created and owned by root and not be readable/writable by the
Mailman user.
4 years
multiple sites on a mailman3 server question
by William Oliver
So, I have successfully installed mailman3 and it's working great.
However, the way it works now, if someone goes to the domain website,
he or she will get the mailman page. I'd prefer that it work something
like:
My
www.example.com goes to a home page
lists.example.com goes to the mailman3 page
mail.example.com goes to a roundcube page
I'm using nginx, and this is the first time I've set up an nginx server
(I have traditionally done apache), and I'm still figuring out the
syntax.
My sites-available file is below, for the domain emergenus.com.
The behavior I'm getting is that if I go to mail.emergenus.com, it
still redirects to mail.emergenus.com/mailman3/lists, but gives a 404
page not found.
If I go to lists.emergenus.com, it redirects to
lists.emergenus.com/mailman3/lists and gives the nice postorius page,
and works fine.
So, I'm trying to figure out how to stop that redirect.
When I look at my nginx access.log file for mail.emergenus.com, I see:
174.212.104.153 - - [28/Dec/2021:21:03:21 -0500] "GET /mailman3/lists/
HTTP/1.1" 404 188 "-" "Mozilla/5.0 (X11; Linux x86_64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.93
Safari/537.36"
Aha! says I. My ip address is 203.159.80.234, not 174.212.104.153.
Thus, uwsgi (I think) is sneaking in there and taking over regardless
of what I'm trying to do.
Is there a way to tell mailman to only take over for
lists.emergenus.com and not for www.emergenus.com or
mail.emergenus.com?
Here's my uwsgi.ini (without then env= PYTHONPATH change discussed in
another thread:
# /etc/mailman3/uwsgi.ini
#
[uwsgi]
# Port on which uwsgi will be listening.
http-socket = 0.0.0.0:8000
# If running uwsgi from the virtual environment ...
virtualenv = /opt/mailman/venv/
module=mailman_web.wsgi:application
# Add to python import path.
pythonpath = /etc/mailman3/
# The default settings module.
env = DJANGO_SETTINGS_MODULE=settings
# Setup default number of processes and threads per process.
master = true
processes = 2
threads = 2
# Setup the django_q related worker processes.
attach-daemon = /opt/mailman/venv/bin/mailman-web qcluster
# Setup the request log.
req-logger = file:/opt/mailman/web/logs/uwsgi.log
# Log qcluster commands separately.
logger = qcluster file:/opt/mailman/web/logs/uwsgi-qcluster.log
log-route = qcluster uwsgi-daemons
# Last log and it logs the rest of the stuff.
logger = file:/opt/mailman/web/logs/uwsgi-error.log
Here's my /etc/nginx/sites-enabled/emergenus.com looks like:
server {
root /var/www/html2;
index index.html index.htm index.nginx-debian.html;
server_name emergenus.com, mail.emergenus.com,
www.emergenus.com;
location /{
try_files $uri $uri/ =404;
}
##### added 12/19
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
##########
ssl_certificate /etc/letsencrypt/live/emergenus.com/fullchain.pem;
# managed by Certbot
ssl_certificate_key
/etc/letsencrypt/live/emergenus.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by
Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
root /var/www/html;
index index.html index.htm index.nginx-debian.html;
server_name lists.emergenus.com;
location /{
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
# proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_redirect off;
}
listen 443 ssl ;
listen [::]:443 ssl ;
location /static/ {
alias /opt/mailman/web/static/;
}
##########
ssl_certificate /etc/letsencrypt/live/emergenus.com/fullchain.pem;
# managed by Certbot
ssl_certificate_key
/etc/letsencrypt/live/emergenus.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by
Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = mail.emergenus.com) {
# return 301 https://$host$request_uri;
return 301 https://mail.emergenus.com;
} # managed by Certbot
if ($host = www.emergenus.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
if ($host = lists.emergenus.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80 ;
listen [::]:80 ;
server_name www.emergenus.com lists.emergenus.com
mail.emergenus.com emergenus.com;
return 404; # managed by Certbot
}
Thanks
billo
3 years, 6 months
Re: Problems with New MM3 Installation
by Abhilash Raj
On Tue, May 11, 2021, at 8:43 PM, Mark Sapiro wrote:
> On 5/11/21 7:46 PM, Jeff wrote:
> >
> > I really appreciate your assistance. New messages are now being archived as expected, but I still have a few small remaining issues to work out with my MM3 installation:
> >
> > 1) some emails that arrived before I got the archive working are still sitting in:
> >
> > /usr/local/mailman3/mm/var/archives/prototype/[listname]@[domain]/new
> >
> > Strangely this includes at least one email that was archived. Should this directly be cleared as messages are archived? Is there a way to force it to be cleared?
>
> /usr/local/mailman3/mm/var/archives/prototype/[listname]@[domain] is a
> collection of messages in maildir format. This is how the prototype
> archiver stores messages. This has nothing to do with HyperKitty. It is
> a separate archiver. If you don't want messages to be stored there, you
> can disable the prototype archiver for the list by unchecking prototype
> in Postorius -> Settings -> Archiving -> Active archivers or disable it
> entirely for the installation by setting
> ```
> [archiver.prototype]
> enable: no
> ```
> in mailman.cfg
>
> > 2) Some messages that arrived while I was having other problems with the setup have been stored in:
> >
> > /usr/local/mailman3/mm/var/queue/shunt
> >
> > What should I do to get these messages processed?
>
>
> Assuming the issues that caused them to be shunted have been fixed, just
> run the command
> ```
> mailman unshunt
> ```
>
> > 3) Similar to above, some messages are in:
> >
> > /usr/local/mailman3/mm/var/queue/bad
> >
> > How can I get these messages processed?
>
>
> First examine the messages with
> ```
> mailman qfile /usr/local/mailman3/mm/var/queue/bad/<file>
> ```
> To be sure you want them. Also examine mailman.log for the times they
> were stored in the `bad` queue. You are looking for 'Skipping and
> preserving unparseable message: <file>' and/or 'SHUNTING FAILED,
> preserving original entry: <file> messages and you want to determine
> which runner preserved the message. There may be a 'whichq' entry in the
> message's metadata in which case, that's the answer.
>
> Once you have determined the queue, you can just move the .psv file from
> the bad queue to the appropriate queue, renaming it from .psv to .pck in
> the process.
>
>
> > 4 Modified the template for “list:admin:action:post” through Postorious and emails that arrived after that were put in the “shunt” queue. I traced this problem to POSTORIUS_TEMPLATE_BASE_URL. By default, it is set to "http://localhost:8000 <http://localhost:8000/>” which is where uwsgi is listening. However, uwsigi is listening for uwsgi:/ not http://. Should I change POSTORIUS_TEMPLATE_BASE_URL to “uwsgi://localhost:8000 <uwsgi://localhost:8000>” or keep http but make it something else?
>
>
> I know little about uwsgi. setting it to `uwsgi://localhost:8000` might
> work. You could also set it to the base URL that a user would use to
> access the web UI, e.g. `https://example.com` and that would presumably
> be proxied to uwsgi. For example, on the server for this list we have
> ```
> POSTORIUS_TEMPLATE_BASE_URL = 'https://lists.mailman3.org'
> ```
> which gets proxied to gunicorn, but the idea is the same.
Using the full external URL should work. Core doesn’t speak uwsgi protocol
so the uwsgi:// URL won’t actually work.
I am starting to think it was a very bad idea to use uwsgi in the official docs :(
--
thanks,
Abhilash Raj (maxking)
4 years, 1 month
Re: Ann: Postorius 1.3.6 is now out
by Guillermo Hernandez (Oldno7)
On 29/9/21 5:27, Abhilash Raj wrote:
> Hey Everyone,
>
> I just tagged and released Postorius 1.3.6. This release includes both bug fixes and
> new features.
Just to confirm that I've done a complete upgrade from last version
without any problem.
From the info page:
Mailman Core Version GNU Mailman 3.3.5 (Tom Sawyer)
Mailman Core API Version 3.1
Mailman Core Python Version 3.7.9 (default, Nov 6 2020, 21:14:59)
[Clang 8.0.1 (tags/RELEASE_801/final 366581)]
Documentación de Postorius <https://postorius.readthedocs.org> • GNU
Mailman <http://list.org> • Versión de Postorius 1.3.6
>
> Some of the notable features include
> - Ability to list and handle un-subscription requests to the list
> - Option to choose delivery mode and delivery_status directly when subscribing to a list
> - Addition of a user management interface, which allows updating a users password,
> manually verifying their email addresses, update user’s Display Name etc.
> - Expose a number of Bounce processing related options in List’s settings
>
> A full list of changes is available here
>
> https://docs.mailman3.org/projects/postorius/en/latest/news.html#news-1-3-6
>
> You can install this release using pip
>
> $ pip install postorius django-mailman3 mailmanclient —upgrade
>
> Do note that this release requires Mailman Core 3.3.5, so you need to upgrade
> Core before upgrading Postorius.
>
> The release tarball is available on PyPI as usual:
>
> https://pypi.org/project/postorius/1.3.6/#files
>
> Please also ensure to run the post-install commands as per the upgrade documentation:
>
> https://docs.mailman3.org/en/latest/upgrade-3.2.html#post-upgrade
>
> Thanks to all the folks who helped with this release!
>
> Abhilash
>
>> Please also ensure to run the post-install commands as per the upgrade documentation[4] (commands _after_ pip install, needs a post-install heading/anchor in there :-).
>> On Sep 19, 2021, at 8:48 PM, Abhilash Raj <maxking(a)asynchronous.in> wrote:
>>
>> Hey Everyone,
>>
>> I am pleased to announce that Postorius 1.3.6b1 is now out. This is the first pre-release for 1.3.6, which is slated to release next week soon after Mailman Core 3.3.5 release.
>>
>> This release requires Mailman Core 3.3.5 release, so if you are trying out this release, please also upgrade Mailman Core to 3.3.5rc1 (which was just released today).
>>
>> This release includes several new features and bug fixes. A full list of changes is available here[1].
>>
>> With this release, we have also improved on the localization of the interface, if you want to help out before the release of the stable 1.3.6, please see the instructions for translators here[2]. We use Weblate for translations, so if you are familiar with that, you can directly head over there[3].
>>
>> Since this is a pre-release version, you can install this using pip via:
>>
>> $ pip install --upgrade --pre postorius django-mailman3 mailmanclient
>>
>> Please also ensure to run the post-install commands as per the upgrade documentation[4] (commands _after_ pip install, needs a post-install heading/anchor in there :-).
>>
>> A release tarball is available on PyPI:
>>
>> https://pypi.org/project/postorius/1.3.6b1/#files
>>
>> Finally, thanks to all the folks who helped with this release in any capacity and made it possible.
>>
>> [1]: https://docs.mailman3.org/projects/postorius/en/latest/news.html#news-1-3-6
>> [2]: https://docs.mailman3.org/en/latest/translation.html
>> [3]: https://hosted.weblate.org/projects/gnu-mailman/postorius/
>> [4]: https://docs.mailman3.org/en/latest/upgrade-3.2.html#virtualenv-install
>>
>>
>> thanks,
>> Abhilash
> --
> 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, 9 months
Re: Long-shot cry for help
by Matthew Alberti
David,
I had alot of the same challenges you are currently seeing. Frankly, a working installation using the Ubuntu packages is seemingly impossible.
After trying that and also pip, I elected to use the Docker method. https://github.com/maxking/docker-mailman
Sanity preserved. It is very easy. Just an idea.
- Matt Alberti
Get BlueMail for Android
On Jun 3, 2021, 9:35 AM, at 9:35 AM, David Partain via Mailman-users <mailman-users(a)mailman3.org> wrote:
>Hi,
>
>I'm having severe operational issues with my mailman3 site. My site is
>built on standard Ubuntu packages (18.04), and they're ancient. I'm
>having two big issues...
>
>1. I have the old smiley problem that I've had from the very beginning
>and never solved. I have added 'charset': 'utf8mb4' to the relevant
>config file (/etc/mailman3/mailman-web.py), but that hasn't "taken", in
>the sense that the calls to mysql do not include the charset stuff.
>
>/usr/share/mailman3-web/settings_local.py links to
>/etc/mailman3/mailman-web.py and there is no file
>/usr/share/mailman3-web/settings_local.pyc. I moved it out of the way
>hoping it'd get re-built, but it has not been in the months since.
>
>The result of this that I get hundreds of mail messages to root
>(thousands, really), rapidly filling / with mail in /var/mail/root and
>logging in /var/log/mail.log. The mail has something like "Subject:
>[Django] ERROR (EXTERNAL IP): Internal Server Error:
>/mailman3/hyperkitty/api/mailman/archive" and "DataError at
>/hyperkitty/api/mailman/archive (1366, u"Incorrect string value:
>'\\xF0\\x9F\\x98\\x8A\\x0D\\x0A...' for column 'content' at row 1")"
>
>I have tried to trace to figure out what file is _actually_ controlling
>the calls to mysql. There's a file called
>/var/lib/ucf/cache/:etc:mailman3:mailman-web.py as well, but I have no
>idea what that is or if it might be used.
>
>Is there something like 'mailman info' for mailman-web so I can see
>what files are being used? I'd love to fix this...
>
>2. There's this one curious cron job...
>
>* * * * * www-data [ -f /usr/bin/django-admin ] && python2.7
>/usr/bin/django-admin runjobs minutely --pythonpath
>/usr/share/mailman3-web --settings settings
>
>(yes, I know python2.7 is a problem... see the last paragraph below).
>
>These jobs start piling up. They run & run & run, and eventually the
>machine screeches to halt when it runs out of memory and goes belly up.
>This is a relatively recent development. After a while, I'll have 5 or
>6 or more of these all running, looking something like this:
>
>www-data 6366 6364 99 15:00 ? 00:12:27 python2.7
>/usr/bin/django-admin runjobs minutely --pythonpath
>/usr/share/mailman3-web --settings settings
>
>What this means in practice right now is that I'm forced to go in and
>kill these on a regular basis or the machine _will_ die and people
>_will_ shout at me.
>
>Does anyone have any idea why these might not be finishing? Can I
>comment this out completely & live happier? Any help whatsoever?
>
>-----------------------------------
>
>Finally, I should add that I know my current installation is
>fundamentally flawed because I chose to go with distro packages. I
>simply cannot fix it. My strong recommendation to others who follow me
>is that they do NOT do this. Bite the bullet and install via pip... I'm
>now in the process of setting up a new server that is completely based
>on the latest via pip installation. I have to get away from what I have
>or lose my sanity.
>
>Cheers,
>
>David
>
>_______________________________________________
>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, 1 month