Administering Virtual Appliance

On logging in to the web UI, a Dashboard is displayed. The Dashboard lets you monitor the services, view the application URLs, download external tools, and view the Setup menu for additional configuration.
cislp143
On logging in to the web UI, a Dashboard is displayed. The Dashboard lets you monitor the services, view the application URLs, download external tools, and view the Setup menu for additional configuration.
This article contains the following sections:
Required Network Ports
The network ports that are required by the Virtual Appliance are as follows:
Application / Service
From
To
Destination Port
Application Protocol
Details
SSH
All Virtual Appliance servers
All Virtual Appliance servers
TCP/22
SSH
Mandatory for Virtual Appliance internal health checks.
SSH
Customer network
All Virtual Appliance servers
TCP/22
SSH
For remote administration using SSH (optional).
CA Identity Governance
All Virtual Appliance servers
All Virtual Appliance servers running CA Identity Governance
TCP/8082
TCP/8445
TCP/8789
HTTP
HTTPS
JDWP/ (Java Debug)
  • Mandatory for Virtual Appliance internal health checks.
  • Optional for HTTPS connection to the application.
  • Debug port
CA Identity Governance
SSO proxy server
All Virtual Appliance servers running CA Identity Governance
TCP/8011
-
Optional: AJP port for SSO integration with a proxy that uses the mod_jk module.
CA Identity Manager
All Virtual Appliance servers
All Virtual Appliance Servers running CA Identity Manager
TCP/8080
TCP/8443
TCP/8787
HTTP
HTTPS
JDWP (Java Debug)
  • Mandatory for Virtual Appliance internal health checks.
  • Optional for HTTPS connection to the application.
  • Debug port
CA Identity Manager
SSO proxy server
All Virtual Appliance Servers running CA Identity Manager
TCP/8009
-
Optional: AJP port for SSO integration with a proxy that uses the mod_jk module.
CA Identity Portal
All Virtual Appliance servers
All Virtual Appliance servers running CA Identity Portal
TCP/8081
TCP/8444
TCP/8788
HTTP
HTTPS
JDWP (Java Debug)
  • Mandatory for Virtual Appliance internal health checks.
  • Optional for HTTPS connection to the application.
  • Debug port
CA Identity Portal
SSO proxy server
All Virtual Appliance servers running CA Identity Portal
TCP/8010
-
Optional: AJP port for SSO integration with a proxy that uses the mod_jk module.
End-User Web UI and Embedded Proxy
Customer network
All Virtual Appliance servers
TCP/80
TCP/443
HTTP
HTTPS
  • Mandatory for customers to access applications (CA Identity Portal, CA Identity Manager, CA Identity Governance).
  • Handled by an internal proxy/load-balancer listening on ports 80 and 443 (User Portal).
Virtual Appliance Admin Web UI
Management network
All Virtual Appliance servers
TCP/10443
HTTPS
  • Mandatory for administrators to access the Admin Portal on port 10443.
  • Accessing this port must be allowed only from a management network/VLAN.
CA Provisioning Server
All Virtual Appliance servers running Provisioning Server
All Virtual Appliance servers running Provisioning Server
TCP/20391
TCP/20394
TCP/20396
TCP/20398
TCP/20404
LDAPS
LDAPS
LDAPS
LDAPS
LDAPS
Mandatory for replication and load-balancing.
CA Provisioning Server
All Virtual Appliance servers running CA Identity Manager
Management network
TCP/20389
TCP/20390
LDAP
LDAPS
  • Mandatory requirement by CA Identity Manager.
  • Optional for direct access using CA Provisioning Manager.
CA User Store
All Virtual Appliance servers running CA Identity Manager
All Virtual Appliance servers running User Store
All Virtual Appliance servers running User Store
TCP/10101
TCP/19289
LDAP (LDAPS in FIPS mode)
LDAP (LDAPS in FIPS mode)
  • Mandatory requirement by CA Identity Manager.
  • Mandatory for replication and load-balancing.
CA Java Connector Server
Management network
All Virtual Appliance servers running Connector Server
TCP/20080
TCP/20443
HTTP
HTTPS
Mandatory for Connector Server admin Web-UI.
CA Java Connector Server
All Virtual Appliance servers running Provisioning Server
All Virtual Appliance servers running Connector Server
TCP/20410
TCP/20411
HTTP
HTTPS
Mandatory requirement by Provisioning Server.
Central Logs Service
All Virtual Appliance servers running:
  • CA Identity Manager
  • CA Identity Governance
  • CA Identity Portal
  • Connector Server
