Unable to ban users via mailman-shell
Hi
I can't seem to be able to add bans via mailman-shell:
# mailman-wrapper shell Welcome to the GNU Mailman shell
from mailman.testing.documentation import dump_json from mailman.interfaces.mailinglist import IMailingList from zope.component import getUtility list_manager = getUtility(IListManager) mlist = list_manager.get('x2go-commits@lists.x2go.org') bans = IBanManager(mlist) new_bans = ["really", "long", "list", "with", "addresses", "I'd", "like", "to", "ban"] for new_ban in new_bans: ... bans.ban(new_ban) ... for ban in bans: ... print('{0}: {1}'.format(ban.list_id,ban.email)) ... [long list of bans] exit()
# mailman-wrapper shell Welcome to the GNU Mailman shell
from mailman.testing.documentation import dump_json from mailman.interfaces.mailinglist import IMailingList from zope.component import getUtility list_manager = getUtility(IListManager) mlist = list_manager.get('x2go-commits@lists.x2go.org') bans = IBanManager(mlist) for ban in bans: ... print('{0}: {1}'.format(ban.list_id,ban.email)) ... exit()
GNU Mailman 3.3.8 (Tom Sawyer), installed on Ubuntu 24.04 via distro packages (yes, they are completely broken; yes, I had to backport fixes from your Gitlab instance to even get this properly installed and working; yes, I think I can handle this)
What could possibly be the cause of this? I don't even see any calls to the REST API for each bans.ban() call. Should I see those? Or is bans.ban() directly modifying the database? I skimmed the source code and it looks like as if IBanManager and the concrete BanManager model seem to work directly on a DB connection, so I assume that it's not going through REST. If that is the case (I'm using sqlite3, nothing fancy), why doesn't it stick? Do I have to commit changes somehow?
Mihai
- On 4/13/25 14:43, Mihai Moldovan wrote:
I can't seem to be able to add bans via mailman-shell:
What I haven't tested before, but should have done: I can, however, add new bans from Postorius (the web interface) and immediately query them via mailman-shell:
for ban in bans: ... print('{0}: {1}'.format(ban.list_id,ban.email)) ... x2go-commits.lists.x2go.org: x@y.z
Obviously, requests via Postorius also go through the REST API via a POST request, as I'd expect, and are immediately committed to the database (I've checked it by directly opening with SQLite3).
I'm quite stumped why the shell interface doesn't commit the data to the DB.
Unfortunately, the web interface doesn't allow mass-adding addresses, which is why I wanted to do that via the shell.
Mihai
Mihai Moldovan writes:
# mailman-wrapper shell Welcome to the GNU Mailman shell
from mailman.testing.documentation import dump_json from mailman.interfaces.mailinglist import IMailingList from zope.component import getUtility list_manager = getUtility(IListManager) mlist = list_manager.get('x2go-commits@lists.x2go.org') bans = IBanManager(mlist) new_bans = ["really", "long", "list", "with", "addresses", "I'd", "like", "to", "ban"] for new_ban in new_bans: ... bans.ban(new_ban) ... for ban in bans: ... print('{0}: {1}'.format(ban.list_id,ban.email)) ... [long list of bans] exit()
You appear to have missed this line from 'mailman shell's banner:
Exit with ctrl+D does an implicit commit() but exit() does not.> I don't even see any calls to the REST API for each bans.ban()
call. Should I see those?
No. Mailman core does not call the REST API for anything that I know of. It implements the API so that processes on a different node can access Mailman's resources, but the 'mailman' utility is intentionally restricted to the same node.
Or is bans.ban() directly modifying the database?
Yes, but inside a transaction that must be committed.
If that is the case (I'm using sqlite3, nothing fancy), why doesn't it stick? Do I have to commit changes somehow?
Of course somebody has to commit the transaction, and Ctrl-D to exit will do that for you. But there also has to be a way to back out without committing, and we use the more verbose exit() (without preceding commit()) for that.
You might think it should require more effort to do possibly destructive changes than to abort safely, but we've found by experience that the majority of usage of 'shell' and 'withlist' is quite simple, and reports of problems with undesired commits are just about nonexistent.
-- GNU Mailman consultant (installation, migration, customization) Sirus Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
- On 4/13/25 16:20, Stephen J. Turnbull wrote:
You appear to have missed this line from 'mailman shell's banner:
Exit with ctrl+D does an implicit commit() but exit() does not.
Oh, wow, thank you. I'm really embarrassed now.
Sorry for the fuss.
This said, I haven't missed it, I've ever seen this message in the banner! Weird. I can see that it's defined as such in config/schema.cfg, but I've only ever seen the first line and a newline, but the next three lines never came up for me:
Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not.
Case in point:
mailman-wrapper shell Welcome to the GNU Mailman shell
That might be a bug in mailman 3.3.8, though, and indeed, there is https://gitlab.com/mailman/mailman/-/issues/1062 which might be partly relevant. While it is generally a fix for use_ipython: true (which I don't use), it might have also fixed the banner issue for the non-ipython case.
# mailman-wrapper info GNU Mailman 3.3.8 (Tom Sawyer) Python 3.12.3 (main, Feb 4 2025, 14:48:35) [GCC 13.3.0] config file: /etc/mailman3/mailman.cfg db url: sqlite:////var/lib/mailman3/data/mailman.db devmode: DISABLED REST root url: http://localhost:8001/3.1/ REST credentials: restadmin:breakme
Mihai
On 4/13/25 07:53, Mihai Moldovan wrote:
That might be a bug in mailman 3.3.8, though, and indeed, there is https://gitlab.com/mailman/mailman/-/issues/1062 which might be partly relevant. While it is generally a fix for use_ipython: true (which I don't use), it might have also fixed the banner issue for the non-ipython case.
This was added in Mailman 3.3.1 by https://gitlab.com/mailman/mailman/-/merge_requests/587
The fix for https://gitlab.com/mailman/mailman/-/issues/1062 doesn't affect this if you aren't using ipython.
Do you have a setting for banner in the [shell] section of your
mailman.cfg?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
- On 4/13/25 17:19, Mark Sapiro wrote:
Do you have a setting for
bannerin the[shell]section of your mailman.cfg?
Whoops, yes, I do. Removed it, and the messages appear correctly, of course.
It's a downstream packaging bug, the sample config they created only includes the first line: https://git.launchpad.net/ubuntu/+source/mailman3/tree/debian/contrib/mailma...
Thanks. Bug report time to Ubuntu it is.
Mihai
participants (3)
-
Mark Sapiro -
Mihai Moldovan -
Stephen J. Turnbull