On 11/09/2016 11:12 AM, Yaniv Kaul wrote:
On Sat, Oct 15, 2016 at 1:04 AM, Ravi Nori <rnori(a)redhat.com
<mailto:rnori@redhat.com>> wrote:
Also can you please try following command to directly obtain token
from SSO. Can replace engine with FQDN and IP to see if both work
curl -v -k -H "Accept: application/json"
'https://<engine>:443/ovirt-engine/sso/oauth/token?grant_type=password&username=admin@internal&password=123&scope=ovirt-app-api'
You should see output similar to the one below
{"access_token":"K0sBa0D3rLtmNTdMJ-Q4FzOgCtGGY2cSFSCwbLkG94te9nDdmEzHSizsFaOeNMdwOziIv3l2-Uqm8bxWkMpwMA","scope":"ovirt-app-api
ovirt-ext=token-info:authz-search
ovirt-ext=token-info:public-authz-search
ovirt-ext=token-info:validate","exp":-381399824,"token_type":"bearer"}
Sorry it took me so long to get back to it, but here it is:
{"access_token":"eA8w0DaapkKAQ8tfHakzA-R0l-mjD_CsTlAqBaH4iVVjXxQN33poXzt9UhPJLxMU8YOvVNX6LICcxL1EeAiAlw","scope":"ovirt-app-api
ovirt-ext=token-info:authz-search
ovirt-ext=token-info:public-authz-search
ovirt-ext=token-info:validate","exp":["java.lang.Long",1479290132000],"token_type":"bearer"}
That "java.lang.Long" there is an error, but not related to this
problem, as the SDK doesn't use the "exp" attribute. I guess it is a
side effect of the recent change to use "long" instead of "int",
looks
like the JSON library used in the engine doesn't like longs.
And here's the difference between the SDK and the manual curl
command in
ssl_access log:
192.168.201.1 - - [09/Nov/2016:04:52:19 -0500] "POST
/ovirt-engine/sso/oauth/token HTTP/1.1" 404 74
192.168.201.1 - - [09/Nov/2016:04:55:32 -0500] "GET
/ovirt-engine/sso/oauth/token?grant_type=password&username=admin@internal&password=123&scope=ovirt-app-api
HTTP/1.1" 200 295
That difference is by design. The SDK uses POST to avoid sending the
credentials (specially the password) as a query parameter, as that is
most probably logged and archived.
We discovered recently an issue with the Python SDK, due to a bug in the
"pycurl" library:
Debug mode raises UnicodeDecodeError: 'utf8' codec can't decode byte
0x8d in position 7: invalid start byte
https://bugzilla.redhat.com/1392878
It isn't exactly the same problem, but as the cause of that bug is a
pointer that is used after releasing, it can cause all kinds of strange
effects.
Please try the latest build of the SDK.
Thanks
Ravi
On Fri, Oct 14, 2016 at 4:00 PM, Yaniv Kaul <ykaul(a)redhat.com
<mailto:ykaul@redhat.com>> wrote:
On Oct 14, 2016 7:13 PM, "Ravi Nori" <rnori(a)redhat.com
<mailto:rnori@redhat.com>> wrote:
>
> SSO configuration looks good.
>
> Can you please share any additional httpd configuration in
/etc/httpd/conf.d. Anything to do with LocationMatch for ovirt-engine urls.
This is a standard ovirt-system-tests on Lago installation,
nothing out of the ordinary, but I'll check.
Y.
>
> On Fri, Oct 14, 2016 at 12:52 PM, Yaniv Kaul <ykaul(a)redhat.com
<mailto:ykaul@redhat.com>> wrote:
>>
>>
>>
>> On Fri, Oct 14, 2016 at 3:50 PM, Ravi Nori <rnori(a)redhat.com
<mailto:rnori@redhat.com>> wrote:
>>>
>>> Hi Yaniv,
>>>
>>> Can you check the output of
https:://<engine>/ovirt-engine/sso/status in your browser and
see if the SSO service is active.
>>>
>>> If SSO is deployed, you should see an output similar to the
one below. Also are you able to login to webadmin using the
browser?
>>
>>
>> I am able to login using the webui.
>>
>>>
>>>
>>> {"status_description":"SSO Webapp
Deployed","version":"0","status":"active"}
>>
>>
>> Indeed:
>> {"status_description":"SSO Webapp
Deployed","version":"0","status":"active"}
>>
>> (not sure what 'version 0' means?)
>>
>>>
>>>
>>> Please share the content of
/etc/ovirt-engine/engine.conf.d/11-setup-sso.conf
>>
>>
>> [root@lago-basic-suite-master-engine ~]# cat
/etc/ovirt-engine/engine.conf.d/11-setup-sso.conf
>> ENGINE_SSO_CLIENT_ID="ovirt-engine-core"
>> ENGINE_SSO_CLIENT_SECRET="bsOabtD7gE2McwLe80P109UV800XLx4O"
>>
ENGINE_SSO_AUTH_URL="https://${ENGINE_FQDN}:443/ovirt-engine/sso"
>>
ENGINE_SSO_SERVICE_URL="https://localhost:443/ovirt-engine/sso
<
https://localhost:443/ovirt-engine/sso>"
>> ENGINE_SSO_SERVICE_SSL_VERIFY_HOST=false
>> ENGINE_SSO_SERVICE_SSL_VERIFY_CHAIN=true
>> SSO_ALTERNATE_ENGINE_FQDNS=""
>> SSO_ENGINE_URL="https://${ENGINE_FQDN}:443/ovirt-engine/"
>>
>>
>> Thanks,
>> Y.
>>
>>
>>>
>>>
>>> Thanks
>>>
>>> Ravi
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Oct 14, 2016 at 7:57 AM, Juan Hernández
<jhernand(a)redhat.com <mailto:jhernand@redhat.com>> wrote:
>>>>
>>>> On 10/14/2016 01:45 PM, Yaniv Kaul wrote:
>>>> >
>>>> >
>>>> > On Thu, Oct 13, 2016 at 11:13 AM, Juan Hernández
<jhernand(a)redhat.com <mailto:jhernand@redhat.com>
>>>> > <mailto:jhernand@redhat.com
<mailto:jhernand@redhat.com>>> wrote:
>>>> >
>>>> > On 10/13/2016 12:04 AM, Yaniv Kaul wrote:
>>>> > > On Fri, Oct 7, 2016 at 10:44 PM, Yaniv Kaul
<ykaul(a)redhat.com <mailto:ykaul@redhat.com>
<mailto:ykaul@redhat.com <mailto:ykaul@redhat.com>>
>>>> > > <mailto:ykaul@redhat.com
<mailto:ykaul@redhat.com>
<mailto:ykaul@redhat.com <mailto:ykaul@redhat.com>>>> wrote:
>>>> > >
>>>> > > I'm trying on FC24, using
>>>> > >
>>>> >
python-ovirt-engine-sdk4-4.1.0-0.0.20161003git056315d.fc24.x86_64 to
>>>> > > add a DC, and failing - against master. The
client is unhappy:
>>>> > > File
>>>> > >
>>>> >
"/home/ykaul/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py",
>>>> > > line 98, in add_dc4
>>>> > >
version=sdk4.types.Version(major=DC_VER_MAJ,minor=DC_VER_MIN),
>>>> > > File
"/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py",
>>>> > > line 4347, in add
>>>> > > response = self._connection.send(request)
>>>> > > File
"/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py",
>>>> > > line 276, in send
>>>> > > return self.__send(request)
>>>> > > File
"/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py",
>>>> > > line 298, in __send
>>>> > > self._sso_token =
self._get_access_token()
>>>> > > File
"/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py",
>>>> > > line 460, in _get_access_token
>>>> > > sso_response =
self._get_sso_response(self._sso_url,
>>>> > post_data)
>>>> > > File
"/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py",
>>>> > > line 498, in _get_sso_response
>>>> > > return
json.loads(body_buf.getvalue().decode('utf-8'))
>>>> > > File
"/usr/lib64/python2.7/json/__init__.py",
line 339, in loads
>>>> > > return _default_decoder.decode(s)
>>>> > > File
"/usr/lib64/python2.7/json/decoder.py",
line 364, in decode
>>>> > > obj, end = self.raw_decode(s, idx=_w(s,
0).end())
>>>> > > File
"/usr/lib64/python2.7/json/decoder.py",
line 382, in
>>>> > raw_decode
>>>> > > raise ValueError("No JSON object
could be
decoded")
>>>> > > ValueError: No JSON object could be decoded
>>>> > >
>>>> > >
>>>> > > Surprisingly, I now can't find that RPM of
this
SDK in
>>>> > >
resources.ovirt.org
<
http://resources.ovirt.org> <
http://resources.ovirt.org>
>>>> > <
http://resources.ovirt.org> now.
>>>> > >
>>>> > > I've tried
>>>> > > with
>>>> >
http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/x86_64/pyth...
<
http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/x86_64/pyth...
>>>> >
<
http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/x86_64/pyth...
<
http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/x86_64/pyth...
>>>> > >
>>>> >
<
http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/x86_64/pyth...
<
http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/x86_64/pyth...
>>>> >
<
http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/x86_64/pyth...
<
http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/x86_64/pyth...
>>>> > >
>>>> > > - same result.
>>>> > >
>>>> > > Did not see anything obvious on server or
engine logs.
>>>> > > The code:
>>>> > > def add_dc4(api):
>>>> > > nt.assert_true(api != None)
>>>> > > dcs_service =
api.system_service().data_centers_service()
>>>> > > nt.assert_true(
>>>> > > dc = dcs_service.add(
>>>> > > sdk4.types.DataCenter(
>>>> > > name=DC_NAME4,
>>>> > > description='APIv4
DC',
>>>> > > local=False,
>>>> > >
>>>> > >
version=sdk4.types.Version(major=DC_VER_MAJ,minor=DC_VER_MIN),
>>>> > > ),
>>>> > > )
>>>> > > )
>>>> > >
>>>> > >
>>>> > > And the api object is from:
>>>> > > return sdk4.Connection(
>>>> > > url=url,
>>>> > >
username=constants.ENGINE_USER,
>>>> > >
>>>> >
password=str(self.metadata['ovirt-engine-password']),
>>>> > > insecure=True,
>>>> > > debug=True,
>>>> > > )
>>>> > >
>>>> > >
>>>> > > The clue is actually on the HTTPd logs:
>>>> > > 192.168.203.1 - - [12/Oct/2016:17:56:27 -0400]
"POST
>>>> > > /ovirt-engine/sso/oauth/token HTTP/1.1" 404
74
>>>> > >
>>>> > > And indeed, from the deubg log:
>>>> > > begin captured logging <<
--------------------\n
>>>> > > root: DEBUG: Trying 192.168.203.3...\n
>>>> > > root: DEBUG: Connected to 192.168.203.3
(192.168.203.3) port 443
>>>> > (#0)\n
>>>> > > root: DEBUG: Initializing NSS with certpath:
sql:/etc/pki/nssdb\n
>>>> > > root: DEBUG: skipping SSL peer certificate
verification\n
>>>> > > root: DEBUG: ALPN/NPN, server did not agree to a
protocol\n
>>>> > > root: DEBUG: SSL connection using
>>>> > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256\n
>>>> > > root: DEBUG: Server certificate:\n
>>>> > > root: DEBUG: subject: CN=engine,O=Test,C=US\n
>>>> > > root: DEBUG: start date: Oct 11 21:55:29 2016
GMT\n
>>>> > > root: DEBUG: expire date: Sep 16 21:55:29 2021
GMT\n
>>>> > > root: DEBUG: common name: engine\nroot: DEBUG:
issuer:
>>>> > > CN=engine.38998,O=Test,C=US\n
>>>> > > *root: DEBUG: POST /ovirt-engine/sso/oauth/token
HTTP/1.1\n*
>>>> > > *root: DEBUG: Host: 192.168.203.3\n*
>>>> > > *root: DEBUG: User-Agent: PythonSDK/4.1.0a0\n*
>>>> > > *root: DEBUG: Accept: application/json\n*
>>>> > > *root: DEBUG: Content-Length: 78\n*
>>>> > > *root: DEBUG: Content-Type:
application/x-www-form-urlencoded\nroot:
>>>> > > DEBUG:
>>>> > >
>>>> >
username=admin%40internal&scope=ovirt-app-api&password=123&grant_type=password\n*
>>>> > > *root: DEBUG: upload completely sent off: 78 out
of
78 bytes\n*
>>>> > > *root: DEBUG: HTTP/1.1 404 Not Found\n*
>>>> > > *root: DEBUG: Date: Wed, 12 Oct 2016 21:56:27
GMT\n*
>>>> > > *root: DEBUG: Server: Apache/2.4.6 (CentOS)
OpenSSL/1.0.1e-fips\n*
>>>> > > *root: DEBUG: Content-Length: 74\n*
>>>> > > *root: DEBUG: Content-Type: text/html;
charset=UTF-8\n*
>>>> > > *root: DEBUG: \n*
>>>> > > *root: DEBUG:
<html><head><title>Error</title></head><body>404 -
Not
>>>> > > Found</body></html>\n*
>>>> > > root: DEBUG: Connection #0 to host 192.168.203.3
left intact\n
>>>> > > --------------------- >> end captured
logging
>>>> > >
>>>> >
>>>> > That definitively looks like version 3 of the engine.
Either that or
>>>> > version 4 of the engine with web server configuration
modified so that
>>>> > the SSO doesn't work as expected.
>>>> >
>>>> > What do you get if you run this against that server?
>>>> >
>>>> >
>>>> > Attached.
>>>> > Y.
>>>> >
>>>>
>>>> OK, that is version 4.1 of the engine, so next question is
why the SSO
>>>> service is not responding. Do you see any message in
>>>> /var/log/ovirt-engine/server.log about "enginesso.war"
not
being
>>>> deployed? Did you do any modification to the
>>>> /etc/httpd/conf.d/z-ovirt-engine.conf file?
>>>>
>>>> Ravi, Martin, any idea of why the SSO service may not be
working?
>>>>
>>>> >
>>>> >
>>>> > curl \
>>>> > --verbose \
>>>> > --insecure \
>>>> > --request GET \
>>>> > --user "admin@internal:yourpassword" \
>>>> > --header "Version: 4" \
>>>> > --header "Accept: application/xml" \
>>>> > "https://thatserver/ovirt-engine/api
<
https://thatserver/ovirt-engine/api>
>>>> > <
https://thatserver/ovirt-engine/api
<
https://thatserver/ovirt-engine/api>>"
>>>> >
>>>>
>>>>
>>>> --
>>>> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea
3, planta
>>>> 3ºD, 28016 Madrid, Spain
>>>> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941
- Red Hat S.L.
>>>
>>>
>>
>
--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.