All Virtual Appliance server running Central Logs
UDP/514
-
Mandatory requirement by Central Logs.
CA Connector Server (External)
All Virtual Appliance servers running Provisioning Server
External servers running Connector Server
TCP/20410
TCP/20411
HTTP
HTTPS
Mandatory requirement by Provisioning Server.
Log Files Location
The Virtual Appliance includes symbolic-links to all applications / services log files and directories in the
/opt/CA/VirtualAppliance/logs
directory.
The default location of log files of all the applications / services are as follows. These are the actual files that are referenced by the symbolic links in the
/opt/CA/VirtualAppliance/logs
directory.
Application / Service
Log File Location
CA Identity Portal
/opt/CA/wildfly-portal/standalone/log/server.log
CA Identity Manager
/opt/CA/wildfly-idm/standalone/log/server.log
CA Identity Governance
/opt/CA/wildfly-ig/standalone/log/eurekify.log
Provisioning Server
/opt/CA/IdentityManager/ProvisioningServer/logs/im_ps.log
Connector Server
opt/CA/IdentityManager/ConnectorServer/jcs/logs/jcs_daily.log
vApp main log
/opt/CA/VirtualAppliance/logs/ca_vapp_main.log
vApp deployment log
/opt/CA/VirtualAppliance/logs/ca_vapp_deployment.log
vApp web-server log
/opt/CA/VirtualAppliance/logs/ca_vapp_webui.log
Oracle database
(not applicable when using an external database with the vApp)
/u01/app/oracle/diag/rdbms/xe/XE/trace
Supported Custom Files
The following CA Identity Suite components support custom files:
  • CA Identity Portal
  • CA Identity Manager
Purpose
CA Identity Manager Reference Path   
Virtual Appliance Reference Path
/iam_im.ear/user_console.war/WEB-INF/lib
/iam_im.ear/user_console.war/WEB-INF/lib
/opt/CA/VirtualAppliance/custom/IdentityManager/iam_im.ear_user_console.war_WEB-INF_lib
Custom folder for components such as Event Listener, LAH’s
/iam_im.ear/custom
/opt/CA/VirtualAppliance/custom/IdentityManager/custom
CA SSO customizations
/opt/CA/VirtualAppliance/custom/IdentityManager/custom
/opt/CA/VirtualAppliance/custom/IdentityManager/SiteMinder_config/ra.xml.
Import Custom Connector Role Definition
After you deploy a custom connector to the Provisioning Server on Virtual Appliance, perform the following steps:
  1. Create a custom .jar file for role definitions using
    RoleDefinitionGenerator
    .
    cd /opt/CA/IdentityManager/IAM_Suite/IdentityManager/tools/RoleDefinitionGenerator/bin/
    ./RoleDefGenerator.sh -h localhost -u etaadmin "<Custom Jar File>"
  2. Provide permission to the <Custom Jar File> created in step 1.
    chmod 777 <Custom Jar File>
  3. Copy <Custom Jar File> to /opt/CA/VirtualAppliance/custom/IdentityManager/iam_im.ear_user_console.war_WEB-INF_lib/.
  4. Restart CA Identity Manager server.
Uploading and Replicating Custom Files
When using Virtual Appliance, use an SCP utility (such as “WinSCP”) to upload any custom files to the /opt/CA/VirtualAppliance/custom/ directory, under the corresponding sub-directory:
/opt/CA/VirtualAppliance/custom/IdentityManager
/opt/CA/VirtualAppliance/custom/IdentityPortal
/opt/CA/VirtualAppliance/custom/IdentityGovernance
/opt/CA/VirtualAppliance/custom/apache-ssl-certificates
Note:
When CA Identity Manager or CA Identity Portal is installed in a
cluster
, perform the following additional steps:
  1. Upload or create the custom file on
    one node
    .
  2. Open a CLI or SSH terminal on the same node.
  3. Change to the directory where the files were created or uploaded.
  4. Run the following script to synchronize the custom files with other nodes. This performs a “push” replication from the current node to other nodes.
    vapp_sync
Replacing Virtual Appliance Web UI SSL Certificate
The following directory contains the SSL certificates that are used by the built-in Virtual Appliance management web UI:
/opt/CA/VirtualAppliance/custom/apache-ssl-certificates
You can replace the following files with your own generated SSL certificates in Apache HTTP server compatible format:
  • localhost.crt (public key)
  • localhost.key (private key)
Notes:
  • Ensure that you back up the certificates before replacing them.
  • After replacing the certificates, run the following command to reload the web server on every server on which the certificates were replaced. The server starts with the replaced certificates:
    sudo /etc/init.d/httpd reload
  • If the certificate pair is missing/invalid, an error message is displayed on the console.
