Veritas Application Director Planning and Installation Guide

Transcription

1 Veritas Application Director Planning and Installation Guide AIX, ESX, HP-UX, Linux, Solaris, and Windows 1.1 Platform Expansion

2 Veritas Application Director by Symantec Planning and Installation Guide Copyright 2007 Symantec Corporation. All rights reserved. Veritas Application Director 1.1 Platform Expansion Symantec, the Symantec logo, Storage Foundation, are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners. The product described in this document is distributed under licenses restricting its use, copying, distribution, and decompilation/reverse engineering. No part of this document may be reproduced in any form by any means without prior written authorization of Symantec Corporation and its licensors, if any. THIS DOCUMENTATION IS PROVIDED AS IS AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID, SYMANTEC CORPORATION SHALL NOT BE LIABLE FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH THE FURNISHING PERFORMANCE, OR USE OF THIS DOCUMENTATION. THE INFORMATION CONTAINED IN THIS DOCUMENTATION IS SUBJECT TO CHANGE WITHOUT NOTICE. The Licensed Software and Documentation are deemed to be commercial computer software and commercial computer software documentation as defined in FAR Sections and DFARS Section Symantec Corporation Stevens Creek Blvd. Cupertino, CA

3 Third-party legal notices Licensing and registration Technical support Third-party software may be recommended, distributed, embedded, or bundled with this Symantec product. Such third-party software is licensed separately by its copyright holder. All third-party copyrights associated with this product are listed in the Veritas Application Director Release Notes. Veritas Application Director is a licensed product. See the Veritas Application Director Planning and Installation Guide for license installation instructions. For technical assistance, visit and select phone or support. Use the Knowledge Base search feature to access resources such as TechNotes, product alerts, software downloads, hardware compatibility lists, and our customer notification service.

4

5 Contents Chapter 1 Chapter 2 Implementation checklist for setting up an Application Director server farm environment Introduction...14 Planning...14 Define your goals...14 Determine the current environment...15 Collect system information...15 Collect application information...15 Plan organizational tasks...16 Determine the difference between goals and current environment...16 System requirements and recommendations...16 Managed applications planning...19 Additional planning for applications in failover environments...20 Planning your user privilege model...21 Planning the names of your server farm objects and attributes...21 Including special characters in attribute values...22 Preparing...23 Implementing...24 Configuring and verifying...26 Pre-installation tasks for Application Director What the installation involves...30 Symantec product licensing...30 Veritas Application Director licenses...31 Configuring SSH or RSH before installing...31 Configuring SSH...31 Configuring RSH or remsh...33 Configuring RSH on Solaris...33 Configuring RSH on Linux...34 Enabling remsh on HP-UX...35 Configuring RSH on AIX...35 Setting up the Policy Master server farm...36 Running installation prechecks...37

6 6 Setting up Symantec Product Authentication Service Overview of Symantec Product Authentication Service About authentication service operation in an Application Director environment If you have an earlier version of Symantec Product Authentication Service installed Installing the root broker, if necessary Installation prerequisites Installation prerequisite for the client on HP-UX Installation prerequisite for NetApp Filers Installation prerequisite on Solaris Installation prerequisite on SUSE Linux Enterprise Chapter 3 Installing Application Director Installing Application Director Policy Master Information required by the installer Running the Application Director Policy Master installer Verifying installation and starting the Policy Master cluster Backing up the Symantec Product Authentication Service configuration Starting the Application Director Web Console Recreating the SSL certificate Installing Application Director client daemon software Mandatory client packages Preparing to install the client Installing the Application Director client daemon software on UNIX systems Installing the Application Director client daemon software on Windows systems Installing Veritas High Availability agents on UNIX systems Installing high availability agents: overview Installing the agents Installing Application Director enterprise agents on Windows clients Installing the Application Director Simulator Prerequisites for installing the Application Director Simulator Installing the Application Director Simulator on UNIX Installing the Application Director Simulator on Windows Adding storage Requirements for adding shared storage Adding storage devices Testing disks for SCSI-3 compliance Setting up and testing data disks... 67

