I’ve been using Idera (previously R1soft) CDP backup for some time now and am very happy with it. It works fine and sends out a daily email with the backup status. While this is fine for some setups, we use nagios to monitor most components of our infrastructure. There was no nagios check for CDP backups yet. The CDP backup server includes an API that enables you to get the status of the backup policies. Idera even supplies some examples on how to use the API.

With little work I updated one of these examples to a nagios check. This nagios check returns 4 statuses:

  • Unknown: if the check cannot get the status
  • Warning: if one or more policies are in warning
  • Error: if one or more policies are in error
  • OK: if all policies finished successfully

The check also returns the list of policies with their status. So when you view the check details you can easily see which policy is in error.

To run the check you need php-cli with php-soap on your nagios server.

To enable the check for a backup server follow the following steps:

Add the following command to nagios:

define command{
command_name check_r1soft_cdp
command_line php $USER1$/check_r1soft_cdp.php -H $HOSTADDRESS$
}

Add the following service to nagios:

define service {
use generic-service
host_name backup.server.nl
service_description Idera_CDP_Backup
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 5
retry_check_interval 1
contact_groups critical-admins
notification_interval 240
notification_period workhours
notification_options w,u,c,r
check_command check_r1soft_cdp
}

Make sure to update the check with the correct username and password:

#set CDP user
$USER="admin";
#set CDP user password
$PASS="password";

Please find the check script attached:
check_r1soft_cdp. Rename this file from check_r1soft_cdp.txt to check_r1soft_cdp.php.

As I wrote in my last blog port, I’ve been enabling selinux on some webservers. Last week I updated the Idera CDP agent on one server to support backup and restore of MySQL via the CDP agent. The backup is successful without any issues. Since this integrated MySQL backup was new functionality, I also wanted to test the restore. The restore did not work with selinux enabled. There were a ton of error messages in the audit.log, actually too much to paste in this blog post. I’ve attached the file with error messages cdp-mysql.

To fix the problem I’ve created multiple selinux policies, after the first 4 tries new deny messages appeared in the audit.log. After the fifth version of the policy the restore finished without any error in the log and the database that I dropped and I tried to restore was available and accessible for the sites.

To create the working policy I did the following. I copied the messages that I attached into a separate file (cdp-mysql.se) and used the following command to create a selinux policy:


audit2allow -i cdp-mysql.se -M cdp-mysql

This creates a couple of files (cdp-mysql.pp and cdp-mysql.te) in the current working directory. The cdp-mysql.te contains the plain text policy. The cdp-mysql.pp file can be used to import the selinux policy:


semodule -i cdp-mysql.pp

This activates the cronolog selinux policy that contains the configuration listed below. After this module is activated cronolog is allowed to create directories under the log directory.

module cdp-mysql 1.0;

require {
type bin_t;
type fixed_disk_device_t;
type mysqld_t;
type port_t;
type var_lib_t;
class sock_file { create unlink getattr };
class tcp_socket name_bind;
class chr_file { read write };
class file { write getattr read lock open append };
}

#============= mysqld_t ==============
allow mysqld_t bin_t:file append;
allow mysqld_t fixed_disk_device_t:chr_file { read write };
#!!!! This avc can be allowed using the boolean 'allow_ypbind'

allow mysqld_t port_t:tcp_socket name_bind;
#!!!! The source type 'mysqld_t' can write to a 'file' of the following types:
# mysqld_db_t, hugetlbfs_t, mysqld_tmp_t, mysqld_log_t, mysqld_var_run_t, root_t

allow mysqld_t var_lib_t:file { read write getattr open lock };
allow mysqld_t var_lib_t:sock_file { create unlink getattr };

For those who want to use it I’ve attaced the cdp-mysql.pp module. Make sure to test the md5 checksum (44ec3ec35db17e0adab38ad0ba1fac10 cdp-mysql.pp). You can also recreate the module with the file containing the errors from the audit.log

When using rancid you have to store the username and password in a text file. When you don’t want to give the user privilege level 15 you have to store the enable password as well. Tacacs with authorization is the best solution to restrict access for the rancid user. Since the rancid user doesn’t need to change any configuration on the network devices, you can restrict the commands it is allowed to run.

When using tac_plus (http://www.shrubbery.net/tac_plus/) you can use the following definition for the rancid user:

user = rancid {
#    default service = permit
login = cleartext "XXX"
enable = cleartext "XXX"
name = "Rancid User"
service = exec {
priv-lvl = 15
}
cmd = show {
permit .*
}
cmd = write {
permit term
}
cmd = dir {
permit .*
}
cmd = admin {
permit .*
}
cmd = more {
permit .*
}

}

user = rancid {
#    default service = permit
login = cleartext “R4nc!d”
enable = cleartext “raNc1d_3naB1e”
name = “Rancid User”
service = exec {
priv-lvl = 15
}
cmd = show {
permit .*
}
cmd = write {
permit term
}
cmd = dir {
permit .*
}
cmd = admin {
permit .*
}
}T

The rancid user is automatically in enable mode because the privilege level is set to 15 in tacacs. You have to configure rancid no to enter enable mode. This is configured (for cisco devices) in ~rancid/.cloginrc

Enter the following details:

add user        *       rancid
add password    *       XXX
add method      *       telnet
add autoenable  *       1