In this recipe, we'll place a Nagios Core configuration directory under version control in an attempt to keep track of the changes made to it and to enable us to reverse changes if there are problems.
You should choose an appropriate version control system. The recipe will vary considerably depending on which system you use; there are too many options to demonstrate here, so we'll use the popular open-source content tracker Git, the basics of which are very easy to use for this kind of version control and do not require an external server. However, there's no reason you can't use Subversion or Mercurial if you prefer them. You should have the client for your chosen system (git(1), hg(1), svn(1), and so on) installed on your server.
This will all work with any version of Nagios Core. It does not involve directly changing any part of the Nagios Core configuration, only keeping track of the files in it.
We can place our configuration directory under version control like so:
- Change to the root of the configuration directory. In the default installation, this is
/usr/local/nagios/etc. Run the following line:# cd /usr/local/nagios/etc - Run
git initcommand to start a repository in the current directory as follows:# git init Initialized empty Git repository in /usr/local/nagios/etc/.git/.
- Then, add all the files in the configuration directory with
git addcommand as follows:# git add . - Commit the files with
git commitcommand via the following code:# git commit -m "First commit of configuration" [master (root-commit) 6a2c605] First commit of configuration. 39 files changed, 3339 insertions(+), 0 deletions(-) create mode 100644 example/athens.example.net.cfg create mode 100644 example/ithaca.example.net.cfg create mode 100644 example/sparta.example.net.cfg ...
With this done, we should have a .git repository in /usr/local/nagios/etc tracking all the changes made to the configuration files.
Changes to the configuration files in this directory can now be reviewed for committing with git status. For example, if we changed the IP addresses of one of our hosts, we might be able to check the changes by typing the following:
# git status -s M example/hosts/sparta.cfg
We could then commit this change with an explanatory message, as follows:
# git commit -am "Changed IP address of host" [master d5116a6] Changed IP address of host 1 files changed, 1 insertions(+), 1 deletions(-)
We can review the change with git log via the following line of code:
# git log --oneline d5116a6 Changed IP address of host 6a2c605 First commit of configuration
If we want to inspect exactly what was changed later on, we can use git diff, followed by the short commit ID given in the first column of the preceding output:
# git diff 6a2c605 diff --git a/example/hosts/sparta.cfg b/example/hosts/sparta.cfg index 0bb3b0b..fb7c2a9 100644 --- a/example/hosts/sparta.cfg +++ b/example/hosts/sparta.cfg @@ -2,7 +2,7 @@ define host { use linux-server host_name sparta.example.net alias sparta - address 192.0.2.101 + address 192.0.2.102 }
The full functionality of Git to manage these changes, including reverting to older revisions, is out of scope here. You can read more about how to use Git in general in Scott Chacon's excellent book entitled Pro Git, which is free to read online at https://git-scm.com/book.
Version control is particularly useful in this way when more than one person is editing a configuration because it allows us to determine who made a change and when. It also allows us to note the exact change set to review why it was changed and to undo or edit it if it causes problems.
If you use this method, it's a good idea to keep your configuration reasonably granular, using at least several files rather than just one or two. It will still work if you have three big files such as hosts.cfg or services.cfg for your network, but the differences between each commit will not be as clear. This is therefore a very good recipe to combine with Grouping configuration files in directories, which is also in this chapter.
Rather than merely the configuration directory, you may prefer to keep the entire Nagios Core directory under version control, plugins and all. This could be particularly handy if you upgrade your installation with new releases and want to see what's changed in your files in case it breaks anything. In this case, be careful to use your chosen version control system's "ignore" functionality to avoid tracking temporary or log files. For Git, take a look at the output of git help ignore.