Re: Configuration write failed - Dataset not found - Please help

[mmestnik]

I think postgressql is where these configs are stored. What is the problem you are having again? I thought it was that the config was failing to load because of a host that referenced a template that didn't exist anymore.

The error you are getting is for database connection issues.

[edgeweb]

Here is the basic issue right now:

If I use the "Write Config Files" link from the menu in the Core Config Manager to "Write monitoring data", "Write additional data" and then "Check configuration files" I get:

Code: Select all

Total Warnings: 0
Total Errors: 0

Things look okay - No serious problems were detected during the pre-flight check 

But, if I go to the "Apply Configuration" link from the Core Config Manager, and click on "Apply Configuration" I get:

Code: Select all

 * Command submitted for processing...
    * Waiting for configuration verification..........
    * Configuration verification failed.

When I view the snapshot logs THEN I get the error about the definition not being found:

Code: Select all

Error: Template 'generic_host' specified in host definition could not be not found (config file '/usr/local/nagios/etc/hosts/ewhserver840.edgewebhosting.net.cfg', starting on line 14)
   Error processing object config files!

If I download the tar.gz file next to the error and then look at the hosttemplates.cfg, all it has in it is the NagiosQL header and footer, but no config content, even though when I look in the configuration using the interface, the host templates do exist:

hosttemplates.PNG

If I look at the "Config Manager Log" link under the "Config Manager Admin" section of the Core Config Manager, there are entries for "Configuration successfully written: <config name>". On the second page of the log entries, I see a lot of "Configuration write failed - Dataset not found" errors.

Thanks,

Dave

[edgeweb]

Any movement on this?

Thanks,

Dave

[tonyyarusso]

If I download the tar.gz file next to the error and then look at the hosttemplates.cfg, all it has in it is the NagiosQL header and footer, but no config content, even though when I look in the configuration using the interface, the host templates do exist:

I don't know if it's relevant, but I find it slightly odd that you have "generic-host" and "generic_host" - current releases include "generic-host" and "xiwizard_generic_host".

[tonyyarusso]

Could you recap for me which things started working again after you addressed the HTTP port issue? I'm not clear yet what was broken and is still broken, what was broken and is now fixed, and if any, what was fine and is now broken, across the time boundary of that change.

[tonyyarusso]

Hey Dave, you could tell us which release/revision of XI you're running?

[edgeweb]

Hey Tony,
The "generic_host" is from the import of our configuration from our Nagios Core install.

As for the timeline, here goes:
1. We installed an SSL certificate for the XI server (which included mod_ssl, should that be relevant).
2. Changes were made to the Apache configuration to only allow SSL connections, and only from certain hosts namely:
the "Listen 80" line of the httpd.conf was commented out
allow/deny directives were changed from Allow from all to Deny from all with Allows to localhost and another range. This was done in the httpd.conf, nagios.conf, nagiosql.conf, nagiosxi.conf as well as uncommenting the "SSLRequireSSL" line in the nagios conf files.
3. After the changes, the configuration for Nagios was changed (added a host and 2 services)
4. Attempted to apply the configuration which failed, or at least kept adding more and more dots but never returned anything. Reviewing the snapshots it appeared the submission was never made.
5. Uncommented the "Listen 80" line in httpd.conf as well as the SSLRequireSSL line
6. Submitted an immediate check for a service which had been alarming, which submitted, was checked and returned to OK status.
7. Attempted to apply the configuration again, still failed.
8. Started this thread and have tried the different things listed in here.
9. Still no "apply configuration" love
10. Updated XI today to 2009R1.1H
11. Still no "apply configuration" love

So my current release/revision is Nagios XI 2009R1.1H.

Thanks,

Dave

[admin]

I would bet that the problem is the result of disabling port 80 for Apache. Not sure why re-enabling it didn't resolve things.

FYI, when you click the "Apply Configuration" button, XI submits a task that is (shortly thereafter) executed by a cron job. That cron job task does a number of things, including running a script that exports the NagiosQL configuration. That script does the export by using wget to access the NagiosQL interface (over port 80) using GET requests.

The PHP script that does that is located here:

Code: Select all

/usr/local/nagiosxi/scripts/nagiosql_exportall.php

[edgeweb]

Ok, so after clicking on the "Apply Configuration" button here is what I am seeing in my Apache logs:

Code: Select all

