Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot resolve localhost to an IPv6 address on ubuntu-latest (all Python versions affected) #929

Closed
1 of 5 tasks
cytopia opened this issue May 22, 2020 · 26 comments
Closed
1 of 5 tasks
Assignees
Labels
Area: Image administration awaiting-deployment Code complete; awaiting deployment and/or deployment in progress OS: Ubuntu

Comments

@cytopia
Copy link

cytopia commented May 22, 2020

Describe the bug
As of today I am getting the following error resolving localhost to an IP address on Ubuntu latest:

[Errno -5] No address associated with hostname

The resolving process is done via Python:

socket.getaddrinfo(...)

It affects all Python versions: 2.6, 3.5, 3.6, 3.7, 3.8 pypy2 and pypy3

This has not happened a few days ago and it also does not happen on MacOS or Windows

Area for Triage:
https://github.com/cytopia/pwncat/pull/77/checks?check_run_id=700746839#step:5:2368

Question, Bug, or Feature?:
Bug

Virtual environments affected

  • macOS 10.15
  • Ubuntu 16.04 LTS
  • Ubuntu 18.04 LTS
  • Windows Server 2016 R2
  • Windows Server 2019

Expected behavior
localhost is resolved to ::1 (IPv6)

Actual behavior
The following error is thrown:

[Errno -5] No address associated with hostname

https://github.com/cytopia/pwncat/pull/77/checks?check_run_id=700886122#step:5:21

Reproducible via the following Python snippet on ubuntu-latest on all available Python versions.

import socket
socket.getaddrinfo("localhost", None)

https://github.com/cytopia/pwncat/pull/77/checks?check_run_id=700886122#step:5:21

@cytopia
Copy link
Author

cytopia commented May 22, 2020

I've investigated this further and it seems like IPv6 support is simply gone: https://github.com/cytopia/pwncat/pull/77/checks?check_run_id=700886122#step:5:21

It seems to be working for IPv4, but not for IPv6 anymore.

@cytopia cytopia changed the title Cannot resolve localhost to an IP address on ubuntu-latest (all Python versions affected) Cannot resolve localhost to an IPv6 address on ubuntu-latest (all Python versions affected) May 22, 2020
@maxim-lobanov
Copy link
Contributor

Probably, similar to #668

@cytopia
Copy link
Author

cytopia commented May 23, 2020

Probably, similar to #668

I don't think so. As I wrote above, the problem started as of today (yesterday). It all worked fine before and now my builds started failing due to this.

@miketimofeev
Copy link
Contributor

@cytopia does the same happen on Ubuntu 16? I wonder if it's related to this PR #881

@cytopia
Copy link
Author

cytopia commented May 23, 2020

Give me a few minutes, will add pipelines for these to try it out

@cytopia
Copy link
Author

cytopia commented May 23, 2020

@al-cheb
Copy link
Contributor

al-cheb commented May 23, 2020

@cytopia

Could you please test with step?

sudo bash -c "cat > /etc/hosts" << EOL
127.0.0.1       localhost
::1     localhost ip6-localhost ip6-loopback
EOL

@cytopia
Copy link
Author

cytopia commented May 23, 2020

@al-cheb is there something where I can tell it for a step to only do this on Linux?

@al-cheb
Copy link
Contributor

al-cheb commented May 23, 2020

if [ `uname` = "Linux" ]; then
sudo bash -c "cat > /etc/hosts" << EOL
127.0.0.1       localhost
::1     localhost ip6-localhost ip6-loopback
EOL
fi

@cytopia
Copy link
Author

cytopia commented May 23, 2020

Looks good so far. I can resolve it to IPv6 again. Will however also wait for the whole pipeline and report back here

@agrobbin
Copy link

@al-cheb we've started running into a very similar issue, specifically with Percy.io's image downloading functionality:

Error: getaddrinfo ENOTFOUND [foo.bar].localhost

We use .localhost as a TLD, which up until 5/22 worked just fine, but starting on 5/22 (and I believe alongside the 20200518.1 virtual env release), requests for our assets on that domain are no longer working.

I tried including your suggested change to /etc/hosts, and unfortunately still no luck. Any help here would be greatly appreciated!

@al-cheb
Copy link
Contributor

al-cheb commented May 26, 2020

Hello, @agrobbin
Could you please validate with step?

- name: revert
  run: | 
        sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

@agrobbin
Copy link

@al-cheb that line did the trick!

@agrobbin
Copy link

@al-cheb is this something that will be resolved in a future virtual environment release, or should we anticipate having to include this in our Actions YAML file going forward?

@al-cheb
Copy link
Contributor

al-cheb commented May 26, 2020

