Bug 500685

Summary:	404 on Login.do After Installation
Product:	Red Hat Satellite 5	Reporter:	Devan Goodwin <dgoodwin>
Component:	Installer	Assignee:	Devan Goodwin <dgoodwin>
Status:	CLOSED WORKSFORME	QA Contact:	wes hayutin <whayutin>
Severity:	high	Docs Contact:
Priority:	high
Version:	530	CC:	cperry
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-05-21 17:44:08 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.