check_http returning FORBIDDEN

[niebais]

I'm having a problem with our main site: "nuskin.com" returning an http forbidden using the wizard for monitoring a website.

We are monitoring about 35 sites right now and two of them act the same way. I need some help fixing this problem, but I'm not sure where to begin. Any ideas?

[tonyyarusso]

Do the sites use HTTP authentication?
If yes, is it BASIC or something else?
Are there any restrictions on allowed IP addresses or anything you could be running into?

[niebais]

Yes, the sites are just regular URLs. For example http://www.nuskin.com is having a problem. The other site is the basic apache entry page. There are no restrictions on either page.

[mmestnik]

Google will have instructions on getting to a shell, with some information provided by us. Once at a shell you should test your url with wget followed by lynx. Then move on to testing the plugin, located in /usr/local/nagios/libexec.

If Nagaios and the shell get different results, it's because the environment does not match.

[niebais]

The shell returns the same thing. I always get FORBIDDEN. However, when I use my own custom script using LWPUSERAGENT, everything works great.

[mmestnik]

The next thing I'd do is trace network traffic or get this information out of an strace. It's most possible that you are just not passing the correct commands to the plugin. I'd wager that your code and the plugin produce different traffic.

Your other option is to just write a plugin, it's not hard at all. The process return code should be from 0 to 3 and Nagios acts on this, it set's the state. Then you print a string, with the graph-able data following a '|'-pipe.

http://nagiosplug.sourceforge.net/devel ... lines.html

[niebais]

Thanks for the replies on both accounts. Going back to the check_http plugin, we set up these monitors using the wizard and they are set up just like the other 39 hosts. I know the options are being set correctly and it acts the same way on the command line. One of the pages is the standard apache default page.

[mmestnik]

When the options are set correctly the check passes when the service is good and fails when the service is bad. Are you saying the options you are using produce this result?

What you will need to look into is how changing the options effects the bits sent over the network, as you have a working test case you can compare one set of bits against another.

The standard apache default page is "GET index.html\n\n", I count 16 bytes or 128 bits. I know it seams simple, but there is plenty of room for error and I can say for certain that both of your checks are going to send more then these 128 bits... This is just my definition or interpretation of the standard apache default page, for this single concept there are hundreds of interpretations and I'd wager there are at least 5 that are commonly used.

[niebais]

I'll put up an strace from the command line when it fails shortly. I'm not using any non-standard options for my site or changing the options for www.nuskin.com, just the standard, built in options the wizard gives you. The really strange part is that the response will sometimes come back with an HTTP ok, but other times it comes back with forbidden. Like I said, I'll put up an strace of it failing later today to see if I can get some help solving this one.

[mmestnik]

I'll also need a working strace and any others that you can provide. Try bumping the string length too, say 512 or 128.