@agrobbin, Sorry for the inconvenience. We are planning to revert the #881 PR that is the root cause of this issue. Not until we roll-out a new image with a fix you should use the temporary workaround. I will provide feedback to you when we can delete the workaround. ETA: ~ 2 weeks.

@agrobbin
Copy link

Sounds good, @al-cheb thanks again for all of your help! In the meantime, I'll keep an eye on these issues.

@al-cheb al-cheb added the awaiting-deployment Code complete; awaiting deployment and/or deployment in progress label May 27, 2020
@al-cheb
Copy link
Contributor

al-cheb commented Jun 10, 2020

Hello,@cytopia, @agrobbin
We have reverted the PR with the issue. Could you please validate your pipelines if the problem is still reproducing?

@agrobbin
Copy link

@al-cheb I just confirmed that removing our patch for this issue no longer causes resolution issues. Looks like things are fixed! Thanks so much for your help.

@al-cheb al-cheb closed this as completed Jun 10, 2020
@yidongnan
Copy link

image

https://github.com/yidongnan/grpc-spring-boot-starter/runs/760320005?check_suite_focus=true#step:3:7

I still have this problem after deleting this patch, is there any cache here?

@al-cheb
Copy link
Contributor

al-cheb commented Jun 11, 2020

@yidongnan, Hello
Could you please try to test #929 (comment) ?

@yidongnan
Copy link

@al-cheb I just confirmed that removing our patch for this issue no longer causes resolution issues. Looks like things are fixed! Thanks so much for your help.

@al-cheb Using this patch will work, I read the comment saying that the patch removal is work. I thought the problem was fixed, but when I removed the patch, it found that it did not work.

This is my modification
https://github.com/yidongnan/grpc-spring-boot-starter/pull/367

@al-cheb
Copy link
Contributor

al-cheb commented Jun 11, 2020

@al-cheb I just confirmed that removing our patch for this issue no longer causes resolution issues. Looks like things are fixed! Thanks so much for your help.

@al-cheb Using this patch will work, I read the comment saying that the patch removal is work. I thought the problem was fixed, but when I removed the patch, it found that it did not work.

This is my modification
yidongnan/grpc-spring-boot-starter#367

I think we have got several issues one with resolving IPv4 localhost(revert PR fixed the issue) and the second one with IPv6.

@al-cheb al-cheb reopened this Jun 11, 2020
@al-cheb
Copy link
Contributor

al-cheb commented Jun 23, 2020

Hello, @yidongnan
I can reproduce this behavior with resolving IPv6 localhost name on clean Ubuntu VMs with OS version 18.04+(Azure VM, Hyper-V). The default /etc/hosts file on Ubuntu Server 14.04+ is (e.g. for other linux distros - https://gist.github.com/ghoneycutt/e531984406b4b86ace687ea8958a6dc3#file-hosts-md):

image

I have created a simple test:

import java.net.InetAddress;

public class Test {
    public static void main(String[] args) throws Exception {
        InetAddress[] inetAddresses = InetAddress.getAllByName(args[0]);
        for(InetAddress inet : inetAddresses){
            System.out.println(inet);
        }
    }
}

Output:

ubuntu:~$ java -classpath . Test localhost
localhost/127.0.0.1
ubuntu:~$ java -classpath . Test ip6-localhost
ip6-localhost/0:0:0:0:0:0:0:1

Update /etc/hosts/ file and add the alias localhost for ::1:

ubuntu:~$ sed -i 's/::1 ip6-localhost ip6-loopback/::1     localhost ip6-localhost ip6-loopback/g' /etc/hosts
ubuntu:~$ java -classpath . Test localhost
localhost/127.0.0.1
localhost/0:0:0:0:0:0:0:1

We are not planning to change/update default name resolution due to unexpected behaviors for other customers.

Workaround:

  1. Add the alias localhost for ::1 manually to the pipeline - Cannot resolve localhost to an IPv6 address on ubuntu-latest (all Python versions affected) #929 (comment)
  2. Change localhost name to ip6-localhost or ::1 in your test
  3. Use only 127.0.0.1 or ::1

@yidongnan
Copy link

We are not planning to change/update default name resolution due to unexpected behaviors for other customers.

@al-cheb Thanks for your reply, I see that ubuntu 18.04 and 14.04 have added ::1 localhost by default, so I think it’s more appropriate to be consistent with the ubuntu official. I think that only by being consistent will no unexpected behavior happen.

image
image

@al-cheb
Copy link
Contributor

al-cheb commented Jul 1, 2020

Hello, @yidongnan
Fix with alias for ::1 localhost has been deployed. Could you please check from your side?

@yidongnan
Copy link

@al-cheb Looks like things are fixed! Thanks so much for your help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Image administration awaiting-deployment Code complete; awaiting deployment and/or deployment in progress OS: Ubuntu
Projects
None yet
Development

No branches or pull requests

6 participants