Bug 806053 - configserver does not handle 302 properly
configserver does not handle 302 properly
Status: CLOSED ERRATA
Product: CloudForms Cloud Engine
Classification: Red Hat
Component: aeolus-configserver (Show other bugs)
1.0.0
Unspecified Unspecified
unspecified Severity medium
: rc
: ---
Assigned To: Greg Blomquist
dgao
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-22 14:40 EDT by dgao
Modified: 2012-12-04 10:00 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
A 302 error was not being handled properly by aeolus-configserver. This bug fix updates aeolus-configserver so that it retries the access attempt (with a maximum of 10 times) using the re-directed URL.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-04 10:00:52 EST
Type: ---
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 dgao 2012-03-22 14:40:28 EDT
When getting a 302, configserver errors out even though it's a benign error. 

ERROR: could not get configuration file contents
Could not download file https://github.com/aeolusproject/audrey/raw/master/examples/wordpress/wordpress-http.sh.  Http Response code: 302
Comment 1 jrd 2012-03-28 10:28:29 EDT
Greg, IIRC we discussed this and decided that at least for 1.0, this was a "well don't do that then" situation.  Can you confirm?  If so, let's move this off the 1.0 list.
Comment 3 Justin Clift 2012-07-06 07:26:18 EDT
As a practical example of where this affects things, the present Audrey wordpress examples use GitHub URLs like this:

  https://github.com/aeolusproject/audrey/raw/master/examples/wordpress/wordpress-http.sh

These should be:

  https://raw.github.com/aeolusproject/audrey/master/examples/wordpress/wordpress-http.sh

On the GitHub side, when a request for the first (above) URL comes in, a 302 response is given, with the new (updated) URL to use.

However, Config Server barfs instead of using the information correctly.

The deployment then fails, not being able to retrieve the needed configuration info from the URL.

The evidence of the failure is in /var/log/aeolus-configserver/thin.log on the running Config Server instance:

  warning: peer certificate won't be verified in this SSL session
  ERROR: could not get configuration file contents
  Could not download file https://github.com/aeolusproject/audrey/raw/master/examples/wordpress/wordpress-http.sh.  Http Response code: 302

Compare to a successful download, using a correct URL:

  warning: peer certificate won't be verified in this SSL session
Comment 4 Justin Clift 2012-07-06 07:29:26 EDT
All that's required here, is for Config Server to honour the http 302 status code (a redirect, pointing to a newer URL location), and automatically retry the download, using the new URL location provided.
Comment 5 jrd 2012-07-26 15:36:13 EDT
PM input required.
Comment 6 Mitch 2012-07-26 16:09:41 EDT
This comes down to whether QE can get this added to their testing and still make the original 1.1 date.  If they can, then yes, this should be in 1.1.  If not, I'm not willing to slip 1.1 for this.  We can add it to v.next.  I'll confirm with QE and get back to everyone.
Comment 8 Mike Orazi 2012-08-06 18:23:36 EDT
Moving it back, this should have already had devel-ack
Comment 9 Greg Blomquist 2012-08-09 17:13:32 EDT
The implementation change here is to attempt to follow a max of 10 redirects before failing to download a file referenced in a deployable.
Comment 12 dgao 2012-09-19 11:42:02 EDT
Configured a redirect in apache and used the following blueprint:

<?xml version="1.0"?>
<deployable version="1.0" name="rhel62_test">
  <description/>
  <assemblies>
    <assembly name="test" hwp="small-x86_64">
      <image id="80f54e44-01b7-11e2-9261-00145e6d1d0c"/>
      <services>
        <service name="http">
          <executable url="https://zhongyong.usersys.redhat.com/redirect_script"/>
          <files>
            <file url="https://zhongyong.usersys.redhat.com/redirect_script"/>
          </files>
          <parameters>
            <parameter name="foo">
                <value>bar</value>
            </parameter>
          </parameters>
        </service>
      </services>
    </assembly>
  </assemblies>
</deployable>




on configserver:


[root@deaddonkey tmp]# tar xvzf ../6903b8a8-026f-11e2-9261-00145e6d1d0c.tgz 
.
http
http/redirect_script
http/start
[root@deaddonkey tmp]# ls
http
[root@deaddonkey tmp]# cd http/
[root@deaddonkey http]# ls
redirect_script  start
[root@deaddonkey http]# cat redirect_script 
#!/bin/bash
touch /etc/cloud-qe.cfg
printenv | grep auto_service_param > /etc/cloud-qe.cfg

exit 0 # Success
Comment 14 errata-xmlrpc 2012-12-04 10:00:52 EST
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

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