SSI problem

[pepe_carlos]

Finally i decided modified the extinfo.c directly and not use the ssi files

Thank you for your support

[millisa]

Just some quick input - I believe pepe_carlos is referring to the Custom CGI Headers and Footers
and that 'ssi' name in the directory might be misdirecting things here.

On a Redhat6.5/CentOS6.5 system, if you install nagios from the EPEL rpm's, your apache nagios config usually ends up at /etc/httpd/conf.d/nagios.conf
and will looks something like this:

Code: Select all

ScriptAlias /nagios/cgi-bin/ "/usr/lib64/nagios/cgi-bin/"

<Directory "/usr/lib64/nagios/cgi-bin/">
#  SSLRequireSSL
   Options ExecCGI
   AllowOverride None
   Order allow,deny
   Allow from all
#  Order deny,allow
#  Deny from all
#  Allow from 127.0.0.1
   AuthName "Nagios Access"
   AuthType Basic
   AuthUserFile /etc/nagios/passwd
   Require valid-user
</Directory>

Alias /nagios "/usr/share/nagios/html"

<Directory "/usr/share/nagios/html">
#  SSLRequireSSL
   Options None
   AllowOverride None
   Order allow,deny
   Allow from all
#  Order deny,allow
#  Deny from all
#  Allow from 127.0.0.1
   AuthName "Nagios Access"
   AuthType Basic
   AuthUserFile /etc/nagios/passwd
   Require valid-user
</Directory>

The important bit for the CGI Headers and Footers is that 'alias' line and the /usr/share/nagios/html section - that may be a different location than the Ubuntu install. This indicates where the nagios web files live and the /ssi directory lives beneath it. Verify on your RedHat install that you are in the directory as defined in your httpd.conf or nagios.conf (wherever you have your nagios directory defined). It is quite likely different than an Ubuntu install, or a source install if you are using a packaged nagios (such as the one from EPEL).

If you put a /usr/share/nagios/html/ssi/extinfo-footer.ssi file there that has the content

Code: Select all

<p>IT IS A TEST </p>

That information will get included in the next load of the http://nagios-server-ip/nagios/cgi-bin/extinfo.cgi?querystringstuff before the closing body tag and does not require any changes to the Options section in the httpd conf (and in this case nagios.conf). The extinfo.cgi is just including the contents of the file above before the body tag in the rendered output.

For this example, I have just now created a bare Centos6.5 system, installed the EPEL repository, and installed a clean nagios 3.5.1 from it and tested added an extinfo-footer.ssi with the above nagios.conf and it works (no options lines changed). I have also used a compiled nagios 4.0.2 install on a bare Centos6.5 system and verified it continues to work as documented for that version as well. Redhat6.5 is functionally equivalent to Centos6.5 in this context.

Until you can get a simple text string in that ssi file being included in your rendered output in the web interface, it's best not to try getting dynamic content to be included (I'll go over how to do dynamic content at the end of the post, don't skip to it).

Now, as for the second issue of placing

Code: Select all

<!--#echo var="DATE_LOCAL" -->

into one of the custom header/footer files, that would be trying to include SSI code that'd require server side includes to work on the .cgi files.

This is mixing two issues - On the given Ubuntu test, only a

Code: Select all

<p>IT IS A TEST </p>

appears to have been tested and shown working, not trying to use actual SSI in the file, which I expect does not work on the Ubuntu install.


The important bit from the documentation is likely this:
It is important to note that, unless they are executable, custom header and footer files are not pre-processed in any way before they are displayed. The contents of the header and footer include files are simply read and displayed in the CGI output. That means they can only contain information a web browser can understand (HTML, JavaScript, etc.).
That does not indicate that actual server side includes will work in these files, despite the directory name and the extensions. Only that files that are marked executable will be pre-processed. If you want execution of those files, you've got to write them in a way that it can render output ready made for a browser.

Adding that SSI code into the extinfo-footer.ssi *does* include that bit into the rendered cgi if the file is just readable, but if you look in the source of an extinfo.cgi page load, you'll just find it above the 'produced by nagios' comment that sits above the body close:
Source output of a rendered page when the extinfo-footer.ssi is 644:

Code: Select all

</TD>
</TR>
</TABLE>
</DIV>
<!--#echo var="DATE_LOCAL" -->

