Welcome to the CA Infrastructure Management Data Aggregator Readme. This Readme contains a complete list of the known issues for this release and details about how the features and enhancements for this release might affect you.

2.0 How To Access Product Documentation

This Readme contains the most recent list of known issues and workarounds. Additional product documentation is available from the Data Aggregator bookshelf, which can be accessed from the Help menu in the CA Performance Center user interface. The bookshelf can also be downloaded from CA Support. The bookshelf contains the Release Notes (with system requirements), online help, and guides in PDF and HTML format.

Context-sensitive online help is available for pages and views when you click a Help (?) button or select Help for This Page from the Help menu.

3.0 Upgrade Considerations

Upgrades of the CA Infrastructure Management software from previous releases are supported and are incremental. For information about upgrade paths, see the Data Aggregator Release Notes.

3.1 Data Repository Upgrade Fails Due to Use of Logical Volume Manager (LVM)

The following procedures describe how to transition from a Data Repository that is running Vertica 6.0.2 using LVM (Logical Volume Manager) for data and catalog directories to Vertica 6.0.2 using non-LVM. The Vertica database backs Data Repository and Vertica does not support its database running on LVM volumes. Vertica has never supported running its database on LVM. However, starting with Vertica 7.0.1-2 (Data Aggregator Release 2.3.4 requires Vertica 7.0.1-2), the Vertica installer enforces this requirement of not allowing Vertica to run on LVM.

The steps to migrate database directories that reside on LVM partitions to non-LVM partitions are described for both single node Data Repository deployments and clustered Data Repository deployments. If Data Repository is using volumes that LVM manages, Data Aggregator Release 2.3.4 cannot be installed.

3.1.1 Data Repository - Single Node

Important! Back up Data Repository before proceeding. Make sure that no scheduled backups will run during this time.

Important! You must have a local or networked partition with adequate free space to store the database contents temporarily while you convert the LVM partition.

Assumptions:

The data directory is /data.
The catalog directory is /catalog.
LVM manages the data and catalog directories.
The database administrative user is dradmin.
The database is named drdata.

To proceed with the migration, do the following steps:

Stop each Data Collector instance:
1. ssh dc_hostname -l root
2. /etc/init.d/dcmd stop
3. /etc/init.d/dcmd status
Stop Data Aggregator:
1. ssh da_hostname -l root
2. /etc/init.d/dadaemon stop
3. /etc/init.d/dadaemon status
As dradmin, stop the database:
1. ssh dr_hostname -l dradmin
2. Stop the database using /opt/vertica/bin/adminTools

Important! Do the following steps as the root user, unless otherwise specified.

Make a temp directory, /tmp_data, to store the data directory contents temporarily. Make sure that the directory is located on a partition that has enough space to accommodate a full copy of the /data/drdata folder. This is a temporary storage location. The data will be moved from this location later.
1. mkdir /tmp_data
2. Verify that /tmp_data is mounted to the temporary partition:
  mount data_partition /tmp_data
3. Make a note of the size of the /data directory for future reference in step #7:
  du -ch /data | grep -i total
4. Determine the amount of free disk space on the destination partition:
  df -h /tmp_data
5. Verify that there is enough free disk space on the destination partition (the partition for /tmp_data) to accommodate a full copy of the /data directory.
Change the permissions of the /tmp_data folder:
chown dradmin:verticadba /tmp_data
- dradmin
  Is the database administrator user.
Move the database into the new directory.
mv /data/drdata /tmp_data
Ensure the file size matches the size reported by step 4.c.:
du -ch /tmp_data | grep -i total
Make a temp directory, /tmp_catalog, to store the catalog directory. Make sure that the directory is located on a partition that has enough space to accommodate a full copy of the /catalog/drdata folder. This is a temporary storage location. The data will be moved from this location later.
1. mkdir /tmp_catalog
2. Verify that /tmp_catalog is mounted to the temporary partition:
  mount data_partition /tmp_catalog
3. Make a note of the size of the /catalog directory for future reference in step 11:
  du -ch /catalog | grep -i total
4. Determine the amount of free disk space on the destination partition:
  df -h /tmp_catalog
5. Verify that there is enough free disk space on the destination partition (the partition for /tmp_catalog) to accommodate a full copy of the /catalog directory.
Change the permissions of the /tmp_catalog folder:
chown dradmin:verticadba /tmp_catalog
- dradmin
  Is the database administrator user.
