unexpected end of file

[tmcdonald]

Make sure you are removing & from the illegal_macro_output_chars, aside from that I would double-check that a $USERx$ macro containing just & still fails. I can't think why it wouldn't work.

In regards to your other question, yes - they all need to be $USERx$

https://assets.nagios.com/downloads/nag ... ource_file

[WillemDH]

I have tested the solution to put the whole URL in the resource.cfg, which worked.

But only replacing & with $USER10$ did not work.

This is resource.cfg:

Code: Select all

# Escaping ampersand
$USER10$=&
$USER11$='/sparql?default-graph-uri=&query=prefix+schema:+%3Chttp://schema.org/%3E%0D%0AASK+%7B%0D%0A%7B%0D%0A?loc+%3Chttp://stad.gent/data/internal/resourceId%3E+?id;%0D%0A%3Chttp://stad.gent/data/internal/resourceType%3E+?type.%0D%0A%0D%0AFILTER+(?id+=+%22%22)%0D%0A%7D%0D%0AUNION+%0D%0A%7B%0D%0A?loc+%3Chttp://stad.gent/data/internal/resourceId%3E+?id;%0D%0A%3Chttp://stad.gent/data/internal/resourceType%3E+?type.%0D%0A%0D%0AFILTER+(?type+=+%22%22)%0D%0A%7D%0D%0A%7D&format=text/html&timeout=0&debug=on'

This is my arg1:

Code: Select all

-u '/sparql?default-graph-uri=$USER10$query=prefix+schema:+%3Chttp://schema.org/%3E%0D%0AASK+%7B%0D%0A%7B%0D%0A?loc+%3Chttp://stad.gent/data/internal/resourceId%3E+?id;%0D%0A%3Chttp://stad.gent/data/internal/resourceType%3E+?type.%0D%0A%0D%0AFILTER+(?id+=+%22%22)%0D%0A%7D%0D%0AUNION+%0D%0A%7B%0D%0A?loc+%3Chttp://stad.gent/data/internal/resourceId%3E+?id;%0D%0A%3Chttp://stad.gent/data/internal/resourceType%3E+?type.%0D%0A%0D%0AFILTER+(?type+=+%22%22)%0D%0A%7D%0D%0A%7D$USER10$format=text/html$USER10$timeout=0$USER10$debug=on' -S -s 'false'

As you can see, there is no & anymore in the string, nor any other character that is not allowed. I still can't get it to work though. Could you test on your end if you are seeing the same behaviour. As said before these URL's are monitored in automated way. I can adjust my scripts to replace & with $USER10$, but I cannot put every URL we need to monitor in resource.cfg....

[tgriep]

Try escaping the ampersand with another ampersand like this && and see if that works for you.

[WillemDH]

As this whole url monitoring thing was becoming a bit too overcomplicated, we decided to make a simple webpage containing several divs linking to the complex and long URL's. We let Nagios check the content on the simple URL overview page.
Just want to give my opinion => The whole URL monitoring capabilities of Nagios are really overcomplicated. I experienced myself several times the natural reactions of people when I tell them some characters prevent the usual way of using check_http to work properly. This should really be simplified imho. An ampersand is something often seen in URL's and URL monitoring is a basic feature. Issues and overcomplicated setups like this really scare people away from Nagios looking for more simple (and existing) alternatives.

[tmcdonald]

This has to be an issue either with XI/CCM removing/changing things, or Core, or possibly bash. I just took your string:

Code: Select all

/sparql?default-graph-uri=&query=prefix+schema:+%3Chttp://schema.org/%3E%0D%0AASK+%7B%0D%0A%7B%0D%0A?loc+%3Chttp://stad.gent/data/internal/resourceId%3E+?id;%0D%0A%3Chttp://stad.gent/data/internal/resourceType%3E+?type.%0D%0A%0D%0AFILTER+(?id+=+%22%22)%0D%0A%7D%0D%0AUNION+%0D%0A%7B%0D%0A?loc+%3Chttp://stad.gent/data/internal/resourceId%3E+?id;%0D%0A%3Chttp://stad.gent/data/internal/resourceType%3E+?type.%0D%0A%0D%0AFILTER+(?type+=+%22%22)%0D%0A%7D%0D%0A%7D&format=text/html&timeout=0&debug=on

