Univention Bugzilla – Bug 45172
docker restart on a UCS docker container resets UCR nameserver1 to environment value
Last modified: 2017-11-09 16:56:51 CET
A docker restart on a UCS docker container resets UCR nameserver1 to the value specified during "docker run" via the "-e nameserver1" environment variable. I've tested this for Bug 44468 with a ucs-master-amd64 image. After setup I have: =================================================================== root@master2:/# ucr search --brief nameserver forwarder dns/forwarder1: 10.200.8.10 dns/forwarder2: 192.168.0.97 dns/forwarder3: <empty> dns/nameserver/registration/forward_zone: <empty> dns/nameserver/registration/reverse_zone: <empty> nameserver/external: false nameserver/option/timeout: 2 nameserver1: 172.17.0.2 nameserver2: <empty> nameserver3: <empty> =================================================================== But after restart I get: =================================================================== root@master2:/# ucr search --brief nameserver forwarder dns/forwarder1: 10.200.8.10 dns/forwarder2: 192.168.0.97 dns/forwarder3: <empty> dns/nameserver/registration/forward_zone: <empty> dns/nameserver/registration/reverse_zone: <empty> nameserver/external: false nameserver/option/timeout: 2 nameserver1: 10.200.8.10 nameserver2: <empty> nameserver3: <empty> =================================================================== This can break several things in the containers provided via hub.docker.com. I guess the /sbin/init wrapper in the container should only transfer the value from the environment if the corresponding UCR variable is yet unset. AFAICS the appcenter doesn't rely on this "-e nameserver1" mechanism anyway.
I think there is also docker dns handling related. When the docker default bridge is used, docker handles and patches the /etc/resolv.conf by itself. https://docs.docker.com/engine/userguide/networking/default_network/configure-dns/ The behavior differs, when a custom bridge is used. Then the dns configuration is handled by an docker internal dns service: https://docs.docker.com/engine/userguide/networking/configure-dns/ Especially important is the following point: ==================================== The exact details of how Docker manages the DNS configurations inside the container can change from one Docker version to the next. So you should not assume the way the files such as /etc/hosts, /etc/resolv.conf are managed inside the containers and leave the files alone and use the following Docker options instead. ==================================== So it seems, that this is a point which can break in the future by docker updates. Maybe ucs should not perform patching of /etc/resolv.conf and docker commands should be used instead? Or at least some docker setup guide should contain statements which docker dns options should be used and which not. Especially if the docker --dns option should be equal to dns/forwarder1 or nameserver1.
I've adjusted the /sbin/init wrapper to only initialize the nameserver UCR variables from the environment (or from /etc/resolv.conf) if the system has not been joined yet. When the container is already joined, the /etc/resolv.conf only gets committed from the UCR template. This is required when "docker restart" is used, because in that case docker re-initializes the file, derived from the resolv.conf of the host, just like during the initial container creation. Reasoning: The initial purpose for this nameserver handling in /sbin/init wrapper is twofold: 1. allow somebody using one of the VM-style role containers from hub.docker.com and hand a specific nameserver to the container, that may differ from the DNS servers configured for the hosting system (or for all other docker containers via the --dns option for the docker daemon). But that's optional, so I removed the "-e nameserver1=..." option from the recommended "docker run" command documented on hub.docker.com. 2. Make the content of resolv.conf consistent with UCR configuration. UCS and UCS users expect the resolver to act as configured in UCR and docker restarts must not break that. These changes should only affect the containers on hub.docker.com. Our appcenter code picks up the nameserver variables from the host UCR anyway and injects them into the appbox-style containers. Advisory: univention-docker-container-mode.yaml
OK, works as expected. Nameserver is preserved for configured UCS containers. YAML: OK
<http://errata.software-univention.de/ucs/4.2/217.html>