nixos/rspamd: Multiple workers, extraConfig priority & postfix integration#49809
nixos/rspamd: Multiple workers, extraConfig priority & postfix integration#49809fpletz merged 4 commits intoNixOS:masterfrom
Conversation
When the workers option for rspamd was originally implemented it was
based on a flawed understanding of how workers are configured in rspamd.
This meant that while rspamd supports configuring multiple workers of
the same type, so that different controller workers could have different
passwords, the NixOS module did not support this because it would write
an invalid configuration file if you tried.
Specifically a configuration like the one below:
```
workers.controller = {};
workers.controller2 = {
type = "controller";
};
```
Would result in a rspamd configuration of:
```
worker {
type = "controller";
count = 1;
.include "$CONFDIR/worker-controller.inc"
}
worker "controller2" {
type = "controller";
count = 1;
}
```
While to get multiple controller workers it should instead be:
```
worker "controller" {
type = "controller";
count = 1;
.include "$CONFDIR/worker-controller.inc"
}
worker "controller" {
type = "controller";
count = 1;
}
```
The lines stored in `extraConfig` and `worker.<name?>.extraConfig` should take precedent over values from included files but in order to do this in rspamd UCL they need to be stored in a file that then gets included with a high priority. This commit uses the overrides option to store the value of the two `extraConfig` options in `extra-config.inc` and `worker-<name?>.inc` respectively.
|
Looks good for me. It builds, and at least postix integration part works. |
fpletz
left a comment
There was a problem hiding this comment.
Thanks a lot! Was about to open a similar PR because I already added a proxy worker with the current module layout.
There was a problem hiding this comment.
Note that when using the proxy worker with postfix, the normal worker isn't strictly needed. We might want do drop it here.
There was a problem hiding this comment.
You are right it is not needed so I have removed it.
The `rmilter` module has options for configuring `postfix` to use it but since that module is deprecated because rspamd now has a builtin worker that supports the milter protocol this commit adds similar `postfix` integration options directly to the `rspamd` module.
| }; | ||
| type = mkOption { | ||
| type = types.nullOr (types.enum [ | ||
| "normal" "controller" "fuzzy_storage" "proxy" "lua" |
There was a problem hiding this comment.
There was a problem hiding this comment.
I guess yeah it got replaced by "rspamd_proxy", but then it should be made backwards compatible in some way.
There was a problem hiding this comment.
proxy was renamed to rspamd_proxy because that is the actual type of the worker. I am sorry it broke those that used it. I should probably make another PR with a warning for proxy instead.
There was a problem hiding this comment.
What's an easy fix for this on the nixpkgs side? I can't expect nixos-mailserver to fix this because they need to support multiple versions.
There was a problem hiding this comment.
Thanks!
I figured out that I can temporarily just use
{
services.rspamd.workers.${worker}.type = mkForce "rspamd_proxy";
}in my NixOS config to fix it.
There was a problem hiding this comment.
@grahamc I haven't changed release-notes before so can you guide me a little?
If I add back support for type having the value proxy but also then show a warning should I then add my release notes description in the Backward Incompatibilities section or the Other Notable Changes section?
There was a problem hiding this comment.
@griff Since after the fix a configuration with the old value still works with the new nixpkgs, it's still compatible. Pretty sure it doesn't need a release note.
There was a problem hiding this comment.
I have made #51012 to address this issue.
There was a problem hiding this comment.
I don't think reallowing proxy is necessary or a good thing to do. These kind of workarounds just increase the complexity of NixOS modules. Nixos-mailserver can fix this with https://gitlab.com/simple-nixos-mailserver/nixos-mailserver/merge_requests/142.
|
I don't think reallowing `proxy` is necessary or a good thing to do. These kind of workarounds just increase the complexity of NixOS modules. Nixos-mailserver can fix this with https://gitlab.com/simple-nixos-mailserver/nixos-mailserver/merge_requests/142.
But adding a release note and producing a warning when it is used is still reasonable.
|
|
Adding a release note certainly is. But if we don't allow |
|
On Sun, Nov 25, 2018 at 02:11:49AM -0800, Robert Schütz wrote:
Adding a release note certainly is. But if we don't allow `"proxy"`, then there's no need for a warning.
Just custom error ("proxy" is not allowed now, use "rspamd_proxy") can
be useful for upgrading. Our upgrade process allow this, because system
never become in middle-aka-broken state.
|
First this doesn't work in general, people don't always use stable versions only. SNM would have to maintain an ugly workaround for a while that can't be removed. Also, since SNM has a stable release cycle, a new minor release is needed. All of that because we don't want to provide at least a little bit of backwards compatibility in nixpkgs? That's a no from me. |
|
On Sun, Nov 25, 2018 at 05:14:42AM -0800, Silvan Mosberger wrote:
> I don't think reallowing `proxy` is necessary or a good thing to do. These kind of workarounds just increase the complexity of NixOS modules. Nixos-mailserver can fix this with [gitlab.com/simple-nixos-mailserver/nixos-mailserver/merge_requests/142](https://gitlab.com/simple-nixos-mailserver/nixos-mailserver/merge_requests/142).
First this doesn't work in general, people don't always use stable versions only. SNM would have to maintain an ugly workaround for a while that can't be removed. Also, since SNM has a stable release cycle, a new minor release is needed.
I am sit on master myself. But I understand. that message "please
replace option xxx with yyy" is a compromise.
All of that because we don't want to provide at least a little bit of backwards compatibility in nixpkgs? That's a no from me.
Reasonable.
Would be nice to have RFC explaining/guiding compatibility procedures.
Any volunteers to write?
|
|
Well I have an RFC (albeit going forward very slowly) that lays foundation for a deprecation guideline for nixpkgs attributes, but not NixOS modules (yet at least): NixOS/rfcs#33 |
|
I personally always try to provide backwards compatibility and warnings when making module changes and had I not missed it originally the changes in #51012 would have been part of this PR. It adds a little module complexity for a lot of user convenience. The discussion to have is then for how many stable releases to keep these compatibility fixes and when to remove them. |
The worker type "proxy" was renamed to "rspamd_proxy" in NixOS/nixpkgs#49809.
Motivation for this change
Multiple workers
When the workers option for rspamd was originally implemented it was based on a flawed understanding of how workers are configured in rspamd. This meant that while rspamd supports configuring multiple workers of the same type, so that different controller workers could have different passwords, the NixOS module did not support this because it would write an invalid configuration file if you tried.
Specifically a configuration like the one below:
Would result in a rspamd configuration of:
While to get multiple controller workers it should instead be:
extraConfig priority
The lines stored in
extraConfigandworker.<name?>.extraConfigshould take precedent over values from included files but in order to do this in rspamd UCL they need to be stored in a file that then gets included with a high priority. This commit uses theoverridesoption to store the value of the twoextraConfigoptions inextra-config.incandworker-<name?>.increspectively.postfix integration
The
rmiltermodule has options for configuringpostfixto use it but since that module is deprecated because rspamd now has a builtin worker that supports the milter protocol this PR adds similarpostfixintegration options directly to therspamdmodule.Things done
sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)nix path-info -Sbefore and after)