Closed jeroenpeeters closed 9 years ago
Yes, unfortunately, with the current mode of operation, this is unavoidable. In a future version of pipework, the DHCP client will execute in a separate container sharing the same namespace, which will avoid the issue (but not completely solve the resolv.conf
update by the DHCP server).
I also meet this problem.
And I avoid the problem by adding option -C resolv.conf
to dhcpcd.
ip netns exec "$NSPID" "$DHCP_CLIENT" -q "$CONTAINER_IFNAME" -h "$GUESTNAME" -C resolv.conf
I think make this option default is ok for almost all situation.
The DHCP client now executes in a separate container; that should fix the problem :-)
Thanks for creating this handy script! Unfortunately I have one issue preventing me from using it successfully. I run Docker on a CoreOS cluster which has dhcpcd installed. Assigning an IP from DHCP to a docker container is successful the first time. However, I discovered that dhcpcd also writes to /etc/resolv.conf on the host machine. It basically empties the file, and leaves a comment stating that dhcpcd changed the file.
My understanding is that ip netns exec would allow the execution of a namespace unaware application in the namespace. Still it seems that dhcpcd is able to "break out" of the namespace and change the configuration of the host machine.
Do you have any pointers for me how to prevent this?
[ $DHCP_CLIENT = "dhcpcd" ] && ip netns exec $NSPID $DHCP_CLIENT -q $CONTAINER_IFNAME -h $GUESTNAME