create service without GUI

[lmiltchev]

I don't understand why you are looking for a different way to "copy files" over, when the restore script does it all for you. You can backup and restore from the command line - there is no need to be using the GUI...

Example:

Code: Select all

# Create a backup on the "old" server
/usr/local/nagiosxi/scripts/backup_xi.sh

# Copy the backup over to the "new" server
scp /store/backups/nagiosxi/xxx.tar.gz [email protected]:/store/backups/nagiosxi/

# Restore from the backup on the new server
/usr/local/nagiosxi/scripts/restore_xi.sh /store/backups/nagiosxi/xxx.tar.gz

[hzsoliel]

I don't have a source to backup. In addition, if my Nagios versions are different, backup and restore won't work.

[lmiltchev]

I don't have a source to backup.

Can you elaborate on that? What do you mean? If you had an old XI instance, running the command below on it would create the "source" (backup):

Code: Select all

/usr/local/nagiosxi/scripts/backup_xi.sh

and place it in the "/store/backups/nagiosxi/" directory. Then you can move the backup to the new server, and restore from it.

Keep in mind that not everything is in config files, so you cannot just "copy over" the files. There are things in the database, e.g. users, dashboards, etc. You need to use the backup/restore scripts in order to be able to migrate from one system to another.

In addition, if my Nagios versions are different, backup and restore won't work.

We do not recommend restoring to a different OS/architecture, and/or restoring a different version of Nagios XI, but it is doable. It's not going to be a very easy (smooth) migration though.

[hzsoliel]

I don't have source which is exactly the same as my destination. Suppose, in my application, there are more than 30 target hosts ( 2 database servers, 2 portal server, 16 conference servers etc ) which work together. In development environment, the target hosts have different names and IPs from those in staging, pre-prod and production. If I want to copy configuration from the development to the staging, pre-prod and production, the hostnames and IPs are different. In the development, my database servers are named devldb1 and devldb2, but in the production, they are proddb1 and proddb2. It's the same in other environemnt. The import and restore won't work.

[lmiltchev]

If you wanted to have the "same" configuration on the "new" server as on the "old" one, but your IPs and hostnames were different, then you would need to come up with a script, that would "bulk mod" your configs before copying them over to the import directory, and running reconfigure_nagios.sh. There is no mechanism to do this "out-of-the-box" in Nagios XI at the moment.

[hzsoliel]

That is exactly what I'm looking for. Suppose that I have backup file from the development which is a zip file, how do I modify it and restore it into another environment?

[lmiltchev]

As I previously said, this functionality doesn't exist. If you were restoring from a backup using our recommended procedure, you would basically end up with a "cloned" environment. If you needed to change the IPs and/or hostnames in the process, you would need to come up with a custom solution, since this is NOT supported.

[bomahony]

@hzsoliel

Just to give you a heads up, what we do with ansible for the client nodes is deploy nrpe rpm & configs & checks via ansible, and then use the rest api to register itself into the hostgroup.
For the monitoring server we deploy the cfg files for services, hostgroups, commands etc via ansible to the mon-node, and as part of the ansible play run the import.
Note: Thee is currently a bug in the way it imports service checks - if you are using a hostgroup method, as we are, it will import the service checks every time. Currently we just move the cfg files out. This will be fixed in v5.6 I believe.

[lmiltchev]

Thanks for the feedback, @bomahony! Using the REST API gives you more flexibility/options. @hzsoliel mentioned they didn't want to use REST API, so I suppose, they are going to be looking into some custom solution, that doesn't utilize the Nagios XI REST API.

[bomahony]

No worries. My thought here would be:
He is probably running ansible to deploy remote checks/cfgs anyways.
The rest API only needs to be accessible from the ansible control node. If security is an issue, API keys and access can be restricted to ansible-vault and the ansible machine.
But if he can't use the API then you could use ansible loops & jinja templates to create a hosts.cfg config file as part of the check/cfg plays using the ansible_hostname var, and deploy that to import via ansible also.