Re: where to configure max_days_to_hold on MM3 GUI interface?
by Abhilash Raj
On Sat, Feb 1, 2020, at 5:27 AM, Shashikanth Komandoor wrote:
> Hello Mark,
>
> Thanks for helping me for moving ahead in my project.
>
> Troubling you again, I would like to put another request at you.
>
> As per your suggestion, I am trying to configure my list
> configuration through REST API for specially the parameter like
> max_days_to_hold as it is not available through interface and I am
> following the official links of mailman 3 i.e
> https://mailman.readthedocs.io/en/latest/src/mailman/rest/docs/listconf.html
>
> But I am getting "name is not defined" sort of errors as below:
>
>
>
>
>
> *>>> dump_json('http://localhost:9001/3.0/lists/
> <http://localhost:9001/3.0/lists/>','ant(a)example.com/config
> <http://ant@example.com/config>',dict(display_name='My
> List'),'PATCH')Traceback (most recent call last): File "<stdin>", line 1,
> in <module>NameError: name 'dump_json' is not defined>>>*
>
> Actually I am new to REST API but hope this is the only issue that
> is preventing me to go ahead.
>
> Could you please help me by saying how should I handle this so that
> I should be able to configure *max_days_to_hold* of a list or multiple ?
>
dump_json is basically a Python function which sends the request to the URL you add as the first parameter (GET, if any data isn't specified and uses POST if data is specified or explicitly define the PATCH or method like you have above) and prints the json response.
You can easily do the same using curl with the right authorization headers, with something like:
$ curl -u restadmin:restpass -X PATCH \
http://localhost:8001/3.1/lists/somelist.example.com/config -d display_name='Patched Name'
Note that "restadmin:restpass" is the username password that you have set in your mailman.cfg.
If you do want to use Python, you can just use a regular PATCH request using requests or standard library urllib3.
Finally, dump_json is documented here: https://mailman.readthedocs.io/en/latest/src/mailman/docs/documentation.htm…
> On Wed, Jan 29, 2020 at 11:20 PM Mark Sapiro <mark(a)msapiro.net> wrote:
>
> > On 1/28/20 8:42 PM, Shashikanth Komandoor wrote:
> > >
> > > But I could see that parameter value configurable on MM2 GUI
> > > interface in General Options but I don't see the same on the MM3 GUI
> > > interface.
> >
> >
> > There are many core settings not (yet) exposed in Postorius.
> > max_days_to_hold. is one of them. It can be set via `mailman shell` or
> > via the REST API
> > <
> > https://mailman.readthedocs.io/en/latest/src/mailman/rest/docs/rest.html#re…
> > >.
> >
> > --
> > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
> > San Francisco Bay Area, California better use your sense - B. Dylan
> > _______________________________________________
> > 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 & Regards,
> Shashi Kanth.K
> 9052671936
> _______________________________________________
> Mailman-users mailing list -- mailman-users(a)mailman3.org
> To unsubscribe send an email to mailman-users-leave(a)mailman3.org
> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
>
--
thanks,
Abhilash Raj (maxking)
6 years, 8 months
Re: mailman-web migrate fails with sqlite3.IntegrityError: UNIQUE constraint failed: account_emailaddress.email
by Stefan Bauer
Dear Mark,
thank you for your time.
After patching your script according to
https://github.com/maxking/docker-mailman/issues/729#issuecomment-2447542238
It fails with
/opt/mailman/venv/data# /usr/local/bin/UC_fix
/opt/mailman/venv/data/mailman3web.db
Traceback (most recent call last):
File "/usr/local/bin/UC_fix", line 77, in <module>
c.execute("delete from account_emailaddress where email = %s;",
sqlite3.OperationalError: near "%": syntax error
for reference:
67 for id, emails in d.items():
68 ems = find(emails)
69 if ems:
70 em1, em2 = ems
71 if em1.lower() == em1:
72 c.execute("delete from account_emailaddress where email =
%s;",
73 [em2])
74 c.execute("""update account_emailaddress set "primary" = 't'
75 where email = %s;""", [em1])
76 elif em2.lower() == em2:
77 c.execute("delete from account_emailaddress where email =
%s;",
78 [em1])
79 c.execute("""update account_emailaddress set "primary" = 't'
80 where email = %s;""", [em2])
81 else:
82 print(f'No LC email for {ems}')
However the sql connection itself works, and the select also reports
addresses:
sqlite> select email, user_id from account_emailaddress;
...
John.Doe(a)my.domain|85
john.doe(a)my.domain|85
.....
Mike.Doe(a)my.domain|96
mike.doe(a)my.domain|96
....
Is there something wrong on my side?
Thank you.
Stefan
Am Mo., 3. März 2025 um 18:40 Uhr schrieb Mark Sapiro <mark(a)msapiro.net>:
> On 3/3/25 07:52, Stefan Bauer via Mailman-users wrote:
> >
> > trying to update mailman3 to lastest version, we fail during
> >
> > mailman-web migrate with:
> >
> > Operations to perform:
> > Apply all migrations: account, admin, auth, contenttypes,
> django_mailman3,
> > django_q, hyperkitty, postorius, sessions, sites, socialaccount
> > Running migrations:
> > Applying account.0006_emailaddress_lower...Traceback (most recent call
> > last):
> > File
> >
> "/opt/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py",
> > line 89, in _execute
> > return self.cursor.execute(sql, params)
> > File
> >
> "/opt/mailman/venv/lib/python3.10/site-packages/django/db/backends/sqlite3/base.py",
> > line 328, in execute
> > return super().execute(query, params)
> > sqlite3.IntegrityError: UNIQUE constraint failed:
> account_emailaddress.email
>
>
> This issue is due to changes in Django allauth to prevent creating
> multiple addresses differing only in case. The problem is if you have
> such multiple addresses in your account_emailaddress table, this
> migration fails. There is a script at
> https://www.msapiro.net/scripts/UC_fix that will fix this. You may need
> to adjust the shebang and replace psycopg2 with sqlite3.
>
> See https://github.com/pennersr/django-allauth/issues/3019 perhaps
> starting at
>
> https://github.com/pennersr/django-allauth/issues/3019#issuecomment-1748028…
>
> > We found a workaround to fake the migration with
> >
> > migrate --fake
>
> You should fix the issue with the DB and run the migrations.
>
> > Could this be some duplicate users with same mail-address?
>
> This is not related to Mailman users. It is Django users.
>
> --
> Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
> San Francisco Bay Area, California better use your sense - B. Dylan
>
> _______________________________________________
> 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/
> Archived at:
> https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…
>
> This message sent to cubewerk(a)gmail.com
>
1 year, 7 months
Re: Getting rid of held messages from the command line
by Mark Sapiro
On 03/16/2018 09:01 AM, Aymeric Mansoux wrote:
>
> However, while I was testing this happily on a list that was not affected with the JSON error, I finally tested discard_held_messages() on one of the problematic list, and I get the exact same problem as when trying to view the moderation queue API:
>
>>>> discard_held_messages_queue('xxx(a)xxx.xxx')
> Traceback (most recent call last):
> File "<console>", line 1, in <module>
> File "<console>", line 6, in discard_held_messages_queue
> File "/usr/local/lib/python3.5/dist-packages/mailman/app/moderator.py", line 97, in handle_message
> key, msgdata = requestdb.get_request(id)
> File "/usr/local/lib/python3.5/dist-packages/mailman/database/transaction.py", line 85, in wrapper
> return function(args[0], config.db.store, *args[1:], **kws)
> File "/usr/local/lib/python3.5/dist-packages/mailman/model/requests.py", line 120, in get_request
> result.data_hash, expunge=False)
> File "/usr/local/lib/python3.5/dist-packages/mailman/database/transaction.py", line 85, in wrapper
> return function(args[0], config.db.store, *args[1:], **kws)
> File "/usr/local/lib/python3.5/dist-packages/mailman/model/pending.py", line 138, in confirm
> value = json.loads(keyvalue.value)
> File "/usr/lib/python3.5/json/__init__.py", line 319, in loads
> return _default_decoder.decode(s)
> File "/usr/lib/python3.5/json/decoder.py", line 339, in decode
> obj, end = self.raw_decode(s, idx=_w(s, 0).end())
> File "/usr/lib/python3.5/json/decoder.py", line 355, in raw_decode
> obj, end = self.scan_once(s, idx)
> json.decoder.JSONDecodeError: Unterminated string starting at: line 1 column 1 (char 0)
>
> With that said, even though I cannot pass the discard action, I can export the queue without problem, so I will send you off-list a sample, because I am not sure what I should be looking for.
Unfortunately, that didn't help. I was able to post all the messages in
your sample to a test list and even with all the messages held, I could
view them and discard them in postorius.
This may not be too surprising as looking at the traceback, the
exception is thrown in trying to delete the pending confirmation from
the pending database. The issue is when a message is held an entry is
made in the pending database with a confirmation token that can be used
for example to approve or discard the message by email.
There is an issue that affects MySQL databases only in that prior to the
merge of <https://gitlab.com/mailman/mailman/merge_requests/333> values
in the pendedkeyvalue table could be truncated (or exceptions thrown
depending on MySQL settings). That appears to be the issue here.
The fix was only merged in January and is not in Mailman 3.1.1.
> Finally, is there another way to get rid of these messages? Are there consequences if I would use message_store.delete_message(message_id) instead of handle_message(m, req.id, Action.discard)?
As I said, I think the issue is with the pendedkeyvalue table, not with
the message itself. The table contains entries which are pickled
versions of various things. A big issue is rule_misses. For one of your
messages, the rule_misses list is
['dmarc-mitigation', 'no-senders', 'approved', 'emergency', 'loop',
'banned-address', 'member-moderation']
this gets pickled into
b'\x80\x03]q\x00(X\x10\x00\x00\x00dmarc-mitigationq\x01X\n\x00\x00\x00no-sendersq\x02X\x08\x00\x00\x00approvedq\x03X\t\x00\x00\x00emergencyq\x04X\x04\x00\x00\x00loopq\x05X\x0e\x00\x00\x00banned-addressq\x06X\x11\x00\x00\x00member-moderationq\x07e.'
which ultimately gets stored in the pendedkeyvalue table as a value for
'_pck_rule_misses' which is
'"\u0080\u0003]q\u0000(X\u0010\u0000\u0000\u0000dmarc-mitigationq\u0001X\n\u0000\u0000\u0000no-sendersq\u0002X\b\u0000\u0000\u0000approvedq\u0003X\t\u0000\u0000\u0000emergencyq\u0004X\u0004\u0000\u0000\u0000loopq\u0005X\u000e\u0000\u0000\u0000banned-addressq\u0006X\u0011\u0000\u0000\u0000member-moderationq\u0007e."'
Which is longer than the VARCHAR(255) MySQL field for that value prior
to <https://gitlab.com/mailman/mailman/merge_requests/333>.
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
8 years, 7 months
Re: Hyperkitty CPU usage
by Alain Kohli
I'm running a custom image which is based on an older version of the one
here: https://github.com/maxking/docker-mailman. I attached it below.
But I separated postorius and hyperkitty, so hyperkitty is running in
its own container. I'm deploying the image with a plain 'docker run'
behind nginx. I made fulltext_index persistent now, but it didn't get
populated with anything yet. I don't really have an error traceback
because there is never an error thrown. The only thing with some content
is uwsgi-error.log, which you can find below. I'm also still getting the
"A string literal cannot contain NUL (0x00) characters." messages. I
also noticed that it takes incredibly long for the webinterface to load
(several minutes) even though there doesn't seem to be any process
consuming notable resources apart from the minutely job.
Funnily enough, I have the exact same image deployed on a second server
as well for testing. On that one everything works fine. The only
difference is that on the problematic one I have a lot more mailing
lists/archives and that I imported them from mailman2. Could something
have gone wrong during the import? I used the regular hyperkitty_import
command.
uwsgi-error.log:
*** Starting uWSGI 2.0.18 (64bit) on [Sat Apr 27 22:50:17 2019] ***
compiled with version: 6.4.0 on 27 April 2019 22:48:42
os: Linux-4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19)
nodename: hyperkitty.docker
machine: x86_64
clock source: unix
detected number of CPU cores: 4
current working directory: /home/hyperkitty
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
setgid() to 82
setuid() to 82
chdir() to /home/hyperkitty
your memory page size is 4096 bytes
detected max file descriptor number: 1048576
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to TCP address 0.0.0.0:8081 fd 8
uwsgi socket 1 bound to TCP address 0.0.0.0:8080 fd 9
Python version: 3.6.8 (default, Jan 30 2019, 23:54:38) [GCC 6.4.0]
Python main interpreter initialized at 0x55dfaa41c980
python threads support enabled
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
[uwsgi-cron] command "./manage.py runjobs minutely" registered as
cron task
[uwsgi-cron] command "./manage.py runjobs quarter_hourly" registered
as cron task
[uwsgi-cron] command "./manage.py runjobs hourly" registered as cron
task
[uwsgi-cron] command "./manage.py runjobs daily" registered as cron task
[uwsgi-cron] command "./manage.py runjobs monthly" registered as
cron task
[uwsgi-cron] command "./manage.py runjobs weekly" registered as cron
task
[uwsgi-cron] command "./manage.py runjobs yearly" registered as cron
task
mapped 208576 bytes (203 KB) for 4 cores
*** Operational MODE: threaded ***
WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter
0x55dfaa41c980 pid: 1 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 1)
spawned uWSGI worker 1 (pid: 40, cores: 4)
Sat Apr 27 22:50:18 2019 - [uwsgi-cron] running "./manage.py runjobs
minutely" (pid 45)
[uwsgi-daemons] spawning "./manage.py qcluster" (uid: 82 gid: 82)
22:50:21 [Q] INFO Q Cluster-47 starting.
22:50:21 [Q] INFO Process-1:1 ready for work at 59
22:50:21 [Q] INFO Process-1:2 ready for work at 60
22:50:21 [Q] INFO Process-1:3 ready for work at 61
22:50:21 [Q] INFO Process-1:4 ready for work at 62
22:50:21 [Q] INFO Process-1:5 monitoring at 63
22:50:21 [Q] INFO Process-1 guarding cluster at 58
22:50:21 [Q] INFO Process-1:6 pushing tasks at 64
22:50:21 [Q] INFO Q Cluster-47 running.
22:59:31 [Q] INFO Enqueued 3403
22:59:31 [Q] INFO Process-1:1 processing [update_from_mailman]
22:59:33 [Q] INFO Processed [update_from_mailman]
Sat Apr 27 23:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs
quarter_hourly" (pid 73)
Sat Apr 27 23:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs
hourly" (pid 74)
[uwsgi-cron] command "./manage.py runjobs quarter_hourly" running
with pid 73 exited after 64 second(s)
23:01:28 [Q] INFO Enqueued 3404
23:01:29 [Q] INFO Process-1:2 processing
[rebuild_mailinglist_cache_recent]
[uwsgi-cron] command "./manage.py runjobs hourly" running with pid
74 exited after 91 second(s)
Sat Apr 27 23:01:36 2019 - uwsgi_response_write_body_do(): Broken
pipe [core/writer.c line 341] during GET / (212.203.58.154)
OSError: write error
23:01:36 [Q] INFO Processed [rebuild_mailinglist_cache_recent]
Sat Apr 27 23:15:00 2019 - [uwsgi-cron] running "./manage.py runjobs
quarter_hourly" (pid 88)
[uwsgi-cron] command "./manage.py runjobs quarter_hourly" running
with pid 88 exited after 4 second(s)
23:28:24 [Q] INFO Enqueued 3405
23:28:24 [Q] INFO Process-1:3 processing [update_from_mailman]
23:28:25 [Q] INFO Processed [update_from_mailman]
Sat Apr 27 23:30:00 2019 - [uwsgi-cron] running "./manage.py runjobs
quarter_hourly" (pid 96)
[uwsgi-cron] command "./manage.py runjobs quarter_hourly" running
with pid 96 exited after 4 second(s)
23:44:40 [Q] INFO Enqueued 3406
23:44:40 [Q] INFO Process-1:4 processing [update_from_mailman]
23:44:41 [Q] INFO Processed [update_from_mailman]
Sat Apr 27 23:45:00 2019 - [uwsgi-cron] running "./manage.py runjobs
quarter_hourly" (pid 104)
[uwsgi-cron] command "./manage.py runjobs quarter_hourly" running
with pid 104 exited after 4 second(s)
Sun Apr 28 00:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs
quarter_hourly" (pid 113)
Sun Apr 28 00:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs
hourly" (pid 114)
Sun Apr 28 00:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs
daily" (pid 115)
Sun Apr 28 00:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs
weekly" (pid 116)
[uwsgi-cron] command "./manage.py runjobs quarter_hourly" running
with pid 113 exited after 55 second(s)
[uwsgi-cron] command "./manage.py runjobs weekly" running with pid
116 exited after 55 second(s)
00:01:36 [Q] INFO Enqueued 3407
00:01:36 [Q] INFO Process-1:1 processing
[rebuild_mailinglist_cache_recent]
[uwsgi-cron] command "./manage.py runjobs hourly" running with pid
114 exited after 99 second(s)
00:01:50 [Q] INFO Processed [rebuild_mailinglist_cache_recent]
00:04:52 [Q] INFO Enqueued 3408
00:04:52 [Q] INFO Process-1:2 processing [update_from_mailman]
00:04:54 [Q] INFO Processed [update_from_mailman]
Dockerfile:
FROM python:3.6-alpine3.7 # Add startup script to container COPY
assets/docker-entrypoint.sh /usr/local/bin/ # Install packages and
dependencies for hyperkitty and add user for executing apps. # It's
important that the user has the UID/GID 82 so nginx can access the
files. RUN set -ex \&& apk add --no-cache --virtual .build-deps gcc
libc-dev linux-headers git \postgresql-dev \&& apk add --no-cache
--virtual .mailman-rundeps bash sassc mailcap \postgresql-client
curl \&& pip install -U django==2.2 \&& pip install
git+https://gitlab.com/eestec/mailmanclient
\git+https://gitlab.com/mailman/hyperkitty@c9fa4d4bfc295438d3e01cd93090064d004cf44d
\git+https://gitlab.com/eestec/django-mailman3 \whoosh \uwsgi
\psycopg2 \dj-database-url \typing \&& apk del .build-deps \&&
addgroup -S -g 82 hyperkitty \&& adduser -S -u 82 -G hyperkitty
hyperkitty \&& chmod u+x /usr/local/bin/docker-entrypoint.sh# Add
needed files for uwsgi server + settings for django COPY
assets/__init__.py /home/hyperkittyCOPY assets/manage.py
/home/hyperkittyCOPY assets/urls.py /home/hyperkittyCOPY
assets/wsgi.py /home/hyperkittyCOPY assets/uwsgi.ini
/home/hyperkittyCOPY assets/settings.py /home/hyperkitty# Change
ownership for uwsgi+django files and set execution rights for
management script RUN chown -R hyperkitty /home/hyperkitty && chmod
u+x /home/hyperkitty/manage.py# Make sure we are in the correct
working dir WORKDIR /home/hyperkittyEXPOSE 8080 8081# Use stop
signal for uwsgi server STOPSIGNAL SIGINTENTRYPOINT
["docker-entrypoint.sh"]CMD ["uwsgi", "--ini",
"/home/hyperkitty/uwsgi.ini"]
On 4/27/19 7:58 PM, Abhilash Raj wrote:
> On Sat, Apr 27, 2019, at 9:40 AM, Alain Kohli wrote:
>> I have run "python manage.py rebuild_index" before, doesn't that do
>> clear_index as well? Apart from that, I run hyperkitty in a docker
>> container and didn't know fulltext_index should be persistent, so that
>> got deleted after every version update for sure.
> Which images are you using and how are you deploying them?
>
> You should persist fulltext_index, yes, and possibly logs if you need
> them for debugging later.
>
> Can you paste the entire error traceback?
>
>>
>> On 4/26/19 10:18 PM, Mark Sapiro wrote:
>>> On 4/26/19 11:14 AM, Alain Kohli wrote:
>>>> I see loads of "A string literal cannot contain NUL (0x00) characters."
>>>> messages, but I haven't found missing messages in the archives yet. Not
>>>> sure how that could be related, though. Apart from that I don't see
>>>> anything unusual. The other jobs (quarter_hourly, hourly, etc.) seem to
>>>> run and finish normally.
>>> Did you upgrade from a Python 2.7 version of HyperKitty to a Python 3
>>> version? The Haystack/Whoosh search engine databases are not compatible
>>> between the two and "A string literal cannot contain NUL (0x00)
>>> characters." is the symptom.
>>>
>>> You need to run 'python manage.py clear_index' or just remove all the
>>> files from the directory defined as 'PATH' under HAYSTACK_CONNECTIONS in
>>> your settings file (normally 'fulltext_index' in the same directory that
>>> contains your settings.py.
>>>
>> _______________________________________________
>> 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/
>>
7 years, 5 months
Re: UnicodeEncodeError: 'ascii' codec can't encode character
by Stephen J. Turnbull
Marvin Gülker writes:
> Am 10. Dezember 2019 um 17:09 Uhr +0900 schrieb Stephen J. Turnbull:
> > You're the "it's 2019, let's use SMTP UTF8 everywhere" guy, right?
>
> No, I'm not that guy.
I'm sorry about that. I knew I didn't know for sure, but not being
able to get at the moderation queue seemed urgent enough to be worth
the chance of being wrong.
> I have not used it, but it turns out that it is enabled by
> default. I can turn it off and see if that makes any difference in
> the future. Testing with telnet, Postfix indeed announced "250
> SMTPUTF8" on EHLO.
>
> > If you're right about the umlaut being the trigger, the first
> > thing I'd look at is a feature-negotiation problem in the MTA
> > delivering to Mailman. I'm pretty sure our LMTP does not offer
> > the SMTP UTF8 feature.
>
> In that case the problem should go away with disabling SMTPUTF8, I
> suppose?
Well, since it's predicated on a bug in Postfix, I wouldn't bet on it,
especially since Postfix probably dominates Mailman 3 installations.
But it's cheap to test, and since you don't explicitly want SMTP UTF8
at this point, little harm in turning it off. *If* there is a bug,
that will prevent the problem in the future, but it wouldn't fix the
problem in the held messages queue.
> > I would guess this is in the shunt queue. If there's only one
> > file there, you can just delete it.
This was a bad guess. I'm not sure why it isn't in the shunt queue
(it shouldn't have been able to escape into the main rule chains with
that bad breakage in the header), but Mailman doesn't try to moderate
shunted messages, that's the whole point of the shunt queue -- they're
out of the way.
> There was a whole bunch of files in that directory. I've taken a look
> several of them, and as they were all spam, I've taken the liberty to
> delete them all (this list is so low volume that I know all the senders
> personally anyway).
A tiny bit of good came of it, at least.
> However, even after restarting mailman, the 500 error persists when
> visiting the held messages page in postorius.
>
> I've also looked into all the other queue directories, they were all
> empty.
I guess it's in the MessageStore, then, which is by default in
/var/tmp/mailman/messages/. (Defined in schema.cfg.) I guess it's a
standard qfile that you can examine with "mailman qfiles
/path/to/file". (I've never actually looked at a "raw" held message
file in Mailman 3, haven't had a failure of this type.) If not, you
can unpickle it with Python (if that makes no sense to you, ask; I'm
running out of steam and need sleep).
> > Assuming you're right about your name being the trigger, U+FFFD
> > REPLACEMENT CHARACTER is not in your name.
I'm starting to wonder about this. It's still possible, but if you
don't deliberately use SMTP UTF8 then your mail client probably
doesn't either, and equally possibly it's a different message causing
the problem (something spammy).
6 years, 10 months
Re: Moderation action "None" is misleading
by Stephen J. Turnbull
Adding mailman-users(a)mailman3.org.
Technical suggestions should go to distro channels or to Mailman's
issue tracker: https://gitlab.com/mailman/mailman/-/issues/1176.
Further discussion of technical details is best done there.
Thomas Krichel writes:
> Stephen J. Turnbull writes
> > Debian has traditionally been quite slow to update Mailman,
>
> And now it has the addition issue that Debian testing python
> standard it 3.13, so the nntplib is no longer supported.
> Thus the current Mailman debian testing appears broken.
That's Debian's problem, as we currently don't support Python 3.13,
although of course we intend to. This is the only issue that came up
in a quick search of Mailman's issue tracker for Python 3.13 (but I
did not check the other subprojects such as Postorius). I conclude
that not a lot of work has been done on supporting Python 3.13 (rather
than the optimistic "there's nothing to be done"). From Mailman's
point of view, users have two excellent options for the forseeable
future: (1) don't gateway list <-> newsgroups (2) install Mailman into
a Python 3.9--3.12 virtual environment.
I'm sympathetic to the needs of the Debian developers, and at this
point for 99% of software it's perfectly reasonable to aim to use 3.13
in the next Debian release. Unfortunately for Mailman users on Debian
hosts that's not high on our list of priorities since we recommend a
virtual environment installation in any case.
At present there seem to be three ways forward for Debian packaging:
1. Remove NNTP support. (In honor of larsi, I'd rather not.)
2. Add nntplib.py from the Python 3.12 nntplib, as a stopgap until
option 3 can be implemented. I can't speak for other developers
but we might be willing to add it as a contrib module, especially
if that might make life easier for distro packagers. It's
suboptimal though since that absolutely has to be considered
techical debt that will need to be paid someday.
3. Port Mailman to pynntp (that may need to be Debian packaged, too),
which has seen a revival of activity and two feature releases
since 2023.
My inclination as a Mailman core developer is not to participate
actively in development of NNTP support in Mailman for Python 3.13+
unless we see an outpouring of support from site admins. However, I
would be happy to answer questions and work on Mailman-side issues
that are blocking or inconvenient for the NNTP work. Mark and
Abhilash would undoubtedly contribute as well, on a time-available
basis.
> I certainly would love to build an alternative Mailman Debian
> package that would be more up-to-date, but I don't want
> to do it on my own.
Debian and Python are compatible free software; just take the existing
package metadata, in a recent Mailman (presumably the most recent
release) drop in the most recent nntplib, and change all the import
statements. mailman/src/mailman/mta/nntplib.py seems like a plausible
location. IWBNI you could keep all Mailmanisms out of nntplib
(because of the GPL) so any bugfixes or improvements could be
available to the Python community.
I think you could probably be up and running VERY quickly with that
approach. Of course it wouldn't just slot into the next iteration of
Debian because they have stringent QA (or maybe that could go into
unstable?). I'm pretty sure it would be useful right away to a whole
lot of people who are willing to use a PPA.
Regards,
Steve
1 year, 8 months
Re: HYPERKITTY_ATTACHMENT_FOLDER
by Abhilash Raj
On Wed, Sep 11, 2019, at 12:47 PM, Ugnius S wrote:
> Could You please confirm that this parameter should be placed in mailman-hyperkitty.cfg file?
> I have checked mailman/postorius/hyperkitty owner user can write files there and web user group
> has privileges to write and to read, but *no any files appear there*. Mailman works, it is possible to download
> attachments from hyperkitty. Mailman restarted, uwsgi restarted, runjobs restarted. No files in
> /full/path/to/folder/
>
> File looks like:
>
> [general]
> base_url: https://flistserv.example.com/hyperkitty/
> api_key: BlaBlabla
>
> HYPERKITTY_ATTACHMENT_FOLDER = /full/path/to/folder/
No, this is supposed to go in your Django's configuration file, settings.py.
mailman-hyperkitty.cfg is used by Mailman Core to read config on how to archive emails in Hyperkitty. You need want to tell Hyperkitty to put attachments on disk and hence the changes are going to be "settings.py".
>
>
> BR
> Ugnius
>
>
> 2019-09-11, tr, 21:21 Ugnius S <ugniusviln(a)gmail.com> rašė:
>> Thank You so much.
>>
>> 1) https://hyperkitty.readthedocs.io/en/latest/install.html
>> Close to the end before the "UPDATE" topic, chapter "Customization".
>>
>> 2) https://buildmedia.readthedocs.org/media/pdf/hyperkitty/stable/hyperkitty.p…
>> Page 10, chapter 2.8 "Customization"
>>
>> BR
>> Ugnius
>>
>> 2019-09-11, tr, 20:16 Abhilash Raj <maxking(a)asynchronous.in> rašė:
>>>
>>>
>>> On Wed, Sep 11, 2019, at 9:52 AM, Ugnius S wrote:
>>> > Hi.
>>> >
>>> > Can anybody send example how to set it? It is mentioned in documentation,
>>> > but very vaguely.
>>>
>>> If you can point out where did you find it in docs, I can update it. Information is kind of duplicated in a few places.
>>>
>>> > HYPERKITTY_ATTACHMENT_FOLDER = /full/unix/path
>>>
>>> This is the right value.
>>>
>>> It is a path on the filesystem, where the user running Hyperkitty is allowed to write.
>>>
>>> >
>>> > HYPERKITTY_ATTACHMENT_FOLDER = http://localhost:8000/something
>>> >
>>> > HYPERKITTY_ATTACHMENT_FOLDER = ./var/data/something/
>>> >
>>> > Has anybody experience of using this, maybe have recommendations of using
>>> > it? Better under project user or better under web content owner where the
>>> > static content is. I would like to store attachments separately to avoid
>>> > growing database.
>>> > Hyperkitty documentation:
>>> > By default, HyperKitty stores the email attachments in the database. If
>>> > you would rather have them stored on the filesystem, you can set the
>>> > HYPERKITTY_ATTACHMENT_FOLDER configuration value to a directory.
>>> > Make sure that the user running the Django process (for example, apache or
>>> > www-data) has the permissions to write in this directory.
>>> >
>>> > -------------
>>> > _______________________________________________
>>> > 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/
--
thanks,
Abhilash Raj (maxking)
7 years, 1 month
Re: About to Install MM3 -- Seeking clarification
by Onyeibo Oku
Hi Mark, thanks for your inputs. I am making progress.
On January 2, 2023 9:15:59 PM GMT+01:00, Mark Sapiro <mark(a)msapiro.net> wrote:
>On 1/2/23 11:56, Onyeibo wrote:
>> On Mon, 2 Jan 2023 09:57:45 -0800
>> Mark Sapiro <mark(a)msapiro.net> wrote:
>>>
>>> curl -urestadmin:restpass http://localhost:8001/3.1/lists
>>>
>>> It should return JSON with information about your lists.
>>>
>>
>> I get the following:
>> {"start": 0, "total_size": 0, "http_etag":
>> "\"678678567346533573674563786538\""}
>
>That is the expected response if you have no lists yet. So connection to
>Mailman's REST API works via curl, so why doesn't it work via
>mailmanclient? If Mailman core was running, it should work. I don't know
>why it doesn't. Perhaps you have some kind of firewall that's blocking it.
>
It turns out to be a fault from my settings. Postfix was not happy
with the default email for the admin (<root@localhost>) since I had
an operational virtual map for users. That connection error
disappeared when I added a functioning admin email address.
There are other issues, however.
(1) Mailman refuses to resolve to a preferred subdomain. If the
server's domain is "website.tld", I'd like mailman's homepage to be
at "list.website.tld". Mailman insists that I add "website.tld" to
the ALLOWED HOSTS, whereas "lists.website.tld" is already there as an
ALLOWED HOST (same VPS/IP address nonetheless). The result is that
the homepage ends up at "https://website.tld/mailman3/lists" when the
desired url is "https://lists.website.tld/mailman3/lists". This is a
conflict because the main domain is intended for another service. How
do I approach this?
(2) See the traceback below:
ERROR 2023-01-03 07:40:32,078 27926 django.request Internal Server
Error: /mailman3/lists/ Traceback (most recent call last):
File
"/opt/mailman/venv/lib64/python3.10/site-packages/django/core/handlers/exception.py",
line 55, in inner response = get_response(request) File
"/opt/mailman/venv/lib64/python3.10/site-packages/django/core/handlers/base.py",
line 197, in _get_response response = wrapped_callback(request,
*callback_args, **callback_kwargs) File
"/opt/mailman/venv/lib64/python3.10/site-packages/postorius/views/list.py",
line 980, in list_index return render(request, template, File
"/opt/mailman/venv/lib64/python3.10/site-packages/django/shortcuts.py",
line 24, in render content = loader.render_to_string(template_name,
context, request, using=using) File
"/opt/mailman/venv/lib64/python3.10/site-packages/django/template/loader.py",
line 62, in render_to_string return template.render(context, request)
File
"/opt/mailman/venv/lib64/python3.10/site-packages/django/template/backends/django.py",
line 62, in render return self.template.render(context) File
"/opt/mailman/venv/lib64/python3.10/site-packages/django/template/base.py",
line 173, in render with context.bind_template(self): File
"/usr/lib64/python3.10/contextlib.py", line 135, in enter return
next(self.gen) File
"/opt/mailman/venv/lib64/python3.10/site-packages/django/template/context.py",
line 254, in bind_template updates.update(processor(self.request)) File
"/opt/mailman/venv/lib64/python3.10/site-packages/django_mailman3/context_processors.py",
line 32, in common context["site_name"] =
get_current_site(request).name File
"/opt/mailman/venv/lib64/python3.10/site-packages/django/contrib/sites/shortcuts.py",
line 16, in get_current_site return Site.objects.get_current(request)
File
"/opt/mailman/venv/lib64/python3.10/site-packages/django/contrib/sites/models.py",
line 59, in get_current return self._get_site_by_id(site_id) File
"/opt/mailman/venv/lib64/python3.10/site-packages/django/contrib/sites/models.py",
line 30, in _get_site_by_id site = self.get(pk=site_id) File
"/opt/mailman/venv/lib64/python3.10/site-packages/django/db/models/manager.py",
line 85, in manager_method return getattr(self.get_queryset(),
name)(*args, **kwargs) File
"/opt/mailman/venv/lib64/python3.10/site-packages/django/db/models/query.py",
line 650, in get raise self.model.DoesNotExist(
django.contrib.sites.models.Site.DoesNotExist: Site matching query does
not exist.
It seems a migration is missing. How should I approach this?
3 years, 9 months
Re: HYPERKITTY_ATTACHMENT_FOLDER
by Ugnius S
OK, I got it, resolved.
I can confirm that adding this syntax line to /project/home settings.py or
settings_local.py it works:
HYPERKITTY_ATTACHMENT_FOLDER = '/full/path/to/folder/'
Thank you Abhilash
Kind regards
Ugnius
2019-09-11, tr, 22:50 Abhilash Raj <maxking(a)asynchronous.in> rašė:
>
>
> On Wed, Sep 11, 2019, at 12:47 PM, Ugnius S wrote:
>
> Could You please confirm that this parameter should be placed in
> mailman-hyperkitty.cfg file?
> I have checked mailman/postorius/hyperkitty owner user can write files
> there and web user group
> has privileges to write and to read, but *no any files appear there*.
> Mailman works, it is possible to download
> attachments from hyperkitty. Mailman restarted, uwsgi restarted, runjobs
> restarted. No files in
> /full/path/to/folder/
>
> File looks like:
>
> [general]
> base_url: https://flistserv.example.com/hyperkitty/
> api_key: BlaBlabla
>
> HYPERKITTY_ATTACHMENT_FOLDER = /full/path/to/folder/
>
>
>
> No, this is supposed to go in your Django's configuration file,
> settings.py.
>
> mailman-hyperkitty.cfg is used by Mailman Core to read config on how to
> archive emails in Hyperkitty. You need want to tell Hyperkitty to put
> attachments on disk and hence the changes are going to be "settings.py".
>
>
>
> BR
> Ugnius
>
>
> 2019-09-11, tr, 21:21 Ugnius S <ugniusviln(a)gmail.com> rašė:
>
> Thank You so much.
>
> 1) https://hyperkitty.readthedocs.io/en/latest/install.html
> Close to the end before the "UPDATE" topic, chapter "Customization".
>
> 2)
> https://buildmedia.readthedocs.org/media/pdf/hyperkitty/stable/hyperkitty.p…
> Page 10, chapter 2.8 "Customization"
>
> BR
> Ugnius
>
> 2019-09-11, tr, 20:16 Abhilash Raj <maxking(a)asynchronous.in> rašė:
>
>
>
> On Wed, Sep 11, 2019, at 9:52 AM, Ugnius S wrote:
> > Hi.
> >
> > Can anybody send example how to set it? It is mentioned in documentation,
> > but very vaguely.
>
> If you can point out where did you find it in docs, I can update it.
> Information is kind of duplicated in a few places.
>
> > HYPERKITTY_ATTACHMENT_FOLDER = /full/unix/path
>
> This is the right value.
>
> It is a path on the filesystem, where the user running Hyperkitty is
> allowed to write.
>
> >
> > HYPERKITTY_ATTACHMENT_FOLDER = http://localhost:8000/something
> >
> > HYPERKITTY_ATTACHMENT_FOLDER = ./var/data/something/
> >
> > Has anybody experience of using this, maybe have recommendations of using
> > it? Better under project user or better under web content owner where the
> > static content is. I would like to store attachments separately to avoid
> > growing database.
> > Hyperkitty documentation:
> > By default, HyperKitty stores the email attachments in the database.
> If
> > you would rather have them stored on the filesystem, you can set the
> > HYPERKITTY_ATTACHMENT_FOLDER configuration value to a directory.
> > Make sure that the user running the Django process (for example, apache
> or
> > www-data) has the permissions to write in this directory.
> >
> > -------------
> > _______________________________________________
> > 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/
>
>
> --
> thanks,
> Abhilash Raj (maxking)
>
>
>
7 years, 1 month
Re: Apache+mod_wsgi issue
by Mark Sapiro
On 12/22/22 22:26, Odhiambo Washington wrote:
> On Fri, Dec 23, 2022 at 9:21 AM Odhiambo Washington <odhiambo(a)gmail.com>
> wrote:
>
>> And now I am having a problem with mod_wsgi.
>> First, the URL displayed when I load the page looks bogus to me.
>> While I expect the URL to be
>> https://mm3-lists.kictanet.or.ke/mailman3/domains/, mod_wsgi give me
>> https://mm3-lists.kictanet.or.ke/mailman3/mailman3/domains/ - there is an
>> extra /mailman3!
See below:
>> So I have;
>> 1. https://mm3-lists.kictanet.or.ke/mailman3/mailman3/lists/ - working,
>> or appears to.
>> 2. https://mm3-lists.kictanet.or.ke/mailman3/mailman3/domains/ - working,
>> or appears to.
>> 3. https://mm3-lists.kictanet.or.ke/mailman3/mailman3/bans/ - working, or
>> appears to
>> 4. https://mm3-lists.kictanet.or.ke/mailman3/mailman3/users - working, or
>> appears to
>> 5.
>> https://mm3-lists.kictanet.or.ke/mailman3/mailman3/lists/kictanet.lists.kic…
>> - This throws an exception error when I click "Manage Subscription".
>>
>> -> https://pastebin.ubuntu.com/p/RkKH793Jgw/
messages like these
[Fri Dec 23 09:10:55.393386 2022] [wsgi:error] [pid 74857] [remote
197.232.81.246:14181] File
"/opt/mailman/mm/venv/lib/python3.9/site-packages/mailmanclient/restbase/connection.py",
line 160, in call
[Fri Dec 23 09:10:55.393390 2022] [wsgi:error] [pid 74857] [remote
197.232.81.246:14181] raise HTTPError(params.get('url'),
response.status_code,
[Fri Dec 23 09:10:55.393394 2022] [wsgi:error] [pid 74857] [remote
197.232.81.246:14181] urllib.error.HTTPError: HTTP Error 500: {"title":
"500 Internal Server Error"}
Indicate an uncaught exception in Mailman core. What's in mailman.log?
>> And while I do not quite understand the error itself, there is also one
>> particular line that I also saw that has left me baffled:
>> [Fri Dec 23 08:53:18.290411 2022] [core:info] [pid 91236] [client
>> 197.232.81.246:13865] AH00128: File does not exist:
>> /usr/local/www/apache24/data/archives/list/
>> kictanet(a)lists.kictanet.or.ke/thread/VIHCC6MSXZSNHY7YPEJ3D2US4N7MHJEC/,
>> referer:
>> https://mm3-lists.kictanet.or.ke/archives/list/kictanet@lists.kictanet.or.ke
This is because something is doing an HTTP GET for
`/archives/list/kictanet(a)lists.kictanet.or.ke/thread/VIHCC6MSXZSNHY7YPEJ3D2US4N7MHJEC/`
and the URL is not recognized as one handled by mod_wsgi so apache tries
to get it from its DocumentRoot.
mod_wsgi has to serve a number of URLs. Look in /opt/mailman/mm/urls.py
for urlpatterns. You will probably see things like
url(r'^accounts/', include('allauth.urls')),
# Django admin
url(r'^admin/', admin.site.urls),
url(r'^mailman3/', include('postorius.urls')),
url(r'^archives/', include('hyperkitty.urls')),
Those are all things that need to be handled by mod_wsgi
In your apache config, you only have a WSGIScriptAlias for /mailman3.
Thus paths need to be prefixed with /mailman3 in order to be handled by
mod_wsgi. I'm not sure what is doing this prefixing, but without it
paths that don't begin with /mailman3 don't work unless you also have
things like
WSGIScriptAlias /accounts /opt/mailman/mm/wsgi.py
WSGIScriptAlias /admin /opt/mailman/mm/wsgi.py
WSGIScriptAlias /archives /opt/mailman/mm/wsgi.py
in your apache config.
> I also need to add the fact that at the point where I am clicking "Manage
> Subscription", the URL has changed to
> https://mm3-lists.kictanet.or.ke/mailman3/archives/list/kictanet@lists.kict…
> (just a single /mailman3).
>
Something is adding mailman3/ to URLs. In the above the URL should be
https://mm3-lists.kictanet.or.ke/archives/list/kictanet@lists.kictanet.or.k…,
but an extra /mailman3 is added. The others are like
https://mm3-lists.kictanet.or.ke/mailman3/lists/ and an extra /mailman3
is added.
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
3 years, 9 months