MEM and HTTP Proxy Not Compatible
By Jonathon Coombes on May 25, 2009
I thought I would do a follow up on the issue found before with how MySQL Enterprise Monitor (MEM) works with http proxies. Previously it was suggested that using the no_proxy environment variable would be enough, since MEM is based on libcurl and libcurl recognises these certain environment variables to enable flexible control of traffic. However, the problem occurs that things seem to work fine on the initial start, but the heartbeat within MEM is not working properly!
After starting, MEM appears to be all working as there is no error showing up, but on examining the logs you start to get worried when you seem strange url's appearing that suggest heartbeat is trying to access www.agent.com for heartbeat confirmation? Why would the monitoring be attempting to go to an external site and not be done internally?
Well, the problem was quickly dismissed when using the no_proxy environment variable to turn off the use of the proxy by the agent server. This worked when using the wildcard ("\*") for all ip addresses, but not if the specific heartbeat server ip address was used. This seemed odd as it is well documented to support single or multiple ip addresses in the definition as defined by curl. So a setting of:
shell> export NO_PROXY="192.168.1.1"
should work, where 192.168.1.1 is our heartbeat server.
This suggested that there was a problem with the proxy software being used. On checking what proxy was used, it was Wingate, which from my experiences in the past, confirmed relatively quickly for me that it was not treating the url correctly. However, on looking at other proxies, the same result seemed to occur?
I talked with one of the guys on #curl on freenode to find out if this was a known problem. Initial confirmation was the the no_proxy environment variable worked fine for both single, multiple and wildcard ip addresses. However, I mentioned that the url is of the full form as:
so one of this form was tried and it failed! It seems that the libcurl library was not properly parsing the url in the full RFC-compliant form and instead extracted a "valid" url based on http://username. This would usually be interpreted by modern browsers as http://www.username.com and hence with the common name of 'agent', the mystery url of www.agent.com was able to be explained.
The good news is that the libcurl guy I talked with produced a patch within 20 minutes, with testing and made it available for incorporating into the next version. As for MEM, it will either use the new libcurl library, or separating out the authentication from the url may also be an option. Which ever method is used, this is not going to be solved until version 2.1 I am afraid. Thankfully, most people will be able to simply turn off all proxy attempts using the wildcard on the agent server, with only a few people probably be affected by this bug in the short term.