Forum Discussion
Dbow_21284
Nimbostratus
NimbostratusHelp with External HTTP Monitor (cURL) - Requires http authentication
Hello,
I am taking a variation of an external monitor used when NTLM auth is required and tweaking it for jsut regular http authentication. However, I am having an issue getting it to work entirely. When I run the external monitor from an SSH CLI (for instance, sh -x /usr/bin/monitors/AUTH_Members 10.10.185.40 80 ) I get the appropriate response, but when I apply the monitor to a pool in the MGMT GUI, it does not work.
My External monitor code is below and is testing return string of "1-UP":
!/bin/sh
remove IPv6/IPv4 compatibility prefix (LTM passes addresses in IPv6 format)
IP=`echo ${1} | sed 's/::ffff://'`
IP=${1}
PORT=${2}
PIDFILE="/var/run/`basename ${0}`.${IP}_${PORT}.pid"
kill of the last instance of this monitor if hung and log current pid
if [ -f $PIDFILE ]
then
kill -9 `cat $PIDFILE` > /dev/null 2>&1
fi
echo "$$" > $PIDFILE
send request & check for expected response
curl -L -v --user 'testuser:superpassword' http://${IP}:${PORT}/_layouts/ACCApplications/CommonLogin/login.aspx?ReturnUrl=%2fwhatsup.aspx -H "Host: members.acc.org" | grep -i "1-UP"
2>&1 > /dev/null
mark node UP if expected response was received
if [ $? -eq 0 ]
then
echo "UP"
fi
rm -f $PIDFILE
exit
When I execute it in the CLI with command, sh -x /usr/bin/monitors/AUTH_Members 10.10.185.40 80, it seems to work! See below:
[admin@dmzlb1:Active] monitors sh -x /usr/bin/monitors/AUTH_Members 10.10.185.40 80
++ echo 10.10.185.40
++ sed s/::ffff://
+ IP=10.10.185.40
+ PORT=80
++ basename /usr/bin/monitors/AUTH_Members
+ PIDFILE=/var/run/AUTH_Members.10.10.185.40_80.pid
+ '[' -f /var/run/AUTH_Members.10.10.185.40_80.pid ']'
+ echo 9294
+ curl -L -v --user testuser:superpassword 'http://10.10.185.40:80/_layouts/ACCApplications/CommonLogin/login.aspx?ReturnUrl=%2fwhatsup.aspx' -H 'Host: members.acc.org'
* About to connect() to 10.10.185.40 port 80
* Trying 10.10.185.40... + grep -i 1-UP
connected
* Connected to 10.10.185.40 (10.10.185.40) port 80
* Server auth using Basic with user 'testuser'
> GET /_layouts/ACCApplications/CommonLogin/login.aspx?ReturnUrl=%2fwhatsup.aspx HTTP/1.1
> Authorization: Basic ZGRlbmJvdzpiYWJ5cmVuMQ==
> User-Agent: curl/7.15.3 (i686-redhat-linux-gnu) libcurl/7.15.3 OpenSSL/0.9.7l zlib/1.1.4
> Accept: */*
> Host: members.acc.org
>
< HTTP/1.1 200 OK
< Date: Tue, 18 Aug 2009 21:05:43 GMT
< Server: Microsoft-IIS/6.0
< X-Powered-By: ASP.NET
< MicrosoftSharePointTeamServices: 12.0.0.6510
< X-AspNet-Version: 2.0.50727
< Cache-Control: private
< Content-Type: text/html; charset=utf-8
< Content-Length: 21385
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 21385 100 21385 0 0 940k 0 --:--:-- --:--:-- --:--:-- 4579k* Connection 0 to host 10.10.185.40 left intact
* Closing connection 0
+ '[' 0 -eq 0 ']'
+ echo UP
UP
+ rm -f /var/run/AUTH_Members.10.10.185.40_80.pid
+ exit
Has anyone ever seen this or experienced this? Or any ideas where to go on this? I have verified the member IP addresses in the pool are right. So unfortunately, its not something simple like this.
Also, I tried a stock HTTP monitor via the GUI with the following configuration which didnt work either, which is why I went to the external monitor:
GET /_layouts/ACCApplications/CommonLogin/login.aspx?ReturnUrl=%2fwhatsup.aspx HTTP/1.1\nHost: members.acc.org \nConnection: close\n\n
Then I put the username and password in their respective fields in the properties of the monitor in the LTM GUI. That didnt work either.
Thanks,
Dbow
11 Replies
- The_BhattmanDoes the script have the right permissions?
CB 
hoolioCirrostratus
For basic auth you should be able to use a stock HTTP monitor with a customized send and receive string. You can insert the credentials base64 encoded in the Authorization headers just like curl does:
GET /_layouts/ACCApplications/CommonLogin/login.aspx?ReturnUrl=%2fwhatsup.aspx HTTP/1.1\r\nHost: members.acc.org\r\nConnection: close\r\nAuthorization: Basic ZGRlbmJvdzpiYWJ5cmVuMQ==\r\n
Aaron
Dbow_21284Ok I realized permissions did fix the issue where my external monitor was not working in the GUI. THANKS! But I also realized I had a code issue that was giving a false positive in the CLI, so now I am running into another problem.
Here was the code issue! What was:
There was line break before the "2>&1 > /dev/null".curl -L -v --user 'testuser:superpassword' http://${IP}:${PORT}/_layouts/ACCApplications/CommonLogin/login.aspx?ReturnUrl=%2fwhatsup.aspx -H "Host: members.acc.org" | grep -i "1-UP" 2>&1 > /dev/null
should have been:curl -L -v --user 'testuser:superpassword' http://${IP}:${PORT}/_layouts/ACCApplications/CommonLogin/login.aspx?ReturnUrl=%2fwhatsup.aspx -H "Host: members.acc.org" | grep -i "1-UP" 2>&1 > /dev/null
I have a new issue though! It actually doesnt work (meaning doesnt see return string) but I think it has something to do with the way the site is redirecting you. Let me explain how it works from user perspective. When you put in something.mydomain.org/whatsup.aspx (which requires basic authentication) in your browser ... you are redirected to something.mydomain.org/_layouts/ACCApplications/CommonLogin/login.aspx?ReturnUrl=%2fwhatsup.aspx where the user puts in their credentials and then it goes back to something.mydomain.org/whatsup.aspx and the return string of "1-UP" shows up on the page.
Now, when I run my External monitor in the SSH CLI, I get a HTTP/1.1 200 OK, but I do not get the echo "UP" as it seems like it is testing for the return string before the redirection occurs ... or it doesnt happen or something. I am not 100% sure on that.
So question: do the developers need to change something in the site bhavior for this to work? Or is there additional logic I can add to my external monitor script to test once it is at the actual page something.mydomain.org/whatsup.aspx? Thanks!- Dbow_21284FYI: I have tried the curl line with both:
curl -L -v --user 'testuser:superpassword' http://${IP}:${PORT}/_layouts/ACCApplications/CommonLogin/login.aspx?ReturnUrl=%2fwhatsup.aspx -H "Host: members.something.org" | grep -i "1-UP" 2>&1 > /dev/null
This is where you are redirected when you just put in members.something.org/whatsup.aspx
andcurl -L -v --user 'testuser:superpassword' http://${IP}:${PORT}/whatsup.aspx -H "Host: members.something.org" | grep -i "1-UP" 2>&1 > /dev/null - hoolioIt might be an interesting exercise to troubleshoot the external monitor issues, but for basic auth monitoring, it is more efficient to use a standard HTTP monitor with a customized send string which includes the Authorization header. If the page you want to check the response content for is /whatsup.aspx, you should try using that in the send string:
GET /whatsup.aspx HTTP/1.1\r\nHost: members.acc.org\r\nConnection: close\r\nAuthorization: Basic ZGRlbmJvdzpiYWJ5cmVuMQ==\r\n
If that doesn't work, can you reply with the applications response? It might actually be necessary to make a request to the intermediate page with an external monitor, but it makes sense from a resource perspective to try to do it first with an standard HTTP(S) monitor.
Aaron - Dbow_21284Ok using a stnd http monitor in the GUI with your string, I still need to put the username and password into those fields correct?
I tried the string in the GUI on a http monitor with the string (with the credentials in the username/ password fields and without). It didnt work.
How do I see the response? Should I capture via tcpdump? It seems the way its redirecting ahs something to do with it. I had actually tried this before but thought I would double check.
Thanks
Dave - hoolioThe sample username and password of testuser:superpassword are already base64 encoded in the Authorization header I included in the example send string. If that isn't the actual username and password the app expects, you can base64 encode the actual username and password using an online tool like this: http://www.opinionatedgeek.com/dotnet/tools/Base64Encode/Default.aspx
The format for the username and password is username:password base64 encoded, so you can include the two fields in that online form for the base64 encoding and replace ZGRlbmJvdzpiYWJ5cmVuMQ== with the actual encoded value in the send string I posted above.
If that doesn't work, then you can either troubleshoot the issue or start looking at the external monitor again. To troubleshoot monitors, you can either enable bigd debug or use tcpdump. See this post for details on enabling bigd debug: http://devcentral.f5.com/Default.aspx?tabid=53&view=topic&postid=58171&ptarget=58182
Aaron - Dbow_21284OK gotcha. The BASE64 encoding in my post was valid ... I jsut changed the username:password in the copied text. But again it was for a valid account. So thanks for that tidbit ... I was confused on that. Learned something from you as usual!
So I did a "b db bigd.debug enable", gave it some time for the monitor to run for a bit (which is every 16 seconds right now) and this is all that I see in the log:15:36:26.038107: (_send_active_service_ping): addr=::ffff:10.10.141.27:80 sent ping 15:36:26.038126: (_main_loop): wfd selected for addr=::ffff:10.10.185.39:80 pending=1 15:36:26.038145: (_send_active_service_ping): addr=::ffff:10.10.185.39:80 15:36:26.038178: send_active_service_ping: addr=::ffff:10.10.185.39:80 writing GET /whatsup.aspx HTTP/1.1 Host: members.acc.org Connection: close Authorization: Basic ZGRlbmJvdzpiYWJ5cmVuMQ== Authorization: Basic ZGRlbmJvdzpiYWJ5cmVuMQ==
Usually for any other monitor, I see stuff like this:15:36:20.114103: (_send_active_service_ping): addr=::ffff:10.10.140.33:443 sent ping 15:36:20.153280: (_main_loop): rfd selected for addr=::ffff:10.10.140.33:443 pending=0 15:36:20.153334: (_recv_active_service_ping): addr=::ffff:10.10.140.33:443 15:36:20.153447: (_recv_active_service_ping): addr=::ffff:10.10.140.33:443 send=GET /registries/WhatsUp.asp regexp=1-Up recv=H WhatsUp WebNCDR Service? 1-Up
So the second entry we see the "1-UP" in the results ... there are no results for the one I am having issue with.
Does this shed any light by any chance!?!!?
Oh thanks for the bigd.debug commands! Learned one more thing as well! Sweet! - hoolioI would expect some kind of response even if it was a 40x level status from the web server. If no response is being logged in bigd debug output, I'd suggest reviewing the web server logs and possibly capturing a tcpdump of the monitor traffic to get a better idea of what's failing.
Also, it looks like there are two authorization headers being sent and no response being received at least from the logs that you've quoted. If you have the username / password configured in the GUI section, then you don't need to include the Authorization header in the send string as LTM will insert it for you.
Aaron 
Peter_ZCirrus
Hello, we use the code as external monitor when checking the websites with NTLM authentication. It works well, when the webpage return a response where we can match the return string (in the response payload). However, when we need to check for the response code (e.g. 200 OK), the monitor will fail to match and will mark the pool member DOWN. Is there a way how we could match for the HTTP responses/status codes with this or similar script? In our case, we are looking for existence od a .dll file on the server.
