kubernetes/apps/paperless/ftp-scanner.yaml

@@ -1,20 +1,3 @@
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: ftp-scanner-config
-  namespace: paperless
-data:
-  PASV_ADDRESS: "10.2.99.82"
-  PASV_MIN_PORT: "21100"
-  PASV_MAX_PORT: "21104"
-  FTP_USER: "scanner"
-  # Run vsftpd's chrooted user as paperless's uid/gid. Uploaded files
-  # then come in already owned paperless:paperless, so paperless's
-  # init-folders s6 service (which chowns the consume-dir to paperless:
-  # paperless on every start) is a no-op and no ACL workaround is needed.
-  UID: "1000"
-  GID: "1000"
----
 apiVersion: apps/v1
 kind: Deployment
 metadata:

kubernetes/apps/paperless/kustomization.yaml

@@ -12,3 +12,27 @@ resources:
   - ftp-scanner.yaml
   - syncthing.yaml
   - network-policy.yaml
+configMapGenerator:
+  # vsftpd config for the ftp-scanner deployment. The content-hash name
+  # suffix is intentionally LEFT ENABLED (unlike home-assistant's nginx
+  # config): vsftpd templates pasv_address from PASV_ADDRESS at container
+  # start, so a changed value must roll the pod. With the hash suffix,
+  # editing any value here renames the generated ConfigMap, which mutates
+  # the Deployment's pod template and triggers an automatic rolling
+  # restart. Without it, an IP change (e.g. an LB re-allocation) silently
+  # leaves the running pod advertising the stale PASV address, which
+  # breaks classic-PASV clients (older Brother scanners) while EPSV
+  # clients keep working.
+  - name: ftp-scanner-config
+    namespace: paperless
+    literals:
+      - PASV_ADDRESS=10.2.99.82
+      - PASV_MIN_PORT=21100
+      - PASV_MAX_PORT=21104
+      - FTP_USER=scanner
+      # Run vsftpd's chrooted user as paperless's uid/gid. Uploaded files
+      # then come in already owned paperless:paperless, so paperless's
+      # init-folders s6 service (which chowns the consume-dir to paperless:
+      # paperless on every start) is a no-op and no ACL workaround is needed.
+      - UID=1000
+      - GID=1000