7 7 Setting up and testing coordinator disks...69 Configuring the coordinator disk group and starting I/O fencing...70 About post-installation options...72 About post-installation configuration...72 About the integrity of Application Director client daemon systems...72 Chapter 4 Chapter 5 Installing on UNIX using response files About response files...74 Example response files...74 Example response file for Application Director client daemon software install...74 Example response file for AGPACK software install...75 About response file variables...76 Installation using a response file...80 Installing the client daemon on multiple systems without Policy Master communication...81 Setting up LDAP and Active Directory About setting up LDAP and Active Directory...84 Setting up LDAP in the Application Director environment...84 Enabling the LDAP authentication plug-in...84 Prerequisites...84 Enabling LDAP authentication in Symantec Product Authentication Service...85 Setting up users, user groups, and roles in Application Director 87 Debugging LDAP authentication...87 Setting up Active Directory in the Application Director environment...88 Setting up the authentication broker in an Active Directory domain.88 Provisioning an identity for the authentication broker...88 Copying the Root Hash file to the new authentication broker system 89 Installing the authentication broker on a Windows system...89 Using Application Director from a Windows Active Directory domain 91 If you already use Active Directory for authentication...92 Authentication to support client-side scripting...93 Adding a user to the PDR so that they may run client-side scripted commands...93 A second method for authenticating users so that they may run client-side scripted commands...95 Running Application Director commands...97

8 8 Chapter 6 Chapter 7 Appendix A Adding a new or replacement system to the Policy Master cluster About adding or replacing a system Prerequisites for the new or replacement system Adding the new system to the existing cluster Setting up the hardware Installing the Application Director software on the new node without configuration Configuring LLT and GAB Configuring LLT and GAB when adding a system Configuring LLT and GAB for a replacement system Copying /etc/vrtsvad files from an existing node to the new or replacement system Configuring Symantec Product Authentication Service for the new node 106 Configuring authentication when the new node replaces a faulted PM system Configuring authentication when adding a new system Adding the system to the VCS configuration and the PMSG Starting VCS on new system Uninstalling Application Director software Uninstalling Application Director software on UNIX Uninstalling high availability agent software Uninstalling the Application Director client daemon software Uninstalling Policy Master server software Uninstalling the Symantec Product Authentication Service software 115 Uninstalling the Application Director Simulator Uninstalling Application Director client daemon and enterprise agent software on Windows I/O fencing topics Troubleshooting I/O fencing vxfentsthdw fails when the SCSI TEST UNIT READY command fails 120 vxfentsthdw fails when prior registration key exists on disk Node is unable to join cluster while another node is being ejected Removing existing keys from disks System panics to prevent potential data corruption How vxfen driver checks for pre-existing split brain condition 122 Case 1: system 2 up, system 1 ejected (actual potential split brain)...123

9 9 Case 2: system 2 down, system 1 ejected (apparent potential split brain) Using the vxfenclearpre command to clear keys after split brain Adding or removing coordinator disks Testing fencing configurations How I/O fencing works in different event scenarios Appendix B Sample installation output Application Director Policy Master with Storage Foundation Application Director Policy Master with NFS Application Director client Index 159

10 10

11 Chapter 1 Implementation checklist for setting up an Application Director server farm environment This chapter includes the following topics: Introduction Planning Preparing Implementing Configuring and verifying

12 14 Implementation checklist for setting up an Application Director server farm environment Introduction Introduction The purpose of the implementation checklist is to make sure the administrator considers all aspects of the Application Director implementation, and no steps are inadvertently missed. The checklist does not attempt to explain all the steps, but instead offers references of where to go for more information. Note: These instructions assume the tasks are performed by an administrator with full permissions to all aspects of the server farm and applications. Before designing and implementing your Application Director installation, be familiar with the architecture and concepts of Application Director as described in the Veritas Application Director Concepts Guide. Planning Planning the Application Director server farm consists of determining your goals, your current environment and the differences between the two. In addition, coordination of the implementation is an important task. Define your goals The first step in planning is to define your goals. There are two ways to accomplish this. Either approach the question from a hardware perspective or approach the question from a software perspective. With the hardware perspective, first evaluate the existing IT hardware infrastructure to decide which systems will be part of the server farm, and note the applications running on them. With the software perspective, first evaluate what applications are going to be managed by Application Director, and note the systems those applications are running on. With either approach, the result is that you have the following: The set of systems that will be controlled by Application Director The list of applications that will be managed by Application Director Remember to list any systems that will be included as spares for maintenance, expansion, or mobility of the managed applications. Note: Often the end goal changes over the course of planning because of hardware requirements or available resources. It is a best practice to estimate the priority of your goals in case adjustments must be considered later in the process.

13 Implementation checklist for setting up an Application Director server farm environment Planning 15 Determine the current environment The second step in planning is a process of discovery of what currently exists in your environment. Collect system information You will need information about both the Policy Master cluster nodes and the server farm systems. For each system that will be controlled by Application Director, collect the following information: Systems: Document the name, OS, OS version, number of CPUs, speed of CPUs, and memory available on the system(s). Network requirements: Determine the network connectivity of the systems. Document the NICs available on each system and what subnets they are on. Storage requirements, if applicable: Determine the storage topology of the systems. Document the HBA(s) available on each system. Also document which systems have shared storage between them if you are considering a server farm configuration that has application failover capability, either manual or automated. For example, all server farm systems may be connected to shared storage, or subsets of the server farm systems may be connected to their own storage. Collect application information For each application that will be controlled by Application Director, collect the following information: Failover capability: Determine if the application will have failover capability, either manual or automated. Hardware requirements: Determine the hardware architecture and version of the operating system that the application requires. Resource requirements: Determine the logical and physical components that are used by the application, and how they depend on each other. These components will become your list of Application Director resources. See Logical components of application management in the Application Director Concepts Guide. Application dependencies: Determine if this application is dependent on other applications. For example, a web based application may require an Oracle application backend database.

