nginx configuration on a multitasking server
Couple of questions about the sample nginx configuration given in the venv doc and the Mailman Mailman Suite Documentation v. 3.3 PDF:
server {
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
server_name MY_SERVER_NAME;
location /static/ {
alias /opt/mailman/web/static/;
}
location / {
proxy_pass 127.0.0.1:8000;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
ssl_certificate /path-to-ssl-certs/cert.pem;
ssl_certificate_key /path-to-ssl-certs/privkey.pem;}
At least on my system, the proxy_pass statement will only run without errors if I change this to a fully formed URL, e.g., 'proxy_pass http://127.0.0.1:8000'. Is this a typo in the docs?
What document root(s) and alias(es) to use for Postorius and Hyperkitty and the Django admin on a server that also runs other services (e.g., Postfix for non-list mail and Roundcubemail)?
With MM2, I use location statements with their own root and aliases:
location /mailman {
root /usr/lib/cgi-bin;
fastcgi_split_path_info (^/mailman/[^/]+)(/.*)$;
fastcgi_pass unix:///var/run/fcgiwrap.socket;
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_FILENAME \ $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; }
location /images/mailman {
alias /var/lib/mailman/icons;
}
location /icons {
alias /var/lib/mailman/icons;
}
location /pipermail {
alias /var/lib/mailman/archives/public;
autoindex on;
}What is the MM3 equivalent way to do this?
I think root would be somewhere under /opt/mailman but don't know exactly where, or which locations to point to.
Many thanks!
dn
On 12/10/21 10:22 AM, David Newman wrote:
- At least on my system, the proxy_pass statement will only run without errors if I change this to a fully formed URL, e.g., 'proxy_pass http://127.0.0.1:8000'. Is this a typo in the docs?
I changed it at
https://docs.mailman3.org/en/latest/install/virtualenv.html#nginx-configurat...
but I wonder if we shouldn't be using uwsgi_pass instead of proxy_pass.
See https://nginx.org/en/docs/http/ngx_http_uwsgi_module.html#uwsgi_pass
Are you using uwsgi or some other wsgi server.
- What document root(s) and alias(es) to use for Postorius and Hyperkitty and the Django admin on a server that also runs other services (e.g., Postfix for non-list mail and Roundcubemail)?
If you can separate Mailman from other services by subdomain, you can configure them separately and for Mailman, root is irrelevant as everything is proxied or aliased in a location directive. For example, Mailman on the server that supports this list uses the lists.mailman3.org domain and we have (excerpted)
server {
listen 443 default_server;
root /usr/share/nginx/html;
index index.html index.htm;
# root and index are probably irrelevant as we never go there
server_name lists.mailman3.org;
ssl on;
#ssl stuff
location / {
proxy_pass http://127.0.0.1:8000/;
# other proxy stuff
}
location /static/ {
alias /var/spool/mailman-web/static/;
}
location /robots.txt {
alias /usr/share/nginx/html/robots.txt;
}
location /favicon.ico {
alias /var/www/listorg/images/favicon.ico;
}
}
And for the other stuff we have
server {
listen 443;
server_name .list.org mirror.list.org mirror.mailman3.org;
root /var/www/listorg;
ssl on;
# ssl stuff
}
--
Mark Sapiro <mark@msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
On 12/10/21 12:57 PM, Mark Sapiro wrote:
On 12/10/21 10:22 AM, David Newman wrote:
- At least on my system, the proxy_pass statement will only run without errors if I change this to a fully formed URL, e.g., 'proxy_pass http://127.0.0.1:8000'. Is this a typo in the docs?
I changed it at https://docs.mailman3.org/en/latest/install/virtualenv.html#nginx-configurat... but I wonder if we shouldn't be using
uwsgi_passinstead of proxy_pass.See https://nginx.org/en/docs/http/ngx_http_uwsgi_module.html#uwsgi_pass
Are you using uwsgi or some other wsgi server.
uwsgi, per the venv and PDF docs. Thanks for the fix.
Regarding the uwsgi_pass docs, would 'uwsgi_pass_header' directives replace the 'proxy_set_header' ones in the venv doc?
Looking at the uwsgi doc, it seems they might do different things.
- What document root(s) and alias(es) to use for Postorius and Hyperkitty and the Django admin on a server that also runs other services (e.g., Postfix for non-list mail and Roundcubemail)?
If you can separate Mailman from other services by subdomain
Alas, I can do that for all but one of the subdomains I have in production.
For the past 15 or so years, users of that subdomain have used mail.domain.tld for MM2, roundcubemail, and an admin web UI that manages regular mail.
The "/" has gone to roundcubemail, and users to go other directories for the other services. For example, MM2 users currently go to /mailman.
, you can
configure them separately and for Mailman, root is irrelevant as everything is proxied or aliased in a location directive. For example, Mailman on the server that supports this list uses the lists.mailman3.org domain and we have (excerpted)
server { listen 443 default_server; root /usr/share/nginx/html; index index.html index.htm; # root and index are probably irrelevant as we never go there server_name lists.mailman3.org; ssl on; #ssl stuff location / { proxy_pass http://127.0.0.1:8000/; # other proxy stuff
In this example, / goes to MM3.
The assumption here and in the MM3 docs is that we're standing up a dedicated server where MM3 pages should be served as the default. That's a totally valid design decision, and one could argue it's superior to running a bunch of other services on one machine.
It's not the situation I have to deal with, though. Short of changing a long-standing URL, what I'm looking to do is have "/" continue to default to roundcubemail, and have users type in longer URLs for MM3 and other services.
You're right that the root and index directives above are irrelevant since / goes to MM3 via proxy.
What I'm asking is what root(s) and location(s) to use with nginx where MM3 isn't the default.
Thanks again!
dn
} location /static/ { alias /var/spool/mailman-web/static/; } location /robots.txt { alias /usr/share/nginx/html/robots.txt; } location /favicon.ico { alias /var/www/listorg/images/favicon.ico; } }
And for the other stuff we haveserver { listen 443; server_name .list.org mirror.list.org mirror.mailman3.org; root /var/www/listorg; ssl on; # ssl stuff }
On 12/10/21 3:22 PM, David Newman wrote:
On 12/10/21 12:57 PM, Mark Sapiro wrote:
Are you using uwsgi or some other wsgi server.
uwsgi, per the venv and PDF docs. Thanks for the fix.
Regarding the uwsgi_pass docs, would 'uwsgi_pass_header' directives replace the 'proxy_set_header' ones in the venv doc?
Looking at the uwsgi doc, it seems they might do different things.
If you are using uwsgi and proxy_pass http://127.0.0.1:8000 is working for you, then I'm satisfied that the docs are OK now and we don't need to say anything about uwsgi_pass.
It's not the situation I have to deal with, though. Short of changing a long-standing URL, what I'm looking to do is have "/" continue to default to roundcubemail, and have users type in longer URLs for MM3 and other services.
I think you can set the document root to the roundcubemail root and then set locations for the Mailman destinations as, e.g.
location /mailman3/ {
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
location /archives/ {
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
location /accounts/ {
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
location /admin/ {
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
location /user-profile/ {
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}I haven't tried anything like this, so I'm not sure it will work, but I think so.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 12/10/21 4:48 PM, Mark Sapiro wrote:
I think you can set the document root to the roundcubemail root and then set locations for the Mailman destinations as, e.g.
..
I haven't tried anything like this, so I'm not sure it will work, but I think so.
Bingo. I can report that all list, archive, account, and Django admin pages I tested work as expected. Thank you!
dn
On 12/10/21 4:48 PM, Mark Sapiro wrote:
On 12/10/21 3:22 PM, David Newman wrote:
On 12/10/21 12:57 PM, Mark Sapiro wrote:
Are you using uwsgi or some other wsgi server.
uwsgi, per the venv and PDF docs. Thanks for the fix.
Regarding the uwsgi_pass docs, would 'uwsgi_pass_header' directives replace the 'proxy_set_header' ones in the venv doc?
Looking at the uwsgi doc, it seems they might do different things.
If you are using uwsgi and proxy_pass http://127.0.0.1:8000 is working for you, then I'm satisfied that the docs are OK now and we don't need to say anything about uwsgi_pass.
It's not the situation I have to deal with, though. Short of changing a long-standing URL, what I'm looking to do is have "/" continue to default to roundcubemail, and have users type in longer URLs for MM3 and other services.
I think you can set the document root to the roundcubemail root and then set locations for the Mailman destinations as, e.g.
location /mailman3/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $remote_addr; } location /archives/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $remote_addr; } location /accounts/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $remote_addr; } location /admin/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $remote_addr; } location /user-profile/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $remote_addr; }
I haven't tried anything like this, so I'm not sure it will work, but I think so.
Update: The above worked fine until MM3 informed a list owner of pending subscription requests, with a URL like this:
https://lists.example.com/mailman/admindb/listname
and that URL returned a 404 error.
Adding a stanza for 'location /mailman/' to the nginx config above clears the 404 error, but Postorius returns "Page not found" with no entry in the web or MM3 logs, and a 200 OK in the Nginx logs.
I think the URL is supposed to go to the list page in Postorius. How to configure this so that list owners and moderators get a valid URL for list management?
Thanks!
dn
On 12/22/21 6:20 PM, David Newman wrote:
Update: The above worked fine until MM3 informed a list owner of pending subscription requests, with a URL like this:
https://lists.example.com/mailman/admindb/listname
and that URL returned a 404 error.
This looks like a uwsgi issue as discussed at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/U... although that's with apache and not nginx so it may not be.
Adding a stanza for 'location /mailman/' to the nginx config above clears the 404 error, but Postorius returns "Page not found" with no entry in the web or MM3 logs, and a 200 OK in the Nginx logs.
I think the URL is supposed to go to the list page in Postorius. How to configure this so that list owners and moderators get a valid URL for list management?
I'm not sure what the solution is in this case, but a workaround would be to add
url(r'^mailman/', include('postorius.urls')),to the urlpatterns list in urls.py.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 12/22/21 7:29 PM, Mark Sapiro wrote:
On 12/22/21 6:20 PM, David Newman wrote:
Update: The above worked fine until MM3 informed a list owner of pending subscription requests, with a URL like this:
https://lists.example.com/mailman/admindb/listname
and that URL returned a 404 error.
This looks like a uwsgi issue as discussed at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/U... although that's with apache and not nginx so it may not be.
If I'm reading the thread correctly, it's Apache workarounds to an underlying Debian issue, so I agree it may not apply with nginx.
Adding a stanza for 'location /mailman/' to the nginx config above clears the 404 error, but Postorius returns "Page not found" with no entry in the web or MM3 logs, and a 200 OK in the Nginx logs.
I think the URL is supposed to go to the list page in Postorius. How to configure this so that list owners and moderators get a valid URL for list management?
I'm not sure what the solution is in this case, but a workaround would be to add
url(r'^mailman/', include('postorius.urls')),
to the urlpatterns list in urls.py.
There are 260 files named 'urls.py' under /opt/mailman, mostly for socialaccount stuff.
Where does that change go? All files? Or just this one:
/opt/mailman/venv/lib/python3.9/site-packages/postorius/urls.py
Or somewhere else?
Thanks again.
dn
On 12/22/21 7:54 PM, David Newman wrote:
On 12/22/21 7:29 PM, Mark Sapiro wrote:
This looks like a uwsgi issue as discussed at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/U... although that's with apache and not nginx so it may not be.
If I'm reading the thread correctly, it's Apache workarounds to an underlying Debian issue, so I agree it may not apply with nginx.
I think you're correct that it doesn't apply to nginx, but the symptom is not the same. It is not a Debian issue per se. It is an Apache change that got installed with a Debian update, but the underlying issue is with Apache. See https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
There are 260 files named 'urls.py' under /opt/mailman, mostly for socialaccount stuff.
Where does that change go? All files? Or just this one:
/opt/mailman/venv/lib/python3.9/site-packages/postorius/urls.py
Not that one. The one whose content looks like https://gitlab.com/mailman/mailman-web/-/blob/master/mailman_web/urls.py. It is probably in the same directory as your Django settings.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 12/22/21 8:50 PM, Mark Sapiro wrote:
On 12/22/21 7:54 PM, David Newman wrote:
On 12/22/21 7:29 PM, Mark Sapiro wrote:
This looks like a uwsgi issue as discussed at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/U... although that's with apache and not nginx so it may not be.
If I'm reading the thread correctly, it's Apache workarounds to an underlying Debian issue, so I agree it may not apply with nginx.
I think you're correct that it doesn't apply to nginx, but the symptom is not the same. It is not a Debian issue per se. It is an Apache change that got installed with a Debian update, but the underlying issue is with Apache. See https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
There are 260 files named 'urls.py' under /opt/mailman, mostly for socialaccount stuff.
Where does that change go? All files? Or just this one:
/opt/mailman/venv/lib/python3.9/site-packages/postorius/urls.py
Not that one. The one whose content looks like https://gitlab.com/mailman/mailman-web/-/blob/master/mailman_web/urls.py. It is probably in the same directory as your Django settings.
On my system that file lives here:
/opt/mailman/venv/lib/python3.9/site-packages/mailman_web/urls.py
But the error persists after this addition and restarting MM3 and mailmanweb and nginx:
url(r'^mailman/', include('postorius.urls')),
There is this 404 error in uwsgi.log:
[pid: 73356|app: 0|req: 3/3] 127.0.0.1 () {48 vars in 1544 bytes} [Wed Dec 22 21:13:48 2021] GET /mailman/admindb/listname => generated 5328 bytes in 14 msecs (HTTP/1.0 404) 6 headers in 197 bytes (1 switches on core 0)
If this is a uwsgi issue, is there something else to tweak with that?
Thanks
dn
On 12/22/21 9:22 PM, David Newman wrote:
On my system that file lives here:
/opt/mailman/venv/lib/python3.9/site-packages/mailman_web/urls.py
It appears that you have installed following https://docs.mailman3.org/en/latest/install/virtualenv.html#virtualenv-insta... and in that case, this is the file.
But the error persists after this addition and restarting MM3 and mailmanweb and nginx:
url(r'^mailman/', include('postorius.urls')),
There is this 404 error in uwsgi.log:
[pid: 73356|app: 0|req: 3/3] 127.0.0.1 () {48 vars in 1544 bytes} [Wed Dec 22 21:13:48 2021] GET /mailman/admindb/listname => generated 5328 bytes in 14 msecs (HTTP/1.0 404) 6 headers in 197 bytes (1 switches on core 0)
However, that's not the issue. You originally reported and I didn't look closely enough:
Update: The above worked fine until MM3 informed a list owner of pending subscription requests, with a URL like this:
https://lists.example.com/mailman/admindb/listname
and that URL returned a 404 error.
That URL is from a Mailman 2.1 installation. Are you still running Mailman 2.1? If so, you need to support Mailman 2.1's CGIs. In Apache, this would be something like
ScriptAlias /mailman/ /parh/to/mailman/cgi-bin/
but nginx doesn't do that. You would need something like
location /mailman/ { proxy_pass <something that can serve Mailman 2.1's CGIs.> }
The something could be apache or ??
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 12/23/21 9:18 AM, Mark Sapiro wrote:
However, that's not the issue. You originally reported and I didn't look closely enough:
Update: The above worked fine until MM3 informed a list owner of pending subscription requests, with a URL like this:
https://lists.example.com/mailman/admindb/listname
and that URL returned a 404 error.
That URL is from a Mailman 2.1 installation. Are you still running Mailman 2.1?
I'm not, but that, and me not looking closely, was the problem.
The system doesn't run MM2.1 any more, and no longer has it installed. But I failed to notice the dates on those 'admindb' messages: They were from the day of the upgrade, about 30 minutes before decommissioning MM2.1. And the docs do say explicitly to deal with any pending tasks before doing a cutover.
The task-pending message that MM3 sends to list owners and moderators just says generically to check the dashboard, without providing a URL.
Can that be modified to provide an explicit URL, something like this?
https://lists.example.com/mailman3/lists/listname
Thanks again for spotting this.
dn
On 12/23/21 9:57 AM, David Newman wrote:
The task-pending message that MM3 sends to list owners and moderators just says generically to check the dashboard, without providing a URL.
Can that be modified to provide an explicit URL, something like this?
Yes, That particular message is built from the list:admin:action:post template. You may wish to make custom versions of that and other templates. The templates and their default values are at https://gitlab.com/mailman/mailman/-/tree/master/src/mailman/templates/en
You can make custom versions of templates in two ways. You can create if necessary a /opt/mailman/mm/var/templates directory (it probably already exists). Within that directory, sitewide English templates are put in the site/en/ directory, domain specific English templates are put in the domains/<domain_name>/en/ directory and list specific English templates are put in the lists/<list_id>/en/ directory.
For templates like this, you probably want sitewide ones. E.g., site/en/list:admin:action:post.txt
As list administrator, your authorization is requested for the following mailing list posting:
List: $listname
From: $sender_email
Subject: $subjectThe message is being held because:
$reasons
At your convenience, visit https://lists.example.com/mailman3/lists/$list_id/held_messages to approve or deny the request.
The other way to create custom templates is via Postotrius, but Postorius only creates list and domain specific templates. Also, if you create a template in Postorius, it overrides any in /opt/mailman/mm/var/templates/ until you delete it in Postorius.
Info about templates and what substitution variables can be used is at https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/t...
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 12/23/21 10:39 AM, Mark Sapiro wrote:
On 12/23/21 9:57 AM, David Newman wrote:
The task-pending message that MM3 sends to list owners and moderators just says generically to check the dashboard, without providing a URL.
Can that be modified to provide an explicit URL, something like this?
Yes, That particular message is built from the list:admin:action:post template. You may wish to make custom versions of that and other templates. The templates and their default values are at https://gitlab.com/mailman/mailman/-/tree/master/src/mailman/templates/en
You can make custom versions of templates in two ways. You can create if necessary a /opt/mailman/mm/var/templates directory (it probably already exists). Within that directory, sitewide English templates are put in the site/en/ directory, domain specific English templates are put in the domains/<domain_name>/en/ directory and list specific English templates are put in the lists/<list_id>/en/ directory.
For templates like this, you probably want sitewide ones. E.g., site/en/list:admin:action:post.txt
As list administrator, your authorization is requested for the following mailing list posting:
List: $listname From: $sender_email Subject: $subject
The message is being held because:
$reasons
At your convenience, visit https://lists.example.com/mailman3/lists/$list_id/held_messages to approve or deny the request.
The other way to create custom templates is via Postotrius, but Postorius only creates list and domain specific templates. Also, if you create a template in Postorius, it overrides any in /opt/mailman/mm/var/templates/ until you delete it in Postorius.
Info about templates and what substitution variables can be used is at https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/t...
Following up on this thread from a few weeks ago, a custom subscribe template I defined is not getting sent out.
I created a pending subscription request on a test list. Here is the text I'm using in a file called 'list:admin:action:subscribe.txt' (minus the rows of hypens):
As list administrator, your authorization is required for a mailing list subscription request approval:
For: $member
List: $listnameAt your convenience, visit:
https://${domain}/mailman/admindb/lists/${short_listname}.${domain}/to approve or deny the request.
Instead the message that goes out at midnight daily reads like this:
The test@lists.domain.tld list has 1 moderation requests waiting.
Held Subscriptions: User: letmein@domain.tld
Please attend to this at your earliest convenience.
On successive nights I have placed copies of the 'list:admin:action:subscribe.txt' file above in these locations:
mm/var/templates/lists/test.lists.domain.tld/en /opt/mailman/mm/var/templates/site/en
and then in Postorius, with the same contents as above. The file versions are owned by the mailman user, and have 0644 permissions. Not sure this is necessary but I've restarted the mailman3 and mailmanweb services each time after a change.
There is no sign of trouble in the MM3 or web logs. The only thing I see is in the Postfix log, where the shorter and less helpful message goes out each night. I don't see anything in the template docs about this.
Questions:
What to do to get the custom message working?
Is there a way to trigger a subscribe reminder for one list only?
Asking because there are other lists on this server with other requests pending, and I don't want to bother other moderators with multiple reminders per day. Not a big deal, but it would be nice to test this with one list rather than waiting up to 24 hours after each change.
Thank you!
dn
On 1/14/22 11:56 AM, David Newman wrote:
I created a pending subscription request on a test list. Here is the text I'm using in a file called 'list:admin:action:subscribe.txt' (minus the rows of hypens):
As list administrator, your authorization is required for a mailing list subscription request approval:
For: $member List: $listname
At your convenience, visit:
https://${domain}/mailman/admindb/lists/${short_listname}.${domain}/
This looks like a Mailman 2.1 URL. Are you sure you don't want something like
https://${domain}/mailman3/lists/${short_listname}.${domain}/to approve or deny the request.
Instead the message that goes out at midnight daily reads like this:
That's a different message. It is sent from the mailman notify command
run by cron. It's built from the list:admin:notice:pending template.
On successive nights I have placed copies of the 'list:admin:action:subscribe.txt' file above in these locations:
mm/var/templates/lists/test.lists.domain.tld/en
I hope you mean
/opt/mailman/mm/var/templates/lists/test.lists.domain.tld/en
/opt/mailman/mm/var/templates/site/en
Either of those should work. The lists one will take priority over the site one for that list.
and then in Postorius, with the same contents as above.
If you set a template in Postorius, it takes priority. If you later decide you want to use one in /opt/mailman/mm/var/templates/ you have to delete the postorius one.
The file versions are owned by the mailman user, and have 0644 permissions. Not sure this is necessary but I've restarted the mailman3 and mailmanweb services each time after a change.
There is no sign of trouble in the MM3 or web logs. The only thing I see is in the Postfix log, where the shorter and less helpful message goes out each night. I don't see anything in the template docs about this.
Questions:
- What to do to get the custom message working?
It should work. I suspect you need to go to the list's Settings ->
Automatic Responses and set Admin immed notify to Yes.
- Is there a way to trigger a subscribe reminder for one list only?
If by subscribe reminder you mean the list:admin:action:subscribe.txt
message, yes that's the above list setting. If you mean the one sent
from the mailman notify command, see mailman notify --help for the
options. You can specify one or more lists (default is all lists) via
options and put them in your cron.
Asking because there are other lists on this server with other requests pending, and I don't want to bother other moderators with multiple reminders per day. Not a big deal, but it would be nice to test this with one list rather than waiting up to 24 hours after each change.
You can test mailman notify at any time by running it by hand.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 1/14/22 4:54 PM, Mark Sapiro wrote:
On 1/14/22 11:56 AM, David Newman wrote:
I created a pending subscription request on a test list. Here is the text I'm using in a file called 'list:admin:action:subscribe.txt' (minus the rows of hypens):
As list administrator, your authorization is required for a mailing list subscription request approval:
For: $member List: $listname
At your convenience, visit:
https://${domain}/mailman/admindb/lists/${short_listname}.${domain}/
This looks like a Mailman 2.1 URL. Are you sure you don't want something like
https://${domain}/mailman3/lists/${short_listname}.${domain}/
Yes. The server redirects MM3-style requests to MM2.1 URLs. I need to determine why, but that may be a different issue than the templates one.
There's nothing obvious in this vhost's nginx config that would generate the redirect. Will check, if I can't resolve this I'll open a different thread.
to approve or deny the request.
Instead the message that goes out at midnight daily reads like this:
That's a different message. It is sent from the
mailman notifycommand run by cron. It's built from the list:admin:notice:pending template.
OK, wrong template then.
On successive nights I have placed copies of the 'list:admin:action:subscribe.txt' file above in these locations:
mm/var/templates/lists/test.lists.domain.tld/en
I hope you mean
/opt/mailman/mm/var/templates/lists/test.lists.domain.tld/en
Yes
/opt/mailman/mm/var/templates/site/en
Either of those should work. The lists one will take priority over the site one for that list.
and then in Postorius, with the same contents as above.
If you set a template in Postorius, it takes priority. If you later decide you want to use one in /opt/mailman/mm/var/templates/ you have to delete the postorius one.
The file versions are owned by the mailman user, and have 0644 permissions. Not sure this is necessary but I've restarted the mailman3 and mailmanweb services each time after a change.
There is no sign of trouble in the MM3 or web logs. The only thing I see is in the Postfix log, where the shorter and less helpful message goes out each night. I don't see anything in the template docs about this.
Questions:
- What to do to get the custom message working?
It should work. I suspect you need to go to the list's Settings -> Automatic Responses and set
Admin immed notifyto Yes.
It's enabled. I think this triggers notifications only for new subscription requests, not pending ones.
- Is there a way to trigger a subscribe reminder for one list only?
If by subscribe reminder you mean the
list:admin:action:subscribe.txtmessage, yes that's the above list setting. If you mean the one sent from themailman notifycommand, seemailman notify --helpfor the options. You can specify one or more lists (default is all lists) via options and put them in your cron.Asking because there are other lists on this server with other requests pending, and I don't want to bother other moderators with multiple reminders per day. Not a big deal, but it would be nice to test this with one list rather than waiting up to 24 hours after each change.
You can test
mailman notifyat any time by running it by hand.
Thanks. This still isn't working as intended. I took these steps:
- Created the file '/opt/mailman/mm/var/templates/lists/test.lists.domain.tld/en/list:admin:action:pending.txt' with these contents (minus the hyphens top and bottom):
The $listname list has $count moderation requests waiting.
$data
At your convenience, visit:
https://${domain}/mailman3/lists/${short_listname}.${domain}/to approve or deny the request.
Restarted the mailman3 and mailmanweb services
As the mailman user, ran the command 'mailman notify -l test.lists.domain.tld -v'
This generated an email message but its contents were the same as in my previous post:
The test@lists.domain.tld list has 1 moderation requests waiting.
Held Subscriptions: User: letmein@domain.tld
Please attend to this at your earliest convenience.
What I'm trying to do here is replicate a feature from MM2.1, where pending notifications had URLs embedded in the message. That's not available out of the box in MM3, and if there's a place for feature requests I'd be glad to ask that this be made the default.
For now, though, I'm looking to get this customization working.
Thanks.
dn
On 1/14/22 6:11 PM, David Newman wrote:
On 1/14/22 4:54 PM, Mark Sapiro wrote:
It should work. I suspect you need to go to the list's Settings -> Automatic Responses and set
Admin immed notifyto Yes.It's enabled. I think this triggers notifications only for new subscription requests, not pending ones.
Yes. That will send a single notification at the time of the request
using the list:admin:action:subscribe.txt template. Notices of pending
requests are sent by the mailman notify command using the
list:admin:notice:pending.txt template.
...
You can test
mailman notifyat any time by running it by hand.Thanks. This still isn't working as intended. I took these steps:
- Created the file '/opt/mailman/mm/var/templates/lists/test.lists.domain.tld/en/list:admin:action:pending.txt'
The template name is list:admin:notice:pending.txt, not
list:admin:action:pending.txt. Thats why it didn't work.
...
- Restarted the mailman3 and mailmanweb services
You only needed to restart Mailman core.
...
What I'm trying to do here is replicate a feature from MM2.1, where pending notifications had URLs embedded in the message. That's not available out of the box in MM3, and if there's a place for feature requests I'd be glad to ask that this be made the default.
The place for feature requests for Mailman core (which this is) is https://gitlab.com/mailman/mailman/-/issues, however, this is not straightforward as Mailman core doesn't know if you even have Postorius or some other web management UI installed or what the URL to access it might be. Thus it's not just a simple matter of editing templates. It would also require a configuration setting for the base URL for the web admin UI and changes in logic to provide an appropriate replacement depending on whether or not the base URL was configured.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 1/14/22 6:35 PM, Mark Sapiro wrote:
On 1/14/22 6:11 PM, David Newman wrote:
On 1/14/22 4:54 PM, Mark Sapiro wrote:
It should work. I suspect you need to go to the list's Settings -> Automatic Responses and set
Admin immed notifyto Yes.It's enabled. I think this triggers notifications only for new subscription requests, not pending ones.
Yes. That will send a single notification at the time of the request using the
list:admin:action:subscribe.txttemplate. Notices of pending requests are sent by themailman notifycommand using thelist:admin:notice:pending.txttemplate....
You can test
mailman notifyat any time by running it by hand.Thanks. This still isn't working as intended. I took these steps:
- Created the file '/opt/mailman/mm/var/templates/lists/test.lists.domain.tld/en/list:admin:action:pending.txt'
The template name is
list:admin:notice:pending.txt, notlist:admin:action:pending.txt. Thats why it didn't work.
Bingo. Thanks -- the template works as intended now.
...
- Restarted the mailman3 and mailmanweb services
You only needed to restart Mailman core.
OK
...
What I'm trying to do here is replicate a feature from MM2.1, where pending notifications had URLs embedded in the message. That's not available out of the box in MM3, and if there's a place for feature requests I'd be glad to ask that this be made the default.
The place for feature requests for Mailman core (which this is) is https://gitlab.com/mailman/mailman/-/issues, however, this is not straightforward as Mailman core doesn't know if you even have Postorius or some other web management UI installed or what the URL to access it might be. Thus it's not just a simple matter of editing templates. It would also require a configuration setting for the base URL for the web admin UI and changes in logic to provide an appropriate replacement depending on whether or not the base URL was configured.
Understood, thanks. Although this distinction is very important for server admins, it's likely not meaningful for many list owners and moderators. For them, MM2.1 sent an email saying "go here" and MM3/Django/Postorius/Hyperkitty doesn't, at least not out of the box.
There is some pending template in use by default, just not one with a URL included.
Is this something better handled in the venv and/or Web installation docs? Or should I file a feature request for core, or Postorious or someplace else?
Thanks very much!
dn
On 1/14/22 6:58 PM, David Newman wrote:
On 1/14/22 6:35 PM, Mark Sapiro wrote:
The place for feature requests for Mailman core (which this is) is https://gitlab.com/mailman/mailman/-/issues, however, this is not straightforward as Mailman core doesn't know if you even have Postorius or some other web management UI installed or what the URL to access it might be. Thus it's not just a simple matter of editing templates. It would also require a configuration setting for the base URL for the web admin UI and changes in logic to provide an appropriate replacement depending on whether or not the base URL was configured.
Understood, thanks. Although this distinction is very important for server admins, it's likely not meaningful for many list owners and moderators. For them, MM2.1 sent an email saying "go here" and MM3/Django/Postorius/Hyperkitty doesn't, at least not out of the box.
There is some pending template in use by default, just not one with a URL included.
All the templates have defaults and the defaults don't have URLs because these are unknown to core.
Is this something better handled in the venv and/or Web installation docs? Or should I file a feature request for core, or Postorious or someplace else?
I think a feature request for core is appropriate. I'm only saying implementing this is a non-trivial change. What I do on sites I admin is put custom versions of all these
domain:admin:notice:new-list.txt list:admin:action:post.txt list:admin:action:subscribe.txt list:admin:action:unsubscribe.txt list:admin:notice:pending.txt list:member:digest:footer.txt list:member:digest:masthead.txt list:member:regular:footer.txt list:user:action:invite.txt list:user:action:subscribe.txt list:user:action:unsubscribe.txt list:user:notice:post.txt list:user:notice:probe.txt list:user:notice:welcome.txt
in /opt/mailman/mm/var/templates/site/en and at mail.python.org which also has German language lists, in /opt/mailman/mm/var/templates/site/de. That could be documented, but it would be preferable to be able to document just a base web management URL and then put a replacement such as $web_ui in the default templates and replace that with a URL if configured or some generic text otherwise.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
David Newman wrote:
https://${domain}/mailman3/lists/${short_listname}.${domain}/
FYI, ${short_listname}.${domain} is the same as ${list_id}
Also, ${domain} as the web site address may not be appropriate. For
example, on this list $domain is mailman3.org, but the base URL for
Postorius is https://lists.mailman3.org/mailman3 and
https://mailman3.org/mailman3 doesn't work. There is no replacement
for the web domain if it's different from the email domain for the same
reason that there are no web URLs in the default templates.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 1/14/22 8:18 PM, Mark Sapiro wrote:
https://${domain}/mailman3/lists/${short_listname}.${domain}/
FYI, ${short_listname}.${domain} is the same as ${list_id}
Good to know. Thanks.
Also, ${domain} as the web site address may not be appropriate. For example, on this list $domain is
mailman3.org, but the base URL for Postorius ishttps://lists.mailman3.org/mailman3andhttps://mailman3.org/mailman3doesn't work. There is no replacement for the web domain if it's different from the email domain for the same reason that there are no web URLs in the default templates.
Is there a variable for the base Postorius URL? Something like:
https://${baseVarName}/lists/${list_id}
Thanks
dn
On Jan 14, 2022, at 20:30, David Newman <dnewman@networktest.com> wrote:
Also, ${domain} as the web site address may not be appropriate. For example, on this list $domain is
mailman3.org, but the base URL for Postorius ishttps://lists.mailman3.org/mailman3andhttps://mailman3.org/mailman3doesn't work. There is no replacement for the web domain if it's different from the email domain for the same reason that there are no web URLs in the default templates.Is there a variable for the base Postorius URL? Something like:
Sorry, guess that should be something like:
${baseVarName}/lists/${list_id}
Is there such an animal?
Thanks
dn
On 1/14/22 8:30 PM, David Newman wrote:
Is there a variable for the base Postorius URL? Something like:
If you or someone submits the relevant feature request and it is implemented, there will be, but not until then.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 1/15/22 9:33 AM, Mark Sapiro wrote:
On 1/14/22 8:30 PM, David Newman wrote:
Is there a variable for the base Postorius URL? Something like:
If you or someone submits the relevant feature request and it is implemented, there will be, but not until then.
OK. Issues 968 and 969 respectively request a new base URL variable and the inclusion of URLs in templates.
https://gitlab.com/mailman/mailman/-/issues/968
https://gitlab.com/mailman/mailman/-/issues/969
Thanks very much for all your helpful thoughts on this.
dn
participants (2)
-
David Newman -
Mark Sapiro