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) |
|
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) |
|
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) |
|
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 |
|
Virtual Appliance Admin Web UI | Management network | All Virtual Appliance servers | TCP/10443 | HTTPS |
|
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 |
| |
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) |
|
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:
| 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
- Resources – shared logos, background, user pictures, and language files
- Plugins – custom java-based server-side plugins
- dxrepo - Deployment Xpress repositoryTo get the latest repository, see Download the Deployment Xpress Templates Repository.
- 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:
- Create a custom .jar file for role definitions usingRoleDefinitionGenerator.cd /opt/CA/IdentityManager/IAM_Suite/IdentityManager/tools/RoleDefinitionGenerator/bin/./RoleDefGenerator.sh -h localhost -u etaadmin "<Custom Jar File>"
- Provide permission to the <Custom Jar File> created in step 1.chmod 777 <Custom Jar File>
- Copy <Custom Jar File> to /opt/CA/VirtualAppliance/custom/IdentityManager/iam_im.ear_user_console.war_WEB-INF_lib/.
- 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:- Upload or create the custom file onone node.
- Open a CLI or SSH terminal on the same node.
- Change to the directory where the files were created or uploaded.
- 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 sharesTemporarily 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 mount point using credentials listed in the file
/home/config/temp
/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:
- Edit the following file:/opt/CA/VirtualAppliance/custom/mounts
- 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-passNote:RunMountNetworkShares -hto view the syntax that is used in the configuration file.
- Save the file and exit.
- Run theMountNetworkSharescommandThe 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:
- Log in to the target server via SSH/CLI as the default Virtual Appliance (config/ec2-user) user.
- Edit thejvm-args.conffile 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
- Uncomment the following line, or duplicate it and uncomment the copied line:From:#JAVA_OPTS=...To:JAVA_OPTS=...
- Make the necessary changes to the JVM arguments specified after the "=" character.
- Save the file.
- Restart the application server by running the corresponding alias for the product:restart_imrestart_igrestart_ip
Perform the following steps to modify the out-of-the-box JVM arguments for Connector Server:
- Log in to the target server via SSH/CLI as the default Virtual Appliance (config/ec2-user) user.
- Edit the /opt/CA/IdentityManager/ConnectorServer/data/jvm_options.conffile.
- 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:
- Log in the Virtual Appliance server using SSH/CLI
- Create or edit the following file:/opt/CA/VirtualAppliance/custom/hosts
- Add the custom host records in a format equivalent to the /etc/hosts format, for example:192.168.1.54 myhost01192.168.1.58 myhost02192.168.1.160 myhost03
- Run the following command:configureCustomHostRecords
- View the /etc/hosts file and notice that the following block was added/modified to reflect the custom hosts block:# CA VAPP CUSTOM HOSTS - START192.168.1.54 myhost01192.168.1.58 myhost02192.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.
- Navigate to the following location:cd /opt/CA/VirtualAppliance/custom/IdentityManager/branding/
- Create your own skin. This is typically done by copying an existing template skin directory fromiam_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
- Modify the skin as required.
- Navigate to the following location./opt/CA/VirtualAppliance/custom/IdentityManager/branding
- Edit theindex.jspfile 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>
- Save the file.
- Edit the<SKIN_NAME>/ui7/ca/ca.propertiesfile and change theresourceBaseNameproperty to direct to the resources file of the new skin.For example:resourceBaseName=/app/imcss/my-custom-skin/ui7/resources
- Save the file.
- Edit<SKIN_NAME>/ui7/index.jspfile and change theskin:updateproperty 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>
- Save the file.
- In order to have branding in place forlogin.jspfile, make the following changes in the custom styles folder that you created. These folders are preserved during an upgrade.
- 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
- 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
- In theIdentity SuiteEnvironmentsand select an environment.
- Navigate toAdvanced Settings,User Console
- Configure theLogin page to useunderAuthentication Propertiesas/app/imcss/my-custom-skin/ui7/login.jsp.
- ConfigureTheme Propertiesas required.
- Restart CA Identity Manager.
- Access the environment with the following URL:https://<domain>/iam/im/identityEnv/imcss/my-custom-skin/ui7/index.jspNote: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:
- Navigate to/opt/CA/VirtualAppliance/custom/IdentityGovernance/branding.
- Editlogin_pagefile with new changes.
- After restarting CA Identity Governance, the changes will reflect ineurekify.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:
- From the Virtual Appliance Admin UI, navigate to the Setup page.
- Add the new node (Node 3) to the cluster.
- From the Services pane on the left, drag a new User Store service to the new node (Node 3).
- Deploy the configuration.
- 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.
- 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.
- 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).
- 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).
- PressDeploy.
- 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:
- From the Virtual Appliance Admin UI, navigate to the Setup page.
- In the Machines pane on the right, identify the node from which you want to remove the service (Node 2 in this example).
- 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).
- 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).
- Deploy the configuration.
- 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.
- During this replication, the service on the new node (Node 4) is in offline mode and does not serve the cluster.
- 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.
- 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:
- From the Virtual Appliance Admin UI, navigate to the Setup page.
- In the Machines pane on the right, identify the node from which you want to remove the service.
- 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.
- From the Services pane on the left, drag a new Database service to the new node to which you want to move the service.
- Deploy the configuration.
- 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:- Start the WildFly application server for CA Identity Manager indebug mode.
- 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_imstart_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
- Edit the route interface configuration files for the corresponding network interfaces: /etc/sysconfig/network-scripts/ifcfg-ethXExample:vim /etc/sysconfig/network-scripts/route-eth1
- Add static routes using the following syntax:10.10.10.0/24 via 10.20.30.254 dev eth0
- 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 reloadIf syntax or logical subnet errors are present, you see the following errors:For example1. 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
- Run the following command to inspect the routing table:route -nExpected Output:(The line that is highlighted ingreenrepresents the static route entry)Kernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface10.20.30.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 → The system has a single NIC on the10.20.30.0/24subnet.10.10.10.0 10.20.30.254 255.255.255.0 UG 0 0 0 eth0 →Traffic destined forwill route via10.10.10.0/2410.20.30.2540.0.0.0 10.20.30.1 0.0.0.0 UG 0 0 0 eth0 → All other traffic will route via10.20.30.1
Add Network Interfaces:
- Shut down the server.
- Ask the ESX administrator to add any additional network interfaces.
- Power on the server.
- Run the following command to verify that the additional network interfaces were registered:ifconfig -a | grep addrExpected Output:eth0 Link encap:Ethernet HWaddr 00:0C:29:B0:FB:C5inet addr:10.0.0.240 Bcast:10.0.0.255 Mask:255.255.255.0eth1 Link encap:Ethernet HWaddr 00:0C:29:B0:FB:D9eth2 Link encap:Ethernet HWaddr 00:0C:29:B0:FB:E3eth3 Link encap:Ethernet HWaddr 00:0C:29:B0:FB:CFThe 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...).
- Edit the network interface configuration files for the corresponding network interfaces: /etc/sysconfig/network-scripts/ifcfg-ethXFor example:vim /etc/sysconfig/network-scripts/ifcfg-eth1
- 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=eth1TYPE=EthernetONBOOT=yesNM_CONTROLLED=noBOOTPROTO=STATICIPADDR=10.0.0.242NETMASK=255.255.255.0#GATEWAY=#DHCP_HOSTNAME=
- 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
- Run the following command to verify that the IP address was registered to the network interface:ifconfig -a | grep addrExpected Output:eth0 Link encap:Ethernet HWaddr 00:0C:29:B0:FB:C5inet addr:10.0.0.240 Bcast:10.0.0.255 Mask:255.255.255.0eth1 Link encap:Ethernet HWaddr 00:0C:29:B0:FB:D9inet addr:10.0.0.242Bcast:10.0.0.255 Mask:255.255.255.0eth2 Link encap:Ethernet HWaddr 00:0C:29:B0:FB:E3eth3 Link encap:Ethernet HWaddr 00:0C:29:B0:FB:CFinet 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:
- In the Virtual Appliance, open/etc/resolv.conffor editing.
- In the file, change the IP address in thenameserverfield 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
- 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:
- Navigate to/opt/CA/VirtualAppliance/custom/IdentityManagerandPS-bind.propertiesfor editing.
- 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 all CA Identity Manager nodes in multiple Virtual Appliance solutions.
/opt/CA/wildfly-idm/modules/com/ca/iam/cajasper/main/
and also copied to /opt/CA/VirtualAppliance/custom/IdentityManager/keystore
onApply Pre-login and Post-login Banner
To apply pre-login and post-login banners, perform the following steps:
- Run the below commands to edit the relevant pre/post login banner files:vim /opt/CA/VirtualAppliance/custom/login-prompt.previm /opt/CA/VirtualAppliance/custom/login-prompt.post
- Make the desired changes and save the files.
- Run the following command to apply the banner:configureLoginPromptThe following output is displayed:[INFO] Configuring pre-login banner[INFO] Configuring post-login banner
- Upon the next SSH or CLI login, the relevant pre/post banner is displayed:login as: configPRE-LOGIN BANNER TEXT[email protected]<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:- Generate an SSH key pair that is owned by WildFly.
- Remove an existing SSH key pair that is owned by Wildfly.
- List all SSH keypairs that are owned by Wildfly.
- 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:
- 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.
- 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:
- Navigate to/opt/CA/VirtualAppliance/custom/IdentityManager or IdentityGovernance/configdirectory.
- Opensession-timeoutfile for editing.
- 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
- 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:
- 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
- Openmax-post-sizefile for editing.
- 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
- Restart the corresponding server for the changes to take effect.
Configure Transaction Timeout
To configure transaction timeout for
Identity Portal
, follow the given steps:
- Navigate to/opt/CA/VirtualAppliance/custom/IdentityPortal/config.
- Opentransaction-timeoutfile for editing.
- 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
- 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:
- Navigate to/opt/CA/VirtualAppliance/custom.
- Openvapp_proxy.conffor editing.
- Configure the following proxy parameters:
- loglevel:Controls the verbosity of the proxy logs.Allowed Values:error, warn, info, debugDefault:warnExample:loglevel=error
- 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 secondsExample:connectiontimeout=15 seconds
- 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 secondsExample:retry=130 seconds
- 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:
- In the Virtual Appliance, navigate to /opt/CA/VirtualAppliance/custom/IdentityManager.
- Openjboss-ejb3.propertiesfor editing.
- Change the value of themaxSessionproperty to a desired value.maxSession=80
- Restart Identity Manager.restart_im