Bug 498650 - Monitoring, TCP CHECK probe port 80 returns html, breaks the page
Monitoring, TCP CHECK probe port 80 returns html, breaks the page
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Monitoring (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Tomas Lestach
wes hayutin
: 503233 (view as bug list)
Depends On:
Blocks: 462714 463877
  Show dependency treegraph
Reported: 2009-05-01 12:38 EDT by wes hayutin
Modified: 2009-09-10 14:49 EDT (History)
4 users (show)

See Also:
Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-10 14:49:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
screenshot (172.20 KB, image/png)
2009-06-19 10:14 EDT, wes hayutin
no flags Details

  None (edit)
Description wes hayutin 2009-05-01 12:38:35 EDT
Description of problem:

4/24.1 build on rhel 5

Monitoring.. it seems if *any* of our probes return raw html as txt as part of the probes status it will break our html.  

In this case..

Probe:  	General: TCP Check
Monitoring Scout 	RHN Monitoring Satellite
Status: 	OK, TCP port 80: Latency 0.0100 sec; Response <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<title>400 Bad Request</title>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
<address>Apache/2.0.52 (Red Hat) Server at fjs-0-19.rhndev.redhat.com Port 80</address>
Last update: 	5/1/09 12:24:30 PM EDT

Here is what breaks... try to graph this probe..
get a blank page w/ some carriage returns..

create probe tcp check on port 80 w/ param "GET HEAD\n"
then generate report on the probe..

breaks page 

I suspect this a *low* priority bug
Comment 1 Clifford Perry 2009-05-07 16:36:22 EDT

Not able to replicate on 5.1 Sat above. Suspect we somehow use to drop the content of the reply, but now we attempt to store it (for some reason). Seems like a change in behavior. 

Comment 2 Tomas Lestach 2009-05-20 10:32:13 EDT
I cannot reproduce the problem.

I get both a graph and an event log without any problem.
I also get no error message when triggering the probe using rhn-runprobe.

Was testing sat5.3. March compose and Satellite-5.3.0-RHEL5-re20090507.1.
Comment 3 Tomas Lestach 2009-05-21 06:59:08 EDT
Could you provide more exact information, how to reproduce the problem?
Comment 4 wes hayutin 2009-05-28 10:51:54 EDT
ok.. it looks like a few things are going on here..

1. create the probe as listed above..
2. on the client toggle the httpd daemon on an off to generate data points.. (goes from critical to ok, and back etc.)

3. in my latest recreate, no additional data points are created > 1 point
4. click, download csv data(from graph), and the page goes blank. (redirected actually to systems overview page) acl may be off.

unable to really test this until data gets populated as it should be.  Sending it back for Tomas to take a look at.
Comment 5 Tomas Lestach 2009-06-11 07:44:08 EDT
Finally reproduced. The BZ is correct. The Event Log was not html escaped.

I html escaped a copy of monitoring data right before displaying them to preserve to original data, that are needed non-escaped later on.

commit: ddb349526220dd58132b0108792eb0afbd8e853f
Comment 6 Tomas Lestach 2009-06-11 07:47:21 EDT
*** Bug 503233 has been marked as a duplicate of this bug. ***
Comment 7 Devan Goodwin 2009-06-11 12:53:29 EDT
Ran into some problems with first draft of the fix, reverted with:

spacewalk.git: b151261ea9ee8e3d34a3a5f78eb22b531ae6d122
satellite.git: 62153950374bc06270c7b27daa1e03ca41cbfd16

Second draft of fix:

spacewalk.git: f81e4ddeed27cf63b485974da3f586b76e840b77
satellite.git: d4834249ffb7e67568ec92cb6a96427cc2810d5c

Should still be destined for next ISO.
Comment 8 Tomas Lestach 2009-06-16 10:27:10 EDT
Fix present in:

Comment 9 wes hayutin 2009-06-19 10:14:11 EDT
Created attachment 348671 [details]
Comment 10 wes hayutin 2009-06-19 10:14:32 EDT
6/16 build.. fails
Comment 12 wes hayutin 2009-06-19 11:17:33 EDT
ok.. Tom emailed me and I took another look at this.
I does appear to be working correctly..

Thanks for pointing that out.. 
verified 6/16
Comment 13 Jan Pazdziora 2009-09-07 10:03:31 EDT
Stage validated on Satellite-5.3.0-RHEL5-re20090820.1, moving to RELEASE_PENDING.

I don't see any WebUI breakage due to unquoted HTML content. As a matter of fact, I don't see any HTML in the WebUI, it just says

Status:  	OK, TCP port 80: Latency 0.0009 sec


9/7/09 9:44:49 AM EDT   	OK   	TCP port 80: Latency 0.0008 sec

at the bottom of the page.

Is that expected that the actual output is not shown at all?
Comment 14 wes hayutin 2009-09-09 13:07:47 EDT
the screenshot from comment #9 would be the correct behavior
Comment 15 Jan Pazdziora 2009-09-09 13:50:43 EDT
In that case, I'm aligning to sat600-triage as the "Response" part is not shown on Satellite 5.3.0.
Comment 16 Brandon Perkins 2009-09-10 14:49:32 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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