Nagios 64 bit issues?

I’m having some issues running Nagios on Fedora Core 4 SMP 64bit (2.6.15-1.1831_FC4smp). had to make sym links to /usr/local/nagios in /usr/share even though all defaults were taken in configure. Well, i got the web interface up, but now i’m getting a '[Mon Feb 20 13:49:14 2006] [error] [client 10.16.42.10] Premature end of script headers: status.cgi, referer: chileii/nagios/side.html’ error in hpptd error log. i tried hardcodeing the ‘…/lib64’ setting in configure, to no avail. anyone having similar issues?

Ah, I just posted the fix for this the other day. I too am running FC4 and had the same issue. There’s a chcon command to run in FC so that SELinux will allow the cgi’s to be run. Do a search of the forum for script headers and I’m sure you’ll find it.

searched around this site and didn’t come up with anything. shut off seLinux for Httpd, same thing.

Okay, try this then

chcon -R system_u:object_r:httpd_sys_script_exec_t /usr/local/nagios/sbin.

Got this from here:

issues.apache.org/bugzilla/show_bug.cgi?id=33504

Tried it with no luck. Thanks for the effort however. I followed the link above and the error mentioned is a ‘permission denied’, i’m getting ‘Premature end of script’ which may be different.

the reply above is from me. sorry, i forgot to login…

I found this (see below) on the Apache Website and tried it. Renamed the suexec file so it could not be found by the server (restarted of cource). Still the same issue.

Suexec
The suexec support program allows CGI programs to be run under different user permissions, depending on which virtual host or user home directory they are located in. Suexec has very strict permission checking, and any failure in that checking will result in your CGI programs failing with Premature end of script headers.

To check if you are using suexec, run apachectl -V and check for the location of SUEXEC_BIN. If Apache finds an suexec binary there on startup, suexec will be activated.

Unless you fully understand suexec, you should not be using it. To disable suexec, simply remove (or rename) the suexec binary pointed to by SUEXEC_BIN and then restart the server. If, after reading about suexec, you still wish to use it, then run suexec -V to find the location of the suexec log file, and use that log file to find what policy you are violating.

Did some more work on this issue. Found this from Apache: The most common cause of this problem is the script dying before sending the complete set of headers, or possibly any at all, to the server. To see if this is the case, try running the script standalone from an interactive session, rather than as a script under the server. If you get error messages, this is almost certainly the cause of the “premature end of script headers” message.

tried to run the status.cgi script with the environmentals above set and get a ‘segmentation fault’. i tried the same thing (running status.cgi) on my 32bit nagios instalation (1.2) and it ran fine.

anyone have any ideas?

Ah, I’m running the 32-bit version of FC4…perhaps this is why that fix is not working for you. Sorry I didn’t read your post more carefully.

i switched to nagios 1.3 and the corresponding status.cgi (after setting environmentals) from 1.3 does run manually.

however, when trying to get to the Nagios Status interface from the web, i still am getting the “premature end of script headers” message in my httpd log.

any ideas would be appreciated. does anyone have Nagios (1.x or 2.0) running on 64bit FC4?

got it to work…

what i ended up doing was to pull all of the /usr/local/nagios installs from the tar balls (1.3 and 2.0) and remove all. then i found a 2.0.x rc2 RPM for x86_64 and re-installed the RPM. basically the one that came with fc4. then i messed around with the httpd/conf.d/nagios.cfg file a bit.

it’s now running with 64 bit and no “premature end of script” messages.

go figure…

Try this.
cd /usr/local/nagios/sbin
ldd status.cgi
libc.so.6 => /lib/tls/libc.so.6 (0x0070a000)
/lib/ld-linux.so.2 (0x006f1000)

Does your output complain about “missing” or something like that? If so, then update your /etc/ld.so.conf to point to where your libs are located and then run
ldconfig