<!-- Produced by Nagios (http://www.nagios.org).  Copyright (c) 1999-2007 Ethan Galstad. -->
</body>
</html>

If you set that ssi file to be executable, instead what you end up with is something similar to this in the apache errorlog when you try to load the page:

Code: Select all

[Thu Jan 23 03:06:01 2014] [error] [client 192.168.176.64] /usr/share/nagios/html/ssi/extinfo-footer.ssi: line 1: syntax error near unexpected token `newline', referer: http://192.168.176.43/nagios/cgi-bin//extinfo.cgi?type=2&host=localhost&service=Current+Load
[Thu Jan 23 03:06:01 2014] [error] [client 192.168.176.64] /usr/share/nagios/html/ssi/extinfo-footer.ssi: line 1: `<!--#echo var="DATE_LOCAL" -->', referer: http://192.168.176.43/nagios/cgi-bin//extinfo.cgi?type=2&host=localhost&service=Current+Load

and it looks like nothing happens on the nagios page.

The reason for this is the extinfo-footer.ssi file is getting executed on the server before the cgi renders its output - what you are seeing in the error_log is the output that you'd see from the shell if you ran the file by hand:

Code: Select all

[root@nagiostestC ssi]# ./extinfo-footer.ssi
./extinfo-footer.ssi: line 1: syntax error near unexpected token `newline'
./extinfo-footer.ssi: line 1: `<!--#echo var="DATE_LOCAL" -->'

However, don't despair, the alternate solution is even niftier! What you *can* do is put perl in those ssi files (and probably C, or ruby, or fortran, or basic). You aren't limited to just what SSI can do, your file just needs to be executable from the command line and deliver browser-ready output.
So, instead of

Code: Select all

<!--#echo var="DATE_LOCAL" -->

You can put your own little bit of custom perl into that extinfo-footer.ssi:

Code: Select all

#!/usr/bin/perl
#
#
use strict;
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);

print eval($year+1900) . '-' . eval($mon+1) . '-' . $mday . ' ' . $hour . ':' . $min . ':'  . $sec ."\n";

exit(0);

The code needs to be executable to the web user:

Code: Select all

chmod 755 /usr/share/nagios/html/ssi/extinfo-footer.ssi 

(keep in mind who has access to the shell on your server before doing this)

And should be runnable from the command line:

Code: Select all

[root@nagiostestC ssi]# /usr/share/nagios/html/ssi/extinfo-footer.ssi
2014-1-23 3:9:59

