cf9e81d8a1
Previous error reporting code was inconsistent in terms of what is
logged, when and by whom. This caused several problems such as: logs
missing important error context, duplicated error messages, too verbose
messages, etc.
Instead of logging all generated errors, module should log
only errors it 'handles' somehow and does not simply pass it to the
caller. This removes duplication, however, also it removes context
information. To fix this, exterrors package was extended to provide
utilities for error wrapping. These utilities provide ability to
'attach' arbitrary key-value ('fields') pairs to any error object while
preserving the original value (using to Go 1.13 error handling
primitives).
In additional to solving problems described above this commit makes logs
machine-readable, creating the possibility for automated analysis.
Three new functions were added to the Logger object, providing
loosely-typed structured logging. However, they do not completely
replace plain logging and are used only where they are useful (to allow
automated analysis of message processing logs).
So, basically, instead of being logged god knows where and when,
all context information is attached to the error object and then it is
passed up until it is handled somewhere, at this point it is logged
together with all context information and then discarded.
|
||
|---|---|---|
| .. | ||
| fail2ban | ||
| logrotate.d | ||
| systemd | ||
| vim | ||
| README.md | ||
Distribution files for maddy
Disclaimer: Most of the files here are maintained in a "best-effort" way. That is, they may break or become outdated from time to time. Caveat emptor.
systemd unit
maddy.service launches using default config path (/etc/maddy/maddy.conf).
maddy@.service launches maddy using custom config path. E.g.
maddy@foo.service will use /etc/maddy/foo.conf.
Both unit files use DynamicUser to allocate user account for maddy, hence you don't need to create it explicitly. Also, they use *Directory options, so required directories will be created as well.
Additionally, unit files apply strict sandboxing, limiting maddy permissions on the system to a bare minimum. Subset of these options makes it impossible for privileged authentication helper binaries to gain required permissions, so you may have to disable it when using system account-based authentication with maddy running as a unprivilieged user.
fail2ban configuration
Configuration files for use with fail2ban. Assume either backend = systemd specified
in system-wide configuration or log file written to /var/log/maddy/maddy.log.
See https://github.com/foxcpp/maddy/wiki/fail2ban-configuration for details.
logrotate configuration
Meant for logs rotation when logging to file is used.
vim ftdetect/ftplugin/syntax files
Minimal supplement to make configuration files more readable and help you see typos in directive names.