Cant resolve host майнинг

Could not resolve host: get.docker.com #14

Comments

nickdos commented May 31, 2018 •

Script failed at

Edit: Using 2018-04-18-raspbian-stretch-lite on a RPi 3B+ booting in headless mode connecting via wifi (using the wpa_supplicant.conf file method).

The text was updated successfully, but these errors were encountered:

nickdos commented May 31, 2018 •

RPi not responding to SSH, so might be PSU issue or network.

dale3h commented May 31, 2018

This does sound like a network related issue that is not caused by the script itself.

nickdos commented May 31, 2018

I was able to reach that site with my Mac, so not a firewall issue. RPi won’t boot now, so starting from scratch again. Everything was fine up to that line, so I’m thinking my PSU might’ve been marginal in terms of supplying enough current and I was using Wifi. Will try with Ethernet next as well.

nickdos commented Jun 1, 2018 •

I’m still getting the same issue — different PSU (but still on wifi) and failed at the same spot.

I’m using CloudFlare DNS (1.1.1.1), so not sure if that is an issue but I can resolve the host on other machines, so maybe Stretch lite is doing something strange with DNS?

Edit: re-imaged SD card and before running script tested DNS/network:

Edit-2: Re-ran on ethernet and script ran to completion. I’m guessing that wifi is the issue and that the docker container cannot access network via the host OS.

Источник

Containers cannot resolve DNS if docker host uses 127.0.0.1 as resolver #541

Comments

jbwyatt4 commented May 7, 2013

I’m trying to install rails on a docker container. However the OS inside docker cannot seem to connect to the internet. I get this error message on the base (just apt-get wasn’t able to connect to the internet).

sudo: unable to resolve host e62b9fa31bb9
Err http://archive.ubuntu.com quantal InRelease

Err http://archive.ubuntu.com quantal Release.gpg
Temporary failure resolving ‘archive.ubuntu.com’
Reading package lists. Done
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/quantal/InRelease

W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/quantal/Release.gpg Temporary failure resolving ‘archive.ubuntu.com’

W: Some index files failed to download. They have been ignored, or old ones used instead.

I’ve had this issue since docker 0.1 to 0.3. Running on either the host machine or in vmware. (Virtualbox does not have this issue but sometimes the kernel segfaults within the container.)

The text was updated successfully, but these errors were encountered:

creack commented May 7, 2013

The kernel segfault is a known bug with kernels

jpetazzo commented May 7, 2013

Maybe we should detect when /etc/resolv.conf is configured to use 127.*,
shouldn’t we?

On Tue, May 7, 2013 at 10:00 AM, Guillaume J. Charmes wrote:

The kernel segfault is a known bug with kernels

unclejack commented May 7, 2013

Perhaps we could use the proxy from docker to proxy these requests to localhost? e.g.: use 172.16.42.1 within docker containers as the DNS server and use 127.0.0.1 as the real DNS

jpetazzo commented May 7, 2013

Well, IMHO, if we detect that the DNS server is 127.*, we should generate a
resolv.conf file containing the address of the bridge, and bind it into the
hosts.

We had lots of discussions with @creack a long time ago about this, so I
thought it was already implemented, in fact 😮

unclejack commented May 7, 2013

@jpetazzo Unfortunately dnsmasq isn’t set up by default to accept requests on the IP of the docker0 bridge, even though it seems to be bound to 0.0.0.0. I’ve just verified whether dnsmasq allows DNS resolution when using the docker0 bridge IP address as the DNS server. Setting it up isn’t an option, imo.

We could set up docker to look for an alternative resolv.conf file (e.g. /etc/resolv.docker). If 127.* is in resolv.conf, no resolv.docker exists and no -dns option was passed to docker -d or docker run, we could use public DNS and print a warning on the screen (. WARNING — docker is using public DNS because /etc/resolv.conf lists 127.0.0.1 as a DNS server).

jpetazzo commented May 7, 2013