(excuse the ugly looking date format, I'd probably insert zeros in front of the single digit numbers to make it look more like a standard date).
That output could be img tags, or java script, or adverts (you evil person), or popunders for zombocom (you very evil person) - as long as it's all ready for the browser to process it, you should be good.

Now, the nagios page will dynamically generate a date in the extinfo footer, using whatever the output of the 'ssi' file gives, just like shows from the command line.
See:

nagios-3.5-included-datefooter

Relevant html source code of above image:

Code: Select all

</TD>
</TR>
</TABLE>
</DIV>
2014-1-23 3:29:31

<!-- Produced by Nagios (http://www.nagios.org).  Copyright (c) 1999-2007 Ethan Galstad. -->
</body>

So if you can do it in perl, you can dynamically generate that footer you want. Or use some other heathen language that's cropped up in the last decade or two.

For funsies, a ruby example extinfo-footer.ssi

Code: Select all

#!/usr/bin/ruby
#
#
time = Time.new
puts "Current time: " + time.inspect

Run from the cli:

Code: Select all

[root@nagiostestC ssi]# ./extinfo-footer.ssi
Current time: Thu Jan 23 03:55:52 -0600 2014

And screen shot of it getting dynamically added to an extinfo.cgi page load:

nagios-3.5-included-datefooter-ruby

So, the short answer is you don't put traditional 'SSI' in those included header/footer files despite the misleading directory name and file extension. You put non executable html in non executable files, or you put executable code in executable files that can stand alone and get processed before the output is handed over to the web client. Apache isn't re-processing the cgi output a second time after it renders the cgi output looking for server side includes (at least I've never seen it work that way since nagios2…). None of this should require enabling traditional web SSI includes in the apache config, it only requires making the files in that ssi dir readable or executable depending on what you are putting in them. Hopefully this clears up some of the confusion!

[millisa]

Finally i decided modified the extinfo.c directly and not use the ssi files

Unless you want to make the change every time you update nagios, you really don't want to do that...
If you are comfy modifying C and recompiling, you'll be more than comfy putting your dynamic code in the ssi files!
I wish I'd gotten my post in a little earlier for you, give it another shot!

[pepe_carlos]

Thanks milisa for your support.

In Red Hat server where it is installed nagios doesn't have the EPEL respository, the repositories used for nagios prerequisites are the official of Red Hat, but without the optional repositories packages.

The Nagios is instaled from tar http://prdownloads.sourceforge.net/sour ... 5.1.tar.gz

In the apache log doesn't appear any error referred to ssi files.

I test with the 666 permisions and 644 in ssi and the result is the same (doesn't work).

The nagios.conf from /etc/httpd/conf.d is this:

Code: Select all

<Directory "/usr/local/nagios/sbin">
#  SSLRequireSSL
   Options ExecCGI
   AllowOverride None
   Order allow,deny
   Allow from all
#  Order deny,allow
#  Deny from all
#  Allow from 127.0.0.1
   AuthName "Nagios Access"
   AuthType Basic
   AuthUserFile /usr/local/nagios/etc/htpasswd.users
   Require valid-user
</Directory>

Alias /nagios "/usr/local/nagios/share"

<Directory "/usr/local/nagios/share">
#  SSLRequireSSL
 #  Options None
Options Includes
   AllowOverride None
   Order allow,deny
   Allow from all
#  Order deny,allow
#  Deny from all
#  Allow from 127.0.0.1
   AuthName "Nagios Access"
   AuthType Basic
   AuthUserFile /usr/local/nagios/etc/htpasswd.users
   Require valid-user
</Directory>

The html code in ssi files is static content, the test of shtml was only a test.

The solution of compile again the extinfo.c with the new code is the better option that i found to solve it.

[millisa]

I have created another, fresh CentOS 6.5 install, this time did not install any additional repositories.
Following the instructions in the nagios 3 quick start for fedora with the linked 3.5.1 source you provided.

My /etc/httpd/conf.d/nagios.conf looks like yours (but without the modifications for Options Includes):

Code: Select all

# SAMPLE CONFIG SNIPPETS FOR APACHE WEB SERVER
# Last Modified: 11-26-2005
#
# This file contains examples of entries that need
# to be incorporated into your Apache web server
# configuration file.  Customize the paths, etc. as
# needed to fit your system.

ScriptAlias /nagios/cgi-bin "/usr/local/nagios/sbin"

<Directory "/usr/local/nagios/sbin">
#  SSLRequireSSL
   Options ExecCGI
   AllowOverride None
   Order allow,deny
   Allow from all
#  Order deny,allow
#  Deny from all
#  Allow from 127.0.0.1
   AuthName "Nagios Access"
   AuthType Basic
   AuthUserFile /usr/local/nagios/etc/htpasswd.users
   Require valid-user
</Directory>

Alias /nagios "/usr/local/nagios/share"

<Directory "/usr/local/nagios/share">
#  SSLRequireSSL
   Options None
   AllowOverride None
   Order allow,deny
   Allow from all
#  Order deny,allow
#  Deny from all
#  Allow from 127.0.0.1
   AuthName "Nagios Access"
   AuthType Basic
   AuthUserFile /usr/local/nagios/etc/htpasswd.users
   Require valid-user
</Directory>

Adding the following file at /usr/local/nagios/share/ssi/extinfo-footer.ssi

Code: Select all

#!/usr/bin/ruby
#
#
time = Time.new
puts "Current time: " + time.inspect

and setting it executable:

Code: Select all

chmod 755 /usr/local/nagios/share/ssi/extinfo-footer.ssi

testing it from the cli:

Code: Select all

root@nagiostestC ssi]# /usr/local/nagios/share/ssi/extinfo-footer.ssi 
Current time: Thu Jan 23 06:11:15 -0600 2014

appears to work as documented when hitting the web gui:

nagios-3.5.1-source-with-ssi-include

If you want this to work as intended, I would check permissions on the directories leading to the extinfo-footer.ssi file.
Running a

Code: Select all

ls -aslh /usr/local/nagios

Code: Select all

ls -aslh /usr/local/nagios/share

and

Code: Select all

ls -aslh /usr/local/nagios/share/ssi

may be useful.



Again, editing the extinfo.c seems like a good solution today, but you are setting yourself up for a maintenance headache in the long run. I can assure you that your exact version does work as documented if implemented with the instructions in the quickstart.

[pepe_carlos]

Hi Again,

I execute this and works:

Code: Select all

# /usr/local/nagios/share/ssi/extinfo-footer.ssi
Current time: Thu Jan 23 13:31:05 +0100 2014

but doesn't work in Nagios

Code: Select all

ls -aslh /usr/local/nagios
total 36K
4.0K drwxr-xr-x   9 root   root   4.0K Jan 23 13:34 .
4.0K drwxr-xr-x. 18 root   root   4.0K Jan 15 17:51 ..
4.0K drwxrwxr-x   2 nagios nagios 4.0K Jan  8 18:39 bin
4.0K drwxrwxr-x   3 nagios nagios 4.0K Jan 16 17:11 etc
4.0K drwxrwxr-x   5 nagios nagios 4.0K Jan 22 11:28 libexec
4.0K drwxrwxr-x   2 nagios nagios 4.0K Jan 22 18:37 sbin
4.0K drwxrwxr-x  17 nagios nagios 4.0K Jan 22 17:10 share
4.0K drwxrwxr-x   5 nagios nagios 4.0K Jan 23 13:34 var

Code: Select all

# ls -aslh /usr/local/nagios/share
total 740K
4.0K drwxrwxr-x 17 nagios nagios 4.0K Jan 22 17:10 .
4.0K drwxr-xr-x  9 root   root   4.0K Jan 23 13:34 ..
4.0K -rw-rw-r--  1 nagios nagios  576 Mar 17  2011 config.inc.php
4.0K -rwxr-xr-x  1 nagios nagios 1.8K May 13  2005 config.js
4.0K drwxrwxr-x  2 nagios nagios 4.0K Mar 17  2011 contexthelp
4.0K drwxrwxr-x  4 nagios nagios 4.0K Jul 17  2012 docs
4.0K drwxr-xr-x  4 nagios nagios 4.0K Sep 20  2012 images
4.0K drwxrwxr-x  3 nagios nagios 4.0K Mar 17  2011 includes
4.0K -rw-r--r--  1 nagios nagios 1.7K Sep 19 15:33 index.html
4.0K -rw-rw-r--  1 nagios nagios 1.5K Jun 17  2011 index.php
4.0K drwxrwxr-x  2 nagios nagios 4.0K Jan 16 16:46 js
4.0K drwxr-xr-x  4 nagios nagios 4.0K Oct 26  2009 locale
8.0K -rw-rw-r--  1 nagios nagios 5.8K Oct  4 10:29 main.php
4.0K drwxrwxr-x  2 nagios nagios 4.0K Oct 26  2009 media
4.0K -rw-rw-r--  1 nagios nagios   26 Mar 17  2011 robots.txt
4.0K drwxrwxr-x  2 nagios nagios 4.0K Jan 22 18:13 ssi
4.0K drwxr-xr-x  2 nagios nagios 4.0K May  9  2011 stylesheets
4.0K -rw-r--r--  1 root   root     31 Jan 22 17:07 test.shtml

Code: Select all

# ls -aslh /usr/local/nagios/share/ssi
total 36K
4.0K drwxrwxr-x  2 nagios nagios 4.0K Jan 22 18:13 .
4.0K drwxrwxr-x 17 nagios nagios 4.0K Jan 22 17:10 ..
4.0K -rwxr-xr-x  1 nagios nagios   73 Jan 23 13:28 extinfo-footer.ssi

[millisa]

Those permissions look right.
Does your nagios.conf have this at the top (or did it just get cut off in the copy/paste)?

Code: Select all

ScriptAlias /nagios/cgi-bin "/usr/local/nagios/sbin"

(I'm assuming it does, other things would look broken if it was missing)


Is your apache install from the stock distribution? (Did you install it with yum?)
Or is it also a custom compile? Does the httpd child processes run as the apache user? (I don't think this matters for a simple date test since the file is being given 755 permissions), but you could try running the command as the web user (you may need to change the shell of the web user to /bin/bash temporarily so you can su to them to try running it).
It might even better to stick with the simple include test before trying to get the dynamic code to work.
It's probably best to start by putting 'hello world' in your extinfo-footer.ssi and getting that to show up before getting the ruby/perl versions to work.

What about settings in your /usr/local/nagios/etc/cgi.cfg, specifically the physical_html_path:

Code: Select all

[root@nagiostestC ssi]# cat /usr/local/nagios/etc/cgi.cfg |grep physical_html_path
physical_html_path=/usr/local/nagios/share

Does that match the directory that has the ssi subdirectory?

I would expect there to be something in either /var/log/messages or /var/log/httpd/error_log regarding this. I did disable selinux followed by a reboot on all my bare centos test installs; I'd be surprised if that was the cause but it's worth a shot if you don't get other suggestions.

(that's probably the extent of my suggestions outside of 'start clean with no nagios setup, get the source, compile using the fedora quick start, then trying to make a simple 'helloworld' ssi file.)

[pepe_carlos]

What about settings in your /usr/local/nagios/etc/cgi.cfg, specifically the physical_html_path:

Code: Select all

# cat /usr/local/nagios/etc/cgi.cfg |grep physical_html_path
physical_html_path=/usr/local/nagios

Bingo!!!! It is the problem.

Thank you very much

[tmcdonald]

Wow, millissa. That might be one of the most in-depth replies I've seen here! Thanks for stepping in and helping out. The SSI bit did have me somewhat confused.

pepe_carlos, is it safe to close this thread now?

[pepe_carlos]

Yes, please close this thread.

Thank you to all for your support and your time.