Veritas Access Installation Guide
- Introducing Veritas Access
- Licensing in Veritas Access
- System requirements
- Important release information
- System requirements
- Linux requirements
- Operating system RPM installation requirements and operating system patching
- Kernel RPMs that are required to be installed with exact predefined RPM versions
- OL kernel RPMs that are required to be installed with exact predefined RPM versions
- Required operating system RPMs for OL 7.4
- Required operating system RPMs for RHEL 7.3
- Required operating system RPMs for RHEL 7.4
- Software requirements for installing Veritas Access in a VMware ESXi environment
- Hardware requirements for installing Veritas Access virtual machines
- Management Server Web browser support
- Supported NetBackup versions
- Supported OpenStack versions
- Supported Oracle versions and host operating systems
- Supported IP version 6 Internet standard protocol
- Linux requirements
- Network and firewall requirements
- Maximum configuration limits
- Preparing to install Veritas Access
- Deploying virtual machines in VMware ESXi for Veritas Access installation
- Installing and configuring a cluster
- Installation overview
- Summary of the installation steps
- Before you install
- Installing the operating system on each node of the cluster
- Installing Veritas Access on the target cluster nodes
- About managing the NICs, bonds, and VLAN devices
- About VLAN tagging
- Replacing an Ethernet interface card
- Configuring I/O fencing
- About configuring Veritas NetBackup
- About enabling kdump during an Veritas Access configuration
- Reconfiguring the Veritas Access cluster name and network
- Configuring a KMS server on the Veritas Access cluster
- Automating Veritas Access installation and configuration using response files
- Displaying and adding nodes to a cluster
- Upgrading Veritas Access and operating system
- Upgrading Veritas Access using a rolling upgrade
- Uninstalling Veritas Access
- Appendix A. Installation reference
- Appendix B. Configuring the secure shell for communications
- Appendix C. Manual deployment of Veritas Access
Manually configuring passwordless SSH
You can use the SSH to log into and execute commands on a remote system. SSH enables encrypted communications and an authentication process between two untrusted hosts over an insecure network.
In this procedure, you first create a DSA key pair. From the key pair, you append the public key from the source system to the authorized_keys file on the target systems.
To create the DSA key pair
- On the source system (sys1), log in as root user, and navigate to the root directory.
sys1 # cd /root
- To generate a DSA key pair on the source system, type the following command:
sys1 # ssh-keygen -t dsa
System output similar to the following is displayed:
Generating public/private dsa key pair. Enter file in which to save the key (/root/.ssh/id_dsa):
- Press Enter to accept the default location of
/root/.ssh/id_dsa. - When the program asks you to enter the pass phrase, press the Enter key twice.
Enter passphrase (empty for no passphrase):
Do not enter a pass phrase. Press Enter.
Enter same passphrase again:
Press Enter again.
- Output similar to the following lines appears.
Your identification has been saved in /root/.ssh/id_dsa. Your public key has been saved in /root/.ssh/id_dsa.pub. The key fingerprint is: 1f:00:e0:c2:9b:4e:29:b4:0b:6e:08:f8:50:de:48:d2 root@sys1
To append the public key from the source system to the authorized_keys file on the target system using secure file transfer
- From the source system (sys1), move the public key to a temporary file on the target system (sys2).
Use the secure file transfer program.
In this example, the file name
id_dsa.pubin the root directory is the name for the temporary file for the public key.Use the following command for secure file transfer:
sys1 # sftp sys2
If the secure file transfer is set up for the first time on this system, output similar to the following lines is displayed:
Connecting to sys2 ... The authenticity of host 'sys2 (10.182.00.00)' can't be established. DSA key fingerprint is fb:6f:9f:61:91:9d:44:6b:87:86:ef:68:a6:fd:88:7d. Are you sure you want to continue connecting (yes/no)?
- Type yes.
Output similar to the following is displayed:
Warning: Permanently added 'sys2,10.182.00.00' (DSA) to the list of known hosts. root@sys2 password:
- Enter the root password of sys2.
- At the sftp prompt, type the following command:
sftp> put /root/.ssh/id_dsa.pub
The following output is displayed:
Uploading /root/.ssh/id_dsa.pub to /root/id_dsa.pub
- To quit the SFTP session, type the following command:
sftp> quit
- Add the
id_dsa.pubkeys to theauthorized_keysfile on the target system. To begin the SSH session on the target system (sys2 in this example), type the following command on sys1:sys1 # ssh sys2
Enter the root password of sys2 at the prompt:
password:
Type the following commands on sys2:
sys2 # cat /root/id_dsa.pub >> /root/.ssh/authorized_keys sys2 # rm /root/id_dsa.pub
- Run the following commands on the source installation system. If your SSH session has expired or terminated, you can also run these commands to renew the session. These commands fetch the private key into the shell environment and make the key globally available to the root user.
sys1 # exec /usr/bin/ssh-agent $SHELL sys1 # ssh-add
Identity added: /root/.ssh/id_dsa
This shell-specific step is valid only while the shell is active. You must execute the procedure again if you close the SSH during the session.
To verify that you can connect to a target system
- On the source system (sys1), enter the following command:
sys1 # ssh -l root sys2 uname -a
where sys2 is the name of the target system.
- The command should execute from the source system (sys1) to the target system (sys2) without the system requesting a pass phrase or password.
- Repeat this procedure for each target system.