Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Installing the Rsync Package and Automating SSH Login

    Before you can use the replication and rsync packages to back up the IP/MPLSView servers and databases in a distributed environment, make sure you have completed all of the following prerequisites:

    • Set up the /etc/hosts file.
    • Install the rsync software package.
    • Automate SSH login on the primary and backup application servers.

    Make sure each application server and database server in your network has entries in its /etc/hosts file to every other application server and database server. These entries enable you to use either IP addresses or hostnames to ping each server in the network.

    Installing the Rsync Package

    You can install the rsync package before, during, or after installing the IP/MPLSView application.

    To install the rsync package on the primary application server and backup application servers:

    1. Determine whether your server already has rsync installed by doing one of the following:
      • Checking your server for the presence of the /usr/local/bin/rsync file.
      • On Linux servers, issuing the rpm -qa | grep rsync command as the root user.
    2. If rsync is not installed, install it from the rsync installation package as the root user.
      • On non-Linux servers, use the replication/ command.
      • On Linux servers, issue the yum -y rsync command.

    Automating SSH Login

    Cron is a time-based job scheduler for Linux-based operating systems. You can use cron to schedule jobs (commands or shell scripts) to run periodically at fixed times, dates, or intervals.

    To ensure that you can perform an automatic rsync with a cron job, you must automate the SSH login process on the primary and backup application servers so you can use SSH to log in remotely without needing to specify a password. Automating SSH login also facilitates the processes for performing status checks, and for starting and stopping the application and databases.

    If you need to only transfer data collection information between the primary and backup application servers, you can automate the SSH login for only the wandl user account. However, if you also need to transfer traffic collection data, you must automate the SSH login for both the wandl user and the root user accounts because the root user account might own some of the traffic collection files that you need to transfer.

    After you perform this procedure, the wandl user should be able to log in as the root user on all servers in your distributed environment. This is accomplished by making sure that the primary server’s public key ( is present in the backup server’s authorized keys (authorized_keys), and the backup server’s authorized keys (authorized_keys) are in the primary server’s public key (

    To automate SSH login on all database servers:

    1. On the primary database server, log in as the wandl user and change directory to the wandl home directory (/home/wandl).
    2. Generate a pair of authentication keys without specifying a passphrase.
      /home/wandl> ssh-keygen -t rsa
      Generating public/private rsa key pair.
      Enter file in which to save the key (/home/wandl/.ssh/id_rsa):
      Created directory '/home/wandl/.ssh'.
      Enter passphrase (empty for no passphrase):
      Enter same passphrase again:
      Your identification has been saved in /home/wandl/.ssh/id_rsa.
      Your public key has been saved in /home/wandl/.ssh/
      The key fingerprint is:
      94:7c:a6:d2:b6:80:19:a4:b9:f4:7d:7f:09:d4:f2:52 wandl@server
    3. Use SSH to create the .ssh directory on the primary application server.

      Substitute remosthostip with the IP address of the primary application server. When prompted, enter the wandl password of the remote host.

      /home/wandl> ssh wandl@remotehostip mkdir -p .ssh
      The authenticity of host ‘<remotehostip> (<remotehostip>)' can't be established.
      RSA key fingerprint is 8a:d9:a9:c5:91:6a:e6:23:8c:2f:ad:4f:ea:48:78:0b.
      Are you sure you want to continue connecting (yes/no)? yes
      Warning: Permanently added ‘<remotehostip>’ (RSA) to the list of known
    4. Append the local host’s new public key to the primary application server’s authorized keys, and enter the wandl password for the primary application server.
      /home/wandl> cat .ssh/ | ssh wandl@remotehostip 'cat >> .ssh/authorized_keys'
    5. Set PermitRootLogin to yes in the sshd_config file. For example, /etc/ssh/sshd_config or /usr/local/etc/sshd_config.

      If PermitRootLogin is not set to yes, edit the sshd_config file and use the service sshd restart command to restart the sshd process.

    6. (Optional) Refresh the sshd process by stopping it, if needed.

      Kill the SSH process. Use the process ID (PID) of the main sshd process. Note that issuing the following command might terminate currently open SSH sessions.

      > kill -1 PID
    7. Repeat Steps 1 through 6 for each backup application server.
    8. Confirm that the .ssh directory has restricted permissions.
      /home/wandl> chmod 700 .ssh
    9. From the database servers, log in to the application servers to confirm that automatic SSH login is enabled.

      If automatic SSH login is working properly, you should be able to directly log in to the application servers from the database servers and to the database servers from the application servers without specifying a password.

    Modified: 2016-09-28