Page 2 of 2
Re: unexpected end of file
Posted: Thu Mar 31, 2016 5:10 pm
by 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
Re: unexpected end of file
Posted: Fri Apr 01, 2016 2:31 am
by 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....
Re: unexpected end of file
Posted: Fri Apr 01, 2016 2:04 pm
by tgriep
Try escaping the ampersand with another ampersand like this && and see if that works for you.
Re: unexpected end of file
Posted: Thu Apr 14, 2016 3:15 am
by 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.
Re: unexpected end of file
Posted: Thu Apr 14, 2016 2:45 pm
by 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
Re: unexpected end of file
Posted: Thu Apr 14, 2016 3:17 pm
by 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..
Re: unexpected end of file
Posted: Thu Apr 14, 2016 5:09 pm
by ssax
Did you already run your URL through a URL encoder and try it?
http://meyerweb.com/eric/tools/dencoder/
Re: unexpected end of file
Posted: Thu Apr 14, 2016 5:10 pm
by 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).
Re: unexpected end of file
Posted: Fri Apr 15, 2016 12:39 pm
by 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?
Re: unexpected end of file
Posted: Thu Apr 28, 2016 7:20 am
by 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.