Bug 500685 - 404 on Login.do After Installation
Summary: 404 on Login.do After Installation
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Installer
Version: 530
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Devan Goodwin
QA Contact: wes hayutin
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-05-13 17:07 UTC by Devan Goodwin
Modified: 2009-05-22 12:09 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-05-21 17:44:08 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Devan Goodwin 2009-05-13 17:07:02 UTC
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 14:59:38 UTC
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 16:40:17 UTC
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 17:44:08 UTC
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.