Mailu / helm-charts

Development repo for helm charts
127 stars 129 forks source link

Allow overrides for dovecot #22

Closed micw closed 3 years ago

micw commented 4 years ago

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.

tgruenert commented 4 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?

unixfox commented 4 years ago

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.

micw commented 4 years ago

@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 commented 4 years ago

@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.

omitrowski commented 4 years ago

I guess this would be related: https://github.com/Mailu/helm-charts/issues/61. I guess our approach would satisfie this request too.

fw8 commented 4 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
...

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.

micw commented 3 years ago

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.

micw commented 3 years ago

Sorry for that long delay. #75 is finally merged. PRs that adds overrides to other service in the same way are welcome.