14 16 Implementation checklist for setting up an Application Director server farm environment Planning Plan organizational tasks Depending on the practices and procedures of the environment, you may need to get approvals, schedule down time in advance or request change orders. Determine the difference between goals and current environment The third step in planning is to contrast your current environment with your goal. This allows you to establish a plan for what needs to be accomplished. System requirements and recommendations The Application Director Release Notes lists supported hardware architecture and operating system versions. This topic gives required and recommended components to run Application Director. Every Application Director production environment requires a highly available Policy Master connected to server farm systems. Use the information collected about the systems in your current environment and Table 1-1 to determine if you must upgrade any of your systems to meet the following requirements. Table 1-1 Hardware requirements and recommendations of Application Director for the Policy Master cluster Requirements Additional Recommendations Policy Master Cluster (Two to four systems) Note: Veritas Application Director 1.1 Platform Expansion supports the Policy Master on Linux only. It does not support the Policy Master on Solaris. Linux PM: Intel-based systems running Opteron or Extended Xeon 64-bit processors (not Itanium ) Solaris PM: Sparc-based systems 1 GHz minimum CPU CD-ROM drive for installation from a software disc Check the Application Director Release Notes or the technical support web site to make sure the system hardware and software is supported Dual processor systems

15 Implementation checklist for setting up an Application Director server farm environment Planning 17 Table 1-1 Hardware requirements and recommendations of Application Director for the Policy Master cluster Requirements Additional Recommendations Memory 512 megabytes minimum Two gigabytes of memory for large numbers of systems, service groups or application resources in the server farm Local storage With Storage Foundation: 520 megabytes local disk space minimum. Shared storage Network Without Storage Foundation: 350 megabytes local disk space minimum. 1 built-in SCSI adapter per system to access the local disks 1 SCSI or Fibre channel attached arraybased storage shared between the Policy Master cluster systems One data disk at least 2 GB in size for Policy Master configuration database. Disk must be protected by mirroring or RAID technology. At least 3 coordinator disks for I/O fencing All disks must be SCSI-3 compliant Check the hardware compatibility list (HCL) to make sure the storage is supported Three 100BaseT network interface cards (NIC) One public network Two cluster interconnect links Fibre channel attached array-based storage recommended Two host bus adapters to eliminate the HBA as a single point of failure Use gigabit network interface cards Additional separate NIC(s) for Policy Master to server farm communications Configure a low priority heartbeat link for the PM cluster using one of the links between the PM and the server farm.

16 18 Implementation checklist for setting up an Application Director server farm environment Planning Warning: Not using SCSI-3 compliant shared storage in the Policy Master cluster can lead to data corruption issues. This can be due to loss of communications between the Policy Master cluster system, manual actions by the operator or other instances where the Policy Master does not have complete control of the environment. See About data protection using SCSI-3 storage in the Application Director Concepts Guide. Table 1-2 Hardware requirements and recommendations of Application Director for server farm system Requirements Additional Recommendations Server farm systems Memory Local Storage Shared storage Network 1 GHz minimum CPU Check the Application Director Release Notes or the technical support web site to make sure the system hardware and software is supported 256 megabytes minimum 300 megabytes local disk space minimum. Disk space as needed for application, Check the hardware compatibility list (HCL) to make sure the storage is supported SCSI-3 compliant shared storage between systems if application movement (manual or automatic) is configured One network interface card connecting the system to both the Policy Master cluster and the customer systems Separate NIC(s) to connect to the Policy Master cluster and the customer systems