On Tue, May 7, 2013 at 12:44 PM, unclejack notifications@github.com wrote:

@jpetazzo https://github.com/jpetazzo Unfortunately, dnsmasq isn’t set
up by default to accept requests on the IP of the docker0 bridge, even
though it seems to be bound to 0.0.0.0. I’ve just verified whether dnsmasq
allows DNS resolution when using the docker0 bridge IP address as the DNS
server. Setting it up isn’t an option, imo.

We could set up docker to look for an alternative resolv.conf file (e.g.
/etc/resolv.docker). If 127.* is in resolv.conf, no resolv.docker exists
and no -dns option was passed to docker -d or docker run, we could use
public DNS and print a warning on the screen (. WARNING — docker is using
public DNS because /etc/resolv.conf lists 127.0.0.1 as a DNS server).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/541#issuecomment-17565591
.

fj commented May 21, 2013

We could set up docker to look for an alternative resolv.conf file (e.g. /etc/resolv.docker). If 127.* is in resolv.conf, no resolv.docker exists and no -dns option was passed to docker -d or docker run, we could use public DNS and print a warning on the screen (. WARNING — docker is using public DNS because /etc/resolv.conf lists 127.0.0.1 as a DNS server).

To whatever extent possible I think containers shouldn’t know about Docker, so injecting Docker-specific knowledge inside the container is something to avoid.

If I misunderstood you and you were instead proposing having the /etc/resolv.conf be outside the containers with a fallback to hardcoded public DNS (but where docker -dns always takes priority). I think that’s a good idea.

unclejack commented May 21, 2013

@fj It was about the /etc/resolv.conf and /etc/resolv.docker which would live on the host. Docker will still manage everything on its own when setting up the resolv.conf in the container, it would just pick a DNS using the rules I’ve described.

shykes commented Jun 14, 2013

This is fixed in master. The docker daemon will detect that the host’s resolv.conf points to localhost, and fallback to a public default (8.8.8.8). This can then be overridden by the admin with ‘docker -d -dns’.

mlebkowski commented Nov 29, 2013

It seems that it’s not just the case of localhost.

It seems that docker uses the same network as the host. I can’t really tell if this is a docker issue or my network configuration. Should I reopen the ticket?

tianon commented Nov 30, 2013

Well, those networks are indeed overlapping, but that looks like it might be a separate issue, since Docker’s automatic network detection code should’ve avoided exactly that, as far as I remember (it’s been a while since I looked at that part of the code).

I believe the exact DNS fix described here was that if your DNS server is anything in a «local» block, it gets remapped to 8.8.8.8, so even in your case it should’ve been remapped, as far as my understanding goes. Perhaps someone with more knowledge of that specific part of the code will chime in here. 🙂

cattz commented Dec 10, 2013

Maybe a better option, other than remap the nameserver to a public one would be to have an way to configure the ‘default’ nameserver for containers. I can get DNS working fine when I run it with the -dns flag. The problem I’m facing is how to have stuff installed when using docker build as apt-get/yum cannot resolve the repos URLs. Having a public nameserver doesn’t work for me, since I’m inside a corporate netrwork where DNS traffic seems to be -somehow- restricted.

cattz commented Dec 10, 2013

I can reply to my own question: #815

(..) in order to use dns server side (i.e. like doing -dns on each run automatically), you can start docker daemon with -dns x.x.x.x.
Ex: docker -d -D -dns 8.8.8.8 -dns 8.8.4.4

anentropic commented Dec 28, 2013

Puzzled newbie here. I am running Docker inside of a Vagrant vm

Yesterday I was able to docker build . an image successfully, today trying a different image (both are FROM ubuntu:12.04 ) I am getting the «Temporary failure resolving ‘archive.ubuntu.com'» errors when the image tries to do apt-get stuff

I tried adding RUN echo «nameserver 8.8.8.8» >> /etc/resolv.conf to the Dockerfile but it errors («returned a non-zero code: 2»)

My /etc/resolv.conf in the vm looks like:

