-
-
Notifications
You must be signed in to change notification settings - Fork 15.5k
nixos/rspamd: Multiple workers, extraConfig priority & postfix integration #49809
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot! Was about to open a similar PR because I already added a proxy worker with the current module layout.
}; | ||
}; | ||
|
||
|
||
###### implementation | ||
|
||
config = mkIf cfg.enable { | ||
services.rspamd.overrides = configOverrides; | ||
services.rspamd.workers = mkIf cfg.postfix.enable { | ||
normal = {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
@@ -58,7 +59,7 @@ let | |||
}; | |||
type = mkOption { | |||
type = types.nullOr (types.enum [ | |||
"normal" "controller" "fuzzy_storage" "proxy" "lua" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least a changelog entry :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have made #51012 to address this issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
extraConfig
andworker.<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 theoverrides
option to store the value of the twoextraConfig
options inextra-config.inc
andworker-<name?>.inc
respectively.postfix integration
The
rmilter
module has options for configuringpostfix
to use it but since that module is deprecated because rspamd now has a builtin worker that supports the milter protocol this PR adds similarpostfix
integration options directly to therspamd
module.Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)