Bug 500685 - 404 on Login.do After Installation
404 on Login.do After Installation
Status: CLOSED WORKSFORME
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Installer (Show other bugs)
530
All Linux
high Severity high
: ---
: ---
Assigned To: Devan Goodwin
wes hayutin
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-13 13:07 EDT by Devan Goodwin
Modified: 2009-05-22 08:09 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-21 13:44:08 EDT
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 Devan Goodwin 2009-05-13 13:07:02 EDT
Description of problem:

In some scenarios, after installation the user sees a 404 when they should see the screen to create initial user.

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

Satellite-5.3.0-RHEL5-re20090507.1-i386-embedded-oracle.iso

How reproducible:

Unclear, this is only surfacing for some installations but does not happen for all. It has also surfaced on a Fedora 10 installation of Spacewalk from the 0.6 devel repo. Suspect the failed activation may be the cause.

Steps to Reproduce:
1. Install Satellite with a 5.3 cert, but attempt to activate against hosted.
2. Repeat with correct activation against webqa.
  
Actual results:

Install completes, but attempting to visit the web UI results in a 404. 


Expected results:

Create first user screen.

Additional info:

When this occurs you will see errors in /var/log/httpd/ssl_error_log for all url's starting with /rhn/ or /rpc/, indicating that the Apache RewriteEngine is not working properly.

The difference between a working install and a not working install appears to be the absence of these lines from the end of /etc/httpd/conf.d/ssl.conf:

RewriteEngine on
RewriteOptions inherit
SSLProxyEngine on

These are normally located inside the VirtualHost configuration, just before the tag is closed.

Not sure if these lines are pre-existing or something we add during the stage of the installer when we prompt for modification of ssl.conf. 

The failed Satellite activation is our best guess so far for a reproducer, something causing the second run to not have ssl.conf properly set up.
Comment 1 Brandon Perkins 2009-05-14 10:59:38 EDT
We'll be happy to approve this once we have a consistent reproducer.  For now, there is approval for investigation of this problem.
Comment 2 Devan Goodwin 2009-05-21 12:40:17 EDT
Fixed for Spacewalk running code from pgsql branch, still not sure how it happened on EL5 Satellite install. Investigating possibility of some bad answer file logic.

Spacewalk.git pgsql fix: e44aed14a4a0df2bb6f76da06ef141d9f397b986
Comment 3 Devan Goodwin 2009-05-21 13:44:08 EDT
Everything I've examined the code and it looks healthy, I cannot reproduce on El5 and Satellite, it may have been a "n" instead of a "y" when prompted for touching up ssl.conf. Closing for now, we'll keep an eye out for it.

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