Bug 45172 - docker restart on a UCS docker container resets UCR nameserver1 to environment value
docker restart on a UCS docker container resets UCR nameserver1 to environmen...
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Docker
UCS 4.2
Other Linux
: P5 normal with 2 votes (vote)
: UCS 4.2-2-errata
Assigned To: Arvid Requate
Dirk Wiesenthal
https://hub.docker.com/u/univention/
:
Depends on:
Blocks: 44468
  Show dependency treegraph
 
Reported: 2017-08-08 20:09 CEST by Arvid Requate
Modified: 2017-11-09 16:56 CET (History)
5 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 6: Setup Problem: Issue for the setup process
Who will be affected by this bug?: 1: Will affect a very few installed domains
How will those affected feel about the bug?: 5: Blocking further progress on the daily work
User Pain: 0.171
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Requate univentionstaff 2017-08-08 20:09:32 CEST
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.
Comment 1 Christian Günther 2017-08-09 11:05:13 CEST
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.
Comment 2 Arvid Requate univentionstaff 2017-10-25 15:50:36 CEST
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
Comment 3 Dirk Wiesenthal univentionstaff 2017-11-09 10:24:07 CET
OK, works as expected. Nameserver is preserved for configured UCS containers.

YAML: OK
Comment 4 Arvid Requate univentionstaff 2017-11-09 16:56:51 CET
<http://errata.software-univention.de/ucs/4.2/217.html>