Move the catalog into the new directory.
mv /catalog/drdata /tmp_catalog
Ensure the file size matches the size reported by step 8.c.:
du -ch /tmp_catalog | grep -i total
Make a note of the lvm mount points by recording output of mount:
mount
Unmount /data and /catalog:
umount /data

umount /catalog

Note: If you get a "busy" related error, please ensure that all windows and applications are not accessing these directories.
Re-establish non-LVM volume on /data and /catalog. There are three approaches:
- EXISTING NON-LVM FILE SYSTEM: When you unmount /data and /catalog, the empty folders will be relocated to the same partition as the root of the Linux file system. If this partition fits the sizing requirements and is where you want to keep your data going forward, remove the lines pertaining to /data and /catalog directories from /etc/fstab:
  vim /etc/fstab
OR
- CONVERT EXISTING LVM FILE SYSTEM TO NON-LVM: If you want to convert your lvm partition to a non-LVM partition, complete the following steps, using information from step 12:
  1. lvremove /dev/<lvmvolumegroup>/<lvmlogicalvolume>
  2. vgremove <lvmvolumegroup>
  3. pvremove /dev/<sdaX>
  4. mkfs.ext3 /dev/sdaX
  5. Add entries in /etc/fstab such as the following:
    /dev/sdaX /catalog ext3 defaults 0 0
    
    /dev/sdaY /data ext3 defaults 0 0
OR
- NEW NON-LVM FILE SYSTEM: If you want to use a new non-LVM partition, format the file system and add the mount points for /data and /catalog:
  a. mkfs.ext3 /dev/sdaX
  
  b. Add entries to /etc/fstab such as the following:
  
  /dev/sdaX /catalog ext3 defaults 0 0
  
  /dev/sdaY /data ext3 defaults 0 0
Remount all filesystems:
mount -a
Move the data from the temporary directories back into the /data and /catalog directories that Vertica knows:
1. mv /tmp_data/drdata /data
2. mv /tmp_catalog/drdata /catalog
Ensure that the size of the /data directory matches the size reported by step 4.c.:
du -ch /data | grep -i total
Ensure that the size of the /catalog directory matches the size reported by step 8.c.:
du -ch /catalog | grep -i total
Restart the database:
1. su – dradmin
2. /opt/vertica/bin/adminTools
Note: This can take several minutes to occur.
Verify that the database is running:
1. su - dradmin
2. /opt/vertica/bin/adminTools
3. Select "View Database Cluster State" and verify that the database state is "UP".
Restart Data Aggregator:
1. ssh da_hostname -l root
2. /etc/init.d/dadaemon start
3. /etc/init.d/dadaemon status
Start each Data Collector instance:
1. ssh dc_hostname -l root
2. /etc/init.d/dcmd start
3. /etc/init.d/dcmd status

3.1.2 Data Repository - Cluster

Important! Back up Data Repository before proceeding. Make sure that no scheduled backups will run during this time.

Assumptions:

The data directory is /data.
The catalog directory is /catalog.
LVM manages the data and catalog directories.
The database administrative user is dradmin.
The database is named drdata.

To proceed with the migration, do the following steps:

Stop each Data Collector instance:
1. ssh dc_hostname -l root
2. /etc/init.d/dcmd stop
3. /etc/init.d/dcmd status
Stop Data Aggregator:
1. ssh da_hostname -l root
2. /etc/init.d/dadaemon stop
3. /etc/init.d/dadaemon status

Steps to Migrate a Node In a Cluster

Important! Do the following steps as the root user, unless otherwise specified.

Do the following steps for each node in the cluster. Follow all of the steps (steps 1-15) for one node at a time.

Important! Use adminTools to verify that the database is running.

