[Ovirt-devel] [patch] oVirt Test Fixes

Thu Aug 14 19:05:01 UTC 2008

On Thu, Aug 14, 2008 at 02:21:35PM -0400, Mohammed Morsi wrote:
> Steve Linabery wrote:
>> On Wed, Aug 13, 2008 at 06:15:04PM -0400, Mohammed Morsi wrote:
>>   
>>> Attached is a patch fixing a few things with the build system. Namely 
>>>  changes in autobuild.sh so that it works with the new changes made 
>>> for  the selenium integration, and changes to the vm controller, vm   
>>> controller test, and permission fixture due to problems caused by 
>>> recent  changes.
>>>
>>>  -Mo
>>>     
>>
>>   
>>> >From 73b27d4e104b0b23eccefbe50c710c7e0975407c Mon Sep 17 00:00:00 2001
>>> From: Mohammed Morsi <mmorsi at redhat.com>
>>> Date: Wed, 13 Aug 2008 18:08:01 -0400
>>> Subject: [PATCH] fixes to autobuild and tests due to recent changes
>>>
>>> ---
>>>  autobuild.sh                                  |    5 +-
>>>  wui/src/app/controllers/vm_controller.rb      |    3 +-
>>>  wui/src/test/fixtures/permissions.yml         |  100 ++++++++++++++++++++++++-
>>>  wui/src/test/functional/vm_controller_test.rb |    4 +-
>>>  4 files changed, 105 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/autobuild.sh b/autobuild.sh
>>> index b565404..cb27221 100755
>>> --- a/autobuild.sh
>>> +++ b/autobuild.sh
>>> @@ -77,10 +77,11 @@ fi
>>>  $ssh_cmd \
>>>    "sed -i -e \"s/KrbMethodNegotiate on/KrbMethodNegotiate off/g\" \
>>>            -e \"s/KrbMethodK5Passwd off/KrbMethodK5Passwd on/g\" \
>>> -          /etc/httpd/conf.d/ovirt-wui.conf"
>>> +          /etc/httpd/conf.d/ovirt-wui.conf && \
>>> +   service httpd restart"
>>>   echo "Running the wui tests"
>>>  $ssh_cmd \
>>> -    "curl -i --negotiate -u : management.priv.ovirt.org/ovirt/ | \
>>> +    "curl -i http://admin:ovirt@management.priv.ovirt.org/ovirt/ | \
>>>     
>>
>> This doesn't work. You'll just get a 302 redirect to http://management.priv.ovirt.org/ovirt/login/login.
>>   
>
> I'm not fully sure I see why its not working. If I understand our new  
> auth setup correctly, apache is still using kerberos to authenticate the  
> user via the ticket / negotiation method, and falling back to kerberos  
> basic auth if it can't. So long as the username:pass is getting to the  
> server, eg there isn't a rewrite (which I removed with my last patch),  
> apache should accept and authenticate the user with the credentials.  

That's not how it works.

All requests except those to /ovirt/login* are going directly to Rails, without any kerberos authentication.

If the request has a session cookie set, and Rails can find a username in the session, then it serves the requested resource.

If there's no username set, Rails sends a redirect to /ovirt/login/login, which is routed through the <ProxyMatch> block in /etc/httpd/conf.d/ovirt-wui.conf, and will either a) accept authentication from a kerberized, kinited browser, or b) accept basic auth and check credentials that way.

So you'll notice that this works:
[root at management ~]# curl -i http://admin:ovirt@management.priv.ovirt.org/ovirt/login/login
HTTP/1.1 302 Moved Temporarily
Date: Thu, 14 Aug 2008 18:56:36 GMT
Server: Mongrel 1.0.1
Status: 302 Found
Location: http://management.priv.ovirt.org/ovirt/
X-Runtime: 0.00100
Cache-Control: no-cache
Content-Type: text/html; charset=UTF-8
Content-Length: 105
Set-Cookie: _ovirt_session_id=0abd8a46b43310ee7737ba11f188b9b9; path=/
Connection: close

<html><body>You are being <a href="http://management.priv.ovirt.org/ovirt/">redirected</a>.</body></html>

But this does not:
[root at management ~]# curl -i http://admin:ovirt@management.priv.ovirt.org/ovirt/
HTTP/1.1 302 Moved Temporarily
Date: Thu, 14 Aug 2008 18:57:31 GMT
Server: Mongrel 1.0.1
Status: 302 Found
Location: http://management.priv.ovirt.org/ovirt/login/login
X-Runtime: 0.00200
Cache-Control: no-cache
Content-Type: text/html; charset=utf-8
Content-Length: 116
Set-Cookie: _ovirt_session_id=459307366fcfea5b49618afdaad11ef1; path=/
Connection: close

<html><body>You are being <a href="http://management.priv.ovirt.org/ovirt/login/login">redirected</a>.</body></html>

Note that this is the case even when kerberos negotiation method is disabled. Curl isn't following the 302 redirects.

> Admitedly, I couldn't get this to work 100% so in autobuild I disable  
> the kerberos negotiation method and everything works like a charm (once  
> httpd is restarted, part of this patch). If this is not working, then  
> one of these steps must be failing.

See above; this will no longer be sufficient.

>
>> There may be a way to make curl negotiate this, but I tried
>> curl -c /tmp/cookies-file --include --location --location-trusted --user admin:ovirt    'http://management.priv.ovirt.org/ovirt/'
>> without success.
>>
>> This does work:
>> lynx -dump -accept-all-cookies -auth=admin:ovirt 'http://management.priv.ovirt.org/ovirt/'
>> but lynx exit status is zero, even for things like 404 errors...
>>
>>   
>>>         grep 'HTTP/1.1 200 OK' && \
>>>     
>>
>> ...I see, however, that you're parsing the output and not depending on the exit status. Not sure how to make lynx output the response headers, or even if lynx is something you'd want to use.
>>   
>
> We can do either or, whatever works, so long as we're verifying that the  
> site is up. As a matter of fact we might be able to skip this curl test  
> and just rely on selenium to do that (since the selenium server will be  
> running on the host, even better), but we still will run into the  
> aformentioned issue of logging in the admin user in an automated fashion  
> via a un / pass.
>
>
>   -Mo

Good day
Steve