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.
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
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
I have mailman3 running now, more or less. Mailman did not send messages
to my list, giving a permiission error on the digest.mmdf file, which
was not there. I created the file and made list.list the owner, now it
sends messages.
I don't know what should have created the file or what set the
permissions to the directory, I just thought I'd let you know.
dagdag
Christine
--
dagdag is just a two character rotation of byebye
I was testing out the process of rejecting an incoming subscription
request. Choosing the reject option for a moderated subscription request
does send out a rejection notice but it gives no reason for the
rejection. Please see:
------------------------------------------------------------------------
Your request to the redacted(a)redacted.com mailing list
Subscription request
has been rejected by the list moderator. The moderator gave the
following reason for rejecting your request:
"[No reason given]"
Any questions or comments should be directed to the list administrator
at:
redacted-owner(a)redacted.com
------------------------------------------------------------------------
Is there a place somewhere in Postorius to provide a rejection reasons
for moderated subscription requests? Does Mailman 3 core provide this
via its REST api but it is just not revealed in Postorius yet?
--
Brian Carpenter
Harmonylists.comEmwd.com
Hi,
I have been using mailman for about ten years, now I want to move the
lists to another server, I have installed mailman3 there, most of it
seems to be running, but the "rest api runner" is not. Nothing is
listening on port 8001. What have I missed? What do I do to start the
restapi runner? I checked the logs, I don't see anything suspicious.
this is what systemctl status says:
root@lists:~# systemctl status mailman3
● mailman3.service - Mailman3 server
Loaded: loaded (/lib/systemd/system/mailman3.service; enabled;
vendor preset: enabled)
Active: failed (Result: timeout) since Sat 2021-03-27 12:04:06
UTC; 6min ago
Docs: man:mailman(1)
https://mailman.readthedocs.io/
Process: 173111 ExecStart=/usr/bin/mailman -C
/etc/mailman3/mailman.cfg start --force (code=killed, signal=TERM)
Mar 27 12:02:36 lists systemd[1]: Starting Mailman3 server...
Mar 27 12:04:06 lists systemd[1]: mailman3.service: start operation
timed out. Terminating.
Mar 27 12:04:06 lists systemd[1]: mailman3.service: Failed with result
'timeout'.
Mar 27 12:04:06 lists systemd[1]: Failed to start Mailman3 server.
There is nothing in mailman.log, nor in smtp.log
dagdag
Christine
--
dagdag is just a two character rotation of byebye
I am moving the website www.t10.org from a private/corporate VM to AWS EC2s.
For many years, t10.org has had very happy results with using Mailman 2 for its email reflector, and I have no real concerns about moving to Mailman 3. My bugbear is the fact that I need the following mixed bag of incoming email addresses to work in concert with each other to receive and handle emails.
> t10(a)t10.org (Primary Mailman Reflector)
> chair(a)t10.org (Mailman Reflector to direct messages to the T10 chair and his designates)
* docs(a)t10.org (document posting mechanics - serviced by a small mountain of home-grown code code)
* bbs(a)t10.org (other publicly accessible services - serviced by code that recalls the days when everything as done on a Bulletin Board System, BBS)
My best guess is that the AWS Simple Email Service (SES) needs to sit in front of both Mailman and the home-grown code, to properly direct the incoming emails to the right places. The big worry is as follows...
All available evidence read to date suggests that the default AWS installation of Mailman 3 assumes that Mailman 3 is the *only* receiver of emails in the configuration. If true, then putting SES in front of Mailman could be a Herculean challenge.
Or... Hercules may have already cleaned the Augean Stables, and left behind a AWS Lambda function that can serve as a keystone puzzle piece for solving my dilemma.
Thanks for taking the time to look at this.
All the best,
.Ralph
FWIW Information about the current t10.org Mailman reflector can be found at https://www.t10.org/t10r.htm. T10 is primarily an open-to-the-public activity, so there are no company confidential secrets there.
For those interested in the archives associated with the t10.org Mailman reflector, they are available at https://www.t10.org/pipermail/t10/ and "inquiring minds" may puzzle over the fact that the archives date back to December 1993. When Mailman 2 was installed, we converted all the Majordomo archives to Mailman 2 format.
I keep seeing bounces being recorded in logs/bounce.log that have no
corresponding entry in Postfix's mail.log. For instance one address had
registered about 2 dozen bounces in the past week in bounce.log and yet
every single entry for this address in mail.log has a status=sent. What
am I missing here?
--
Brian Carpenter
Harmonylists.comEmwd.com
So I am working with our Linux admin to install mailman3 in centos7 following this instructions https://docs.mailman3.org/en/latest/install/virtualenv.html# (and adjusting for centos versus Debian)
The install went fine with the command “pip install wheel mailman psycopg2-binary”until the config file. /etc/mailman3/mailman.cfg
The /etc/mailman3 directory did not get created? Should it have?
We created it and the config file
But “mailman info” throws errors
venv) [mailman@bmimailmandr2 var]$ mailman info
Traceback (most recent call last):
File "/opt/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/engine/base.py", line 2336, in _wrap_pool_connect
return fn()
File "/opt/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/pool/base.py", line 364, in connect
return _ConnectionFairy._checkout(self)
File "/opt/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/pool/base.py", line 778, in _checkout
fairy = _ConnectionRecord.checkout(pool)
File "/opt/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/pool/base.py", line 495, in checkout
rec = pool._do_get()
File "/opt/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/pool/impl.py", line 140, in _do_get
self._dec_overflow()
File "/opt/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/util/langhelpers.py", line 70, in __exit__
with_traceback=exc_tb,
File "/opt/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/util/compat.py", line 182, in raise_
raise exception
File "/opt/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/pool/impl.py", line 137, in _do_get
return self._create_connection()
File "/opt/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/pool/base.py", line 309, in _create_connection
return _ConnectionRecor
I suspect it is not using the config file at /etc/mailman3/mailman.cfg But we do not even see a mailman service in /etc/systemd/system/mailman3.service.
Also, we are using python 3.6, will that be a major issue? or should spend the time to install 3.7 from source?
All,
I need help with this.
A subscriber is a member of 14 of the lists on my system (others have more subscriptions). This member needs to change the address and is dyslexic, so I’ve been asked to help.
I added the new address to her account in Django and set it as the preferred address. However, when she was subscribed, the system set her old address as the list subscription address, instead of her ‘preferred’ address. Well, I’m not sure of this as I cannot access her Settings, but that’s how it worked with one of my own addresses.
Will I now have to tell her to do this for each list she is subscribed to:
Select ‘Mailman Settings’ in dialog pulldown.
Select one of the lists listed.
Click on ‘Manage Subscription.’
In ‘Select Emai’, select the ‘Primary Address’ pulldown option
Click on ‘Change email used for subscription.’
Please note that the “Global Mailman preferences’ nor the ‘Address-based preferences’ have the option to select the preferred address. I realize that once a member has an account in Django AND has preferred address set AND has selected the ‘Primary Address’ for each list, then this will be easier. However, I have 10000+ subscriptions by some 1500 members, most of whom were moved over from MM2 and have no Django accounts.
Someone on list some time ago advised me that it was possible to do this easily globally. I have spent a couple of hours on the system trying to find that way but the above per-list procedure is all I found.
Please make this easy, as I get these requests all the time and some, like this one, are on many lists.
Yours,
Allan
In /etc/mailman3/mailman-web.py I have added
FILTER_VHOST = True
so that only the list for the current domain are shown.
But this has no effect.
What's more, in hyperkitty I see at the top left the lable for the
default domain, even though I am visiting from another domain.
The web domains are exactly the same as the mail domans
(lists.[domain].[tld])
In the Nginx config I have added
location / {
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_pass http://localhost:8000/;
[....]
}
to make sure that mailman3 knows from which URL it is visited.
Am I overlooking something?
I am using the distribution packages on Ubuntu 20.04:
mailman3 3.2.2-1
mailman3-web 0+20180916-10
I see, the mailman3-web package is quite dated. Is it recommended to
install via virtualenv instead?
Cheers,
Johannes
Hey Everyone,
I am pleased to announce that Mailman Core 3.3.4 is now out.
Because of incompatibility with the new version of a downstream
library (SQLAlchemy), this release add is setting 1.3.x as the max
supported version of SQLAlchemy.
Even though it comes soon after 3.3.3, it has a lot of bug fixes and
new features. Some notable ones are:
* Email -join command now supports subscribing as digests with
digest=<no|mime|plain> options being honored.
* For anonymous lists, Mailman will filter all the headers except a few
that can be configured using a new config option.
* Mailman can do max_size checks on filtered message rather than
original message (which might be larger before being filtered)
* Previously deprecated --add, --del and --sync options from
`mailman members` command are now removed. Their alternatives
are `addmembers`, `delmembers` and `syncmembers` subcommands.
* If configured, Mailman will add a report about content filtering.
A complete change log is available here:
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/NEWS.…
This release is available via PyPI:
https://pypi.org/project/mailman/3.3.4/
You can install or upgrade using:
```
$ pip install --upgrade mailman
```
Thanks to all the contributors who helped with this release!
--
On behalf of Mailman Core Team
Abhilash Raj
