Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upUnix sysadmin friendliness: /etc/mailpile/ #2002
Comments
This comment has been minimized.
This comment has been minimized.
|
I'm still pretty new to Mailpile, but one thing that I would like to see in |
This comment has been minimized.
This comment has been minimized.
In which case, I do think it would be nice to let |
This comment has been minimized.
This comment has been minimized.
|
@peturingi Interesting idea! However, I don't think users create new Mailpiles often enough to justify cluttering their home directories with a .new_user_setup file. However, this does remind me that there is a pre-existing mechanism that solves part of the problem - we could put @dominic-p: I think that one I would veto. Your browser doesn't log things system-wide, nor does LibreOffice. Mailpile is a private user application. On a multi-user machine it's none of the admin's business what your Mailpile is doing. I do hear you that Mailpile's internal logs and status could be a lot more discoverable - but broadcasting to a system-wide log is not the way. |
This comment has been minimized.
This comment has been minimized.
|
@BjarniRunar @dominic-p Neither would I want system-wide logging for end user software, especially on a shared system. On the other hand, an admin might be interested in getting his hands on authentication logs, even if it was merely one which contains failed authentication attempts. Such a log might make it easier to guard Mailpile with intrusion prevention systems such as Fail2ban or sshguard. For the sake of completeness I do mention that macOS has a per-user variant of /var/log/. One which resides under ~/Libraries/Logs/ and is used to log stdout and stderr. Another under ~/Libraries/DiagnosticReports/ which contains diagnostic reports, one for each time the app's process has crashed (I believe that one is generated automatically). This is usually the first place I look in when things go wrong, even 'big photo manipulation product' places logs in that dir. Again, I mention this only for the sake of completeness. |
These are a few simple things that would greatly improve the accessibility and usability (from a sysadmin point of view) of Mailpile on shared Unix deployments. The focus here would be on an
/etc/mailpile/folder that contains shared system settings, or at least helps the admin find such things.For multipile (mailpile-apache2), that means:
/var/lib/mailpile/apache/usermap.txtinto/etc/mailpile/We should double-check that the usermap.txt file contains comments explaining what it is, along with pointers to where to learn more. For integrating other web servers, equivalent symlinks would make sense?
For all Mailpile installations:
/etc/mailpile/new_user_setupThe
/etc/mailpile/new_user_setupshould be file which allows the admin to deploy default settings into each new Mailpile, system-wide. The mechanism here will need to depend a bit on which features we want to support - a shell script of some sort or python library might be useful (a Mailpile equivalent of/etc/bash.bashrc), or if the use cases are well-defined enough a static config might suffice.The default
new_user_setupshould do nothing at all, but should include commented out examples of common things admins might like to do:/var/mail/USERor a shared IMAPsendmaildoesn't workFeel free to add your own ideas.
Does
/etc/mailpile/need anything else? Default signature as a standalone file? Shared whitelist of emails never to send to spam? What sort of shared config do e-mail clients benefit from?