Mounting Network Drives
The Virtual Appliance supports mounting of the network drives based on the standard Linux kernel support.
Example:
NFS shares, SMB/CIFS shares
Temporarily Mounting a Network File System
You can use the standard Linux "
mount
" command to perform a provisional mount.
For example, to mount an SMB/CIFS share that is on \\132.70.100.10\temp to the
/home/config/temp
mount point using credentials listed in the file
/home/config/creds.txt
., run the following command:
mount -t cifs -ocreds=/home/config/creds.txt,noserverino,dir_mode=0777,file_mode=0777 //132.70.100.10/temp /home/config/temp
Permanently Mounting a Network File System
As the provisional mount command does
not persist
after rebooting the server, it is advised to use the
MountNetworkShares
command. This command performs mount operations according to a
configuration file
and supports persistence as the configuration it uses is processed by the Virtual Appliance platform scripts on every boot.
The configuration file for the
MountNetworkShares
command resides in:
/opt/CA/VirtualAppliance/custom/mounts
Follow the steps to perform persistent mount operations using the MountNetworkShares command:
  1. Edit the following file:
    /opt/CA/VirtualAppliance/custom/mounts
  2. Define any mount points, for example:
    [Device] [Mount Point] [File System Type] [Options]
    10.20.3.2:/public /home/config/my-nfs-mount-point nfs
    //10.20.3.1/some-share /home/config/my-cifs-mount-point cifs username=my-user,password=my-pass
    Note:
    Run
    MountNetworkShares -h
    to view the syntax that is used in the configuration file.
  3. Save the file and exit.
  4. Run the
    MountNetworkShares
    command
    again to perform immediate mounting.
    The command writes a detailed output to the console regarding each mount operation performed.
Custom JVM Arguments
The Virtual Appliance comes with suggested default JVM configuration for CA Identity Manager, CA Identity Governance, and CA Identity Portal application servers. These JVM arguments include static values and dynamic values such as minimum and maximum heap size set based on the deployment type (for example, Demo, Production).
For example, the following JVM arguments are set for CA Identity Manager that is deployed in Demo mode:
-Xms512m -Xmx2048m -XX:+UseG1GC -XX:+UseStringDeduplication -XX:+UseCompressedOops -Djava.net.preferIPv4Stack=true -Djava.awt.headless=true -XX:+UseLargePages -Djava.security.egd=file:/dev/./urandom
Customizing the JVM Startup Arguments
The Virtual Appliance supports customization of JVM startup arguments.
Changing the JVM arguments may result in the application server startup failure or may cause run-time issues during normal operation or stress performance. In such situations, revert to the out of the box JVM suggested configuration by commenting out the lines in the jvm-args.conf file and restarting the application server.
Perform the following steps to modify the out-of-the-box JVM arguments on Identity Manager, Identity Governance, Identity Portal:
  1. Log in to the target server via SSH/CLI as the default Virtual Appliance
    (config/ec2-user) user.
  2. Edit the
    jvm-args.conf
    file for the relevant product:
    /opt/CA/VirtualAppliance/custom/IdentityManager/jvm-args.conf /opt/CA/VirtualAppliance/custom/IdentityGovernance/jvm-args.conf /opt/CA/VirtualAppliance/custom/IdentityPortal/jvm-args.conf
  3. Uncomment the following line, or duplicate it and uncomment the copied line:
    From:
    #JAVA_OPTS=...
    To:
    JAVA_OPTS=...
  4. Make the necessary changes to the JVM arguments specified after the "=" character.
  5. Save the file.
  6. Restart the application server by running the corresponding alias for the product:
    restart_im
    restart_ig
    restart_ip
Perform the following steps to modify the out-of-the-box JVM arguments for Connector Server:
  1. Log in to the target server via SSH/CLI as the default Virtual Appliance
    (config/ec2-user) user.
  2. Edit the /opt/CA/IdentityManager/ConnectorServer/data/
    jvm_options.conf
    file.
  3. Restart Connector Server:
    restart_jcs
Custom Host Records
The Virtual Appliance uses the /etc/hosts file to store common host names for internal use.
You must prefer using DNS names instead of adding records to the /etc/hosts file.
In case you have to edit the /etc/hosts file, perform the following steps on each Virtual Appliance host which requires custom host mapping:
  1. Log in the Virtual Appliance server using SSH/CLI
  2. Create or edit the following file:
    /opt/CA/VirtualAppliance/custom/hosts
  3. Add the custom host records in a format equivalent to the /etc/hosts format, for example:
    192.168.1.54 myhost01
    192.168.1.58 myhost02
    192.168.1.160 myhost03
  4. Run the following command:
    configureCustomHostRecords
  5. View the /etc/hosts file and notice that the following block was added/modified to reflect the custom hosts block:
    # CA VAPP CUSTOM HOSTS - START
    192.168.1.54 myhost01
    192.168.1.58 myhost02
    192.168.1.160 myhost03
    # CA VAPP CUSTOM HOSTS - END
