nixos-mailserver
nixos-mailserver copied to clipboard
r-raymond
Expose rspamd's web interface
This depends on https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/mail/rspamd.nix getting an option for setting the controller password. Since neither rspamd.nix offers such an option nor a way to add extraConfig a change to that nix file has to be made.
Once this is done the web interface can be exposed which allows for more insight into what rspamd is doing.
It seems to be common practice to hide it behind a nginx proxy. An nginx server is required for easy let's encrypt certificates anyway, so I'd follow this practice.
While the original idea was to not include a web server at all, I'd like to see this as an opt in feature. To be honest though, once we have a full fledged web server running, the question arises if we should also provide some kind of groupware solution.
I agree. I personally don't see the need to include a groupware solution bt YMMV. Perhaps something small and tiny of the size of roundcubemail but IMHO that's highly optional.
This is just about making available the functionality that's already there. rspamd already starts the web interface and its web server - might as well use it. After all that is one of its benefits over spamassassin. The proxying through nginx is mainly a security consideration.
Ok, I'll try to include this as soon as the Let's Encrypt certificates have landed.
Regarding those certificates, ignoring the changes necessary for postfix, dovecot and so on this is all it needs, assuming you haven't found out by yourself already:
services.nginx = {
enable = true;
virtualHosts."example.com".enableACME = true;
}
@phdoerfler @r-raymond regarding Let's Encrypt, I don't have time to put together a PR right now, but this is how I have approached it in the past:
services.nginx = {
enable = true;
virtualHosts = {
"_" = {
default = true;
locations = {
"/.well-known/acme-challenge" = {
root = "/var/www/challenges";
};
};
};
};
};
security.acme.certs = {
"${hostname}" = {
webroot = "/var/www/challenges";
email = "${email}";
plugins = [
"fullchain.pem"
"key.pem"
"account_key.json"
"cert.pem"
"chain.pem"
];
postRun = "systemctl reload-or-restart postfix dovecot2"; # etc
};
};
This is more or less what the enableACME option does, but it gives you a bit more control over the resulting certificate (maybe you want to add some extra hostnames to it or something) and you are able to specify the postrun clause.
The one nice thing about enableACME that this lacks is that enableACME generates preliminary self signed certificates so that your services do not completely fail before obtaining the certificate from Let's Encrypt.
If you want to combine the best of both approaches, you can just generate the preliminary self signed cert like this: https://github.com/eqyiel/nixos-config/blob/master/config/localghost/configuration.nix#L276-L333
There's a bit more discussion about this here: https://github.com/NixOS/nixops/issues/283#issuecomment-205051140
@phdoerfler @eqyiel thanks for the suggestions. Since we already have a "create certificates on the fly" option, the preliminary certificates are not an issue.
The biggest time requirement for this is surely testing the whole setup, as I now need to put it on an actual static IP, not on my local VM. I used to use Vultr for this, is there a better option out there today?
@r-raymond maybe the free tier AWS/EC2? In my experience NixOps works really well there.
I have my nixos server running on vultr, too. Don’t see anything wrong with it.
Don't get me wrong, vultr is awesome for letting you pick arbitrary iso's to boot, but they are a little more expensive as say scaleway.
Oh I did not know about scaleway. There exist instructions on how to install NixOS on scaleway. Those don't look too bad to me.
NixOS has a test helper that sets up its own letsencrypt server to test letsencrypt options nixos/tests/common/letsencrypt.nix. Maybe you can use that to test letsencrypt support
