oc: oc should not use /etc/resolv.conf on macOS

On OCP 4.3 the oc login command generated from the dashboard “Copy Login Command”

oc login --token=asdfghjk... --server=https://api.xxx.com:6443

fails with:

error: dial tcp: lookup api.xxx.com on 192.168.0.1:53: no such host - verify you have provided the correct host and port and that the server is currently running.

When I substitute the public ip of my cluster for the host name it works.

oc login --token=asdfghjk... --server=https://1.2.3.4:6443

I can successfully ping api.xxx.com, the curl command generated by “Copy Login Command” resolves the hostname, and the curl url also works in chrome. I’ve tried adding the host and public ip to my /etc/hosts file but it still fails.

The problem appears to be that oc is using /etc/resolv.conf for hostname resolution. When I edit /etc/resolv.conf and change:

nameserver 192.168.0.1 to nameserver 8.8.8.8 I get:

error: dial tcp: lookup api.xxx.com on 8.8.8.8:53: no such host...

resolve.conf contains the following deprecation notice:

$ cat /etc/resolv.conf
#
# macOS Notice
#
# This file is not consulted for DNS hostname resolution, address
# resolution, or the DNS query routing mechanism used by most
# processes on this system.
#
# To view the DNS configuration used by this system, use:
#   scutil --dns

Relevant versions:

macOS 10.15.3

$ oc version
Client Version: openshift-clients-4.3.0-201910250623-88-g6a937dfe
Server Version: 4.3.0
Kubernetes Version: v1.16.2
$

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 21
Comments: 36 (9 by maintainers)

Most upvoted comments

I have also hit the same error. And after adding entries to resolve the URL in /etc/hosts file on Mac, it helped login.

Considering these are the URLs of your openshift cluster… API URL --> api.<clustername>.xxx.com OAUTH URL --> oauth-openshift.apps.<clustername>.xxx.com
Note down the IP addresses with ping command… ping <API URL> # note down the IP ping <OAUTH URL> # note down the IP
Edit the /etc/hosts file… sudo vi /etc/hosts

# Added to resolve Redhat OCP cluster API endpoint
9.xx.yy.zz api.<clustername>.xxx.com
9.xx.yy.zz oauth-openshift.apps.<clustername>.xxx.com

oc login https://<API URL>:6443 -u <user> -p <password> --insecure-skip-tls-verify=false

The server uses a certificate signed by an unknown authority.
You can bypass the certificate check, but any data you send to the server could be intercepted by others.
Use insecure connections? (y/n): y

Login successful.

venkataramanam on Jun 24, 2021

I encountered the same issue… oc version: 4.6.0

Mac OS: Big Sur Version 11.2.3

fmerici on Mar 15, 2021

Same behavior with version 4.5.0-202005291417-9933eb9 and macOS 10.15.6. I do not encounter this problem when using the Homebrew version.

jensmueller-com on Aug 25, 2020

Works now for me in 4.14 😃

paulben on Nov 8, 2023

@Jamstah: Closing this issue.

In response to this:

go.mod now lists 1.20 so I expect this can be closed. Not sure I can do it though.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

openshift-ci[bot] on Jul 28, 2023

Had same problem today. Noticed that ping worked to resolve the host BUT nslookup and dig both could NOT resolve the host, and the nameserver that dig and nslookup used was my default gateway address / port 53.

Fix: Go to System Preferences > Network > Advanced > DNS tab. Add in name servers that resolve the hostname, which in my case are intranet nameservers (i’m VPN’ed). I also added in several public nameservers just in case.

Now Dig / nslookup resolve the host, and my oc login works

Conclusion? I’m not sure this is an oc issue as much as it is a VPN configuration problem. Seems VPN did not add in intranet DNS properly. However I cannot explain why, before i added the nameservers, ping worked but dig/nslookup did not.

Thank you @veronicaboychuk for the suggestion 😃

tseelbach on May 6, 2022

Affecting 4.8.2., too.

karstengresch on Aug 3, 2021