Search results for query "sapiro"
- 6281 messages
[MM3-users] Re: Archiver "prototype" and disabling archiving at all
by Torge Riedel
Am 28.03.19 um 17:45 schrieb Abhilash Raj:
> On Thu, Mar 28, 2019, at 9:18 AM, Torge Riedel wrote:
>> Am 24.03.19 um 16:49 schrieb Mark Sapiro:
>>> On 3/24/19 5:40 AM, Torge Riedel wrote:
>>>> in the settings of a mailing list I can choose two archivers:
>>>> "Hyperkitty" and "prototype". What is this archive "prototype" and how
>>>> can I disable/remove/deinstall it? And how can I disable archiving at
>>>> all, so no archiver can be chosen in the settings.
>>> The prototype archiver stores messages individually in
>>> var/archives/prototype/LIST_NAME/.
>>>
>>> You can disable the prototype archiver by putting
>>>
>>> [archiver.prototype]
>>> enable: no
>>>
>>> in your mailman.cfg. To disable all archiving, just remove all the
>>> [archiver.*] sections from your mailman.cfg or set them to 'enable: no'
>>>
>>>
>> Hi Mark,
>>
>> thanks. This disabled the archivers, but there is still the "Archives"
>> link on top of the page. Is it possible to remove it? Cause there is
>> nothing to see there. I tried commenting "'hyperkitty'," in
>> INSTALLED_APPS, but then I got a 500.
> INSTALLED_APPS = (
> 'postorius',
> 'django_mailman3',
> # Uncomment the next line to enable the admin:
> 'django.contrib.admin',
> # Uncomment the next line to enable admin documentation:
> # 'django.contrib.admindocs',
> 'django.contrib.auth',
> 'django.contrib.contenttypes',
> 'django.contrib.sessions',
> 'django.contrib.sites',
> 'django.contrib.messages',
> 'django.contrib.staticfiles',
> 'django_gravatar',
> 'allauth',
> 'allauth.account',
> 'allauth.socialaccount',
> )
>
>
> This is how it should look like if you want to remove Hyperkitty. There
> are a few other settings you should remove.
>
> https://gitlab.com/mailman/postorius/blob/master/example_project/settings.py
>
> This is a Postorius only configuration for reference.
>
>
>> _______________________________________________
>> 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/
>>
Hi,
I gave it a try, but I was not able to disable hyperkitty. I compared the settings in the link you gave and I see a lot of differences. Some of them I am not sure why they are missing in other example settings.
Currently I would say, I will keep the archive link there until it is more clear for me how to set things up. Since archiving is disabled, there will be no data in the archive. That is okay for the moment.
Regards
Torge
7 years, 3 months
[MM3-users] Re: Hyperkitty not receaving messages / empty archive [Django] ERROR (EXTERNAL IP): Internal Server Error: /hyperkitty/api/mailman/urls
by Helge Baumgart
Hello Mark,
THANK You for identifying MY typos.... how embarrassing. :-)
Now ist running like a charm.
It's always the same...
These Variables are setting the internal Values via the docker-compose.yml.
If they do not match, the internal variables are not set.
Therefor my typo H*A*YPERKITTY_API_KEY =! HYPERKITTY_API_KEY caused,
that the mailman-web section of the docker-compose.yml had NO Hyperkitty
API- KEY.
I suspected something like that, that's why i set the key via the .env
variabels to ensure
identical values in all sections oft the docker.compose.yml.
I didn't check the name of the variables...
Thx again!
Best wishes
Helge
Ps.:
That docker-compose.yml with the settings_locale.py and
mailman_extra.cfg basically setts a complete deployable environment
INCLUDING the MTA,
which is independent of the host...
Am 22.01.2025 um 06:36 schrieb Mark Sapiro:
> On 1/21/25 05:44, Helge Baumgart wrote:
>
>> Hyperkitty-Api-Key in the docker-compose.yml is set via .env
>> Variabel, so it should be identical.
>
>
> I don't know how this works in the Docker image, but ...
>
>> Traceback (most recent call last):
>> File
>> "/usr/lib/python3.11/site-packages/django/core/handlers/exception.py",
>> line 56, in inner
>> response = get_response(request)
>> File
>> "/usr/lib/python3.11/site-packages/django/core/handlers/base.py",
>> line 197, in _get_response
>> response = wrapped_callback(request, *callback_args,
>> **callback_kwargs)
>> File
>> "/usr/lib/python3.11/site-packages/hyperkitty/views/mailman.py", line
>> 109, in _decorator
>> not hmac.compare_digest(
>>
>> Exception Type: TypeError at /hyperkitty/api/mailman/urls
>> Exception Value: unsupported operand types(s) or combination of
>> types: 'str' and 'NoneType'
>
> The above code is doing
>
> auth = authorization.split()
> if (len(auth) != 2 or auth[0] != 'Token' or
> not hmac.compare_digest(
> auth[1], settings.MAILMAN_ARCHIVER_KEY)):
>
>
> and the exception says either auth[0] is None or auth[1] or
> settings.MAILMAN_ARCHIVER_KEY is None.
>
> But
>
>> META:
> ...
>> HTTP_AUTHORIZATION = 'Token (value)'
> and
>
>> Settings:
>> Using settings module settings
> ...
>> MAILMAN_ARCHIVER_KEY = '********************'
>
> So The Authorization header is the appropriate `Token value` which
> should result in auth[0] being 'Token', auth[1] being the value and
> MAILMAN_ARCHIVER_KEY is set
>
>> That is my docker-compose.yml:
> ...
>> mailman-web:
> ...
>> - HAYPERKITTY_API_KEY=${MM3_HYPERKITTY_API_KEY}
>> #someapikey_longAndTrustworty
>
>
> I don't really understand why the above typo (HAYPERKITTY_API_KEY, not
> HYPERKITTY_API_KEY) would cause this error, but it needs to be fixed.
>
1 year, 6 months
[MM3-users] Re: Welcome message template errors
by Mark
On 2024-04-22 14:07, Mark Sapiro wrote:
> I think you must be setting the custom template via Postorius and
> your Django setting for POSTORIUS_TEMPLATE_BASE_URL is wrong. It
> should be set to the scheme and host you use to access Postorius. I.e,
> if you normally access Postorius via something like
> https://example.com/mailman3 set
>
> POSTORIUS_TEMPLATE_BASE_URL = 'https://example.com'
>
> It is probably now set as
>
> POSTORIUS_TEMPLATE_BASE_URL = 'http://<REDACTED-PUBLIC-IPv4-ADDRESS>'
================================================================================
There was no line POSTORIUS_TEMPLATE_BASE_URL in
/etc/mailman3/settings.py
So I've now added the line: POSTORIUS_TEMPLATE_BASE_URL =
'https://lists.mydomain.com'
Checked in settings.py that:
- "lists.mydomain.com" is in ALLOWED_HOSTS; and
- "https://lists.mydomain.com" is in CSRF_TRUSTED_ORIGINS
Restarted everything...
rm /opt/mailman/mm/var/locks/*
systemctl restart mailman3
systemctl restart mailmanweb
systemctl daemon-reload
systemctl restart qcluster
# pstree
systemd─┬─
├─gunicorn───gunicorn
├─mailman-web───mailman-web───4*[mailman-web]
├─nginx───2*[nginx]
├─postgres───18*[postgres]
├─python3─┬─11*[python3]
│ ├─python3───{python3}
│ └─python3───2*[python3]
I deleted the custom Welcome template via the WebUI (Postorius), and
checked it was removed from the database (PostGres mailman.template).
Then, as site-owner, creating a new custom Welcome template (again via
the WebUI) I can see it correctly added to the database in
mailman.template.uri
-
https://lists.mydomain.com/mailman3/api/templates/list/lists.mydomain.com/l…
Previously it was writing ...
-
http://localhost:8000/mailman3/api/templates/list/lists.mydomain.com/list:u…
So far so good. Nothing showing in mailmanweb.log yet.
Then, still as site-owner using Postorius, I mass-subscribed a new
member (pre confirm, pre approve, pre verify all ticked).
The error below displays on the webpage, the member is subscribed, but
no custom welcome message emailed out.
===================================
HTTP Error 400: HTTPSConnectionPool(host='lists.mydomain.com',
port=443): Read timed out. (read timeout=5)
===================================
And the syslog shows a ton of issues, starting with:
===================================
2024-04-22T23:39:27.536002+00:00 lists mailman[1317]: Apr 22 23:39:27
2024 (1317) HTTPSConnectionPool(host='<LISTS.MYDOMAIN.COM>', port=443):
Read timed out. (read timeout=5)
2024-04-22T23:39:27.537648+00:00 lists mailman[1317]: Traceback (most
recent call last):
2024-04-22T23:39:27.537681+00:00 lists mailman[1317]: File
"/opt/mailman/venv/lib/python3.11/site-packages/urllib3/connectionpool.py",
line 536, in _make_request
2024-04-22T23:39:27.537700+00:00 lists mailman[1317]: response =
conn.getresponse()
2024-04-22T23:39:27.537717+00:00 lists mailman[1317]:
^^^^^^^^^^^^^^^^^^
2024-04-22T23:39:27.537740+00:00 lists mailman[1317]: File
"/opt/mailman/venv/lib/python3.11/site-packages/urllib3/connection.py",
line 461, in getresponse
2024-04-22T23:39:27.537757+00:00 lists mailman[1317]:
httplib_response = super().getresponse()
2024-04-22T23:39:27.537772+00:00 lists mailman[1317]:
^^^^^^^^^^^^^^^^^^^^^
2024-04-22T23:39:27.537790+00:00 lists mailman[1317]: File
"/usr/lib/python3.11/http/client.py", line 1374, in getresponse
===================================
I removed the custom welcome message and the newly subscribed members.
The default "You've been unsubscribed" notice got emailed out okay.
Then mass subscribing a member, the default welcome message gets emailed
out okay and no error displayed on the webpage.
I have no idea what the report in syslog is saying, or where to look
next. Any help appreciated.
2 years, 3 months
[MM3-users] Re: Mails are stuck in Mailman Pipeline Queue
by Shashikanth Komandoor
Thank you Mark for your response.
As you have listed all the runners are shown working fine.
I don't find any traceback during mailman service starting.
But the below trace back is observed during mailman service stopping:
Mar 27 09:01:19 2022 (5859) out runner caught SIGTERM. Stopping.
Mar 27 09:01:19 2022 (5859) out runner exiting.
Mar 27 09:01:19 2022 (5860) pipeline runner caught SIGTERM. Stopping.
Mar 27 09:01:19 2022 (5864) digest runner caught SIGTERM. Stopping.
Mar 27 09:01:19 2022 (5846) Master watcher caught SIGTERM. Exiting.
Mar 27 09:01:19 2022 (5858) nntp runner caught SIGTERM. Stopping.
Mar 27 09:01:19 2022 (5853) archive runner caught SIGTERM. Stopping.
Mar 27 09:01:19 2022 (5858) nntp runner exiting.
Mar 27 09:01:19 2022 (5853) archive runner exiting.
Mar 27 09:01:19 2022 (5854) bounces runner caught SIGTERM. Stopping.
Mar 27 09:01:19 2022 (5854) bounces runner exiting.
Mar 27 09:01:19 2022 (5855) command runner caught SIGTERM. Stopping.
Mar 27 09:01:19 2022 (5855) command runner exiting.
Mar 27 09:01:19 2022 (5863) virgin runner caught SIGTERM. Stopping.
Mar 27 09:01:19 2022 (5863) virgin runner exiting.
Mar 27 09:01:19 2022 (5862) retry runner caught SIGTERM. Stopping.
Mar 27 09:01:19 2022 (5862) retry runner exiting.
Mar 27 09:01:19 2022 (5857) lmtp runner caught SIGTERM. Stopping.
Mar 27 09:01:19 2022 (5857) lmtp runner exiting.
Mar 27 09:01:19 2022 (5856) in runner caught SIGTERM. Stopping.
Mar 27 09:01:19 2022 (5856) in runner exiting.
[2022-03-27 09:01:19 +0530] [5861] [INFO] Handling signal: term
[2022-03-27 09:01:19 +0530] [18009] [INFO] Worker exiting (pid: 18009)
[2022-03-27 09:01:19 +0530] [18004] [INFO] Worker exiting (pid: 18004)
[2022-03-27 09:01:21 +0530] [5861] [INFO] Shutting down: Master
Mar 27 09:01:22 2022 (5864) Uncaught runner exception:
Mar 27 09:01:22 2022 (5864) Traceback (most recent call last):
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py",
line 173, in _one_iteration
self._process_one_file(msg, msgdata)
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py",
line 266, in _process_one_file
keepqueued = self._dispose(mlist, msg, msgdata)
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/runners/digest.py",
line 332, in _dispose
digest_members = set(mlist.digest_members.members)
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/model/roster.py",
line 254, in members
DeliveryMode.summary_digests)
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/model/roster.py",
line 226, in _get_members
if member.delivery_mode in delivery_modes:
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/model/member.py",
line 205, in delivery_mode
return self._lookup('delivery_mode')
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/model/member.py",
line 167, in _lookup
pref = getattr(self.address.preferences, preference)
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/model/member.py",
line 117, in address
if self._address is None
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/orm/attributes.py",
line 287, in __get__
return self.impl.get(instance_state(instance), dict_)
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/orm/attributes.py",
line 723, in get
value = self.callable_(state, passive)
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/orm/strategies.py",
line 760, in _load_for_state
session, state, primary_key_identity, passive
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py",
line 114, in signal_handler
raise RunnerInterrupt
mailman.interfaces.runner.RunnerInterrupt
Mar 27 09:01:22 2022 (5864) SHUNTING: 1648351882.6693938+
c2e6ed709646a7680c73059b52d2f0451836e591
Mar 27 09:01:22 2022 (5864) digest runner exiting.
Mar 27 09:01:22 2022 (5860) Uncaught runner exception:
Mar 27 09:01:22 2022 (5860) Traceback (most recent call last):
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py",
line 173, in _one_iteration
self._process_one_file(msg, msgdata)
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py",
line 266, in _process_one_file
keepqueued = self._dispose(mlist, msg, msgdata)
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/runners/pipeline.py",
line 37, in _dispose
process(mlist, msg, msgdata, pipeline)
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/core/pipelines.py",
line 50, in process
handler.process(mlist, msg, msgdata)
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/
mailman/handlers/member_recipients.py", line 84, in process
for member in mlist.regular_members.members
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/
mailman/handlers/member_recipients.py", line 83, in <genexpr>
recipients = set(member.address.email
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/model/roster.py",
line 239, in members
yield from self._get_members(DeliveryMode.regular)
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/model/roster.py",
line 226, in _get_members
if member.delivery_mode in delivery_modes:
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/model/member.py",
line 205, in delivery_mode
return self._lookup('delivery_mode')
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/model/member.py",
line 167, in _lookup
pref = getattr(self.address.preferences, preference)
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/orm/attributes.py",
line 287, in __get__
return self.impl.get(instance_state(instance), dict_)
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/orm/attributes.py",
line 723, in get
value = self.callable_(state, passive)
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/orm/strategies.py",
line 760, in _load_for_state
session, state, primary_key_identity, passive
File "<string>", line 1, in <lambda>
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/orm/strategies.py",
line 850, in _emit_lazyload
session.query(self.mapper), primary_key_identity
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/ext/baked.py",
line 603, in _load_on_pk_identity
setup, tuple(elem is None for elem in primary_key_identity)
File "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py",
line 114, in signal_handler
raise RunnerInterrupt
mailman.interfaces.runner.RunnerInterrupt
Mar 27 09:01:22 2022 (5860) SHUNTING: 1648351882.8537986+
9bf59cb23a71a4bae65536bfdbec0abb261adaa0
Mar 27 09:01:22 2022 (5860) pipeline runner exiting.
Mar 27 09:01:23 2022 (5846) Master stopped
I have shared more log because I could not understand where can the clue be
to resolve the issue. Please suggest me.
On Sat, Mar 26, 2022, 11:33 PM Mark Sapiro <mark(a)msapiro.net> wrote:
> On 3/26/22 10:28, Shashikanth Komandoor wrote:
> > Hi Team,
> >
> > We have restarted the services as well but no change.
>
>
> Odd.
>
>
> > We tried manually moving the pck file from pipeline queue to
> > out queue but the file disappeared from out queue but is not getting
> > delivered.
>
>
> This is expected because if the message hasn't been processed through
> the pipeline, it has no recipients in the metadata, so the outgoing
> runner delivered it to no one. Also, it skipped archiving and digesting.
>
> > We moved the pck file from pipeline queue to out queue with
> the
> > extension .bak still no use.
>
>
> Same as above.
>
>
> > Not sure what to try next. Please help.
>
>
> Mi first guess is the pipeline runner isn't running, but you restarted
> the services, presumably Mailman core, and that might fix it, but there
> are various ways the pipeline runner could have died that would cause
> the master to not restart it.
>
> You need to stop Mailman core and then start it rather than just
> restarting. That may help.
>
> Also look in mailman.log. Assuming the pipeline runner died at some
> point, there should be a log entry and possible an exception with
> traceback indicating why.
>
> You can see which runners are running with something like
> ```
> ps -fwwA|grep runner=|sed s/.*runner=//
> ```
> This should produce a list something like
> ```
> archive:0:1
> bounces:0:1
> command:0:1
> in:0:1
> lmtp:0:1
> nntp:0:1
> out:0:1
> pipeline:0:1
> rest:0:1
> retry:0:1
> task:0:1
> virgin:0:1
> digest:0:1
> rest:0:1
> rest:0:1
> ```
> except depending on version, `task` may not be there.
>
>
> --
> 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/
>
4 years, 4 months
[MM3-users] Re: Mailman3 without Hyperkitty in docker
by Abhilash Raj
On Thu, Feb 28, 2019, at 10:18 PM, Danil Smirnov wrote:
> Hi Abhilash,
>
> Thank you very much - the previous error is fixed now.
>
> But I have another one now, which causes the same 500 Server Error:
>
> bash-4.3# cat /opt/mailman-web-data/logs/uwsgi-error.log
> *** Starting uWSGI 2.0.18 (64bit) on [Fri Mar 1 05:42:09 2019] ***
> compiled with version: 6.3.0 on 01 March 2019 01:52:42
> os: Linux-3.10.0-693.11.1.el7.x86_64 #1 SMP Mon Dec 4 23:52:40 UTC 2017
> nodename: mailman-web
> machine: x86_64
> clock source: unix
> detected number of CPU cores: 2
> current working directory: /opt/mailman-web
> detected binary path: /usr/local/bin/uwsgi
> !!! no internal routing support, rebuild with pcre support !!!
> setgid() to 101
> setuid() to 100
> chdir() to /opt/mailman-web
> your memory page size is 4096 bytes
> detected max file descriptor number: 1048576
> building mime-types dictionary from file /etc/mime.types...1168 entry found
> 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:8080 fd 8
> uwsgi socket 1 bound to TCP address 0.0.0.0:8000 fd 9
> Python version: 3.6.8 (default, Jan 30 2019, 23:58:16) [GCC 6.3.0]
> Python main interpreter initialized at 0x55a2df7f57e0
> python threads support enabled
> your server socket listen backlog is limited to 100 connections
> your mercy for graceful operations on workers is 60 seconds
> mapped 166752 bytes (162 KB) for 2 cores
> *** Operational MODE: threaded ***
> Traceback (most recent call last):
> File "/usr/local/lib/python3.6/site-packages/django/utils/module_loading.py", line 20, in import_string
> return getattr(module, class_name)
> AttributeError: module 'django.contrib.auth.middleware' has no attribute 'SessionAuthenticationMiddleware'
>
> The above exception was the direct cause of the following exception:
>
> Traceback (most recent call last):
> File "wsgi.py", line 38, in <module>
> application = get_wsgi_application()
> File "/usr/local/lib/python3.6/site-packages/django/core/wsgi.py", line 13, in get_wsgi_application
> return WSGIHandler()
> File "/usr/local/lib/python3.6/site-packages/django/core/handlers/wsgi.py", line 136, in __init__
> self.load_middleware()
> File "/usr/local/lib/python3.6/site-packages/django/core/handlers/base.py", line 34, in load_middleware
> middleware = import_string(middleware_path)
> File "/usr/local/lib/python3.6/site-packages/django/utils/module_loading.py", line 24, in import_string
> ) from err
> ImportError: Module "django.contrib.auth.middleware" does not define a "SessionAuthenticationMiddleware" attribute/class
> unable to load app 0 (mountpoint='') (callable not found or import error)
> *** no app loaded. going in full dynamic mode ***
> *** uWSGI is running in multiple interpreter mode ***
> spawned uWSGI master process (pid: 1)
> spawned uWSGI worker 1 (pid: 37, cores: 2)
> --- no python application found, check your startup logs for errors ---
> --- no python application found, check your startup logs for errors ---
> --- no python application found, check your startup logs for errors ---
> --- no python application found, check your startup logs for errors ---
> --- no python application found, check your startup logs for errors ---
> --- no python application found, check your startup logs for errors ---
> --- no python application found, check your startup logs for errors ---
> --- no python application found, check your startup logs for errors ---
> --- no python application found, check your startup logs for errors ---
> --- no python application found, check your startup logs for errors ---
> --- no python application found, check your startup logs for errors ---
> --- no python application found, check your startup logs for errors ---
>
> As per my investigation, this error possibly caused by Django upgrade:
>
> *The SessionAuthenticationMiddleware class is removed. It provided no functionality since session authentication is unconditionally enabled in Django 1.10.*
>
> See https://docs.djangoproject.com/en/2.0/releases/2.0/
>
> After I've removed the line
> https://github.com/maxking/docker-mailman/blob/master/postorius/mailman-web…
> from settings.py, the container is finally working.
>
> I've placed PR in github:
> https://github.com/maxking/docker-mailman/pull/314
Thank you for your contributions!
I have merged your pull request and it should now be out (hopefully!).
>
> Thank you for your help.
>
> Danil
>
>
> пт, 1 мар. 2019 г. в 04:33, Abhilash Raj <maxking(a)asynchronous.in>:
>>
>>
>> On Thu, Feb 28, 2019, at 5:19 PM, Abhilash Raj wrote:
>> > On February 27, 2019 11:53:34 PM PST, Danil Smirnov <danil(a)smirnov.la> wrote:
>> > >Hi Mark,
>> > >
>> > >Actually all this stuff happens inside the container after it's started
>> > >and
>> > >initialized without errors. I didn't amend the image anyhow.
>> > >
>> > >Also I have the configuration based on docker-compose.yaml provided in
>> > >the
>> > >repository which works just fine for mailman-web image.
>> > >
>> > >The very same config with postorius image (+ UWSGI_STATIC_MAP param)
>> > >fails
>> > >with 500 error...
>> > >
>> > >Now answering your questions:
>> > >
>> > >ср, 27 февр. 2019 г., 22:56 Mark Sapiro <mark(a)msapiro.net>:
>> > >
>> > >> do you have django-q in INSTALLED_APPS in your Django settings and
>> > >what
>> > >> is set for Q_CLUSTER?
>> > >>
>> > >
>> > >I've checked settings.py inside the container and I haven't found any
>> > >of
>> > >the mentioned configurations there.
>> > >
>> > >Does the manage.py that's being run here point to the right
>> > >settings.py?
>> > >>
>> > >
>> > >No clue.
>> > >
>> > >Also I wonder why we have some Hyperkitty-related cronjobs in non-HK
>> > >configured image?
>> > >
>> > >https://github.com/maxking/docker-mailman/blob/master/postorius/mailman-web…
>> >
>> > Because I am a dum dum ;-)
>> >
>> > Will work on removing those crons and stuff. Would be nice if you
>> > opened an issue on Github so that I don't forget.
>>
>> Should now be fixed in the latest image.
>>
>> >
>> > >Danil
>> > >
>> > >
>> > >
>> > >> --
>> > >> 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/
>> > >>
>> > >_______________________________________________
>> > >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/
>> >
>> >
>> > --
>> > Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>> --
>> thanks,
>> Abhilash Raj (maxking)
--
thanks,
Abhilash Raj (maxking)
7 years, 4 months
[MM3-users] Re: Confirm and Moderate Unsubscribe Requests
by Brian Carpenter
On 10/21/20 9:39 PM, Abhilash Raj wrote:
>
> On Wed, Oct 21, 2020, at 3:35 PM, Brian Carpenter wrote:
>> On 10/21/20 5:39 PM, Mark Sapiro wrote:
>>> On 10/21/20 12:14 PM, Brian Carpenter wrote:
>>>> Well I can't dictate that to my list owners and there is no confirm
>>>> token sent with the moderation notice. Why include this option in
>>>> Postorius when it can't be properly handled?
>>> Postorius is still a work in progress. The unsubscription policies are
>>> in core and are exposed in Postorius. Certainly the ability to moderate
>>> an unsubscription should be in Postorius, but it isn't yet. We are an
>>> all volunteer project and there aren't that many of us, and perhaps I'm
>>> overreacting, but the tone of some of your recent posts seems a bit
>>> demanding.
>> I apologize. I didn't think I was coming across demanding but I am
>> somewhat exasperated at some of these issues. I have a list owner who is
>> now going to get a moderated request notice everyday that he can't do
>> anything about it.
>>
>> But my question still remains: why is this option in Postorius when it
>> can't be handled properly? Surely the option can be easily removed, right?
> I added the option in my drive to expose every possible Mailinglist settings via Postorius and missed the fact that we weren't actually able to moderate those requests.
>
> Yes, this option can be hidden if it doesn't work until the next stable release. I hid one of the list settings in Postorius exactly because it didn't work, but this one slipped.
Thank you. I will go ahead and remove the option within Affinity.
>> Is the ability to list (via the pending moderation notices tab) and
>> handle (as in the List owner can decide a moderation response) an
>> unsubscribe moderation request there in Mailman core so that I can
>> properly address it via Affinity?
> Unfortunately no, there is a bug report open for it though and I have some done some analysis on root cause[1]. The bug turned out to be a more than a trivial one and I haven't been able to get to it yet.
>
> [1]: https://gitlab.com/mailman/mailman/-/issues/768
>
>
This is good information to have at least so I appreciate letting me
know. I probably need to spend more time looking through the outstanding
issues for Mailman core and Postorius before launching a nuclear strike
of epic and catastrophic proportions upon Mark.
--
Brian Carpenter
Harmonylists.com
Emwd.com
5 years, 9 months
[MM3-users] Re: Errors while importing mm2 list archives - SOLVED
by Odhiambo Washington
On Thu, Dec 22, 2022 at 9:36 AM Mark Sapiro <mark(a)msapiro.net> wrote:
> On 12/20/22 22:25, Odhiambo Washington wrote:
> >
> > In my case, running `mailman` without any arguments just makes it grok :)
> >
> > (venv) [mailman@gw ~/mm]$ mailman info
> ...
> > *config file: /opt/mailman/mm/mailman.cfg*
>
>
> That's because it first looks in the current directory for `mailman.cfg`
> and only if it doesn't find it there does it look in /etc/mailman3.
>
And that happens because I have all my config files in /opt/mailman/mm/.
So if I moved all of them to /etc/mailman3/ it would settle for that? I
will test it.
>> Ultimately, when I did the import, there was only one email from the
> >>> archives that failed to be imported - which I honestly don't mind, but
> >>> maybe there is a solution for this
> >>> "'utf-8' codec can't encode character '\udcae' in position 331:
> >> surrogates not allowed" ??
> >>
> >>
> >> If you provide a copy of that message from the mbox, either on the list
> >> or to me directly, I'll investigate.
> >>
> >
> > A mbox file containing that email and the associated thread can be
> > downloaded from here:
> > https://webmail.kictanet.or.ke/~wash/chunk_7.txt.gz
>
> The offending message is multipart with an attached message/rfc822 part
> and that part has a preamble which in bytes is
>
> b'This document is a Single File Web Page, also known as a Web Archive
> file. If you are seeing this message, your browser or editor doesn't
> support Web Archive files. Please download a browser that supports Web
> Archive, such as Windows\xae Internet Explorer\xae.'
>
> The '\xae' is an iso-8859-1 encoding for '®', but no charset is
> specified for this preamble so email message parsing ends up decoding
> those as surrogates '\udcae' which throws the exception when
> hyperkitty.lib.incoming.add_to_list() in trying to save the attachment
> does `att.set_content(content)`.
>
> Normally, when messages to be archived arrive from core via
> mailman_hyperkitty, the surrogates are replaced by
> email.utils._sanitize(), but this doesn't happen with messages from
> hyperkitty_import.
>
I am glad it's an email that is probably overtaken by events. However, the
good thing is that I will have the archives from MM2 still accessible once
I move to MM3.
--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
3 years, 7 months
[MM3-users] re-sending confirmation mails (was Re: Re: pending subscriptions lost?)
by IEM Network Operation Center (IOhannes m zmölnig)
On 3/14/22 18:36, Mark Sapiro wrote:
> On 3/14/22 09:18, IEM Network Operation Center (IOhannes m zmölnig) wrote:
>>
>> this is with "Postorius Version 1.2.4" (as installed by the mailman3
>> Debian package).
>
> The Debian packages are OK for people who want to install things via a
> package manager, but they are quite out of date.
i know.
the problem is, that right now i have a running (Debian-based, thus
outdated) mailman3 installation, and I still haven't found a proper
strategy to upgrade and keep staying up-to-date.
so for the time being i'm stuck with what i have.
>
> Something like the following in `mailman shell` can do it.
thanks a lot.
afaiu, this snippet allows me to purge outdated pending subscriptions.
modifying it slightly, also allows me to just list the pending
subscriptions along with their tokens and print them out.
is it still possible to just use these tokens to confirm the pending
subscription (even though it is long overdue)?
if so, i could just send out a reminder to those 50 or so people who
have not confirmed yet.
while investigating this a bit, i also noticed that it seems that with
mailman3 the only option to confirm a pending subscription is via email
("leaving the subject intact") - at least that is the only option that
is listed in the confirmation mail.
now i would like to massage this into what i think is a bit more
user-friendly.
first of all: most email confirmation systems allow me to either "reply
by email" or "click this link".
is there a way to do this for mailman3? that is: is there a (hidden) URL
that would accept the token in order to confirm a subscription?
also: the confirmation mail says that the subject must be kept intact.
however, i noticed that the actual "From" address of the confirmation
mail already contains the token.
would it be enough if people just sent an email to this special
email-address (that contains the token), regardless of the subject?
i'm thinking of sending a rather personalized email that has a more
attractive subject than "confirm flkdsajfsalkjflsajfsoisjdl".
finally: what else is required to approve the confirmation? will the
sender's email-address be taken into account? (e.g. if they subscribed
"foo+mylist(a)example.com" but send the confirmation-reply from
"foo(a)example.com", will that still work?
sorry for so many questions.
i *did* search the documentation, but simply haven't found anything that
would help me.
i've probably looked in the wrong places, but mailman3 is rather huge so
it's easy to miss the imprtant parts.
gmdsa
IOhannes
4 years, 4 months
[MM3-users]Re: mailman 2 vs. mailman 3: what happened to multipart/digest?
by John Hein
Mark Sapiro wrote at 12:18 -0700 on May 12, 2016:
> On 5/12/16 9:16 AM, deu8yz2mpq(a)snkmail.com wrote:
> > Digest delivery in mailman 2 encapsulated the individual message/rfc822 messages in a multipart/digest container. This allowed email clients to show the messages in the particular digest in a threaded view.
>
>
> This format vs. plain text digests was a user option in Mailman 2.
>
>
> > It seems like the various digest options that I have tried [1] in mailman 3.1.0 (as implemented for the fedora-users mailing list) no longer encapsulate messages in multipart/digest.
>
>
> The core still supports the same plain text and MIME format digests and
> the same individual subscriber and per-list default formats as did
> Mailman 2. The issue is none of these things are exposed in Postorius.
>
> If you subscribe to digests on this list, you will receive the
> 'encapsulated' MIME format because the lists mime_is_default_digest
> setting is True, but currently that has to be set through the
> bin/mailman shell tool.
>
>
> > Is this intentional? Is it a bug - feature that was lost in translation from 2 to 3? Is there a delivery option I'm missing that will turn that back on?
Thanks for the info - and Barry's reply as well. I understand that
MIME digests are supported in Mailman 3 - that's what I'm using (and
thanks, Barry, for the info that Summary Digests is the same right
now). My quibble is that the multipart/digest encapsulation level is
gone.
Barry Warsaw wrote at 15:16 -0400 on May 12, 2016:
> The MIME format of MIME digests should roughly be:
>
> multipart/mixed
> text/plain (the digest heading)
> text/plain (the TOC)
> message/rfc822
> message-1
> message/rfc822
> message-2
> ...
> text/plain (footer)
But mm 2 had:
multipart/mixed
text/plain (the digest heading)
text/plain (the TOC)
multipart/digest <--- this is the part that's gone in mm3
message/rfc822
message-1
message/rfc822
message-2
...
text/plain (footer)
So was that removal intentional, a bug or ??
Maybe you're saying there is definitely an unexposed (in Postorius)
knob for that in mm3.
>
> It is the intent that Postorius will eventually expose all these
> settings. We're not there yet. At present you could possibly do this by
> interacting with mailmanclient, although I'm not certain the settings
> are exposed there. You can do it via bin/mailman shell if you have
> access and know what you're doing (see
> <http://mailman.readthedocs.io/en/release-3.0/src/mailman/runners/docs/diges…>)
>
> If you file an issue at
> <https://gitlab.com/mailman/postorius/issues/new>, it might help
> expedite this.
Okay.
10 years, 2 months
[MM3-users] Re: Customise Postorius templates?
by Duane Raymond
On Mon, 7 Feb 2022 at 00:56, Abhilash Raj <maxking(a)asynchronous.in> wrote:
> > On Feb 1, 2022, at 11:01 AM, Mark Sapiro <mark(a)msapiro.net> wrote:
> >
> > On 2/1/22 09:47, Duane Raymond wrote:
> >> Hi,
> >> I'm looking to do some radical customisation of the Postorius (and
> Hyperkitty) templates over the next 6 ish months and was wondering if there
> is a 'best practice' way to do this that will survive updates to MM3. I've
> searched around and not found much and also tested copying
> >>
> venv/lib/python3.7/site-packages/postorius/templates/postorius/lists/summary.html
> >> to
> >> var/templates/lists/summary.html
> >> As suggested in some posts - but it didn't seem to pick up the
> customisation - only customisations in the venv path worked - and they get
> overwritten on update.
> The best way to do this would be utilize Django’s template loader. See
> here[1] for the documentation on how you can do this. You want to put the
> path where you are putting the templates under `DIRS` option of the
> `TEMPLATES` section.
>
> Do make sure that you are keeping the directory structure correct so that
> Django can discover them. Like, Hyperkitty’s base.html should be in
> `/custom/path/hyperkitty/base.html`, where `/custom/path` is what you’ve
> setup in DIRS setting above.
>
This looks promising! I've not got it working yet, but this is what I've
tried:
1. Created folder 'custom' in the mm root (in my case: /opt/mailman/mm/)
2. Copied the files and folders from postorius/templates/postorius/* and
hyperkitty/templates/hyperkitty/* to the custom/ folder (not the
full postorius/templates/postorius/ match, just evening in the
second postorius/ dirrectory)
3. Recursive update of permissions of the custom/ folder and files to be
mailman
4. Updated /opt/mailman/mm/settings.py by changing "'DIRS': []"
to "'DIRS': [BASE_DIR, '/custom/']" in the "TEMPLATES =" section
5. Edited the original AND copied postorius/lists/summary.html to have a
small change in the footer of each so I know what version it is serving
6. Restarted: gunicorn qcluster mailman nginx and cleared browser cache
7. Reloaded the 'info' page of a few lists to see which version ti was
serving
Variants: I've also changed the DIRS value to the hard-coded path:
/opt/mailman/mm/custom
Result: it is still serving the default/original Postorius template vs the
custom one.
Any suggestions for things I should do to make it use the /custom/ folder
instead? Any recompiling or other actions beyond just restarting? (I
probably don't need to restart qcluster and maybe not even mailman core for
this to take effect but I do it just in case!)
Cheers,
Duane
4 years, 5 months