On Tue, May 11, 2021, at 8:43 PM, Mark Sapiro 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.
Using the full external URL should work. Core doesn’t speak uwsgi protocol so the uwsgi:// URL won’t actually work.
I am starting to think it was a very bad idea to use uwsgi in the official docs :(
-- thanks, Abhilash Raj (maxking)