[Core 4.0.8] - RHEL 6.

[ssax]

Have you tried reinstalling glibc-common to see if it's an issue with your locales?

Code: Select all

yum reinstall glibc-common

[jolson]

I have done further testing and cannot get your symptoms to reproduce on my end:

Code: Select all

[root@nagioscore ~]# curl -ns -u nagiosadmin:pass --header "Accept-Language: fr" "http://nagioscore/nagios/cgi-bin/statusjson.cgi?query=programstatus" |grep type_text
    "type_text": "Success",
[root@nagioscore ~]# curl -ns -u nagiosadmin:pass --header "Accept-Language: fr-FR" "http://nagioscore/nagios/cgi-bin/statusjson.cgi?query=programstatus" |grep type_text
    "type_text": "Success",

I have a suspicion that ultimately we'll need to recompile Nagios on this machine and ensure that locales are properly set before the compilation begins. Please follow the suggestion made by ssax, and let us know if that helps.

My next suggestion is to use the following CentOS iso to build out your machine, if possible:
http://mirror.tocici.com/centos/6.6/iso ... inimal.iso

Disable selinux off of the bat, and follow the installation instructions provided by Box293.
http://sites.box293.com/nagios/guides/i ... centos-6-5

[shadowwisps]

Have you tried reinstalling glibc-common to see if it's an issue with your locales?

Code: Select all

yum reinstall glibc-common

No change with that unfortunately.
All base packages + nagios requirements have already been reinstalled, no change

[shadowwisps]

I have done further testing and cannot get your symptoms to reproduce on my end:

Code: Select all

[root@nagioscore ~]# curl -ns -u nagiosadmin:pass --header "Accept-Language: fr" "http://nagioscore/nagios/cgi-bin/statusjson.cgi?query=programstatus" |grep type_text
    "type_text": "Success",
[root@nagioscore ~]# curl -ns -u nagiosadmin:pass --header "Accept-Language: fr-FR" "http://nagioscore/nagios/cgi-bin/statusjson.cgi?query=programstatus" |grep type_text
    "type_text": "Success",

I have a suspicion that ultimately we'll need to recompile Nagios on this machine and ensure that locales are properly set before the compilation begins. Please follow the suggestion made by ssax, and let us know if that helps.

Well, no issues doing that, but my incompetence level is below making locale checks before a compilation..

Also, all our unix/linux systems are managed by a dedicated team, so no option to run a different OS.
I checked SElinux before the installation, if was already off

My best bet here (unless someone has better recommendations over the weekend) will be to get this server rebuilt from scratch, and go through some extensive pre-flight checks to make sure that the basis before Nagios even hits the deck are all OK.

If anyone has the time to make that list or point me somewhere where it already exists (on top of both box's and the default tutorials whose bases i've already covered), I would be very grateful.

Cheers

[jolson]

In addition to what you've already stated, I would run through this and make sure your locales are all proper:
https://sites.google.com/site/syscookbo ... ocale-lang

Other than that, you should be good to compile. I look forward to your results!

[shadowwisps]

Right, I have found what was breaking this, and if it is not definitely a bug with Nagios, it is at least an issue with the config checker.

In one of my config files (pretty much migrated as such from a 3.0.6 box), I had the following line

Code: Select all

retry_check_interval   0.5                             ; Re-check the service every minute until its final/hard state is determined

Commenting and replacing with

Code: Select all

retry_check_interval    1

solved the issue

I haven't checked all the release notes about decimal value handling, and it makes sense that this would cause issue with the locales as the decimal character might vary between dot (.) and comma (,), but if this kind of think breaks the CGIs (phps seemed to be running fine) then I think it should be included in the config checker!

Edit: Side note for reference, here is the locale on the other box, identical..:

Code: Select all

[PROD][root@eqdg3pperf001 ~]# locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

However, the old box was running RHEL 5 and a slightly older version of apache

Code: Select all

[PROD][root@eqdg3pperf001 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.11 (Tikanga)
[PROD][root@eqdg3pperf001 ~]# httpd -v
Server version: Apache/2.2.3
Server built:   Jul 18 2014 04:46:39

Edited for syntax/spelling/clarity

[jolson]

I have submitted a bug report regarding this problem, and hopefully we can get this patched in as part of the configuration verification process. I appreciate the time you took in figuring this out - I'm sure this thread will save someone a lot of pain in the future. If you have no further questions, would it be alright if I locked this port?

[shadowwisps]

Sure, go ahead !

Thanks for the insights along the way

Woudl be grateful for the exact root cause if anyone does ever get around to looking into in more depth.

[jolson]

No problem. If I am given the testing role for this bug, I will follow up with you via PM. Thanks again shadowwisps!