What am I supposed to do to make it work?

anentropic commented Dec 28, 2013

and. rebooting the vagrant vm fixed it

tamsky commented Jan 6, 2014

This is fixed in master. The docker daemon will detect that the host’s resolv.conf points to localhost, and fallback to a public default (8.8.8.8). This can then be overridden by the admin with ‘docker -d -dns’.

The ‘fix’ above excludes all production environments which deliberately run a caching nameserver on 127.0.0.1.

Our resolv.conf reads:

Is there a way to support environments which run a per-host caching-only dns recursive resolver?

BadgerOps commented Jan 15, 2014

I’m experiencing the exact same issue as tamsky —
I’m running 12.04.3 with kernel 3.8.0-35 and docker version 0.7.5 (existed in docker version 0.7.3 as well)

My company does a caching nameserver at 127.0.0.1 and my resolv.conf reads the same as tamsky’s.

I’ve appended ‘nameserver 8.8.8.8’ to my resolv.conf, but it appears docker never checks that far down?

In my honest opinion, this kills the portability factor of docker, as currently the daemon has to be restarted using a specified dns server. It looks like there have been several issue threads discussing this problem — what is the possibility/probability of a docker.conf where we can specify instance variables like dns?

tianon commented Jan 16, 2014

@Badger32d just as a point of interest, if all you need to «fix» this in your environment is a configuration file to specify -dns for the daemon, then «/etc/default/docker» is just such a thing (provided you use Upstart or SysV, which if you’re on 12.04 you do).

Just put something like this inside:

Then service docker restart or restarting your system completely will make sure Docker starts up with -dns as specified.

So it’s not exactly a solution to all the issues, but it’s certainly a reasonable way to specify the workaround in a simple and persistent way.

BadgerOps commented Jan 16, 2014

Tianon: I didn’t realize that was a possibility, thanks! That should solve it.

tamsky commented Jan 19, 2014

@Badger32d ‘s solution will not work on our network.
Our machines do not have direct access to the full internet, but they can reach a nearby recursive dns resolver.

I’m not sure what our workaround will be but it might involve having named listen on the docker0 interface, and setting the DOCKER_OPTS=»-dns 172.17.42.1″

crosbymichael commented Jan 20, 2014

@tamsky yes, you need to have your resolver bind on the docker0 bridge. Then pass the -dns flag to the docker daemon with the bridge ip. This ill make all container’s created use the bridge as the resolver.

tamsky commented Feb 2, 2014

It sure would be nice if these issues could be addressed:

1. In order for our localhost bind nameserver to actually bind()/listen() on the bridge interface, dockerd must have already started, and successfully created and configure(number) the bridge interface. This ordering requirement is sub-optimal.
2. There is no deterministic address that we can configure bind to listen() on, as it’s dynamic.
   • https://github.com/WarheadsSE/docker/blob/master/network.go#L100

Can we, as part of our system networking startup configuration, create and configure the bridge interface before dockerd starts?

If so, that would resolve both issues.

tianon commented Feb 3, 2014

@tamsky Absolutely! If you create/configure the docker0 interface before starting Docker, Docker will pick up the network settings from the interface instead of making them up (for example, using the IP/mask on the bridge instead of trying to find a suitable one).

You can also use -b to change the bridge that Docker attaches to, or —bip to just change the bridge’s IP/mask:

seshendra commented Feb 25, 2014

I have installed docker on 1) Ubuntu 12.04 and 2) CentOS 6.4. I did this on my work laptop connected to our corporate VPN, as I was trying to demonstrate docker for a potential production use.

However, I cannot connect to internet (if I had to run a mvn install ) or yum -y update inside the image.

Do you guys think it is related to the DNS issue?

dodev commented Feb 25, 2014

@seshendra I think I’m facing the same problem:

• I’m running ubuntu quantal
• connected to the corporate VPN the containers have network access, can resolve hostnames;
• on wlan0 the containers still have network access, but can’t resolve names.

And yes, I think it’s DNS related 🙂

