Thanks Mark and Abhilash (who responded separately).
I have worked out all the issues I was having and now the list is running smoothly. The trick for POSTORIUS_TEMPLATE_BASE_URL with uwsgi was "http://[hostname]/mailman3/ <http://[hostname]/mailman3/>“.
I appreciate all the help I’ve received from this mailing list.
On May 11, 2021, at 11:43 PM, Mark Sapiro <mark@msapiro.net> wrote:
On 5/11/21 7:46 PM, Jeff wrote:
I really appreciate your assistance. New messages are now being archived as expected, but I still have a few small remaining issues to work out with my MM3 installation:
- some emails that arrived before I got the archive working are still sitting in:
/usr/local/mailman3/mm/var/archives/prototype/[listname]@[domain]/new
Strangely this includes at least one email that was archived. Should this directly be cleared as messages are archived? Is there a way to force it to be cleared?
/usr/local/mailman3/mm/var/archives/prototype/[listname]@[domain] is a collection of messages in maildir format. This is how the prototype archiver stores messages. This has nothing to do with HyperKitty. It is a separate archiver. If you don't want messages to be stored there, you can disable the prototype archiver for the list by unchecking prototype in Postorius -> Settings -> Archiving -> Active archivers or disable it entirely for the installation by setting
[archiver.prototype] enable: noin mailman.cfg
- Some messages that arrived while I was having other problems with the setup have been stored in:
/usr/local/mailman3/mm/var/queue/shunt
What should I do to get these messages processed?
Assuming the issues that caused them to be shunted have been fixed, just run the command
mailman unshunt
- Similar to above, some messages are in:
/usr/local/mailman3/mm/var/queue/bad
How can I get these messages processed?
First examine the messages with
mailman qfile /usr/local/mailman3/mm/var/queue/bad/<file>To be sure you want them. Also examine mailman.log for the times they were stored in the
badqueue. You are looking for 'Skipping and preserving unparseable message: <file>' and/or 'SHUNTING FAILED, preserving original entry: <file> messages and you want to determine which runner preserved the message. There may be a 'whichq' entry in the message's metadata in which case, that's the answer.Once you have determined the queue, you can just move the .psv file from the bad queue to the appropriate queue, renaming it from .psv to .pck in the process.
4 Modified the template for “list:admin:action:post” through Postorious and emails that arrived after that were put in the “shunt” queue. I traced this problem to POSTORIUS_TEMPLATE_BASE_URL. By default, it is set to "http://localhost:8000 <http://localhost:8000/>” which is where uwsgi is listening. However, uwsigi is listening for uwsgi:/ not http://. Should I change POSTORIUS_TEMPLATE_BASE_URL to “uwsgi://localhost:8000 <uwsgi://localhost:8000>” or keep http but make it something else?
I know little about uwsgi. setting it to
uwsgi://localhost:8000might work. You could also set it to the base URL that a user would use to access the web UI, e.g.https://example.comand that would presumably be proxied to uwsgi. For example, on the server for this list we havePOSTORIUS_TEMPLATE_BASE_URL = 'https://lists.mailman3.org'which gets proxied to gunicorn, but the idea is the same.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/