Make note of the IP address for the current node:
ifconfig
As the dradmin user, access adminTools:
1. su - dradmin
2. /opt/vertica/bin/adminTools
Stop Vertica on the host:
1. Navigate to "Advanced Tools Menu". Press enter.
2. Navigate to "Stop Vertica on Host". Press enter.
3. Select the appropriate host IP address as found in step 1 in the section, "Steps to Migrate a Node In a Cluster". Press Enter.
4. Navigate to "Main Menu". Press enter.
5. Navigate to "Exit". Press enter.
Switch back to the root user:
exit
Verify that the following command outputs "root":
whoami
Remove the files from the /data directory:
rm -rf /data/drdata
Remove the files from the /catalog directory:
rm -rf /catalog/drdata
Record the output of the following commands for debugging purposes:
1. mount
2. cat /etc/fstab
Unmount the /data LVM directory:
umount /data
Unmount the /catalog LVM directory:
umount /catalog
Re-establish non-LVM volume on /data and /catalog. There are three approaches:
- EXISTING NON-LVM FILE SYSTEM: When you unmount /data and /catalog, the empty folders will be relocated to the same partition as the root of the Linux file system. If this partition fits the sizing requirements and is where you want to keep your data going forward, remove the lines pertaining to /data and /catalog directories from /etc/fstab:
  vim /etc/fstab
  
  OR
- CONVERT EXISTING LVM FILE SYSTEM TO NON-LVM: If you want to convert your lvm partition to non-LVM partition, complete the following steps, using information from step 8:
  1. lvremove /dev/<lvmvolumegroup>/<lvmlogicalvolume>
  2. vgremove <lvmvolumegroup>
  3. pvremove /dev/<sdaX>
  4. mkfs.ext3 /dev/sdaX
  5. Add entries in /etc/fstab such as the following:
    /dev/sdaX /catalog ext3 defaults 0 0
    
    /dev/sdaY /data ext3 defaults 0 0
OR
- NEW NON-LVM FILE SYSTEM: If you want to use a new non-LVM partition, format the file system and add the mount points for /data and /catalog:
  a. mkfs.ext3 /dev/sdaX
  
  b. Add entries to /etc/fstab such as the following:
  
  /dev/sdaX /catalog ext3 defaults 0 0
  
  /dev/sdaY /data ext3 defaults 0 0
Remount all file systems:
mount -a
Create the drdata folder with correct permissions within /data and /catalog:
1. mkdir -p /data/drdata
2. mkdir -p /catalog/drdata
3. chown -R dradmin:verticadba /data
4. chown -R dradmin:verticadba /catalog
Restart Vertica on the host:
1. su - dradmin
2. /opt/vertica/bin/adminTools
3. Use the down arrow key to navigate to "Restart Vertica on host". Press enter.
Continue to monitor adminTools. The status for the current node will remain as "Recovering" while the data is rebuilt. Do not continue until the database is back "UP". It can take a considerable amount of time for the database to transition to the“UP” state.
1. Select "View Database Cluster State". Press enter.
2. Press enter to escape to the Main Menu.
After the database is back up, repeat steps 1-15, "Steps to Migrate a Node In a Cluster", for the next node. Continue through these steps until all Data Repository nodes are migrated off LVM.

After you complete the steps in the section "Steps to Migrate a Node In a Cluster" for all Data Repository nodes, do the following steps:

Log in to any Data Repository node:
su - dradmin

/opt/vertica/bin/vsql -U dradmin –w drpass
Run the following vsql commands to re-establish custom application settings:
1. SELECT set_config_parameter('MaxClientSessions',1024);
2. SELECT set_config_parameter('StandardConformingStrings','0');
Start Data Aggregator:
1. ssh da_hostname -l root
2. /etc/init.d/dadaemon start
3. /etc/init.d/dadaemon status
Start all Data Collector instances:
1. ssh dc_hostname -l root
2. /etc/init.d/dcmd start
3. /etc/init.d/dcmd status

3.2 Reimport .csv File of Aliases for Monitored Devices

If you imported a .csv file of alias names for monitored devices in CA Infrastructure Management Data Aggregator Release 2.3.3, reimport the file after you upgrade to Release 2.3.4. Alias names will not be recognized if you do not reimport the file.

3.3 Migrate Existing CAMM Device Packs

In CA Infrastructure Management Data Aggregator Release 2.3.4, there is a change in the way device packs are deployed and configured. If you are upgrading from Release 2.3.3 to Release 2.3.4, install CA Mediation Manager (CAMM) components and run the migration script to migrate the existing device packs. See the complete CAMM documentation set at https:www.wiki.ca.com/camm.

3.4 CA Mediation Manager Known Limitation After Upgrade

The architecture of the integration with CA Mediation Manager has been significantly enhanced. Version 2.2.6 of CA Mediation Manager is required to run with CA Infrastructure Management Release 2.3.4. However, that version of the integration does not support the Device Pack Generator utility.

