Bootstrap FreeKB - OpenShift - Resolve "verify you have provided the correct host and port and that the server is currently running"
OpenShift - Resolve "verify you have provided the correct host and port and that the server is currently running"

Updated:   |  OpenShift articles

Let's say you are trying to log into OpenShift using the oc login command.

oc login --username john.doe api.openshift.example.com:6443

 

And something like this is being returned.

i/o timeout - verify you have provided the correct host and port and that the server is currently running

 

Notice in this example that John Doe is attempting to log into the OpenShift system with URL api.openshift.example.com:6443. This is the URL of the OpenShift API server. If you are by chance able to log into OpenShift with some other user account, such as cluster-admin or kubeadmin, you could then use the oc get apiserver command to verify that api.openshift.example.com is the correct URL.

~]$ oc get apiserver cluster --output jsonpath={.spec.servingCerts.namedCertificates[*].names[*]}
api.openshift.example.com

 

nslookup can be used to determine if DNS is able to resolve the OpenShift API Server URL to the IP addresses of the OpenShift  API Server.

]$ nslookup api.openshift.example.com
Server:         10.4.14.7
Address:        10.4.14.7#53

Non-authoritative answer:
Name:   api.openshift.example.com
Address: 10.17.100.10
Name:   api.openshift.example.com
Address: 10.17.100.11
Name:   api.openshift.example.com
Address: 10.17.100.12

 

openssl s_client -connect can be used to determine if you are able to connect to the OpenShfit API Server on port 6443.

]$ openssl s_client -connect api.openshift.example.com:6443
CONNECTED(00000003)

 

Let's say openssl s_client -connect hangs indefinetly or returns something. In this scenario, I would first suspect that there is some sort of firewall refusing the connection to the OpenShift API Server on port 6443.

]$ openssl s_client -connect api.openshift.example.com:6443
socket: Bad file descriptor
connect:errno=9

 

Your users /home/your_username/.kube/config file may contain something like this. While unlikely this is going to resolve the issue, you can try to delete the record from your /home/your_username/.kube/config file and then try to log in again to see if this resolves the issue.

~]$ cat /home/john.doe/.kube/config
users:
- name: john.doe
  user: {}

 




Did you find this article helpful?

If so, consider buying me a coffee over at Buy Me A Coffee



Comments


Add a Comment


Please enter d82e6a in the box below so that we can be sure you are a human.