Modify CA Identity Manager Branding
Follow the given instructions on each CA Identity Manager node to edit a skin in the Virtual Appliance based CA Identity Manager.
  1. Navigate to the following location:
    cd /opt/CA/VirtualAppliance/custom/IdentityManager/branding/
  2. Create your own skin. This is typically done by copying an existing template skin directory from
    iam_im.ear/user_console.war/app/<SKIN_NAME>
    and modifying the contents.
    For example, the steps to copy the "
    ui7
    " skin to a custom skin named "
    my-custom-skin
    " are as follows:
    mkdir my-custom-skin cp -rp /opt/CA/wildfly-idm/standalone/deployments/iam_im.ear/user_console.war/app/ui7 /opt/CA/VirtualAppliance/custom/IdentityManager/branding/my-custom-skin
  3. Modify the skin as required.
  4. Navigate to the following location.
    /opt/CA/VirtualAppliance/custom/IdentityManager/branding
  5. Edit the
    index.jsp
    file and reference the new skin, for example:
    <skin:update>
    <skin:skin name ="my-custom-skin" filename="/app/imcss/my-custom-skin/ui7/ca/ca.properties"/>
    <skin:skin name="idm" filename="/app/imcss/idm/idm.properties" />
    <skin:skin name="neteauto" filename="/app/imcss/neteauto/neteauto.properties" />
    <skin:skin name="horizontal" filename="/app/imcss/horizontal/horizontal.properties" />
    <skin:skin name="horizontal2" filename="/app/imcss/horizontal2/horizontal2.properties" />
    </skin:update>
  6. Save the file.
  7. Edit the
    <SKIN_NAME>/ui7/ca/ca.properties
    file and change the
    resourceBaseName
    property to direct to the resources file of the new skin.
    For example:
    resourceBaseName=/app/imcss/my-custom-skin/ui7/resources
  8. Save the file.
  9. Edit
    <SKIN_NAME>/ui7/index.jsp
    file and change the
    skin:update
    property to direct to the ca.properties file of the new skin.
    For example:
    <skin:update>
    <skin:skin name="my-custom-skin" filename="/app/imcss/my-custom-skin/ui7/ca/ca.properties"/>
    </skin:update>
  10. Save the file.
  11. In order to have branding in place for
    login.jsp
    file, make the following changes in the custom styles folder that you created. These folders are preserved during an upgrade.
    1. As the config user, execute the following commands:
      cd /opt/CA/VirtualAppliance/custom/IdentityManager/branding/imcss/my-custom-skin/
      cp /opt/CA/wildfly-idm/standalone/deployments/iam_im.ear/user_console.war/login.jsp ui7
    2. Customize /opt/CA/VirtualAppliance/custom/IdentityManager/branding/imcss/my-custom-skin/ui7/login.jsp to your needs.
      vi /opt/CA/VirtualAppliance/custom/IdentityManager/branding/imcss/my-custom-skin/ui7/login.jsp
    3. In the
      Identity Suite
      Management Console, navigate to
      Environments
      and select an environment.
      1. Navigate to
        Advanced Settings
        ,
        User Console
      2. Configure the
        Login page to use
        under
        Authentication Properties
        as
        /app/imcss/my-custom-skin/ui7/login.jsp
        .
      3. Configure
        Theme Properties
        as required.
  12. Restart CA Identity Manager.
  13. Access the environment with the following URL:
    https://<domain>/iam/im/identityEnv/imcss/my-custom-skin/ui7/index.jsp
    Note:
    Since WildFly application server loads the static files, the logo.png file must have at least the Read permission. Else, the company logo fails to load or looks broken.
    Example Path:
    imcss/my-custom-skin/ui7/ca/images.
CA Identity Governance Login Page Customization
To customize the CA Identity Governance login page, perform these steps:
  1. Navigate to
    /opt/CA/VirtualAppliance/custom/IdentityGovernance/branding
    .
  2. Edit
    the
    login_page
    file with new changes.
  3. After restarting CA Identity Governance, the changes will reflect in
    eurekify.war/WEB-INF/classes/com/eurekify/web/Login_castyles-r7.html
    .
Moving CA Identity Suite Data Services between Cluster Nodes
CA Identity Suite data services are unique. They store customer or deployment-specific data, such as users in the user store and endpoint accounts in the Provisioning Server.
The following are the CA Identity Suite data services:
  • User Store
  • Provisioning Server
  • Oracle Database Express 11g – the embedded Virtual Appliance database
Moving the User Store or the Provisioning Server Services
When moving the data services, perform the following procedures to verify that the data that is stored in the service is also moved to the new node.
Note:
The following procedures are for the User Store service, but are applicable for the Provisioning Server service too.
Scenario 1 – Single instance of the data service deployed in the cluster
Example:
You have a three-node cluster with the User Store service deployed only on one node.
  • Node 1: CA Identity Manager, CA Identity Portal, User Store
  • Node 2: CA Identity Manager, CA Identity Portal
  • Node 3: New node (added to the cluster)
