* going from s3 to file target wasn't working
* use 'local' in the config instead of a file: url, for the local target, so it is not path-specific
* break out the S3 fields since users can't be expected to know how to form a URL
* use boto to generate a list of S3 hosts
* use boto to validate that the user input for s3 is valid
* fix lots of html errors in the backup admin
Backup location and maximum age can now be configured in the admin panel.
For now only S3 is supported, but adding other duplicity supported backends should be straightforward.
Some users report munin is broken because munin and munin-node disagree about the name of the machine. I think this occurs if hostname (used by munin-node) reports a different name than PRIMARY_HOSTNAME (which we put in the munin config).
Hard-code PRIMARY_HOSTNAME in munin-node.conf.
Fixes#474.
See https://discourse.mailinabox.email/t/404-not-found-on-admin-munin/623/24.
This is an extension of #427. Building on that change it adds support in the
aliases table for flagging aliases as:
1. Applicable to inbound and outbound mail.
2. Applicable to inbound mail only.
3. Applicable to outbound mail only.
4. Disabled.
The aliases UI is also updated to allow administrators to set the direction of
each alias.
Using this extra information, the sqlite queries executed by Postfix are
updated so only the relevant alias types are checked.
The goal and result of this change is that outbound-only catch-all aliases can
now be defined (in fact catch-all aliases of any type can be defined).
This allow us to continue supporting relaying as described at
https://mailinabox.email/advanced-configuration.html#relay
without requiring that administrators either create regular aliases for each
outbound *relay* address, or that they create a catch-all alias and then face a
flood of spam.
I have tested the code as it is in this commit and fixed every issue I found,
so in that regard the change is complete. However I see room for improvement
in terms of updating terminology to make the UI etc. easier to understand.
I'll make those changes as subsequent commits so that this tested checkpoint is
not lost, but also so they can be rejected independently of the actual change
if not wanted.
remove live dependency on Sourceforge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVq5kxAAoJELkgQfTBC92B9uMIALcrGjq7weaL3qRHYRoeVs5C
/Ov1Lg9QY7PGRl3HtBmFvw50E3coxFCFBfEycK0D9Rue6xF2PHyg8n0DvX5Q2wSD
A9EWAv27ZPoup8/ggv970lTZSpJzseJs1Km0QeOaapfgzPFFtDDwUbkV8sHQxXi4
KCFzmlE72rmvsley/u3IlS/dCb07QdLhdIa/ZJYxSIMJdvMqj0enefBOELoeomYC
ZoNzzzB08eCiyTVd6BTFPBz6CWI6yW203JWoQsSjaz9qEB/N6m9u/PrHBT8VPIRM
Q/a4gn598eAzcGEjub3ZYmJlnbBSlhvczfljmYgNcgizy/SwByaA1AaAemdwI5s=
=2FnK
-----END PGP SIGNATURE-----
Merge tag 'v0.12c'
v0.12c
remove live dependency on Sourceforge
everything was already on master
While not widely supported, there are some browser addons that can
validate DNSSEC and TLSA for additional out-of-band verification of
certificates when browsing the web. Costs nothing to implement and
might improve security in some situations.
Recidive can be thought of as FAIL2BAN checking itself. This setup will monitor the FAIL2BAN log and if 10 bans are seen within one day activate a week long ban and email the mail in a box admin that it has been applied . These bans survive FAIL2BAN service restarts so are much stronger which obviously means we need to be careful with them.
Our current settings are relatively safe and definitely not easy to trigger by mistake e.g to activate a recidive IP jail by failed SSH logins a user would have to fail logging into SSH 6 times in 10 minutes, get banned, wait for the ban to expire and then repeat this process 9 further times within a 24 hour period.
The default maxretry of 5 is much saner but that can be applied once users are happy with this jail. I have been running a stronger version of this for months and it does a very good job of ejecting persistent abusers.
