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

[cytopia]

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]

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.

[maxim-lobanov]

Probably, similar to #668

[cytopia]

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]

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

[cytopia]

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

[cytopia]

Seems to be the same issue on Ubuntu 16: No IPv6 support available anymore

• Ubuntu 16 (fails): https://github.com/cytopia/pwncat/runs/701818515?check_suite_focus=true#step:5:22
• MacOS (success): https://github.com/cytopia/pwncat/runs/701818551?check_suite_focus=true#step:5:22
• Windows (success): https://github.com/cytopia/pwncat/runs/701828359?check_suite_focus=true#step:5:28

[al-cheb]

@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]

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

[al-cheb]

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]

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

[agrobbin]

@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]

Hello, @agrobbin
Could you please validate with step?

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

[agrobbin]

@al-cheb that line did the trick!

[agrobbin]

@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]

@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]

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

[al-cheb]

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

[agrobbin]

@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.

[yidongnan]

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]

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

[yidongnan]

@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]

@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]

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):

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]

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.

[al-cheb]

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

[yidongnan]

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