Bug 1250266 - Peer's certificate issuer has been marked as not trusted by the user.
Peer's certificate issuer has been marked as not trusted by the user.
Status: CLOSED NOTABUG
Product: OpenShift Container Platform
Classification: Red Hat
Component: Build (Show other bugs)
3.0.0
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Scott Dodson
Gaoyun Pei
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-04 19:03 EDT by Chmouel Boudjnah
Modified: 2015-08-06 14:25 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-06 14:25:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chmouel Boudjnah 2015-08-04 19:03:47 EDT
Description of problem:

Since 3.0.1.0 we have been getting those error when running a S2I the sti-builder cannot simply connect to https:// url github here but really any https:// in general


Version-Release number of selected component (if applicable):

3.0.0.1

How reproducible:

I am not so sure it shows on a fresh install on amazon for me and on an upgrade as well

Steps to Reproduce:
1. oc start-build a sti image with https:// git url


Actual results:

I0804 16:42:05.153011       1 docker.go:199] Image registry.access.redhat.com/openshift3/python-33-rhel7:latest available locally
I0804 16:42:05.162270       1 sti.go:99] Starting S2I build from foo/simple-test-314 BuildConfig ...
I0804 16:42:05.162903       1 sti.go:113] Building 172.30.160.37:5000/foo/simple-test:latest
I0804 16:42:05.238666       1 clone.go:27] Cloning into /tmp/sti463645757/upload/src
E0804 16:42:06.033900       1 git.go:127] fatal: unable to access 'https://github.com/chmouel/simple-dockerfile/': Peer's certificate issuer has been marked as not trusted by the user.


Expected results:

Build

Additional info:

I have tried to git clone directly on the sti-builder image and it works, I can't find a way to properly debug that
Comment 2 Johnny Liu 2015-08-05 02:49:23 EDT
I can not reproduce this issue on 3.0.1.0 installation.

$ oc new-app https://github.com/chmouel/simple-dockerfile.git -i openshift/python
$ oc start-build simple-dockerfile
simple-dockerfile-1
$ oc build-logs simple-dockerfile-1
<--snip-->
I0805 02:30:37.747892       1 docker.go:199] Image registry.access.redhat.com/openshift3/python-33-rhel7:latest available locally
I0805 02:30:37.781727       1 sti.go:99] Starting S2I build from jialiu/simple-dockerfile-1 BuildConfig ...
I0805 02:30:37.781778       1 sti.go:113] Building 172.30.164.136:5000/jialiu/simple-dockerfile:latest
I0805 02:30:37.789926       1 clone.go:27] Cloning into /tmp/sti049201203/upload/src
I0805 02:30:54.635299       1 docker.go:199] Image registry.access.redhat.com/openshift3/python-33-rhel7:latest available locally
I0805 02:30:54.635443       1 docker.go:305] Image contains io.openshift.s2i.scripts-url set to 'image:///usr/local/sti'
I0805 02:30:54.635479       1 download.go:57] Using image internal scripts from: image:///usr/local/sti/assemble
I0805 02:30:54.635914       1 download.go:57] Using image internal scripts from: image:///usr/local/sti/run
I0805 02:30:54.642127       1 docker.go:199] Image registry.access.redhat.com/openshift3/python-33-rhel7:latest available locally
I0805 02:30:54.642147       1 docker.go:305] Image contains io.openshift.s2i.scripts-url set to 'image:///usr/local/sti'
I0805 02:30:54.642178       1 download.go:57] Using image internal scripts from: image:///usr/local/sti/save-artifacts
I0805 02:30:54.642201       1 sti.go:186] Using assemble from image:///usr/local/sti
I0805 02:30:54.642216       1 sti.go:186] Using run from image:///usr/local/sti
I0805 02:30:54.642223       1 sti.go:186] Using save-artifacts from image:///usr/local/sti
I0805 02:30:54.642234       1 sti.go:121] Clean build will be performed
I0805 02:30:54.642240       1 sti.go:124] Performing source build from https://github.com/chmouel/simple-dockerfile.git
I0805 02:30:54.642246       1 sti.go:134] Building 172.30.164.136:5000/jialiu/simple-dockerfile:latest
<--snip-->
Comment 3 Scott Dodson 2015-08-05 10:00:53 EDT
I doubt it's the cause, but can you verify that the date is set properly on all hosts?
Comment 4 Cesar Wong 2015-08-05 13:20:28 EDT
Are you using a proxy in your build config?
Comment 5 Chmouel Boudjnah 2015-08-06 04:11:37 EDT
No proxy straight to the internet on AWS, as for the date they are all properly syncronize :

[root@master ~]# date;for i in node1 node2;do ssh $i date;done
Wed Aug  5 12:06:56 EDT 2015
Wed Aug  5 12:06:56 EDT 2015
Wed Aug  5 12:06:57 EDT 2015
Comment 6 Jordan Liggitt 2015-08-06 10:38:02 EDT
what do you see if you run the following on the nodes:

curl -s -vvv https://github.com > /dev/null

and this within a container on the nodes:

docker run openshift/ruby-22-centos7 curl -s -vvv https://github.com > /dev/null
Comment 7 Jordan Liggitt 2015-08-06 10:40:48 EDT
then try with this image:


docker run registry.access.redhat.com/openshift3/python-33-rhel7:latest curl -s -vvv https://github.com > /dev/null
Comment 9 Scott Dodson 2015-08-06 13:37:16 EDT
Still looking, but as far as I can tell there's no management of node /etc/resolv.conf in ansible. I suspect this is simply a misconfigured environment, you cannot have a search path that matches your wildcard dns.
Comment 10 Scott Dodson 2015-08-06 14:25:59 EDT
NetworkManager / dhcp is adding the host's domain name to the search
path. If your host's domain name matches the wildcard path then you'll
end up with these problems.

wildcard *.apps.example.com  and {master,nodeX}.example.com is safe
wildcard *.example.com and {master,nodeX}.example.com is not

The problem exhibits itself in 3.0.1 because kubernetes changed the
ndots value to 5 in order to allow for dns lookups on SRV lookup names
like _dns._udp.kube-dns.default.svc to be considered relative and
follow the search path.

For more info on that change please see
https://github.com/GoogleCloudPlatform/kubernetes/issues/10161 and
https://github.com/GoogleCloudPlatform/kubernetes/pull/10266

Note You need to log in before you can comment on or make changes to this bug.