You want to move the User Store service from Node 1 to the new Node 3, for freeing up the resources on Node 1.
Follow these steps:
  1. From the Virtual Appliance Admin UI, navigate to the Setup page.
  2. Add the new node (Node 3) to the cluster.
  3. From the Services pane on the left, drag a new User Store service to the new node (Node 3).
  4. Deploy the configuration.
  5. After the deployment completes (all services start on all nodes), the data service on the new node (Node 3) automatically replicates the data from the existing User Store service on Node 1. During this replication, the service on the new node (Node 3) is in offline mode and does not serve the cluster.
  6. Connect directly to the data service on the new node (Node 3) to verify if the replication is completed.
    Example:
    Using JExplorer, see the Virtual Appliance UI online help page for connectivity details to the various data services. If the connection succeeds and you can see your data, replication has completed.
    Note:
    Replication of large data sets can take a longer time, depending on the size of the data set and the performance of your network. Replication time can be from few minutes to few hours.
  7. On successful completion of replication and when the new data service can service a request, you can remove the old service from the original node (Node 1).
  8. To remove the old service, navigate to the Virtual Appliance Admin UI Setup page again. Drag the data service from Node1 toward the Services pane. This removes the data service from the configuration. You are now left with only the new data service on the new node (Node 3).
  9. Press
    Deploy
    .
  10. After a successful deployment, the data service exists only on the new node (Node 3).
Scenario 2 – Multiple instances of the data service deployed in the cluster
Example:
You have a four-node cluster with the User Store service that is deployed on Node1 and Node2 of the cluster but not on Node3 and Node4.
  • Node 1: User Store
  • Node 2: CA Identity Manager, CA Identity Governance, User Store
  • Node 3: CA Identity Manager
  • Node 4: CA Identity Governance
You want to move the User Store service from Node 2 to Node 4 for freeing up the resources on Node 2.
Follow these steps:
  1. From the Virtual Appliance Admin UI, navigate to the Setup page.
  2. In the Machines pane on the right, identify the node from which you want to remove the service (Node 2 in this example).
  3. From the Machines pane, drag the existing User Store service that you want to move to the Services pane on the left.
    This marks the instance of that service for removal from the node (Node2).
  4. From the Services pane on the left, drag a new User Store service to the node to which you want to move the service to (Node4 in this example).
  5. Deploy the configuration.
  6. After the deployment completes (all services start on all nodes), the data service on the new node (Node 4) automatically replicates the data from the other User Store service (which you did not touch) on Node 1.
  7. During this replication, the service on the new node (Node 4) is in offline mode and does not serve the cluster.
  8. Connect directly to the data service on the new node (Node 4) to verify that replication has completed.
    Example:
    Using JExplorer, see the Virtual Appliance UI online help page for connectivity details to the various data services. If the connection succeeds and you can see your data, replication has completed.
    Note:
    Replication of large data sets can take a long time, depending on the size of the data set and the performance of your network. Replication time can be from few minutes to few hours.
  9. On successful completion of replication if the new data service can service a request, then the data service move is complete. No further action is required.
Moving the Oracle Database Express Service
Virtual Appliance does not support movement of the Oracle Database Express service data; however it supports the movement of a service.
Moving the service causes reinitialization of the data to an Out of the box (Factory Default) configuration. All customer or deployment-specific data is lost.
To preserve the data, use the Oracle supplied tool “exp and imp” to backup and restore your database.
Use the exp command to backup your data before moving the service. Use the imp command to restore your data, after the service has been moved to a new node.
To use these commands, perform SSH to the Virtual Appliance and run the following command on the command line to switch user to the Oracle user:
su – oracle”
Note:
See Oracle documentation for more information about using the exp and imp tools.
Follow these steps:
  1. From the Virtual Appliance Admin UI, navigate to the Setup page.
  2. In the Machines pane on the right, identify the node from which you want to remove the service.
  3. From the Machines pane, drag the existing Database service that you want to relocate, to the Services pane on the left.
    This marks the instance of that service for removal from the node.
  4. From the Services pane on the left, drag a new Database service to the new node to which you want to move the service.
  5. Deploy the configuration.
  6. After the deployment completes (all services start on all nodes), the database service on the new node is initialized with factory default data. The old data in the database is lost.
    If necessary, see Oracle documentation for information about restoring a backup of the original data.
Enabling Debugging Port on CA Identity Manager
To speed up the development process of
Business Logic Task Handlers (BLTH)
and
Event Listeners
in CA Identity Manager, do the following:
  1. Start the WildFly application server for CA Identity Manager in
    debug mode.
  2. Connect to the application server from the development environment (Eclipse). This allows you to execute one line of code at a time, thus making the debugging process easier.