17 Implementation checklist for setting up an Application Director server farm environment Planning 19 Warning: Not using SCSI-3 compliant shared storage in the server farm can lead to data corruption issues. This can be due to loss of communications between the Policy Master and the server farm systems. See About data protection using SCSI-3 storage in the Application Director Concepts Guide. Managed applications planning Use the information collected from the applications in your current environment and this topic to outline the plan for your managed applications. For each application that will be managed by Application Manager, do the following: Determine the list of system(s) the application will run on. The following considerations will determine this list: System configuration. Choose the appropriate operating system, number and speed of CPUs, and memory requirements of the application. Consider any performance criteria or service level agreements (SLA) that must be met. The capability of the application to move between systems for maintenance or availability. If the application is to be managed locally on one server, for start, stop, and monitor activities, this list will be one system. If there are additional systems that will be included as spares for the managed application (the application will be capable of movement, either manual or automated), there will be multiple systems identified. Choose systems that have shared storage between them if the application has movement capability, either manual or automated. Note: This list of systems will become the value for the SystemList attribute of the managed application s service group. Use the application resource requirements information you collected to build a resource dependency tree. Building your resource dependency tree determines your service groups. Use the application dependency information you collected to build an service group dependency tree. Determine the type of the service group dependency.

18 20 Implementation checklist for setting up an Application Director server farm environment Planning For example, a web based application may require that an Oracle application backend database is running before it starts up. See Service Group Reference in the Application Director User s Guide. Determine the resource type of each Application Director resource. Note: The list of resource types necessary for each resource will become the list of agents required to support the managed application. Additional planning for applications in failover environments The following attributes may be independently set for a service group: Load Compatibility Priority One or more of the following tasks may be appropriate if the application is configured to be able to move between servers for maintenance or availability: Determine the resources required by the application (Load) with respect to the resources available on the servers (Capacity). Typically the Load of an application represents the number of CPUs and the amount of physical memory required for the application. See Application Management Reference in the Application Director User s Guide Note: These settings become the values of the Load attribute of the service group and the Capacity attribute of the server farm systems. Determine the compatibility of each application with other applications in the server farm. Compatibility is defined with one of the following criteria: Compatible with all other applications Compatible with no other applications Compatible with a specific list of other applications Not Compatible with a specific list of other applications See Application Management Reference in the Application Director User s Guide. Determine the priority of each application. Assign a priority value that reflects the importance of the application to the business. Use a scale of 1 to 5 (Priority =1 is highest) See Application Management Reference in the Application Director User s Guide

