Merge #2444

2444: Remove POD_ADDRESS_RANGE r=mergify[bot] a=DjVinnii

## What type of PR?

Removal

## What does this PR do?

As discussed in #1209 `POD_ADDRESS_RANGE` should be removed in favor of  `SUBNET`. This PR removes the few references that are still left.

### Related issue(s)
- closes #1258

## Prerequisites
Before we can consider review and merge, please make sure the following list is done and checked.
If an entry in not applicable, you can check it or remove it from the list.

- [x] In case of feature or enhancement: documentation updated accordingly
- [x] Unless it's docs or a minor change: add [changelog](https://mailu.io/master/contributors/workflow.html#changelog) entry file.


Co-authored-by: Vincent Kling <v.kling@vinniict.nl>

core/admin/mailu/configuration.py

@@ -87,8 +87,7 @@ DEFAULT_CONFIG = {
     'HOST_REDIS': 'redis',
     'HOST_FRONT': 'front',
     'SUBNET': '192.168.203.0/24',
-    'SUBNET6': None,
-    'POD_ADDRESS_RANGE': None
+    'SUBNET6': None
 }
 
 class ConfigManager:

core/admin/mailu/internal/views/dovecot.py

@@ -13,8 +13,6 @@ def dovecot_passdb_dict(user_email):
     allow_nets.append(app.config["SUBNET"])
     if app.config["SUBNET6"]:
         allow_nets.append(app.config["SUBNET6"])
-    if app.config["POD_ADDRESS_RANGE"]:
-        allow_nets.append(app.config["POD_ADDRESS_RANGE"])
     return flask.jsonify({
         "password": None,
         "nopassword": "Y",

core/postfix/conf/main.cf

@@ -39,7 +39,7 @@ recipient_delimiter = {{ RECIPIENT_DELIMITER }}
 
 # Only the front server is allowed to perform xclient
 # In kubernetes and Docker swarm, such address cannot be determined using the hostname. Allow for the whole Mailu subnet instead.
-smtpd_authorized_xclient_hosts={{ POD_ADDRESS_RANGE or SUBNET }}
+smtpd_authorized_xclient_hosts={{ SUBNET }}
 
 ###############
 # TLS

core/rspamd/conf/worker-controller.inc

@@ -1,4 +1,4 @@
 type = "controller";
 bind_socket = "*:11334";
 password = "mailu";
-secure_ip = "{{ POD_ADDRESS_RANGE or SUBNET }}";
+secure_ip = "{{ SUBNET }}";

docs/swarm/master/README.md

@@ -75,7 +75,7 @@ On this example, we are using:
 - the default ingress mode.
 
 ### Allow authentification with the mesh routing
-In order to allow every (front & webmail) container to access the other services, we will use the variable POD_ADDRESS_RANGE.
+In order to allow every (front & webmail) container to access the other services, we will use the variable SUBNET.
 
 Let's create the mailu_default network:
 ```bash
@@ -83,8 +83,8 @@ core@coreos-01 ~ $ docker network create -d overlay --attachable mailu_default
 core@coreos-01 ~ $ docker network inspect mailu_default | grep Subnet
                     "Subnet": "10.0.1.0/24",
 ```
-In the docker-compose.yml file, we will then use POD_ADDRESS_RANGE = 10.0.1.0/24 
-In fact, imap & smtp logs doesn't show the IPs from the front(s) container(s), but the IP of  "mailu_default-endpoint". So it is sufficient to set POD_ADDRESS_RANGE to this specific ip (which can be found by inspecting mailu_default network). The issue is that this endpoint is created while the stack is created, I did'nt figure a way to determine this IP before the stack creation...
+In the docker-compose.yml file, we will then use SUBNET = 10.0.1.0/24 
+In fact, imap & smtp logs doesn't show the IPs from the front(s) container(s), but the IP of  "mailu_default-endpoint". So it is sufficient to set SUBNET to this specific ip (which can be found by inspecting mailu_default network). The issue is that this endpoint is created while the stack is created, I did'nt figure a way to determine this IP before the stack creation...
 
 ### Limitation with the ingress mode
 With the default ingress mode, the front(s) container(s) will see origin IP(s) all being 10.255.0.x (which is the ingress-endpoint, can be found by inspecting the ingress network)
@@ -106,7 +106,7 @@ When using ingress mode you probably want to disable rate limits, because all re
 
 ## Scalability
 - smtp and imap are scalable
-- front and webmail are scalable (pending POD_ADDRESS_RANGE is used), although the let's encrypt magic might not like it (race condidtion ? or risk to be banned by let's encrypt server if too many front containers attemps to renew the certs at the same time) 
+- front and webmail are scalable (pending SUBNET is used), although the let's encrypt magic might not like it (race condidtion ? or risk to be banned by let's encrypt server if too many front containers attemps to renew the certs at the same time) 
 - redis, antispam, antivirus, fetchmail, admin, webdav have not been tested (hence replicas=1 in the following docker-compose.yml file)
 
 ## Docker secrets