To start CA Identity Manager in debug mode, run the following command:
stop_im
start_im --debug
Note:
When you start CA Identity Manager in debug mode, it runs with "
suspend=Y
" unless you specify "
--no-suspend
" as a second argument.
The following message is displayed.
[INFO] enabling debug mode for /opt/CA/wildfly-idm
The debugger port listens on port
8787
.
Adding Additional Network Interfaces and Static Routes
The Virtual Appliance supports adding up to ten additional network interfaces and adding static routes on a per-NIC basis.
Add Static Routes
  1. Edit the route interface configuration files for the corresponding network interfaces: /etc/sysconfig/network-scripts/ifcfg-eth
    X
    Example:
    vim /etc/sysconfig/network-scripts/route-eth
    1
  2. Add static routes using the following syntax:
    10.10.10.0/24 via 10.20.30.254 dev eth0
  3. Run the following command to apply the network configuration:
    Running this command may disconnect active sessions to the server.
    We recommend that you run this command only when CLI/console access to the node is available so that if the network service fails to restart, you can use the CLI/console to revert the configuration.
    service network reload
    If syntax or logical subnet errors are present, you see the following errors:
    For example
    1. Error in IP address syntax:
    Bringing up interface eth0:  Error: an inet address is expected rather than "10.20.30.2544".
    2. Defined gateway is not local to the interface:
        Bringing up interface eth0:  RTNETLINK answers: No such process
  4. Run the following command to inspect the routing table:
    route -n
    Expected Output
    :
    (The line that is highlighted in
    green
    represents the static route entry)
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use Iface
    10.20.30.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 → The system has a single NIC on the
    10.20.30.0/24
    subnet.
    10.10.10.0 10.20.30.254 255.255.255.0 UG 0 0 0 eth0 →
    Traffic destined for
    10.10.10.0/24
    will route via
    10.20.30.254
    0.0.0.0 10.20.30.1 0.0.0.0 UG 0 0 0 eth0 → All other traffic will route via
    10.20.30.1
Add Network Interfaces:
  1. Shut down the server.
  2. Ask the ESX administrator to add any additional network interfaces.
  3. Power on the server.
  4. Run the following command to verify that the additional network interfaces were registered:
    ifconfig -a | grep addr
    Expected Output:
    eth0 Link encap:Ethernet HWaddr 00:0C:29:B0:FB:C5
    inet addr:10.0.0.240 Bcast:10.0.0.255 Mask:255.255.255.0
    eth1 Link encap:Ethernet HWaddr 00:0C:29:B0:FB:D9
    eth2 Link encap:Ethernet HWaddr 00:0C:29:B0:FB:E3
    eth3 Link encap:Ethernet HWaddr 00:0C:29:B0:FB:CF
    The first network interface (eth0) is the primary Virtual Appliance network interface, and you must only change the IP address of additional NICs (Example: eth2, eth3, eth4...).
  5. Edit the network interface configuration files for the corresponding network interfaces: /etc/sysconfig/network-scripts/ifcfg-eth
    X
    For example:
    vim /etc/sysconfig/network-scripts/ifcfg-eth
    1
  6. Define the IP configuration and save the file.
    For example, – the following sets an IP address of 10.0.0.242 and a network mask of /24 ( = 255.255.255.0):
    DEVICE=eth1
    TYPE=Ethernet
    ONBOOT=yes
    NM_CONTROLLED=no
    BOOTPROTO=STATIC
    IPADDR=10.0.0.242
    NETMASK=255.255.255.0
    #GATEWAY=
    #DHCP_HOSTNAME=
  7. Run the following command to apply the network configuration:
    Running this command may disconnect active sessions to the server.
    We recommend that you run this command only when CLI/console access to the node is available so that if the network service fails to restart, you can use the CLI/console to revert the configuration.
    service network reload
  8. Run the following command to verify that the IP address was registered to the network interface:
    ifconfig -a | grep addr
    Expected Output:
    eth0 Link encap:Ethernet HWaddr 00:0C:29:B0:FB:C5
    inet addr:10.0.0.240 Bcast:10.0.0.255 Mask:255.255.255.0
    eth1 Link encap:Ethernet HWaddr 00:0C:29:B0:FB:D9
    inet addr:
    10.0.0.242
    Bcast:10.0.0.255 Mask:
    255.255.255.0
    eth2 Link encap:Ethernet HWaddr 00:0C:29:B0:FB:E3
    eth3 Link encap:Ethernet HWaddr 00:0C:29:B0:FB:CF
    inet addr:127.0.0.1 Mask:255.0.0.0
Changing DNS Configuration
To change the DNS server IP on the Virtual Appliance that is already deployed, follow the given steps:
  1. In the Virtual Appliance, open
    /etc/resolv.conf
    for editing.
  2. In the file, change the IP address in the
    nameserver
    field to a desired value.
    Sample snippet of the file:
    ; generated by /sbin/dhclient-script search localdomain nameserver 192.168.73.2 nameserver 192.168.73.3
  3. Save the file.
