Forum Discussion
eav with curl doing posts
I'm trying to copy the EAV example shown in the monitoring examples. The EAV keeps failing and I'm trying to troubleshoot. When I run curl from cli to test using the syntax below I think I get the correct redirect
curl -fNs http://:8882/jde/E1Menu.maf -d 'jdeowpBackButtonProtect=PROTECTED&User=testuser&Password=testpassword&Environment=testenv&Role=*All' ...
the EAV I created I copied exactly from the HTTPbasic postexample on the monitoring/management section
http://devcentral.f5.com/wiki/default.aspx/AdvDesignConfig/HTTPMonitor_cURL_BasicPOST.html
when I created the external monitor I discovered that I can't put the eav in /config/eav even though the instructions say to do so. The file has to go into /usr/bin/monitors. I set the perms to 700 . I then created an external monitor with a DATA variable containing the exact string listed above, a URI variable for /jde/E1Menu.maf , and a Data variable with the exact 302 content pulled from HTTPwatch.
I apply this monitor to the nodes and it fails instantly. I'm concerened about the special char. I'm also wondering if using the whole HTTP redirect
Redirect to http://testserver:8882/jde/E1Menu.maf?RENDER_MAFLET=E1Menu&jdeowpBackButtonProtect=PROTECTED
was the right thing to do. This is my 1st attempt at EAV's using curl and I'm wondering how to proceed to troubleshoot.
Thanks!! Oh and I'm running 9.3 HF3.
- correction to above...RECV variable with the exact 302 content.
hoolioCirrostratus
Can you try replacing the receive string with just 'HTML' to test? If that doesn't work, can you try testing with a request that generates an HTTP 200 response and set the receive string to '200'?
Aaron- setting RECV variable to HTML fails also. I'm not really sure how to send a request that will get a 200 response. The way their app works is when the user logs in (the desired test for the monitor) their app sends a 302
- found it...I cut and pasted the original exactly as is..!/bin/sh http_monitor_cURL+POST it appears the extra test http_monitor_cURL+POST was the problem...after that, Aaron's test of just using http still failed. I removed the double quotes from around the ${DATA} variable on the curl line of the script and in the monitor, enclosed the text for that variable in single quotes. now the http test worked..I put my original RECV string back in and had the same special character issue...I removed teh double quotes from the RECV variable on the curl line, put in single quotes in the gui for the text for that variable and now it is working...thanks Aaron !!
- correct on first line..extra TEXT http_monitor_cURL+POST ....one additional question...is the issue with my not being able to put the monitor in /config/eav a version problem ? IE I'm running 9.3 and the ability to use that is either 9.4.1 or 9.4.2 ?
- Are you saying you had not included that line, and once you did it worked? (Just wanted to make sure the codeshare entry doesn't need tweaking.)
Beginning in 9.0 the recommendation was to put monitors in /config/eav, but I do vaguely remember there being some problem with that at one point. If you are still seeing that behaviour, please open a Support case. Placing monitor scripts under the /config directory ensures they are sync'd and included in archives, otherwise they may not be.
/deb - sorry for not being clear...the original text was
!/bin/sh http_monitor_cURL+POST ....this gave me errors at runtime...something like http_monitor_cURL+POST not found...I had to remove that extra text so that the line looked like !/bin/sh and then the script run..
as far as the directory goes, per the 9.4 documentation, see url, /usr/bin/monitors is the correct dir
https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip9_4config/BIGIP_LTM_CONFIG_GD_9_4-13-1.htmlwp1182648 - If you change the script name when you save it to your LTM, you'd also have to change that line to match, otherwise it will exit on "no such file" error when the shell tries to run it.
It's not necessary, so I will remove it to prevent anyone else from encountering that issue.
Looks like LTM now archives & syncs monitors in /usr/bin/monitors, so that issue was apparently fixed in a different way than expected.
Will update codeshare with both items, thanks for the feedback!
/deb - ah, I see I left out the path, so it wouldn't have worked even with the same name.
Sorry, and thanks for catching that!
All affected monitors have been updated.
/deb - heck, thanks got to you and the rest of the dev central gang...the monitor examples are great...they may require a little specific tweaking for the specific situation but all the major work is already done. I can't begin to say how much the monitor / irule code share helps out !!!!
