What does the curl call without -k show?

Wondering if your system CA bundle is unhappy with the proxy cert. Did you
have to add exceptions for your browsers?



On Feb 28, 2016, at 3:38 PM, Mohamed Lrhazi <[email protected]>
wrote:

Very weird... looks like my own exact curl is behaving differently?

On Sun, Feb 28, 2016 at 3:37 PM, Mohamed Lrhazi <
[email protected]> wrote:

> ➜  OpenShift oc login https://mgmt.os.gu.edu -u ml623  --loglevel=18
> I0228 15:35:03.590599   30156 loader.go:241] Config loaded from file
> /Users/mohamed/.kube/config
> I0228 15:35:03.590934   30156 loader.go:241] Config loaded from file
> /Users/mohamed/.kube/config
> I0228 15:35:03.591206   30156 loader.go:241] Config loaded from file
> /Users/mohamed/.kube/config
> I0228 15:35:03.591431   30156 loader.go:241] Config loaded from file
> /Users/mohamed/.kube/config
> I0228 15:35:03.591598   30156 round_trippers.go:267] curl -k -v -XGET  -H
> "User-Agent: oc/v1.1.2 (darwin/amd64) openshift/2711160"
> https://mgmt.os.gu.edu:443/
> I0228 15:35:03.829473   30156 round_trippers.go:286] GET
> https://mgmt.os.gu.edu:443/  in 237 milliseconds
> I0228 15:35:03.829507   30156 round_trippers.go:292] Response Headers:
> I0228 15:35:03.829640   30156 helpers.go:159] Connection error: Get
> https://mgmt.os.gu.edu:443/: read tcp 10.212.140.29:52838->
> 141.161.99.87:443: read: connection reset by peer
> F0228 15:35:03.829668   30156 helpers.go:99] Unable to connect to the
> server: read tcp 10.212.140.29:52838->141.161.99.87:443: read: connection
> reset by peer
> ➜  OpenShift curl -k -v -XGET  -H "User-Agent: oc/v1.1.2 (darwin/amd64)
> openshift/2711160" https://mgmt.os.gu.edu:443/
> *   Trying 141.161.99.87...
> * Connected to mgmt.os.gu.edu (141.161.99.87) port 443 (#0)
> * TLS 1.2 connection using TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
> * Server certificate: mgmt.os.gu.edu
> * Server certificate: Let's Encrypt Authority X1
> * Server certificate: DST Root CA X3
> > GET / HTTP/1.1
> > Host: mgmt.os.gu.edu
> > Accept: */*
> > User-Agent: oc/v1.1.2 (darwin/amd64) openshift/2711160
> >
> < HTTP/1.1 200 OK
> < Content-Type: application/json
> < Date: Sun, 28 Feb 2016 20:36:58 GMT
> < Content-Length: 204
> <
> {
>   "paths": [
>     "/api",
>     "/api/v1",
>     "/controllers",
>     "/healthz",
>     "/healthz/ping",
>     "/healthz/ready",
>     "/logs/",
>     "/metrics",
>     "/oapi",
>     "/oapi/v1",
>     "/swaggerapi/"
>   ]
> * Connection #0 to host mgmt.os.gu.edu left intact
> }%
>
>                                                      ➜  OpenShift
>
>
> On Sun, Feb 28, 2016 at 3:33 PM, Jordan Liggitt <[email protected]>
> wrote:
>
>> What about a curl with the :443 port included?
>>
>> On Feb 28, 2016, at 3:28 PM, Mohamed Lrhazi <
>> [email protected]> wrote:
>>
>> a GET curl request also works, instead of HEAD:
>>
>> ➜  curl  https://mgmt.os.gu.edu:443/ -i
>> HTTP/1.1 200 OK
>> Content-Type: application/json
>> Date: Sun, 28 Feb 2016 20:27:13 GMT
>> Content-Length: 204
>>
>> {
>>   "paths": [
>>     "/api",
>>     "/api/v1",
>>     "/controllers",
>>     "/healthz",
>>     "/healthz/ping",
>>     "/healthz/ready",
>>     "/logs/",
>>     "/metrics",
>>     "/oapi",
>>     "/oapi/v1",
>>     "/swaggerapi/"
>>   ]
>> }%
>>
>>
>>
>> On Sun, Feb 28, 2016 at 3:25 PM, Mohamed Lrhazi <
>> [email protected]> wrote:
>>
>>> Thanks Jordan.. Here it is:
>>>
>>> ➜  oc login https://mgmt.os.gu.edu -u ml623  --loglevel=8
>>> I0228 15:23:13.811505   30087 loader.go:241] Config loaded from file
>>> /Users/mohamed/.kube/config
>>> I0228 15:23:13.811805   30087 loader.go:241] Config loaded from file
>>> /Users/mohamed/.kube/config
>>> I0228 15:23:13.812061   30087 loader.go:241] Config loaded from file
>>> /Users/mohamed/.kube/config
>>> I0228 15:23:13.812267   30087 loader.go:241] Config loaded from file
>>> /Users/mohamed/.kube/config
>>> I0228 15:23:13.812414   30087 round_trippers.go:264] GET
>>> https://mgmt.os.gu.edu:443/
>>> I0228 15:23:13.812419   30087 round_trippers.go:271] Request Headers:
>>> I0228 15:23:13.812422   30087 round_trippers.go:274]     User-Agent:
>>> oc/v1.1.2 (darwin/amd64) openshift/2711160
>>> I0228 15:23:13.959537   30087 round_trippers.go:289] Response Status:
>>>  in 147 milliseconds
>>> I0228 15:23:13.961454   30087 round_trippers.go:292] Response Headers:
>>> I0228 15:23:13.961992   30087 helpers.go:159] Connection error: Get
>>> https://mgmt.os.gu.edu:443/: read tcp 10.212.140.29:52561->
>>> 141.161.99.87:443: read: connection reset by peer
>>> F0228 15:23:13.962029   30087 helpers.go:99] Unable to connect to the
>>> server: read tcp 10.212.140.29:52561->141.161.99.87:443: read:
>>> connection reset by peer
>>> ➜
>>> ➜
>>> ➜  curl -I https://mgmt.os.gu.edu:443/
>>> HTTP/1.1 200 OK
>>> Content-Type: application/json
>>> Date: Sun, 28 Feb 2016 20:23:43 GMT
>>> Content-Length: 204
>>>
>>> ➜
>>>
>>>
>>> On Sun, Feb 28, 2016 at 3:06 PM, Jordan Liggitt <[email protected]>
>>> wrote:
>>>
>>>> What do you see with --loglevel=8?
>>>>
>>>> On Feb 28, 2016, at 3:01 PM, Mohamed Lrhazi <
>>>> [email protected]> wrote:
>>>>
>>>> Hello,
>>>>
>>>> My  oc on OS X, works if I point directly to the real IP/port of the
>>>> origin server (port 8443)... but if I tried using a VIP which terminates
>>>> SSL, the re-encrypts to the server on 8443.. I get this error:
>>>>
>>>>
>>>> ➜  oc login https://mgmt.os.gu.edu -u ml623
>>>> Unable to connect to the server: read tcp 10.212.140.29:51773->
>>>> 141.161.99.87:443: read: connection reset by peer
>>>> ➜
>>>>
>>>>
>>>> What's odd is that with Chrome and Firefox, that URL works fine!
>>>>
>>>> How do I debug this further?
>>>>
>>>> Thanks a lot,
>>>> Mohamed.
>>>>
>>>> _______________________________________________
>>>> users mailing list
>>>> [email protected]
>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>>
>>>>
>>>
>>
>
_______________________________________________
users mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Reply via email to