Support for Provisioning Server to Listen on Multiple IP Addresses
For the Provisioning Server to listen on multiple IP addresses, do the following:
  1. Navigate to
    /opt/CA/VirtualAppliance/custom/IdentityManager
    and
    open
    PS-bind.properties
    for editing
    .
  2. In the properties file, include the local IP addresses (each address in a separate line) on which the Provisioning Server must listen, or "0.0.0.0" to listen on all interfaces.
Use a Single JasperReports Server for Multiple Virtual Appliance Solutions
You can use a single JasperReports Server for multiple Virtual Appliance solutions.
A custom JasperReports key for CA Identity Manager is stored at
/opt/CA/VirtualAppliance/custom/IdentityManager/keystore.
On each CA Identity Manager startup, this key is copied to
/opt/CA/wildfly-idm/modules/com/ca/iam/cajasper/main/
and also copied to
/opt/CA/VirtualAppliance/custom/IdentityManager/keystore
on
all  CA Identity Manager nodes in multiple Virtual Appliance solutions.
Apply Pre-login and Post-login Banner
To apply pre-login and post-login banners, perform the following steps:
  1. Run the below commands to edit the relevant pre/post login banner files:
    vim /opt/CA/VirtualAppliance/custom/login-prompt.pre
    vim /opt/CA/VirtualAppliance/custom/login-prompt.post
  2. Make the desired changes and save the files.
  3. Run the following command to apply the banner:
    configureLoginPrompt
    The following output is displayed:
    [INFO] Configuring pre-login banner
    [INFO] Configuring post-login banner
  4. Upon the next SSH or CLI login, the relevant pre/post banner is displayed:
    login as: config
    PRE-LOGIN BANNER TEXT
    config@<IP Address>'s password:
    Last login: <DATE> from <IP Address>
    POST-LOGIN BANNER TEXT
Enable Key-Based Authentication to a Remote SSH Server
To connect to a remote SSH Server using a key-based authentication, use the
wildfly-ssh-keymgr
command. This command enables the following functions:
  1. Generate an SSH key pair that is owned by WildFly.
  2. Remove an existing SSH key pair that is owned by Wildfly.
  3. List all SSH keypairs that are owned by Wildfly.
  4. Export an SSH key pair that is owned by Wildfly.
All the generated keys are stored in the following directory (Accessible only by the "wildfly" user):
/opt/CA/VirtualAppliance/conf/wildfly-ssh-keys
In order to use a specific key, the ssh command should reference the exact key name in the directory using the following syntax:
ssh -o StrictHostKeyChecking=no -i /opt/CA/VirtualAppliance/conf/wildfly-ssh-keys/my_custom_key1 <username>@<remote host> "<remote command>"
Backup and Restore Virtual Appliance
To backup the Virtual Appliance configurations and data, run the command on all the cluster nodes:
backupVapp
To restore the Virtual Appliance configurations and data to a replacement server, run the command on all the cluster nodes:
restoreVapp
Custom Firewall Configuration
Virtual Appliance supports custom firewall configuration. To configure a custom firewall system, you must modify the following file:
/opt/CA/VirtualAppliance/custom/iptables-firewall-configuration
Wildfly HTTPS Listener and SSL Certificates
Virtual Appliance supports Wildfly HTTPS listener and SSL certificates for CA Identity Manager, CA Identity Governance, and CA Identity Portal.
The following certificates and ports are used by various applications:
Application
HTTPS Port
Certificate location
CA Identity Manager
8443
/opt/CA/VirtualAppliance/custom/wildfly-ssl-certificates/
caim-srv
CA Identity Portal
8444
/opt/CA/VirtualAppliance/custom/wildfly-ssl-certificates/
caip-srv
CA Identity Governance
8445
/opt/CA/VirtualAppliance/custom/wildfly-ssl-certificates/
caig-sr
On every service restart:
  1. Self-signed certificates for each Wildfly application instance (CA Identity Manager, CA Identity Governance, and CA Identity Portal) are automatically generated in
    /opt/CA/VirtualAppliance/custom/wildfly-ssl-certificates/ Note:
    If a certificate already exists in the directory, a new certificate will not be created and the existing certificate will be retained.
  2. The certificate is automatically imported into the java keystore of the server.
    • The java keystore is unique per server and there is no synchronization of keystore data between hosts.
    • The certificates can be replaced with custom certificates. A restart of the service is required.