and broke it down into unique, non-alpha non-numeric characters:

Code: Select all

[root@localhost libexec]# echo '/sparql?default-graph-uri=$USER10$query=prefix+schema:+%3Chttp://schema.org/%3E%0D%0AASK+%7B%0D%0A%7B%0D%0A?loc+%3Chttp://stad.gent/data/internal/resourceId%3E+?id;%0D%0A%3Chttp://stad.gent/data/internal/resourceType%3E+?type.%0D%0A%0D%0AFILTER+(?id+=+%22%22)%0D%0A%7D%0D%0AUNION+%0D%0A%7B%0D%0A?loc+%3Chttp://stad.gent/data/internal/resourceId%3E+?id;%0D%0A%3Chttp://stad.gent/data/internal/resourceType%3E+?type.%0D%0A%0D%0AFILTER+(?type+=+%22%22)%0D%0A%7D%0D%0A%7D$USER10$format=text/html$USER10$timeout=0$USER10$debug=on' | sed -e 's/[a-zA-Z0-9]//g' | sed 's/\(.\)/\1\n/g' | sort | uniq

=
-
;
:
?
/
.
(
)
$
%
+

I then built a check_http parameter that includes all of those at least once:

Code: Select all

[root@localhost libexec]# ./check_http -H "www.google.com" -u "/humans.txt?hello=true&world=false&foo=-;:()$%20+" --verbose
GET /humans.txt?hello=true&world=false&foo=-;:()$%20+ HTTP/1.1
User-Agent: check_http/v2.0.3 (nagios-plugins 2.0.3)
Connection: close
Host: www.google.com
Accept: */*


http://www.google.com:80/humans.txt?hello=true&world=false&foo=-;:()$%20+ is 632 characters
STATUS: HTTP/1.1 200 OK
**** HEADER ****
Vary: Accept-Encoding
Content-Type: text/plain
Date: Thu, 14 Apr 2016 19:33:55 GMT
Expires: Thu, 14 Apr 2016 19:33:55 GMT
Cache-Control: private, max-age=0
Last-Modified: Tue, 11 Mar 2014 22:11:10 GMT
X-Content-Type-Options: nosniff
Server: sffe
X-XSS-Protection: 1; mode=block
Accept-Ranges: none
Connection: close
**** CONTENT ****
Google is built by a large team of engineers, designers, researchers, robots, and others in many different sites across the globe. It is updated continuously, and built with more tools and technologies than we can shake a stick at. If you'd like to help us out, see google.com/careers.

HTTP OK: HTTP/1.1 200 OK - 632 bytes in 0.108 second response time |time=0.107797s;;;0.000000 size=632B;;;0

Handled it like a champ. Google is probably scratching their heads at the request, but check_http took it without issue.

So at least that removes check_http from the suspect list (assuming I tested this properly, feel free to point out any mistakes). My next thought is more likely XI than Core, and more likely Core than bash. I'll rule out bash for the time-being since it handled the above command just fine, and I'll rule out Core simply because PHP is more likely than C to have these sorts of issues.

Unfortunately without giving this the attention of a dev I don't have any further answers. I'm basing this entirely on my own testing above, so there might be some intricacies of the usage of quotes, backslashes, etc. that make your use case fail in XI.

UPDATE: This recent post from @eloyd somewhat confirms my theory: https://support.nagios.com/forum/viewtopic.php?t=38002

[WillemDH]

Could very well be related Trevor. If you make a bug report I'm ok with closing this up. I'll read along with https://support.nagios.com/forum/viewtopic.php?t=38002

Less of a priority for me atm as I have my workaround and working on some other things.. But this should definitely get investigated..

[ssax]

Did you already run your URL through a URL encoder and try it?

http://meyerweb.com/eric/tools/dencoder/

[tmcdonald]

I'm going to keep this thread pinned to my browser while the one I referenced with @eloyd plays out. I will likely end up filing a single BR for both if it turns out to be the same issue (which I believe will be the case).

[tmcdonald]

@WillemDH we're doing some testing on our end and I took my example from my earlier post and noticed that my semi-colon messed things up since it's a comment character in Core apparently - Can you try replacing yours with %3B and trying that?

[WillemDH]

Trevor, I'm using a workaround for this. very short on time lately, for me this thread can be closed. Thanks for your time and effort.