Closed micw closed 3 years ago
i would like to suggest a structure at values.yaml for this
# overrides define file content at ./overrides directory
# for each supported component here an set of files and there content can be defined
overrides:
rspamd:
actions.conf: |
# reject = 8; # Reject when reaching this score
# add_header = 6; # Add header when reaching this score
# greylist = 4; # Apply greylisting when reaching this score (will emit `soft reject action`)
#unknown_weight = 1.0; # Enable if need to set score for all symbols implicitly
# Each new symbol is added multiplied by gf^N, where N is the number of spammy symbols
#grow_factor = 1.1;
# Set rewrite subject to this value (%s is replaced by the original subject)
#subject = "***SPAM*** %s"
# .include(try=true; priority=1; duplicate=merge) "$LOCAL_CONFDIR/local.d/actions.conf"
# .include(try=true; priority=10) "$LOCAL_CONFDIR/override.d/actions.conf"
whiteliste.conf: |
whitelist_from {
type = "from";
filter = "email:domain";
prefilter = "true";
map = "/${LOCAL_CONFDIR}/override.d/whitelist_from.map";
# action = "accept";
score = -15;
symbol = "WHITELIST_FROM_DOMAINS";
}
so for every component supporting (rspamd, nginx, ...) overrides i would like to define a configmap and mount the files shown in example inside the directory /overrides/{component}/
would this cover your needs?
Helm allows to pass a whole file using --set-file
(see this comment for an example: https://github.com/helm/helm/issues/3276#issuecomment-496730046). Then like @tgruenert said, you "just" need to mount the configmap of the file on the appropriate deployment.
I think it's more appropriate than including the override files into the values.yml which could become a mess if one has a lot of files.
@unixfox: as far as I can see it should be possible to set these variables from a file too (e.g. help --set-file overrides=myoverrides.yaml) - right?
@unixfox: as far as I can see it should be possible to set these variables from a file too (e.g. help --set-file overrides=myoverrides.yaml) - right?
Probably but I can't confirm on that because there could be some transformation needed from YAML to actual helm YAML. Anyway it's better to test with an example helm chart in order to be sure that it really works.
I guess this would be related: https://github.com/Mailu/helm-charts/issues/61. I guess our approach would satisfie this request too.
i would like to suggest a structure at values.yaml for this
# overrides define file content at ./overrides directory # for each supported component here an set of files and there content can be defined overrides: rspamd: actions.conf: | # reject = 8; # Reject when reaching this score ...
so for every component supporting (rspamd, nginx, ...) overrides i would like to define a configmap and mount the files shown in example inside the directory /overrides/{component}/
would this cover your needs?
Nice idea!
But I would prefer to add the overrides to the existent entries of each component... like so:
postfix:
overrides:
postfix.cf: |
# overrides for postfix
dovecot:
overrides:
dovecot.conf: |
# overrides for dovecot
...
What do you think about that?
So far I've done it for postfix and it is working. I can extend the other components in the same way (if they support the "override" mechanism) and make a PR.
I agree that having overrides in components makes more sense. @zurajm the PR is mixed up with the previous one, we need to get this sorted. Otherwise it looks good. Best way to fix this is to create a new branch from origin/master and cherry-pick your own changes into it.
Sorry for that long delay. #75 is finally merged. PRs that adds overrides to other service in the same way are welcome.
Overrides can customize config of mailu's services. E.g. for NFS, the following is required: https://mailu.io/1.7/kubernetes/mailu/index.html#adaptations
Overrides should also be supported by the helm chart. I think the best way is to use values and configmaps here.