Nagios Support Forum

Just to verify, did you use the import prep tool on each file to prepare them to be imported into NagiosQL?

I'm not sure what differences there are in the config files from Nagios 2.X to 3.x, but it's entirely possible that's why you're seeing unexpected results. You're welcome to send us a configuration snapshot and we can take a look at them.

Hi,
I used the prep tool to go through every config file individually.

I am going to send you the hosts.cfg file that I import in that generates the duplicates. My guess is that some hosts are referenced twice in various places. so you can probably see that some hosts have parent hosts and I am thinking that the import thinks that this is another host.

We'll take a look at the config files when they arrive, and we'll also look at maybe doing a remote session sometime next week. The import from 2.7 might present some unique issues that we haven't seen before and I think that will be the quickest solution.

Hi,
Sorry I hadn't replied, I have been on training for the past week. I would very much like that. Let me know which day suits this week and what time is good for you. I will send you through the config via email.
THanks,
Rob

(sent this reply to email as well, you only need to reply to one).

I'm looking at your configuration files, and I don't see any obvious issues.

Do you by chance have your original configuration files located in your import directory as well as these prepped files? If so Nagios xi would also attempt to import them, but the sync failure would explain why you're not seeing duplicates in the xi tables.

Hi i am happy to reply here.
I can confirm there is nothing in the import directory.

Let me know when is a good time this week to do a remote session. I would prefer it to be early morning your time as it's probably going to be early morning for me if we were to do it at other times.

Thanks.

Ok, sent you a Private Message (PM) with some possible times.

Hello thanks again for the help today.

I have done some tests with a small number of hoses just to show how it behaves.
so I imported exactly the same way as I have before, but instead of importing the normal hosts file I imported this file below.
#####Hosts_test.cfg##########
define host{
host_name 11_router
use Networking_Template
alias NCS GC
address 132.234.11.209
hostgroups Network_Routers_Lan/WAN
}
define host{
host_name anu-3
use Unix_Prod_Template
alias anu-3
address 132.234.250.45
parents 250_router
hostgroups Container_Hosts_Prod
}
define host{
host_name apollo
use Unix_Prod_Template
alias vdx production server
address 132.234.250.144
parents 250_router, anu-3
hostgroups Containers_Prod
}

And this is how it showed up in the ccm
As you can see it's creating duplicates from the parent entry.

Well the good news on this is that the problem is identified and confirmed. There is a confirmed bug in the import script where it will create a table entry for a host if it's listed as a parent, but doesn't currently exist in the table. That's why the results weren't very consistent each time we ran the import.

The bad news is that doesn't actually "solve" your current import issue. Until we create a fix in the code, you could run the configs from the static directory for now. Or you could do a string replacement that removed the parent config, but then you'd have to rebuild your heirarchy. I'll see what I can find out as far how ugly it's going to be to make a code patch, but let me know what you'd prefer to do for your current import process.

In doing a little more research on this, it sounds like the "dummy" entries are somewhat by design in the import process, since that's the only way to create a valid relation if the entry isn't there. The inactive entries are used like pointers for those particular configs. On my small scale tests, it looks like a valid config still gets written to file. How does it look on your end when you run the full import, will the configuration verify?