denibertovic commented Jun 3, 2016

I understand that it’s desirable to rewrite /etc/resolv.conf if it only has 127.0.0.1 listed because the containers are isolated in their own network. But if I’m using net=»host» isn’t this behavior a bug?

Specifically I think I’m seeing a race because one container get’s started with the correct /etc/resolv.conf from the host and the other one (also net:»host») get’s a rewritten /etc/resolv.conf with public dns’s listed.

justincormack commented Jun 3, 2016

There is an outstanding issue to change this behaviour in the case of net=host see #22853

denibertovic commented Jun 3, 2016

skirdey commented Jun 10, 2016

This helped in my case:

config.vm.provision :shell, :inline => «echo ‘nameserver 8.8.8.8’ | sudo tee /etc/resolv.conf &> /dev/null», :privileged => true

flypenguin commented Jul 7, 2016

I have just hit this issue. Hard.
I really think that in that case (DNS set to 127.0.0.1) docker should just proxy those requests to the outer «localhost». It’s what I expected. Docker does a lot of things, why not this?! Everything else just sucks, sorry.

cpuguy83 commented Jul 7, 2016

@flypenguin please upgrade to 1.11 and try again. Thanks!

flypenguin commented Jul 7, 2016

Hm. Tested on 1.9.1 and 1.11.2, didnt work in both .

sanimej commented Jul 7, 2016

@flypenguin Yes, forwarding the queries to the host’s 127.0.0.1 is not supported now. You can use the —dns option on container run. Will that work for you ?

flypenguin commented Jul 11, 2016 •

[Update]

Okay, solved it it seems. Ubuntu 16.04 installed — for whatever reason — the lxc packages, which contain a local dnsmasq set up which somehow prevents DNS to be used in the containers. Seems I have to read up on what that is, but uninstalling lxc* packages did the trick.

[Original post]

It might — but I think I hit another problem. I opened all DNS servers on the «public» network interfaces now, and on some machines it «just works», on others it doesn’t. It actually seems to be distribution dependent.

• Ubuntu 15.10:
  • works.
• Ubuntu 16.04:
  • freshly booted, docker 1.11.2, Ubuntu 16.04
  • in container: host IP is set as nameserver in /etc/resolv.conf
  • in container: can ping the host IP from within container
  • in container: cannot resolv DNS queries using host IP as DNS
  • host DNS working perfectly fine

Both hosts should have exactly the same configuration (I use the same puppet rules for both), and I don’t know of any difference except some installed software or IP address out of my head.

denibertovic commented Sep 12, 2016 •

This might be related with the issue I was seeing and posted above but was not really given much attention. Namely, I think I was seeing a race condition because the issue was not happening on different OS version but on the same OS in different containers. Some got the correct /etc/resolv.conf some did not. I have not checked with the latest release.

I did some quick testing on 1.11.2: docker run -it —net=»host» debian:jessie /bin/bash -c «cat /etc/resolv.conf» .

I ran the command a couple of times and I can’t seem to reproduce like I was able before. So at least the perceived race is gone.

rage-shadowman commented Sep 13, 2016

Will there be a real fix to this? Such that if /etc/resolve.conf points to localhost, the docker daemon will forward dns requests to localhost? (as opposed to forwarding them to google’s dns servers)

denibertovic commented Sep 14, 2016

@rage-shadowman Are you talking with «—net=host»? Cause that appears to to be working with 1.11.2. If you’re not talking about «—net=host». I don’t see how that could work.

rage-shadowman commented Sep 14, 2016 •

No, I mean using the default bridge network. You are already filtering out localhost from /etc/resolv.conf. Why not simply replace it with the ip address of the host? My current hack is to do this in my .bashrc:

However, this is an ugly hack with its own issues. It currently works for me in my dev environment but a real solution which points dns requests to the host machine would be much preferable.

PS — I will admit to having very little knowledge of the inner workings of docker. However, to my uneducated mind this seems like something that should be workable.

Источник