Bug 760592

adding ce-sprint-next bugs to ce-sprint

In #760377, Greg got around this by <a href="https://fedorahosted.org/pipermail/aeolus-devel/2011-December/007547.html">using the oauth gem directly</a> instead of using restclient at all. That's probably a good path to take here as well.

Where this actually matters for Conductor (besides the config server code, which was fixed in 760377) is in our iwhd client in rubygem-aeolus-image. Fixing it there would mean that we want to implement https://www.aeolusproject.org/redmine/issues/2606 to have iwhd verify the full hash.

Patch sent for feedback: http://lists.fedorahosted.org/pipermail/aeolus-devel/2012-January/007838.html

Pushed to aeolus-image-rubygem's master:

commit 67fdf6ff1a395624c81df8b16832248b45185505
Author: Matt Wagner <matt.wagner>
Date:   Wed Jan 4 17:04:10 2012 -0500

    Use oauth gem directly for signing OAuth requests
    
    Using restclient appears to cause part of the request to get dropped
    on the floor, causing oauth_body_hash to be invalid.
    
    This appears backwards compatible with existing versions of iwhd.
    
    Resolves https://bugzilla.redhat.com/show_bug.cgi?id=760592

I've pushed this, but note that the code to validate this on the iwhd side isn't yet committed. It's possible that it won't be committed: http://lists.fedorahosted.org/pipermail/aeolus-devel/2012-January/007896.html

This patch is still a good thing in that we're sending a properly-signed request to iwhd now, but it will have no real-world benefit as iwhd isn't checking whether the oauth_body_hash is correct or not unless the patch linked in the previous paragraph is committed to iwhd.

Blindly setting this to ON_QA in the belief that a fix is included in the latest aeolus packages.

bugs in verified or on_qa moving off tracker

Fixed in the latest build of audrey client and configserver:

aeolus-audrey-agent-0.4.3-1.el6.noarch.rpm                                  
aeolus-configserver-0.4.5-1.el6.noarch.rpm

oops mistakenly commented the wrong bug, disregard the last comment.

Setting this back to POST because https://fedorahosted.org/pipermail/aeolus-devel/2011-December/007547.html has never been applied.

I'll work with someone from conductor to get this in.

This bug is to track the changes on the conductor side of the conductor -> config server communication.

It looks like Matt's comments relate to the same type of communication between conductor -> iwhd.  This should be opened and tracked in another bug.

rubygem-aeolus-image-0.3.0-3.el6.src.rpm
67fdf6ff1a395624c81df8b16832248b45185505

Ugh, according to dgao, this bug is actually to track the conductor side of the conductor -> configserver oauth relationship.  All of the comments related to the communication with iwhd should be associated with https://bugzilla.redhat.com/show_bug.cgi?id=782899.

I submitted a patch for this on Dec.16,2011, but didn't get it reviewed.  So, I'm rebasing the patch, retesting and re-posting.

Moving this back to assigned.

Moving this to 1.1. Dev agrees this is too invasive to fix this late in the game.

https://github.com/aeolusproject/conductor/pull/46

Validation notes:

What this patch changes:

This patch changes the way that conductor authenticates with config server.  The latest config server (aeolus-configserver-0.4.10-2) no longer accepts the way that conductor was authenticating--which was not fully signing the request body.

Now, config server requires that the request POST body be fully and correctly signed.

This patch removes RestClient as the mechanism for building the oauth request to config server.  Instead, it now uses the Ruby OAuth client directly to build the oauth request.

How to validate this change actually works:

Prereqs:
  - an unpatched conductor
  - a provider account
  - a config server running version 0.4.10-2

Setup:

a) associate the config server with the provider account
  - in conductor, navigate to the provider account, and click "Add" next to config server
  - enter the config server's endpoint (https://fqdn)
  - enter the oauth key
  - enter the oauth secret
  - save

b) launch a deployable with at least one service (this doesn't need to be a complex service ... any service will do)

c)  witness the 404 in the config server logs and conductor fails to launch the deployment

Validation:

a) Patch conductor

b) launch the same deployable

c) see the 200 in the config server log and conductor successfully launches the deployment.


Getting a config server:

The easiest way to get access to a config server is to work with QE.  Talk to dgao at redhat dot com.  He usually has one running and can provide the connection details as well as access to the config server logs.

Thanks for the detailed instructions!  ACK'd and pushed.

The initial patch had a minor flaw that I failed to detect.  Here's the reworked patch, which is now in master:

https://github.com/aeolusproject/conductor/pull/55

Pushed to 1.1.  Just to be clear, https://github.com/aeolusproject/conductor/pull/46 was reverted; https://github.com/aeolusproject/conductor/pull/55 is what's been pushed.

Patch is good for aeolus-conductor-0.13.7-1.el6cf.noarch

technical notes added. Feedback appreciated.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2012-1516.html