19 Implementation checklist for setting up an Application Director server farm environment Planning 21 Determine the fault behavior of the resources, service groups and systems. See Fault Management Options Reference in the Application Director User s Guide. Planning your user privilege model Determine if the predefined roles for users match to the requirements of your environment. A comparison of the privileges for predefined roles is available in the Veritas Application Director User s Guide. Planning the names of your server farm objects and attributes The following criteria describe the requirements of Application Director object names. Attribute and object names are case-insensitive. Attribute values are case-sensitive by default but can be configured otherwise. The following special characters are not allowed in names of systems, service groups, resources, and agents: `'\"/\=* +?(){}[]$#^!%&,.:;<> ~@ An attribute value that contains an escape sequence for a special character must be enclosed in double quoation marks. Resource names must only be unique in a service group. Two different service groups can have resources with the same name. A group extended attribute can not have the same name as an already existing group attribute or common extended attribute. A system extended attribute can not have the same name as an already existing system attribute or common extended attribute. A set name is local to a user. Set names do not have to be unique across the server farm. A fully qualified resource name is in the format group.resource. For example, oracle_group.ip_resource Table 1-3 lists the maximum permissible size for various Application Director objects.

20 22 Implementation checklist for setting up an Application Director server farm environment Planning Table 1-3 Size of Application Director objects Object System name Group name Maximum permissible size 128 characters 128 characters OUName node name OUValue node name Depth or the Organization Tree Length of the fully qualified path of a OUNode ( from root of the tree to the node ) Resource name Resource type name 128 characters 128 characters 512 OUname=OUvalue pairs 4096 characters 128 characters 128 characters Fully qualified resource name Group name + Resource name + 2 User name Usergroup name Fully qualified user name (name@domain) Domain name Role name String attribute name 64 characters 64 characters 128 characters 64 characters 128 characters 32 characters Including special characters in attribute values To include special characters in attribute values in the XML configuration file, use standard XML escape sequences. This pertains when manually editing the XML configuration file. Enclose attribute values that have XML escape sequences in double-quotation marks. For example: <attribute name="startprogram"><scalar>"start in bg -- &" </scalar></attribute>

21 Implementation checklist for setting up an Application Director server farm environment Preparing 23 Special character Escape sequence (double quotes) " & (ampersand) & < (less than) < > (greater than) > (single quote) &#39; The escape character for a resource attribute variable is the caret character (ˆ). Caution: Symantec recommends using the escape sequences instead of the special characters. If you use the special character, you may encounter error depending on the location of the special character. Preparing Now that you have identified what you need, in this phase you use that knowledge to prepare for installation and implementation. In this step, do the following: Gather reference material. Product documentation and other reference material can help implementation go more smoothly when questions arise. Validate agent requirements. Determine if the agents bundled with Application Director meet your resource management requirements. If you have a resource that can not be managed by existing agents, it may be necessary to create a custom agent, or to use the application agent with custom start and stop scripts. Collect agent specific attributes. Most agents required specific information at the individual resource level in order to control the resource. For example, the Mount agent requires a specific file system name, and the IP agent requires a specific IP address. Set up your Policy Master cluster hardware. See Configuring SSH or RSH before installing on page 31.

22 24 Implementation checklist for setting up an Application Director server farm environment Implementing Implementing Collect information about the Policy Master cluster for the installation scripts. Identify the names of the systems in the Policy Master cluster. Choose a number ( ) to represent the cluster ID. If there are other Veritas Cluster Server (VCS) clusters in the environment, choose a unique cluster ID to differentiate this Policy Master cluster. Verify network connectivity, and collect network information for the installation scripts. Test the Policy Master can connect to the server farm systems with operating system tools, such as the ping command. Identify the names of the two cluster interconnect NICs on each Policy Master system. Identify the virtual IP address for the Policy Master cluster systems. Identify the netmask used by the virtual IP address. Get your license key for Application Director. Get the name of a root broker for Veritas Product Authentication Services. During installation, you will be asked for the name of a root broker. If you do not already have Veritas Product Authentication Services running in your environment, you will need to install and configure this software before installing Veritas Application Director. Installation of Application Director provides the option to install the root broker on one of the Policy Master nodes. This phase summarizes the steps for implementation and installation of Veritas Application Director. This phase should occur only after planning is complete and all preparations have been completed. More details on these steps are available later in this document. The following are the general steps for implementation: Enable secure shell communications on each server farm system. This is one of the few tasks that may require accessing every system of the server farm. See Configuring SSH or RSH before installing on page 31. Configure shared storage on the Policy Master nodes, and test the disks for SCSI-3 compliance.

23 Implementation checklist for setting up an Application Director server farm environment Implementing 25 Before installation, collect the storage information you will need to configure shared storage: Identify the name of the mount point for the shared storage. If you need a mount point for the Network Appliance Filer (NetApp Filer), mount the NFS point on a local directory on the system where you will install the Policy Master. Identify the type of file system used on the shared storage. Identify the name of the disk group to store the database (if Storage Foundation configuration is not performed by the installer). Identify the name of the disk that will be part of the disk group to store the database (if Storage Foundation configuration is not performed by the installer). Use short disk names. Identify the name and size of the volume where the database is to be created on external storage (if Storage Foundation configuration is not performed by the installer). See Adding storage on page 66. Set up I/O fencing on the Policy Master nodes. See Setting up and testing coordinator disks on page 69 and Configuring the coordinator disk group and starting I/O fencing on page 70. Note: A response file can be used to allow for unattended installations on multiple server farm systems. See Installing on UNIX using response files on page 73. Install the Policy Master See Installing Application Director Policy Master on page 44. The installation names the Policy Master cluster vad_cluster. If you do not already have Veritas Storage Foundation installed, you will be prompted to install it when you install the Application Director Policy Master. There is no need to separately install Storage Foundation. If you will use the Network Appliance Filer (NetApp Filer), you will be prompted to install it when you install the Application Director Policy Master. Install the Application Director client daemon software on the server farm systems. See Installing Application Director client daemon software on page 53. Install the high availability agents. See Installing Veritas High Availability agents on UNIX systems on page 61. Verify the installation.

24 26 Implementation checklist for setting up an Application Director server farm environment Configuring and verifying [Optional] Configure shared storage hardware as appropriate if the managed applications will be configured to move between systems. Configuring and verifying This topic outlines the process the administrator can follow in configuring the Application Director server farm. Each step should be verified as it is completed. Start Application Director. Start the Application Director Web Console. Log in to the Application Director software. Configure server farm level attributes. Set or accept the default value of the PrecedenceOrder attribute. Set or accept the default value of the FragmentationPolicy attribute. Add systems. [Optional] Set system Capacity attribute. [Optional] Define the organizational units and extended attributes, if needed. Configure the server farm systems. [Optional] Define Capacity for each server farm system. Start vadclientd on each server farm system. Verify it is running. Configure the managed applications. Add resources. Define resource dependencies. Create service groups and then add resources. [Optional] Define Load for each service group. [Optional] Link service groups as necessary for service group dependencies. [Optional] Define the organizational unit and extended attribute values, if you have not already done so, and move them under the pre-defined Organization Tree. Note: It is a best practice to manually move the application outside of Application Director control before testing movement under Application Director control.

25 Implementation checklist for setting up an Application Director server farm environment Configuring and verifying 27 Configure Notification. SMTP SNMP Assign User Permissions. Designate privileges to users based on their job tasks, such as operator level privileges. Customized Management: Sets [Optional] Assign this application to the proper department or line of business. Specialized Configuration Tasks [Optional] Configure Triggers

26 28 Implementation checklist for setting up an Application Director server farm environment Configuring and verifying

27 Chapter 2 Pre-installation tasks for Application Director This chapter includes the following topics: What the installation involves Symantec product licensing Veritas Application Director licenses Configuring SSH or RSH before installing Setting up the Policy Master server farm Running installation prechecks Setting up Symantec Product Authentication Service Installation prerequisites

28 30 Pre-installation tasks for Application Director What the installation involves What the installation involves The installation involves the following procedures: Setting up the Policy Master cluster hardware. Setting up the communications among systems. Setting up Symantec Product Authentication Service (AT) Running the Application Director Policy Master installation program and verifying the installation. You will be prompted to install Storage Foundation or Network Appliance Filer (NetApp Filer). In Veritas Application Director 1.1 Platform Expansion, the Policy Master may be installed only on Linux. Connecting the Application Director client daemon systems via the network to the Policy Master cluster. Installing the Application Director client daemon system software. Installing the agents. Installing the Simulator (optional). Configuring the shared storage for the cluster. Testing shared storage devices and coordinator disks for compliance with SCSI-3 persistent reservations. Creating the disk group and file system for Application Director Policy Master database. Configuring I/O fencing. Application Director is a licensed product. Supply the license provided with your software at the appropriate prompt during installation. Symantec product licensing To register and receive a software license key, go to the Symantec Licensing Portal at the following location: Make sure you have your Software Product License document. You need information in this document to retrieve and manage license keys for your Symantec product. After you receive the license key, you can install the product. Click the Help link at this site to access the License Portal User Guide and FAQ.

29 Pre-installation tasks for Application Director Veritas Application Director licenses 31 Veritas Application Director licenses Veritas Application Director has the following offerings: Veritas Application Director Enterprise Client (Intel and non-intel) Table 2-1 lists the features available with each Veritas Application Director version. Table 2-1 Veritas Application Director offerings Veritas Application Director version Veritas Application Director Enterprise Client license Products and features Veritas Application Director with all features enabled Includes a license for all Application Director bundled agents. (Does not include Enterprise agents.) Intel and non-intel licenses available. Configuring SSH or RSH before installing Configuring SSH You can install Veritas Application Director to remote systems using either secure shell (SSH) or remote shell (RSH). SSH is the default and the recommended method of installation. The SSH program lets you log into and execute commands on a remote system. SSH enables encrypted communications in an authentication process between two untrusted hosts over an insecure network. SSH is the preferred method of remote communication because it provides a greater level of security than the RSH suite of protocols. Symantec recommends configuring a secure shell environment before installing Veritas Application Director and other Veritas products by Symantec. The following is an example SSH setup procedure. Note: Read the SSH documentation and online manual pages before enabling SSH. Visit the OpenSSH website for more information. Contact your operating system support provider for issues about SSH configuration.

30 32 Pre-installation tasks for Application Director Configuring SSH or RSH before installing To configure SSH to allow communications without use of passwords 1 Log in as root on the system where you plan to run the installation. 2 Generate a DSA key pair with the following command: ssh-keygen -t dsa 3 Press enter to accept the default location. Typically, this location is: For AIX, HP-UX, and Solaris: /.ssh/id_dsa For Linux and ESX Server: /root/.ssh/id_dsa System output similar to the following is displayed: Enter passpharase (empty for no passphrase): 4 Do not enter a passphrase. Press Enter: Enter same passphrase again: 5 Press Enter again. The output names the file containing the public key and lists the key fingerprint. 6 Change the permissions of the.ssh directory. For AIX, HP-UX, and Solaris: chmod 755 /.ssh For Linux and ESX Server: chmod 755 /root/.ssh 7 View the file.ssh/id_dsa.pub and find the line that begins with ssh_dss and ends with the name of the system. 8 Copy or append that line to the following file on all systems where you will install the Application Director software. For AIX, HP-UX, and Solaris: /.ssh/authorized_keys2 For Linux and ESX Server: /root/.ssh/authorized_keys2 9 Run the following commands: exec /usr/bin/ssh-agent $SHELL ssh-add 10 Enter the DSA passphrase when prompted. 11 To verify that SSH is set up correctly, run the following command: exec /usr/bin/ssh -l root system_name "LANG=C echo Symantec 2>&1" 2>&1 Symantec

31 Pre-installation tasks for Application Director Configuring SSH or RSH before installing 33 The above command should return Symantec. If it does not, there is an SSH setup issue that needs to be fixed. To restore password requirement between systems If you have configured SSH to enable communications between systems without passwords for the duration of an installation, you can restore the password requirement when the installation is done. Do this by removing the line you added to file /root/.ssh/authorized_keys2 on all systems where you added it. See step 7 of To configure SSH to allow communications without use of passwords. Configuring RSH or remsh The following section describes how to enable remote shell. Veritas recommends configuring a secure shell environment for Veritas product installations. See the operating system documentation for more information on configuring remote shell. Configuring RSH on Solaris 1 To determine the current status of rsh and rlogin, enter the following command: inetadm grep -i login If the service is enabled, the following line is displayed: enabled online svc:/network/login:rlogin If the service is not enabled, the following line is displayed: disabled disabled svc:/network/login:rlogin 2 To enable a disabled rsh/rlogin service, type the following command: inetadm -e rlogin To disable an enabled rsh/rlogin service, type the following command: inetadm -d rlogin 3 To verify that RSH is set up correctly, run the following command: exec /usr/bin/rsh system_name "LANG=C echo Symantec 2>&1" 2>&1 Symantec The above command should return Symantec. If it does not, there is an RSH-setup issue that needs to be fixed. 4 Modify the.rhosts file. A separate.rhosts file is in the $HOME directory of each user and must be modified for each user who will remotely access the system using RSH. Each line of the.rhosts file contains a fully qualified domain name or IP address for each remote system having access to the local system. For example, if the root user must remotely access system1

32 34 Pre-installation tasks for Application Director Configuring SSH or RSH before installing from system2, you must add an entry for system2.companyname.com in the.rhosts file on system1. echo "system2.companyname.com" >> $HOME/.rhosts 5 After completing an installation procedure, delete the.rhosts file from each user s $HOME directory to ensure security: rm -f $HOME/.rhosts Configuring RSH on Linux 1 To ensure that the rsh and rsh-server packages are installed, enter the following command: rpm -qa grep rsh rsh-server rsh If it is not already in the file, enter the following command to append the line rsh to the /etc/securetty file: echo "rsh" >> /etc/securetty 3 In the /etc/pam.d/rsh file, change the auth type from required to sufficient for pam_rhosts_auth.so : auth sufficient pam_rhosts_auth.so 4 To enable the RSH server, type the following command: chkconfig rsh on 5 To verify that RSH is set up correctly, run the following command: exec /usr/bin/rsh system_name "LANG=C echo Symantec 2>&1" 2>&1 Symantec The above command should return Symantec. If it does not, there is an RSH-setup issue that needs to be fixed. 6 Modify the.rhosts file. Each line of the.rhosts file contains a fully qualified domain name or IP address for each remote system, and the name of a user having access to the local system. For example, if the root user must remotely access system1 from system2, add an entry for system2.companyname.com to the.rhosts file on system1 by typing the following command: echo "system2.companyname.com" >> $HOME/.rhosts 7 After installing the product, remove the rsh entry in the /etc/securetty file. 8 Disable the RSH server by typing the following command: chkconfig rsh off 9 After completing an installation procedure, delete the.rhosts file from each user s $HOME directory to ensure security: rm -f $HOME/.rhosts

33 Pre-installation tasks for Application Director Configuring SSH or RSH before installing 35 Enabling remsh on HP-UX Remote shell functionality is enabled automatically after installing an HP-UX system. Typically, the only requirement to enable remote installs is to modify the.rhosts file. There is a separate.rhosts file in the $HOME directory of each user that you must modify for each user who will remotely access the system using remsh. Each line of the.rhosts file must contain a fully qualified domain name or IP address for each remote system that has access to the local system. For example, if the root user must remotely access system1 from system2, add an entry for system2.companyname.com to the /.rhosts file on system1. echo "system2.companyname.com" >> $HOME/.rhosts After completing an installation procedure, delete the.rhosts file from each user s $HOME directory to ensure security: rm -f $HOME/.rhosts See the operating system documentation and the remsh(1m) manual page for more information on configuring remote shell. Configuring RSH on AIX 1 To enable RSH, create a /.rhosts file on each target system and add a line to the file specifying the full domain name of the source system. For example, add the line: sysname.domainname.com root 2 Change permissions on the /.rhosts file to 600 by typing the following command: chmod 600 /.rhosts 3 To verify that RSH is set up correctly, run the following command: exec /usr/bin/rsh system_name "LANG=C echo Symantec 2>&1" 2>&1 Symantec The above command should return Symantec. If it does not, there is an RSH-setup issue that needs to be fixed. 4 After completing an installation procedure, delete the.rhosts file from each target system to ensure security: rm -f /.rhosts

34 36 Pre-installation tasks for Application Director Setting up the Policy Master server farm Setting up the Policy Master server farm Start the installation by setting up the Policy Master server farm hardware components, using the following procedure. To set up the Policy Master in a production environment 1 Select two or four Solaris or Linux systems with the following capabilities: At least 2 gigabyte memory (for use by the Application Director). At least one network interface for private communication between the Policy Master server farm systems; two links are desirable. At least one network link between the Policy Master and the server farm system (also known as client daemon systems); two links are preferable. 2 Select the storage device for the Policy Master configuration database. The device is to be shared between the two systems. It is highly recommended that the device support SCSI-3 persistent reservations. The section Adding storage on page 66 provides procedures for connecting and configuring the storage at the appropriate time. 3 Make the TCP/IP network connection to the Application Director client daemon systems. 4 Test the network connections using the ping utility.

35 Pre-installation tasks for Application Director Running installation prechecks 37 Running installation prechecks For each software installation described in this chapter, you can check the target systems before installation to verify that: There is sufficient disk space on the system for the installation. The product being installed is not already installed. You can do this using the precheck function from the installer utility menu on the software disc or by using a -precheck option when you run the specific installation command. To run the precheck on the installer menu 1 Mount the Application Director software disc. 2 From the software disc, start the installer../installer 3 From the installer menu, choose the option to Perform a Pre-Installation Check by pressing P when prompted to enter a task. 4 The utility checks the systems you specify. To run the precheck from the command line 1 Mount the Application Director software disc. 2 On the installation software disc, navigate to the directory containing the installation programs for Application Director: cd application_director 3 Enter the installation command with the -precheck option, specifying the systems on which to install:./installvadcd -precheck sysa sysb sysc 4 The precheck utility runs non-interactively and reports its results. Note: Precheck utilities do not check for the necessary dependent packages or rpms.

36 38 Pre-installation tasks for Application Director Setting up Symantec Product Authentication Service Setting up Symantec Product Authentication Service Symantec Product Authentication Service provides a hierarchy of brokers that issue credentials permitting trusted communications between users and processes on the Policy Master nodes and on the Application Director client daemon systems. All Application Director environments require the use of Symantec Product Authentication Service for trusted communications. Overview of Symantec Product Authentication Service The Symantec Product Authentication Service Administrator s Guide contains an introductory chapter that provides the concepts necessary for a basic understanding of authentication and of the Symantec Product Authentication Service components. About authentication service operation in an Application Director environment The Symantec Product Authentication Service root broker is the highest broker of trusted communications in an environment of computer services and users. Each service and each user in a Symantec Product Authentication Service trusted communications environment must exchange credentials that can be verified to have originated with the root broker, which is the authority all services and users can trust. In the Application Director environment, an authentication broker obtains a certificate from the root broker and is established as a security principal with the root broker. The authentication broker serves as an intermediate broker between the root broker and Application Director services and Application Director users, issuing credentials to the Policy Master, the Application Director client daemon processes, and all users in the server farm. The Application Director Policy Master installation process sets up the authentication broker process in the Policy Master cluster. The installer creates a private domain repository that can exist in a cluster environment (that is, it can be switched from one cluster system to another). Symantec Product Authentication Service supports third-party private domain repositories, such as LDAP and Active Directory. For information on setting up authentication with third-party private domain repositories, see Chapter 5, Setting up LDAP and Active Directory on page 83. If you have not previously installed a Symantec Product Authentication Service root broker that can be accessed by the Application Director server farm, the

37 Pre-installation tasks for Application Director Setting up Symantec Product Authentication Service 39 Application Director Policy Master installation process creates one on the first system specified during installation. Note: Although you may let the installer create the Symantec Product Authentication Service root broker on a system within the Policy Master cluster, it is recommended that the root broker be separate and isolated for the highest level of security. The root broker may be on a Linux, Solaris, HP-UX, AIX, or Windows system. If you have an earlier version of Symantec Product Authentication Service installed If you have an earlier version of Symantec Product Authentication Service installed, you must remove it before installing Application Director. See Uninstalling the Symantec Product Authentication Service software on page 115. On client nodes, remove all VRTSatclient and VRTSatserver packages, including credentials, and the /var/vrtsat directory before installing Application Director. Before removing them, ensure that they are not in use by other products. Installing the root broker, if necessary Perform the following steps to install the root broker. It is recommended that you install the root broker on a separate and isolated system (either on one Policy Master cluster system or a non-policy Master cluster system connected to the Policy Master cluster). Note that the authentication broker and client software are installed later when Application Director is installed. To install and setup the root broker 1 Mount the Application Director software disc. 2 From the software disc, start the installer../installer 3 From the installer menu, choose Install/Upgrade a Product. 4 From the list of products, choose Symantec Product Authentication Service. 5 Choose Root Mode. 6 Enter the system on which to install the root broker. 7 Start configuration by entering y when prompted.