Future versions of CA Mediation Manager will support an enhanced version of this utility. Until then, custom device packs are not supported.

Important! CA Mediation Manager 2.2.6 is not fully backward-compatible with previous versions of CA Infrastructure Management. To process the raw data, you must upgrade Data Collector to Release 2.3.4. Be sure to migrate your device packs before you upgrade CA Infrastructure Management. See the scenario on the CA Infrastructure Management Data Aggregator Documentation Bookshelf titled "How to Migrate Device Packs" for more information.

3.5 Segment Database Tables

If you are upgrading CA Infrastructure Management Data Aggregator and if Data Repository is installed in a cluster environment, verify that the database tables are segmented after you upgrade the Data Repository component and before you upgrade the Data Aggregator component.

Note: For more information about verifying if the database tables are segmented, see the CA Infrastructure Management Data Aggregator upgrade guides.

3.6 Change the Size of the Write Optimized Storage on Data Repository

If you are managing one million or more polled items, change the size of the Write Optimized Storage (WOS) on Data Repository from the default of 2 GB to an increased value of 4 GB. Because this operation requires Data Aggregator to be shut down, we recommend that you perform the following steps before upgrading Data Aggregator.

Log in to the computer where Data Aggregator is installed. To stop Data Aggregator, open a command prompt and type the following command:
service dadaemon stop
SSH to a Data Repository node.
To move all data that is in Write Optimized Storage (WOS) to Read Optimized Storage (ROS), type the following command:
/opt/vertica/bin/vsql -U database_admin_user -w database_admin_user_password -c "select do_tm_task('moveout')";
To verify that no data remains in WOS, type the following command:
/opt/vertica/bin/vsql -U database_admin_user -w database_admin_user_password -c "select sum( region_in_use_size_kb ) as wos_usage_kb from wos_container_storage";

If this command does not return a 0 value, wait 5 minutes and then issue the command again. If after 5 minutes the value that is returned is still greater than 0, retype the command in step 3 and then issue the command in this step again.
To increase the size of WOS to 4 GB, type the following command:
/opt/vertica/bin/vsql -U database_admin_user -w database_admin_user_password -c "alter resource pool wosdata maxMemorySize '4G'";

3.7 CA Spectrum Support and Upgrade Considerations

If you plan to register a CA Spectrum data source with CA Infrastructure Management Release 2.3.4, we recommend upgrading to CA Spectrum Release 9.3. Earlier versions of CA Spectrum do not fully support the following new features:

Synchronization of CA Performance Center IP domains in CA Spectrum
Global collection and landscape synchronization
Drilldown capabilities from device and interface models in CA Spectrum OneClick to CA Performance Center performance data
IP domain-aware synchronized discovery

Note: For information about upgrading CA Spectrum to Release 9.3, see the CA Spectrum Release 9.3 documentation.

3.8 Upgrade Impact for Environmental Sensor - Temperature Status (NormalizedTempSensorInfo) Metric Family and Device Components

New device components discovered based on the Environmental Sensor - Temperature Status metric family have a new context page available out-of-the-box. However, existing device components that are associated with Environmental Sensor - Temperature Status may display on a different context page. This design lets you keep historical data. For existing device components to display on the same context page as the newly discovered device components, delete and rediscover the corresponding devices.

4.0 Allocating Memory Usage

Use the following information to help you configure memory usage for Data Aggregator:

VMs with physical memory that is >= 8 GB
You can allocate less than 85% of the total physical memory.

For example, if a server has 30 GB of physical memory, Data Aggregator uses 30 GB * 0.85 =~ 25 GB.
VMs with physical memory that is < 8 GB
We recommend that you reserve at least 1 GB for the operating system.

For example, if a server has 4 GB of physical memory, Data Aggregator uses 4 GB – 1 GB = 3 GB.

Note: There are two ways to configure memory usage for Data Aggregator. For more information about configuring memory usage during and after installation, see the Installation Guide that is specific to your installation method.
Swap size
Make sure that the swap size is not less than the total physical memory. If the swap size is less than the total physical memory, create a swap file so that the total swap size is not less than the total physical memory.

5.0 Prerequisite for Data Export

Requirements for CPU, memory, network I/O for Data Aggregator have not changed when enabling the data export feature. However, there is an extra requirement for a second, separate partition of disk space storage for the data export. The size of the partition must be 50 GB for a medium size deployment. The 50 GB size permits the retention of one hour of data before a batch job moves the files to another file system.