Enabling the HTTPS listener in standalone.xml
The following blocks are required in each application standalone.xml configuration file in order for the HTTPS listener to be enabled (utilizing the certificate):
<https-listener name="https" socket-binding="https" security-realm="WebSslRealm"/>
<security-realm name="WebSslRealm">
<server-identities>
<ssl>
<keystore path="/opt/CA/VirtualAppliance/custom/wildfly-ssl-certificates/caim-srv" .../>
</ssl>
</server-identities>
</security-realm>
Note 1:
To enable TLSv1.2 and limited cipher suites, ensure that the
/opt/CA/VirtualAppliance/custom/<Wildfly-Service>/https-listener-hardening
file contains the line
true
. If the file contains the line
true
, the WildFly HTTPS Listener hardening will be enabled on the next service startup. The hardening can be disabled by removing the line
true
from the file.
# This file controls the list of enabled protocols and cipher suites for the HTTPS listener of wildfly # If this file includes value "true" on a single uncommented line - TLSv1.2 is used and cipher suites are limited. # Otherwise - the wildfly defaults are used (TLSv1.0, TLSv1.1 and TLSv1.2 and all cipher suites). # Uncomment the following line to enable TLSv1.2 and limited cipher suites # true
Note 2:
In CA Identity Portal, the cookie is by default set to HttpOnly. You can set to
secure
by inserting the value
true
in /opt/CA/VirtualAppliance/custom/IdentityPortal/secure-cookie and then restarting CA Identity Portal.
Configure Session Timeout
To configure session timeout for
Identity Manager
and
Identity Governance
, follow the given steps:
  1. Navigate to
    /opt/CA/VirtualAppliance/custom/IdentityManager or IdentityGovernance/config
    directory.
  2. Open
    session-timeout
    file for editing.
  3. In the file, specify the numerical value representing the session timeout in minutes as shown below:
    # This file holds the HTTP session timeout value used by Identity Manager User Console # This file must contain a single line (except comments beginning with a "#") with a numeric value representing the session timeout in minutes 30
  4. Restart the corresponding server for the changes to take effect.
Configure Upload Size
To configure upload size for Identity Manager, Identity Governance and Identity Portal, follow the given steps:
  1. Navigate to the following directories:
    • Identity Manager:
      /opt/CA/VirtualAppliance/custom/IdentityManager/config
    • Identity Governance:
      /opt/CA/VirtualAppliance/custom/IdentityGovernance/config
    • Identity Portal:
      /opt/CA/VirtualAppliance/custom/IdentityPortal/config
  2. Open
    max-post-size
    file for editing.
  3. In the file, specify the numerical value representing the max-post-size in bytes as shown below:
    # This file holds the max-post-size value used by http and https listeners # This file must contain a single line (except comments beginning with a "#") with a numeric value representing the max-post-size in bytes 52428800
  4. Restart the corresponding server for the changes to take effect.
Configure Transaction Timeout
To configure transaction timeout for
Identity Portal
, follow the given steps:
  1. Navigate to
    /opt/CA/VirtualAppliance/custom/IdentityPortal/config
    .
  2. Open
    transaction-timeout
    file for editing.
  3. In the file, specify the numerical value representing the transaction timeout in seconds as shown below.
    # This file holds the default-timeout (transaction timeout) value used by wildfly # This file must contain a single line (except comments beginning with a "#") with a numeric value representing the transaction timeout in seconds 600
  4. Restart the Identity Portal server for changes to take effect.
Configure Proxy Parameters
Virtual Appliance allows you to configure proxy parameters such as Log Levels, Connection Timeout and Retry Timeout. To configure proxy parameters, follow these steps:
  1. Navigate to
    /opt/CA/VirtualAppliance/custom
    .
  2. Open
    vapp_proxy.conf
    for editing.
  3. Configure the following proxy parameters:
    1. loglevel:
      Controls the verbosity of the proxy logs.
      Allowed Values:
      error, warn, info, debug
      Default:
      warn
      Example:
      loglevel=error
    2. connectiontimeout:
      Represents connection timeout in seconds for the Apache httpd to wait for the creation of a connection to the backend to complete.
      Default:
      5 seconds
      Example:
      connectiontimeout=15 seconds
    3. retry:
      Represents connection pool worker retry timeout in seconds. If the connection pool worker to the backend server is in the error state, Apache httpd will not forward any requests to that server until the timeout expires. A value of 0 means always retry workers in an error state with no timeout.
      Default:
      120 seconds
      Example:
      retry=130 seconds
  4. Restart the HTTPD server for the changes to take effect.
    $> service httpd restart
Configure MDB Maximum Sessions
[Applicable only to Identity Manager]
By default, the maximum number of sessions for MDB is set to 50. You can change the value of the MDB maximum sessions to a desired value as follows:
  1. In the Virtual Appliance, navigate to /opt/CA/VirtualAppliance/custom/IdentityManager.
  2. Open
    jboss-ejb3.properties
    for editing.
  3. Change the value of the
    maxSession
    property to a desired value.
    maxSession=80
  4. Restart Identity Manager.
    restart_im