@@ -121,7 +121,7 @@ Instead, we will use the following work-around:
 We need also to:
 - add a deploy section for every service
 - modify the way the ports are defined for the front service
-- add the POD_ADDRESS_RANGE definition for admin (for imap), smtp and antispam services
+- add the SUBNET definition for admin (for imap), smtp and antispam services
 
 ## Docker compose 
 An example of docker-compose-stack.yml file is available here:
@@ -185,7 +185,7 @@ services:
     restart: always
     env_file: .env
     environment:
-      - POD_ADDRESS_RANGE=10.0.1.0/24
+      - SUBNET=10.0.1.0/24
     volumes:
       - "$ROOT/overrides:/overrides"
     depends_on:
@@ -198,7 +198,7 @@ services:
     restart: always
     env_file: .env
     environment:
-      - POD_ADDRESS_RANGE=10.0.1.0/24
+      - SUBNET=10.0.1.0/24
     volumes:
       - "$ROOT/filter:/var/lib/rspamd"
       - "$ROOT/dkim:/dkim"
@@ -231,7 +231,7 @@ services:
     restart: always
     env_file: .env
     environment:
-      - POD_ADDRESS_RANGE=10.0.1.0/24
+      - SUBNET=10.0.1.0/24
     volumes:
       - "$ROOT/data:/data"
       - "$ROOT/dkim:/dkim"

docs/swarm/master/README_nfs_example.md

@@ -62,7 +62,7 @@ On this example, we are using:
 - the default ingress mode.
 
 ### Allow authentification with the mesh routing
-In order to allow every (front & webmail) container to access the other services, we will use the variable POD_ADDRESS_RANGE.
+In order to allow every (front & webmail) container to access the other services, we will use the variable SUBNET.
 
 Let's create the mailu_default network:
 ```bash
@@ -70,8 +70,8 @@ core@coreos-01 ~ $ docker network create -d overlay --attachable mailu_default
 core@coreos-01 ~ $ docker network inspect mailu_default | grep Subnet
                     "Subnet": "10.0.1.0/24",
 ```
-In the docker-compose.yml file, we will then use POD_ADDRESS_RANGE = 10.0.1.0/24 
-In fact, imap & smtp logs doesn't show the IPs from the front(s) container(s), but the IP of  "mailu_default-endpoint". So it is sufficient to set POD_ADDRESS_RANGE to this specific ip (which can be found by inspecting mailu_default network). The issue is that this endpoint is created while the stack is created, I did'nt figure a way to determine this IP before the stack creation...
+In the docker-compose.yml file, we will then use SUBNET = 10.0.1.0/24 
+In fact, imap & smtp logs doesn't show the IPs from the front(s) container(s), but the IP of  "mailu_default-endpoint". So it is sufficient to set SUBNET to this specific ip (which can be found by inspecting mailu_default network). The issue is that this endpoint is created while the stack is created, I did'nt figure a way to determine this IP before the stack creation...
 
 ### Limitation with the ingress mode
 With the default ingress mode, the front(s) container(s) will see origin IP(s) all being 10.255.0.x (which is the ingress-endpoint, can be found by inspecting the ingress network)
@@ -90,7 +90,7 @@ As a side effect of this ingress mode "feature", make sure that the ingress subn
 
 ## Scalability
 - smtp and imap are scalable
-- front and webmail are scalable (pending POD_ADDRESS_RANGE is used), although the let's encrypt magic might not like it (race condidtion ? or risk to be banned by let's encrypt server if too many front containers attemps to renew the certs at the same time) 
+- front and webmail are scalable (pending SUBNET is used), although the let's encrypt magic might not like it (race condidtion ? or risk to be banned by let's encrypt server if too many front containers attemps to renew the certs at the same time) 
 - redis, antispam, antivirus, fetchmail, admin, webdav have not been tested (hence replicas=1 in the following docker-compose.yml file)
 
 ## Variable substitution and docker-compose.yml
@@ -176,7 +176,7 @@ services:
     restart: always
     env_file: .env
     environment:
-      - POD_ADDRESS_RANGE=10.0.1.0/24
+      - SUBNET=10.0.1.0/24
     volumes:
 #      - "$ROOT/overrides:/overrides"
       - type: volume
@@ -192,7 +192,7 @@ services:
     restart: always
     env_file: .env
     environment:
-      - POD_ADDRESS_RANGE=10.0.1.0/24
+      - SUBNET=10.0.1.0/24
     depends_on:
       - front
     volumes:
@@ -240,7 +240,7 @@ services:
     restart: always
     env_file: .env
     environment:
-      - POD_ADDRESS_RANGE=10.0.1.0/24
+      - SUBNET=10.0.1.0/24
     volumes:
 #      - "$ROOT/data:/data"
       - type: volume

towncrier/newsfragments/1258.removal

@@ -0,0 +1 @@
+Remove POD_ADDRESS_RANGE in favor of SUBNET