Red Hat Bugzilla – Bug 498650
Monitoring, TCP CHECK probe port 80 returns html, breaks the page
Last modified: 2009-09-10 14:49:32 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"> <html><head> <title>400 Bad Request</title> </head><body> <h1>Bad Request</h1> <p>Your browser sent a request that this server could not understand.<br /> </p> <hr> <address>Apache/2.0.52 (Red Hat) Server at fjs-0-19.rhndev.redhat.com Port 80</address> </body></html> 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.. recreate: monitoring 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
https://rlx-1-16.rhndev.redhat.com/rhn/systems/details/probes/ProbeDetails.do?probe_id=27&sid=1000010073 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. Cliff
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.
Could you provide more exact information, how to reproduce the problem?
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.) problems: 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.
Finally reproduced. The BZ is correct. The Event Log was not html escaped. Fix: 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
*** Bug 503233 has been marked as a duplicate of this bug. ***
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.
Fix present in: spacewalk-java-0.5.44-22 spacewalk-java-lib-0.5.44-22
Created attachment 348671 [details] screenshot
6/16 build.. fails
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
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 and 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?
the screenshot from comment #9 would be the correct behavior
In that case, I'm aligning to sat600-triage as the "Response" part is not shown on Satellite 5.3.0.
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. http://rhn.redhat.com/errata/RHEA-2009-1434.html