On Thu, Aug 8, 2024 at 10:34 AM IEM Network Operation Center (IOhannes m zmölnig) <noc@iem.at> wrote:
On 8/7/24 12:55, Odhiambo Washington via Mailman-users wrote:
On Wed, Aug 7, 2024 at 1:05 PM IEM Network Operation Center (IOhannes m zmölnig) <noc@iem.at> wrote:
- ./data: empty
With a Postfic MTA situation, that would have had some files. So you don't use Postfix.
- ./lists: empty directories named after each list (i think these are used by the MTA to determine whether it should hand over a mail to the mm3-ltmp)
True, at least according to Exim MTA.
indeed, i'm using exim. i guess these directories are named like they are for backwards compatibility. if the sysadmin is supposed to ever do something with them, it would be nice if there was some (discoverable) documentation (like a README in Mailman's var; or the yet-to-be-written mm3-to-mm3 migration guide; even if those files/directories are mentioned in the Bible for installing Mailman, i don't think this can be found by a normal administrator (it's not reasonable to assume that one should look up each file/directory in Mailman's var to see if it is needed).
If you read that Bible with a toothcomb, you will be led to the READMEs which are online. And I think the Developers wrote this summarized version of the 'Bible' with the focus of getting us up and running with MM3 in the easiest way and shortest time. The complete MM3 'Bible' <https://docs.mailman3.org/projects/mailman/en/latest/README.html>is as large as the real Bible itself and that is left for the curious to go read online:
https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/config/schema.c... https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/config/docs...
- ./locks: plenty of lock-files, most of them rather stale (as in: 3
years old)
So MM3 on that host hasn't been running or?
it *is* running. i do not know why it didn't cleanup.
- ./messages: a couple of old messages (i think all of them have been
held for approval)
- ./queue: dirtree without files
- ./templates: more templates for the existing mailinglists, though they don't seem to be used (are these the fallbacks when I remove a template via the webinterface?)
Yes.
so can i just ignore them?
I believe it is safe to ignore them.
So out here we focus so much on the following as the Bible for installing and running MM3: https://docs.mailman3.org/en/latest/install/virtualenv.html
probably. sorry for being obtuse.
afaict, the documentation is written for people setting things up from scratch, where the paths are mostly setup automatically, and you only need to configure them manually for interoperability with other software (e.g. when using postfix as the MTA, the docs tell the admin to ensure that both mm3 and postfix communicate via the same paths).
I am not sure that is entirely correct. People have installed MM3 on paths other than what the docs say. Narrowing down on Postfix, I know that all it needs to be told is how to 'know the lists being created by MM3 in order to handle mail deliveries for MM3'. There are instances where people don't even run a local Postix instance.
i guess i'm confused because it is unclear to me, which of these paths hold persistent data, and which are just for ephemeral things (like sockets).
In the summarized Bible, there is a reference to https://docs.mailman3.org/en/latest/config-core.html#config-core, which tells you that! There are also other references to the things you are interested in. Just a little more curiosity and you find them.
PS: I saw the point you raised about the "the yet-to-be-written mm3-to-mm3 migration guide". In one of my responses to your posts, I attempted to write part of the process off the top of my head. I think you are going finish writing it for us since you are on that path. You will be able to complete the portions that I left out. Your experience, if documented and discussed here (addressing the pitfalls on the way) will finally bring forth that document. Or a semblance of it.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]