6.0 Known Issues

6.1 Data Repository Installation or Upgrade Incorrectly Detects Logical Volume Manager (LVM) and Fails

Data Repository cannot be installed if Logical Volume Manager (LVM) is being used to manage volumes that Data Repository uses.

The Vertica database backs Data Repository and Vertica does not support its database running on LVM volumes. Vertica has never supported running its database on LVM. However, starting with Vertica 7 (Data Aggregator Release 2.3.4 requires Vertica 7), the Vertica installer enforces this requirement of not allowing Vertica to run on LVM.

There is a known issue with the Vertica 7.0.1-2 installer. If LVM is detected on any volumes (not just volumes that Vertica uses) within the cluster, the installer will generate a WARN message. The specific WARN message is as follows:

WARN (S0170): https://my.vertica.com/docs/7.0.x/HTML/index.htm#cshid=S0170

lvscan (LVM utility) indicates some active volumes.

If you encounter the WARN message during the execution of dr_install.sh and you have verified that the catalog and data directories that Vertica uses are not managed by LVM, take further steps to help ensure a successful installation or upgrade of Vertica.

Note: If the catalog and data directories that Vertica uses are managed by LVM, refer to the Upgrade Considerations section.

Important! Perform the following steps only after you have verified that the install.sh script has not generated any additional WARN or ERROR messages unrelated to LVM.

Do the following steps:

Search for the line in the dr_install.sh script that begins with “/opt/vertica/sbin/install_vertica”. The line should look like the following line:
/opt/vertica/sbin/install_vertica -s $DB_HOST_NAMES -u $DB_ADMIN_LINUX_USER -l $DB_ADMIN_LINUX_USER_HOME -d $DB_DATA_DIR -L ./resources/$VLICENSE -Y -r ./resources/$VERTICA_RPM_FILE $POINT_TO_POINT_SPREAD_OPTION 2>&1 | tee -a $LOG_FILE
After the “-d $DB_DATA_DIR” entry in the line, add the following new entry, surrounded by a space on each side:
--failure-threshold FAIL

The line should now look like the following line:

/opt/vertica/sbin/install_vertica -s $DB_HOST_NAMES -u $DB_ADMIN_LINUX_USER -l $DB_ADMIN_LINUX_USER_HOME -d $DB_DATA_DIR --failure-threshold FAIL -L ./resources/$VLICENSE -Y -r ./resources/$VERTICA_RPM_FILE $POINT_TO_POINT_SPREAD_OPTION 2>&1 | tee -a $LOG_FILE

Adding this entry will help ensure that the installation will fail only if one or more FAIL messages are encountered during installation. The installation ignores the LVM WARN message and the installation completes successfully.
To install or upgrade Vertica, re-execute the dr_install.sh script. The LVM-specific WARN message is bypassed.
When you re-execute dr_install.sh, you will see the following LVM WARN message:

WARN (S0170): https://my.vertica.com/docs/7.0.x/HTML/index.htm#cshid=S0170

lvscan (LVM utility) indicates some active volumes.

However, this WARN message will not block the installation or upgrade of Vertica 7.

6.2 Data Repository Username and Data Repository Admin Username Cannot Be the Same

When you install the Data Aggregator component and you are prompted for the Data Repository credentials, do not use the same username for the Data Repository username and the Data Repository admin username. The Data Aggregator enforces that these usernames are different during a new installation.

6.3 Multiple Octets and OOB Interface Metric Family

When you create a custom certification for Interface/Port components, if the index of the MIB table has multiple octets (for example: 23.4.5.12), then you cannot use the out-of-box Interface metric family for your certification. Using the Interface metric family in this situation causes synchronization problems in CA Performance Center.

Workaround:

Use the Alternate Interface metric family or create your own custom metric family. This action causes your interface/port items to show up under device components, although this result may not be ideal.

6.4 Unknown Status on Data Collector Instances That Must Be Upgraded

If a Data Collector instance has not been upgraded, it can appear in the System Status table for Data Collectors with a status of Unknown instead of indicating that an upgrade is required.

6.5 Dashboards Include Incorrect Devices or Component Items

If you are upgrading from Release 2.3.1 or prior and CA Performance Center dashboards seem to include devices or component items that are not present in the group that the dashboard was generated for, do the following steps before you upgrade CA Infrastructure Management Data Aggregator:

Type the following command to start vsql:
/opt/vertica/bin/vsql -U username -w password
- username
  Specifies the username that Data Aggregator uses to connect to the database. When installing Data Aggregator for the first time, you can specify a username and any password as long as the password does not match the username. This username and password combination is added to the database during installation.
  
  Example: dauser
- password
  Defines the password for the username that Data Aggregator uses to connect to the database.
Run the following VSQL code:
DELETE FROM item_relationship WHERE left_item_id IN (SELECT item_id FROM item g WHERE g.item_name='group name'); COMMIT;

6.6 Data Aggregator Memory Settings Not Stored in Release 2.3.1 and Release 2.3.2

The installers for Release 2.3.1 and Release 2.3.2 do not store Data Aggregator memory settings in the DA.cfg file when running in a language other than English.

If you already upgraded CA Infrastructure Management from Release 2.3.1 to Release 2.3.2 or Release 2.3.3 on any language other than English, do the following steps to update the Data Aggregator memory settings manually:

Log in to the computer where Data Aggregator is installed. To stop Data Aggregator, open a command prompt and type the following command:
service dadaemon stop
Access the Data Aggregator installation directory/apache-karaf-2.3.0/bin/setenv.old file.
Locate and make note of the number unit in the export IM_MAX_MEM=number unit line.
Access the Data Aggregator installation directory/apache-karaf-2.3.0/bin/setenv file.
Add the number unit that you noted earlier and add it to the export IM_MAX_MEM= line.
Save the file.
To restart Data Aggregator, type the following command:
service dadaemon start

If you have not yet upgraded CA Infrastructure Management from Release 2.3.1 to Release 2.3.2 or Release 2.3.3 on any language other than English, do the following steps to update the Data Aggregator memory settings manually:

Verify that the /etc/DA.cfg file does not have the da.memory variable defined. If the da.memory variable is defined, you can upgrade CA Infrastructure Management and you do not need to continue with this procedure. The following information is a sample DA.cfg file:
da.home=/opt/IMDataAggregator

da.karaf.home=/opt/IMDataAggregator/apache-karaf-2.3.0

da.version=2.3.2.1

da.user=root

da.memory=2369M

da.activemq.home=/opt/IMDataAggregator/broker/apache-activemq-5.5.1d

da.activemq.memory=790M

da.activemq.version=5.5.1d
Access the Data Aggregator installation directory/apache-karaf-2.3.0/bin/setenv file. Locate and make note of the number unit in the export IM_MAX_MEM=number unit line.
Access the Data Aggregator installation directory/broker/apache-activemq-5.5.1X directory and make a note of he activemq.home information.
Access the Data Aggregator installation directory/broker/apache-activemq-5.5.1X/bin/activemq file. Locate and make note of the number unit in the ACTIVEMQ_OPTS_MEMORY=number unit line. Locate and make a note of the activemq version.
Update the DA.cfg file with the following information that you made a note of:
- da.memory
- da.activemq.home information
- da.activemq.memory
- da.activemq.version
Upgrade CA Infrastructure Management.

7.0 Documentation Known Issues

7.1 Steps for Changing the Data Aggregator IP Address Are Incorrect

The steps for changing the Data Aggregator IP address in the topic "Troubleshooting: A Change in My Environment Requires That I Change the Data Aggregator IP Address" are incorrect. You do not have to modify any files with the Data Aggregator IP address change. Simply restart Data Aggregator for the IP address change to take effect.

Do the following steps:

Stop Data Aggregator by logging in to the computer where Data Aggregator is installed as the root user. Type the following command:
service dadaemon stop

Data Aggregator stops.
Restart Data Aggregator by logging in to the computer where Data Aggregator is installed as the root user. Open a command prompt and type the following command:
service dadaemon start

7.2 Steps for Setting Up Passwordless SSH for Root User Are Missing

In the Data Aggregator installation guides, the topic "Install the Data Repository Component", is missing an optional step. After step 7, and before step 8, you can optionally set up passwordless SSH for the root user in cluster environments. When you set up passwordless SSH, the root user is not required to input credentials during installation. To set up passwordless ssh for the root user from one Data Repository host to another, do the following steps:

Open a console and log in to the Data Repository host as the root user.
Type the following commands:
ssh-keygen -N "" -t rsa -f ~/.ssh/id_rsa

cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys2

chmod 644 ~/.ssh/authorized_keys2
To copy the root user public key into the remote host's list of authorized keys, type the following command:
ssh-copy-id -i root_user@remotehost
- remotehost
  Is another host in the cluster where you are copying the SSH ID.
To verify that passwordless ssh is set up correctly, login to the remote host from the local host:
ssh root_user@remotehost ls
Repeat steps 1-4 for each pair of hosts.
Note: A three-node cluster requires six variations of the previous steps.

If the passwordless SSH has been set up successfully, you are not prompted for a password. You also see a directory listing from the ‘ls command’.

7.3 Procedure in the Export Data Scenario is Unclear

The procedure, "Start the Rate Data Export Feature" in the scenario "Export Data" is unclear. The correct steps for this procedure are as follows:

Set up a REST client with a connection to the Data Aggregator server.
Set the REST client's Content-type to application/xml.
Enter the following URL:
GET http://da_hostname:port/rest/dataexport/
Take note of the id of the data export profile you wish to modify. By default, there is only one profile.
Enter text in the Body tab of the HTTP Request pane. At a minimum, set Enabled to true. For example:
   <DataExportInfo version="1.0.0">

               <Enabled>true</Enabled>

   </DataExportInfo>
Review other options that can be set at the following URL:
http://da_hostname:port/rest/dataexport/xsd/get.xsd
Save and start the rate data export feature by entering the following URL:
PUT http://da_hostname:port/rest/dataexport/id
- da_hostname:port
  Specifies the Data Aggregator host name and the port number.
  
  Default port: 8581
- id
  Specifies the ID of the Data Export service.
  
  Note: The following URL retrieves the ID of the Data Export service:
  
  GET http://da_hostname:port/rest/dataexport
To verify that your changes took effect, enter the following URL:
GET http://da_hostname:port/rest/dataexport/id

The data export starts automatically and temporary export files are created.

When the export file is ready, the exporter automatically renames it to the file extension you configured previously (such as .csv).

You do not need to restart the services for a newly written file.

After the data is exported, copy the data to your other system using the method required by that other system.

Important! You must regularly process the output CSV files to avoid exhausting the available disk space.

7.4 MaxPercentofPollCycle Parameter Should Not Be Documented

The scenario, "Monitor the Health of the Threshold Monitoring Engine" incorrectly discusses how to increase the MaxPercentOfPollCycle parameter. This parameter has been removed from the product and is not available.

7.5 Troubleshooting: Vertica Fails to Install in a Cluster Environment Topic Missing from Installation Guides

The topic "Troubleshooting: Vertica Fails to Install in a Cluster Environment " is missing from the Data Aggregator installation guides.

Symptom:

Vertica fails to install in my cluster environment.

Solution:

Set up passwordless SSH for the Vertica Linux database administrator user and then retry the installation. Do the following steps to set up passwordless SSH:

Open a console and log in to the Data Repository host as the Vertica Linux database administrator user.
Type the following commands:
ssh-keygen -N "" -t rsa -f ~/.ssh/id_rsa

cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys2

chmod 644 ~/.ssh/authorized_keys2
To copy the Vertica Linux database administrator user public key into the remote host's list of authorized keys, type the following command:
ssh-copy-id -i database_admin_user@remotehost
- remotehost
  Is another host in the cluster where you are trying to copy the SSH ID.
To verify that passwordless ssh is set up correctly, login to the remote host from the local host:
ssh database_admin_user@remotehost ls
Repeat steps 1-4 for each pair of hosts.
Note: A three-node cluster requires six variations of the previous steps.

If the passwordless SSH has been set up successfully, you are not prompted for a password. You also see a directory listing from the ‘ls command’.

8.0 Contact CA Technologies

Contact CA Support

For your convenience, CA Technologies provides one site where you can access the information that you need for your Home Office, Small Business, and Enterprise CA Technologies products. At http://ca.com/support, you can access the following resources:

Online and telephone contact information for technical assistance and customer services
Information about user communities and forums
Product and documentation downloads
CA Support policies and guidelines
Other helpful resources appropriate for your product

Providing Feedback About Product Documentation

If you have comments or questions about CA Technologies product documentation, you can send a message to techpubs@ca.com.

To provide feedback about CA Technologies product documentation, complete our short customer survey which is available on the CA Support website at http://ca.com/docs.