Hi Nicolas, First of all, thank you for trying out images so quickly, it is much appreciated!
> On 25.09.2026., at 15:58, Nicolas CARPi <[email protected]> wrote: > > Hello Dinko, > > I tried the new image with a read-only root filesystem: > > docker run --rm --read-only --name hatest -d > haproxytech/haproxy:debian-s6-3.5-dev7 > > And the error was: > > [ALERT] (117) : Binding [/etc/haproxy/haproxy.cfg:10] for frontend GLOBAL: > protocol unix_stream: error when trying to unlink previous UNIX socket > (Read-only file system) [/var/run/haproxy-runtime-api.sock]. > 2026/09/25 13:36:41 error initializing dataplane internal storage: missing > directory, unable to create: mkdir /usr/local/var/lib/dataplaneapi/storage: > read-only file system This is actually expected. Dataplaneapi needs at least its own folders (defined in dataplaneapi configuration) and HAProxy configuration folder to be writeable, to be able to manage HAProxy configuration, certificates, maps and everything else. Without write permissions it cannot operate correctly. > > The services did not start. > > Should these directories be exported as tmpfs on read-only filesystems? Dataplaneapi folders should be either tmpfs mounts or volumes, but in any case folders should reside on a volume with full r/w permissions. Note that these settings to not belong to Dockerfile, as they are environment-specific so that’s why they are not part the image — but we can certainly better document this for users that want the image to operate in r/o mode. > > There is another related issue: 01-dataplaneapi attempts to replace the > default admin password using sed -i. With --read-only, that write cannot > succeed, but the script explicitly exits with 0. So unless I am missing > something, after making the runtime directories writable, Data Plane API > could end up starting with the shipped admin password unchanged. At least for Docker container, mounts are fixed at container creation and updating “live” container by adding writeable filesystem/volume is impossible at this moment. Recreating the container (commit, stop, run) would cause 01-dataplaneapi to run again rewriting the bad password... > > Illustration: > > docker run --rm --tmpfs /var/run --read-only --name hatest -d > haproxytech/haproxy:debian-s6-3.5-dev7 > > docker exec -it hatest grep password: /usr/local/etc/haproxy/dataplaneapi.yml > password: admin > > Adding "set -eu" to that script should at least prevent deploying something > with password set to "admin". I completely agree, good observation and we’ll do it ASAP. > > Perhaps read-only operation should either be supported explicitly, with the > required writable paths documented, or fail clearly when the configuration > cannot be updated. > > Side note: I suggest increasing the password size to 24 characters. 8 > characters from 66 characters alphabet is pretty weak by today's standard ;) > > I normally use the images from docker.io/haproxy rather than the haproxytech > images, so perhaps this limitation was already present before the gopherd > migration. I could not find anything about read-only filesystems in the > README. We indeed support r/o deployments in K8s for KIC and HUG projects, but in general sense Dataplaneapi was always written to be able to have all its folders (documented and configured) writeable, as well as HAProxy configuration folder writeable by definition — there is no sense of having it running without r/w permissions to begin with. Again, thank you for useful observations. Kind regards, D. -- Dinko Korunic ** Standard disclaimer applies ** Sent from OSF1 osf1v4b V4.0 564 alpha