127.0.0.1 - - [08/Apr/2010:16:27:20 -0400] "POST /nagiosql/index.php HTTP/1.0" 302 1027 "-" "Wget/1.11.4 Red Hat modified"
127.0.0.1 - - [08/Apr/2010:16:27:20 -0400] "POST /nagiosql/index.php HTTP/1.0" 302 1027 "-" "Wget/1.11.4 Red Hat modified"
127.0.0.1 - - [08/Apr/2010:16:27:21 -0400] "POST /nagiosxi/backend/ HTTP/1.1" 200 690 "-" "BinGet/1.00.A (http://www.bin-co.com/php/scripts/load/)"
127.0.0.1 - - [08/Apr/2010:16:27:22 -0400] "POST /nagiosxi/backend/ HTTP/1.1" 200 690 "-" "BinGet/1.00.A (http://www.bin-co.com/php/scripts/load/)"
127.0.0.1 - - [08/Apr/2010:16:27:23 -0400] "POST /nagiosxi/backend/ HTTP/1.1" 200 690 "-" "BinGet/1.00.A (http://www.bin-co.com/php/scripts/load/)"
127.0.0.1 - - [08/Apr/2010:16:27:21 -0400] "POST /nagiosql/admin/verify.php HTTP/1.0" 200 7150 "-" "Wget/1.11.4 Red Hat modified"
127.0.0.1 - - [08/Apr/2010:16:27:24 -0400] "POST /nagiosxi/backend/ HTTP/1.1" 200 690 "-" "BinGet/1.00.A (http://www.bin-co.com/php/scripts/load/)"
127.0.0.1 - - [08/Apr/2010:16:27:24 -0400] "POST /nagiosql/admin/verify.php HTTP/1.0" 200 7400 "-" "Wget/1.11.4 Red Hat modified"
127.0.0.1 - - [08/Apr/2010:16:27:25 -0400] "POST /nagiosxi/backend/ HTTP/1.1" 200 690 "-" "BinGet/1.00.A (http://www.bin-co.com/php/scripts/load/)"
127.0.0.1 - - [08/Apr/2010:16:27:26 -0400] "POST /nagiosxi/backend/ HTTP/1.1" 200 690 "-" "BinGet/1.00.A (http://www.bin-co.com/php/scripts/load/)"
127.0.0.1 - - [08/Apr/2010:16:27:27 -0400] "POST /nagiosxi/backend/ HTTP/1.1" 200 717 "-" "BinGet/1.00.A (http://www.bin-co.com/php/scripts/load/)"
127.0.0.1 - - [08/Apr/2010:16:27:32 -0400] "POST /nagiosxi/backend/ HTTP/1.1" 200 817 "-" "BinGet/1.00.A (http://www.bin-co.com/php/scripts/load/)"

Thanks,
Dave

[edgeweb]

Ok, I think I may have found the issue, or at least a fix:

I was looking through the cron scripts and the export script you mentioned, and by an odd twist of fate I accidentally ran one (export_nagiosql.sh). Here was the output:

Code: Select all

--2010-04-08 17:57:38--  http://localhost/nagiosql/index.php
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://localhost/nagiosql/admin.php [following]
--2010-04-08 17:57:38--  https://localhost/nagiosql/admin.php
Connecting to localhost|127.0.0.1|:443... connected.
ERROR: certificate common name `<myhostname>' doesn't match requested host name `localhost'.
To connect to localhost insecurely, use `--no-check-certificate'.
Unable to establish SSL connection.
CMDLINE:
/usr/bin/wget --load-cookies=nagiosql.cookies http://localhost/nagiosql/admin/verify.php --post-data 'writeMonitoring=Go' -O nagiosql.export.monitoring
--2010-04-08 17:57:38--  http://localhost/nagiosql/admin/verify.php
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 7150 (7.0K) [text/html]
Saving to: `nagiosql.export.monitoring'

Looking at the log entries I posted above, the 302 redirect makes sense, it was a redirect to HTTPS, but as the wget client refused to connect with the invalid cert (well, valid cert, but not for 'localhost'), there were no traces of it in the Apache logs.
I checked my Apache configs for any redirect i may have put in there, but nothing. So I went through the NagiosQL code and found:

Code: Select all

header("Location: ".$SETS['path']['protocol']."://".$_SERVER['HTTP_HOST'].$SETS['path']['root']."index.php");

So that explains the redirect. Checking the tbl_settings for the nagiosql db, the ['path']['protocol'] was set to "https". That's when I realized that I had changed another setting (referenced in http://support.nagios.com/forum/viewtop ... t=SSL#p765), which I had forgotten about. On the "Config Manager Settings" page I had set the Server protocol to "https". I changed it back to "http", saved it, and did an "Apply Configuration":

Code: Select all

    * Command submitted for processing...
    * Waiting for configuration verification..................................
    * Configuration applied successfully.

Success! Nagios Core was restarted with an updated configuration.

Sweet.

To be sure, I added a new host, applied the config again, and waited for the check. Went through just fine.

So it looks like it is fixed.

Thanks guys!

Dave