Unix sysadmin friendliness: /etc/mailpile/

[BjarniRunar]

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:

1. Add a symlink to /var/lib/mailpile/apache/usermap.txt into /etc/mailpile/
2. ...?

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:

1. Config files: /etc/mailpile/new_user_setup
2. ...?

The /etc/mailpile/new_user_setup should 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_setup should do nothing at all, but should include commented out examples of common things admins might like to do:

• Auto-create accounts that read mail from /var/mail/USER or a shared IMAP
• Configure the default account SMTP server, if local sendmail doesn't work
• Configure and enable use of a shared Tor server
• Set a common default signature or common default GPG preferences
• Move the user's web interface to a port other than 33411 (if not handled by Multipile)

Feel 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?

[dominic-p]

I'm still pretty new to Mailpile, but one thing that I would like to see in /etc/mailpile would be system wide logging settings. To be honest, I'm still not quite sure how to view application logs. :)

[ghost]

The /etc/mailpile/new_user_setup should be file which allows the admin to deploy default settings into each new Mailpile, system-wide.

In which case, I do think it would be nice to let ~/.new_user_setup override any settings specified by that file. (The file ~/.new_user_setup could optionally distributed to new users via /etc/skel/.) Also, should /etc/mailpile/ be a default then it would be nice to have the ability to specify a different directory, such as /usr/local/etc/mailpile/.

[BjarniRunar]

@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 .local/share/Mailpile/default/mailpile.rc in /etc/skel to accomplish most of this. So maybe an /etc/mailpile/ isn't needed. On the other hand, it still might be more admin-friendly to have an /etc/mailpile/, especially considering that Mailpile might be installed after users are created (so too late for an /etc/skel/ based solution).

@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.

[ghost]

@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.