FAS Administration Guide

FAS Administration Guide
YRP1-508, 3-4 Hikari-no-Oka Yokosuka-Shi, Kanagawa, 239-0847, Japan

tel.: + 81-(0) 46-821-3362 | cba-japan.com
This document contains confidential information that is proprietary to CBA. No part of its contents
may be used, disclosed or conveyed to any party, in any manner whatsoever, without prior
written permission from CBA.
© Copyright 2023 CBA
All rights reserved.
Updated: 2022-06-22
Document version: 2.6
Contact Information
For technical support or other queries, contact CBA Support at:
[email protected]
For our worldwide corporate office address, see:
https://www.cba-japan.com (Japanese) https://www.cba-gbl.com (English)
© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 2

Documentation in this Release
The following user documentation is provided in this release
Fusion Application Server Architecture Guide
Fusion Application Server Installation Guide
Fusion Application Server Administration Guide

Contents
Introduction
Domains, Server Groups, Server Processes, and Profiles
Management Interfaces
File System
Managing Cluster Components
Managing Applications
Licensing
SNMP Traps
Logging
Security
Ports
Monitoring
Trust Management
Performance
Domains
Server Groups and Server Processes
Profiles
Management Console
Starting the Management Console
Management Console Overview
Managing Profiles
Managing Servers
Managing Runtime Configuration
Command Line Interface (CLI)
Starting the CLI
Using the CLI
Determining the Address
Determining the Operation Name
Determining any Parameters

Running an Operation
Running a CLI Script from a File
Running Commands in Batch Mode
File System
Files in the domain/configuration Directory
Files in the bin Directory
Starting a FAS Node
As a Service
Using the Script
Starting and Stopping Server Processes
Adding Load Balancers
Adding a Load Balancer to the Cluster
Adding a Load Balancer to an Existing Node
Configuring Load Balancers
Editing LB Properties using the Management Console
Editing LB Properties using the CLI
LB Properties
Adding Application Servers
Adding an Application Server to the Cluster
Configuring Application Servers
Removing an AS or LB
Disabling Support for RFC 3581
Disabling RFC3581 using the Management Console
Disabling RFC3581 using the CLI
Viewing Cluster Configuration
Changing Addresses
Configuring Addresses on a Node
Changing the IP Addresses of a Node
Configuring the External Address Mode
Changing the External Address Modes
Configuring the Cluster Address
Changing the Cluster Address using the Management Console
Changing the Cluster Address using the CLI
Configuring the Cluster Name

Changing the LB HTTP Address to bind to all IP Addresses
Managing Frequently Changing IP Addresses
To Change the IP Address in the fas.properties file
Using the loopback Address
Reverting the Changes
Deploying Applications
Deploying an Application
Updating an Application
Undeploying an Application
Enabling or Disabling an Application
Application Backups
Configuring Application Properties
Configuration using System Properties
Configuration using the Application Configuration Framework
Managed and Unmanaged Applications
Managing ACF Applications using the Management Console
Managing ACF Applications using the CLI
Co-hosting Applications
Configuring AR Details in the Management Console
Configuring AR Details in the CLI
Configuring Datasources
Installing the JDBC Driver
Creating the Datasource
Configuring the Datasource
Testing the Connection
Licensing
Managing Licenses
SNMP Traps
Managing Licenses using the Management Console
Viewing License Details using the Management Console
Adding a License using the Management Console
Removing a License using the Management Console
Managing Licenses using the CLI
Connecting to a different License Server

Connecting to different License Server using the Management Console
Connecting to different License Server using the CLI
Configuring SNMP
Configuring the SNMP Agent
Configuring SNMP Trap Targets
Configuring the SNMP Client
Fusion Application Server SNMP Traps
Example Scenarios
Decoding the Resource ID
Traps Raised on FAS Startup
Configuring SNMP Trap Security
SNMP Security Levels and Users
Implementing SNMPv3 Security
SNMP View Access Control
Configuring Logging
Configuring SIP Call Logging
To Configure the Log Files for SIP Call Logging
To Change the SIP Call Logging Level
Configuring HTTP Logging
Configuring the Root Logging Level
Configuring a Logging Category
To Configure a Logging Category
Changing to Periodic Logging
To Create a Periodic Log Handler
To Use the Periodic Logging Handler for Root Logging
To Use the Periodic Logging Handler for SIP Call Loging
SNMP Logging
Licensing Logging
Logging for a Specific Period
To Capture Logs for a Specific Period
Creating a Log Archive
Configuring Security
Controlling Access to the Management Interfaces
Changing the Local User Credentials

Adding a New User
Changing the Credentials used between Master and Slave
host.xml
fas.properties
Resetting Administrator Credentials
Configuring TLS Cipher Suites
HTTPS
SIPS
Enabling and Disabling TLS v.1 and 1.1
Configuring Trust Management
Using Certificates with FAS
Managing Certificates
Identity and Trust Certificate Groups
Configuring with Certificates signed by a CA
Generating a Certificate Signing Request
Sending a CSR to an External CA for Signing
Importing a Signed Certificate
Configuring with Certificates signed by a SCEP Server
Configuring FAS to use the SCEP protocol
Generating a SCEP-Signed Certificate
Configuring LBs with Trust Certificates
Importing a Trust Certificate
Configuring the DHC with an Identity Certificate
Replacing an Identity Certificate
Exporting an Identity Certificate
Removing a Trust Certificate
Generating a New Identity Certificate
Configuring SIP
Configuring the SIP Servlet Subsystem
Configuring the SIP Servlet Subsystem using the Management Console
Configuring the SIP Servlet Subsystem using the CLI
Configuring SIP Connectors
Configuring SIP Connectors using the Management Console
Configuring the SIP Connectors using the CLI
Configuring the SIP Stack

Configuring the SIP Stack using the Mangement Console
Configuring the SIP Stack using the CLI
Configuring JGroups
Configuring Performance
HA Performance Options
Load Balancer Transaction Data
Application Server Failure Detection Timeout
JVM Options
Editing JVM Settings at the Host Level
Editing JVM Settings at the Server Process Level
Configuring Garbage Collection
Configuring FAS HA without Multicast
Before Changing the Configuration
Find the Configured TCP Ports
Configuring the HA Profile
Configuring the LB Profile
Configuring the Management Profile
After Changing the Configuration
Monitoring
Monitoring using JMX
Diagnostics
Core Dumps
Ports
Glossary

Introduction
This section provides an overview of each of the subject areas covered in this guide, which
includes the concepts involved in administering a Fusion Application Server cluster, and the
main areas of administration.
You can manage Fusion Application Server configuration at a number of different levels: the
domain level, server group level, server process level, or by way of profiles. See the
Domains, Server Groups, Server Processes, and Profiles section.
You can perform much of the configuration and management of Fusion Application Server
clusters using the Management Console. You can also perform the same configuration tasks,
and some additional tasks, using the CLI.
File System
FAS stores its configuration options in a number of property files. You do not normally need to
edit these files directly; in most cases you can use the Management Console or CLI. See the File
System section.
A FAS cluster consists of FAS nodes running Load Balancers (LBs) and Application Servers
(ASs), which are server processes. See the Managing Cluster Components section.
FAS is the platform on which CBA applications and other applications run. Several types of
application can run on FAS. See the Managing Applications section.

Licensing
Some CBA applications require a license to enable subscribers to use them. Licenses are
available from CBA Support, and are applied to the application using FAS’s License Server. See
the Licensing section.
SNMP Traps
Each Host Controller process contains an SNMP Agent, which provides a means by which
applications deployed on FAS can raise traps. There are also a number of SNMP traps that the
FAS cluster itself may raise when significant events occur. See the Configuring SNMP section.
Logging
FAS uses Log4J to log events to the console, and to various files in the system. You can change
logging levels and logging destinations using the Management Console. See the Configuring
Logging section.
Security
By default, local access (that is, from the node itself) is not restricted, but remote access is
restricted by credentials specified during installation. These credentials are also used by slave
application servers to communicate with the master application server. See the Configuring
Security section.
Ports
Fusion Application Server uses a number of ports for communication between cluster
components and external SIP or HTTP devices. These ports are listed in the Ports section.
Monitoring
The operational status of FAS components is exposed using JMX MBeans.
This data can be viewed using JConsole, which is supplied with your JDK. FAS also provides a
script for collecting diagnostic information from a server for further offline investigation. See the
Monitoring section.

Trust Management
By default, FAS is configured to use Transport Layer Security (TLS).
The components within a FAS cluster must trust each other, so you must provision all of them
with identity certificates signed by a trusted CA. As the LBs send and receive external data, you
should provision them with trust certificates which will let them know which external hosts to
trust. See the Configuring Trust Management section.
Performance
There are a number of properties on Fusion Application Server cluster components, and on the
SIP stack, which you can change to improve performance. See the Configuring Performance
section.

Domains, Server Groups, Server Processes,
and Profiles
A Fusion Application Server (FAS) cluster is made up of one or more host machines (also
referred to as nodes), each one running one or more of the component server processes
(Application Server (AS), Load Balancer (LB), or Management). These server processes are
grouped by a domain into server groups, each of which is associated with a set of subsystems
(for example, logging, web, SIP), called a profile. For details on the relationship between
domains, server groups, servers, and profiles, see the Fusion Application Server Architecture
Guide.
One of the processes that make up each FAS is its Host Controller, which provides the FAS’s
management interfaces. Although each FAS node has a Host Controller, one is singled out as
the master Host Controller, known as the Domain Host Controller. In multi-box installations,
one of the hosts is installed as the master node (see the Fusion Application Server
Installation Guide), and it is the master node which contains the Domain Host Controller.
Domains
All ASs and LBs in a domain share the same Domain Host Controller, which offers a single point
of administration to all the other slave Host Controllers within the domain.
The Domain Host Controller can manage the cluster using the Management Console or a CLI,
whereas slave host controllers only offer a limited read-only CLI interface.
When it starts, a slave Host Controller will attempt to read its configuration from the Domain Host
Controller. This process ensures that all hosts in a domain have the same configuration.
The installer decides which node is the master node that runs the Domain Host Controller, and
that node remains the master node; there is no automatic process for replacing a failed master
node. (There is a manual process which could be followed but we do not recommend this).
However, a FAS cluster can continue successfully when a master node is down, and high
availability is unaffected. The only effects are a reduction in capacity, and that configuration
changes cannot be made until the master node is back up.
Server Groups and Server Processes

A single FAS cluster contains several server processes, each running on one of the nodes
which make up the cluster. These server processes are grouped into server groups, even if the
server group only has a single server process associated with it. All server processes in a server
group have a consistent configuration. They are all configured with the same profile and have
the same deployment content, such as the applications deployed. Server processes on different
nodes can belong to the same server group, so that you can configure all the server processes
in a server group together, whatever node they run on.
On installation, a host typically has two or three server processes running on it, each belonging
to a separate server group:
An AS process, belonging to the main-server-group.
An LB process, belonging to the lb-server-group.
The Domain Host Controller on the master FAS node runs as an additional server process
that runs in its own server group, called mgmt-server-group. This server process runs the
License Server and Trust Management module.
A domain can have multiple server groups. You can configure different server groups with
different profiles and deployments; you can also configure different server groups with the same
profile and deployments.
Profiles
A profile is a named list of subsystems, such as logging, Web, and SIP, along with the details of
each subsystem’s configuration. For example, a profile specifies the logging configuration such
as handlers and log categories. Multiple server groups can share the same profile.
The installer creates three default profiles:
management
Contains the default configuration suitable for hosting non-SIP, non-HA applications. It is used to
configure a server process for CBA management subsystems and applications such as trust
management, SNMP and licensing.
ha
Contains the default configuration for the ASs in the main-server-group.
lb

Contains the default configuration for the LBs in the lb-server-group. The LB profile is a
lightweight profile that lacks JEE and JSR 289 subsystems; it therefore exposes less
configuration options and cannot host JEE or SIP applications.
Administrators might want to alter a profile’s configuration. For example, an administrator might
add a datasource with details of database connection details, or an Infinispan cache that
replicates data to all nodes in the server group. Applications deployed to server processes with
that profile can then use these resources.
The profiles can also change the behavior of subsystems. For example, you can configure the
JMX subsystem to expose the domain configuration model as MBeans.

This section describes the Fusion Application Server management interfaces (the
Management Console and the Command Line Interface (CLI)), and provides some general
instructions for using them.
Management Console
The Management Console is a browser-based UI provided by the Domain Host Controller, which
can be used to configure the Fusion Application Server.
Before using the Management Console to configure FAS, ensure that:
The required FAS cluster components are installed, as detailed in the Fusion Application
Server Installation Guide. All cluster components that are part of the same cluster have the
same Cluster Address, which is set during installation.
Each FAS node in the cluster (or the only FAS node in a single-box installation) is running.
The LBs and ASs in the cluster are running. The Management Console cannot start other
host controllers or FAS nodes, but you can use it to start or stop server processes on a local
or remote FAS node, as long as the FAS node itself is running.
Starting the Management Console
To launch the Management Console, open the following URL in a browser:
https://<fas address>:9990
where <fas address> is the IP address of the master node, or the machine hosting a single-
box installation.
You must supply the administrator credentials to log in to the Management Console; enter the
administrator credentials that you specified during installation. The console should launch
successfully:

Management Console Overview
The Management Console is the web interface provided by the Domain Host Controller, and
allows you to configure the FAS nodes in a domain. You can configure most of the attributes and
perform most of the operations available through the CLI more conveniently through the
Management Console. The main screen has several elements:

1. Main navigation (often referred to as top right menu). Split into:
Profiles
See the Managing Profiles section.
Server
See the Managing Servers section.
Runtime
See the Managing Runtime Configuration section.
2. Secondary navigation (often referred to as the top left menu). It may contain a list of:
Profiles, if the main navigation selection is Profiles.
Hosts, if the main navigation selection is Servers.
Server Processes, if the main navigation selection is Runtime.

Select the resource in the list that you want to view or modify.
3. Third navigation (often referred to as menu on the left, or left hand menu).
Displays sections of the configuration of the item selected in the secondary navigation, which
you can display and modify. Some of the items in this menu can be opened to show a sub-menu.
4. Navigation tabs.
Having selected a section in the third navigation, the navigation tabs display subsections of the
configuration.
5. Main content area
The main content area displays the configuration for an item. Commonly, it shows a list of
resources in a table in the top half, and displays an item selected from the table in more detail in
the bottom half. There may also be buttons for the operations which you can apply to the items in
the table. If the configuration of each item is complex, the lower half of the window might contain
additional tabs.
6. Messages and notifications area
Clicking on Messages displays a list of recent messages, such as the outcome of a recent
operation.
7. Toolbar
The toolbar contains the following general operations:
Tools->Browser
Provides an alternative read-only view of the Dynamic Representation Model. This view is
closer to the structure used by the CLI (see the Command Line Interface (CLI) section), and may
help you to understand the structure of resources in the CLI, or to allow you to see the values of
attributes which you cannot access in the Management Console.
Settings
Allows the user to change the locale of the Management Console itself.
Logout
Closes the current management session.

You can set certain configuration items, such as system properties, interfaces, and JVM
configurations, at a number of levels. If a configuration item is set at more than one level, the
most specific takes precedence. The levels, from most to least specific, are: server process,
host, server group, and domain (that is, a JVM configuration item set in the appserver server
process on localhost will override a JVM configuration set on the localhost host itself).
Managing Profiles
Select Profiles from the main navigation area. The secondary navigation area contains a list of
profiles which can be managed.
The FAS installer creates and configures three profiles:
ha profile
This is the profile used by SIP and Web applications hosted by FAS. The installer applies it to the
main-server-group.
lb profile
By default, this profile applies to the lb-server-group. It has the following subsystems, some of
which can be managed through the Management Console: LB, OAMP, JMX, Remoting, and
Logging.
management profile
This profile is reserved for management applications such as the License Server and the Trust
Management module. By default, it applies to the mgmt-server-group.
After you select a profile, the third navigation area displays items which can be configured, in two
menus:
Subsystems
Shows a list of subsystems specific to the profile. Which subsystems are shown depends on the
profile selected (the ha profile has many more subsystems than the lb profile, for instance).
When you select one of these subsystems, its content (divided between one or more navigation
tabs) appears in the main content area.
Note: The Subsystems menu is typically grouped into sub-menus (such as Container, Core, or
Web), indicated by a + or - next to them, with the subsystem menu items beneath them. The
sub-menus can be expanded or collapsed.

General Configuration
These settings are common across all profiles (that is, they are at the domain level):
Interfaces
Displays a list of interfaces (for example, public, management) and allows you to specify which
IP address they bind to or NIC they use.
You typically specify these at the host level (see the Managing Servers section), not at the profile
level.
Socket Binding
Displays a list of socket binding groups. The FAS installer creates a single group, ha-sockets,
that is used by both the ha and management profiles.
The binding group specifies the default ports used for each binding (for example, http=8080), but
these can be overridden at the server group level.
System Properties
Displays a list of system properties. These are set at the domain level, and can be overridden at
the server group, host, or server process level.
The Management Console cannot create additional profiles. It is possible to create profiles using
the CLI, but it is probably simpler to clone an existing profile by editing the domain.xml file
directly and changing the profile name. See the Files in the domain/configuration Directory
section for more information about this file.
Managing Servers
Select Server from the main navigation area. The secondary navigation area contains a list of
hosts which can be managed.
A host is a physical server (or VM) that has FAS installed on it, and whose Host Controller is
either the Domain Host Controller (in which case the host is the master node), or the Host
Controller of a slave node that has successfully connected to the Domain Host Controller.
Once you have selected a host, the third navigation area displays items which can be
configured:
Server Configuration

The main content area displays a list of server processes that have been configured on the
selected host.
When you have selected a server process from the list, you can configure it in the bottom half of
the main content area. For example, you can configure JVM settings and system properties,
change the assigned server group, alter the auto-start flag, or change the port offset.
Server Groups
The main content area displays the list of server groups configured for this domain.
You can add and remove server groups, and when you have selected one of them, you can
configure the server group in the bottom half of the main content area. For example, you can
configure JVM settings, system properties, or change the associated profile, or socket
binding.
JVM Configuration
All server processes on this host will start up using these JVM settings unless overridden at the
server process level.
Interfaces
Define what IP address, NIC, and so on, to use for management and public interfaces.
During installation, FAS configures and stores the IP addresses to bind to in the fas.properties
file. These are referenced as system property expressions in this section. The easiest way to
change the bind IP address is to edit the fas.properties file. See the Files in the
domain/configuration Directory section for more information about this file.
Host Properties
Defines the system properties at the host level. All server processes on this host will use these
system property values, unless they are overridden at the server process level.
The items are divided into two groups in the third navigation area, Server and Host Settings.
Both sets of configuration items apply to the host, but those in Server relate specifically to the
way that FAS operates; the items in Host Settings are more generic, and have their equivalents
on any application server.
Note: To start, stop, and view the status of the server processes running on the server, see the
Starting and Stopping Server Processes section.

Managing Runtime Configuration
Select Runtime from the main navigation area. The secondary navigation area shows a pop-out
dialog, in which you can select a host and server process pair:
Select a server process on a specific host and click Done; the third navigation area shows items
related to that host and server process:
Domain
These settings are common to the domain or host (they are the same whichever server process
you have selected from the second navigation area).
Server Instances
A list of server processes for the selected host, including their current status. From here you can
start or stop the selected server process.
When you select a server process, you can view the environment properties; these are the
system properties available to applications and subsystem services running on the server. They
contain properties set by the container, as well as properties set by the administrator at domain,
server group, host, or server process level.
Note: The environment properties are different for different server processes, but those displayed
depend on the server process selected in the main content area, not that selected in the
secondary navigation area; as long as you select a server process on the correct host in the

secondary navigation area, you can select the correct server process on that host in the main
content area. To change the environment properties for e.g. the loadbalancer on localhost:
1. Select one of the server processes on localhost in the second navigation area and click
Done.
2. Select Server Instances in the third navigation pane.
3. Select the loadbalancer server process in the main content area
You can now view and edit the environment properties for the loadbalancer server process by
clicking the Environment Properties tab in the lower part of the main content area.
Manage Deployments
Displays the deployed objects in the Content Repository tab. These are typically Web, SIP or
JEE EAR application archives, but they can also contain things such as JDBC driver jars, and
even XML files.
You can add, update, or remove content. When you add content, you must assign it to one or
more server groups before it can be used.
There is a second navigation tab called Server Groups. This provides an alternative view of the
same deployments, with objects grouped according to the server groups they are assigned to.
This allows you to view the applications deployed to each server group, and to enable or disable
these applications.
Server Status
Displays statistics related to subsystems or core components of FAS. For example, you can view
statistics for JVM, datasource, JPA, JNDI, transactions, Web and Webservices.
Command Line Interface (CLI)
The CLI is a utility installed on FAS hosts. You can use the CLI to configure Fusion Application
Server from a command prompt.
Before using the CLI to configure FAS, ensure that:
The required FAS cluster components are installed, as detailed in the Fusion Application
Server Installation Guide. All cluster components that are to be part of the same cluster
will have the same Cluster Address, which is configured during installation.

The LBs and ASs in the cluster are running. You cannot use the CLI to start cluster
components.
The CLI can also be run from a Java application, which might be useful for scripting repetitive
tasks.
For more information about using the CLI than the Fusion Application Server Administration
Guide provides, type help on the CLI command line, or look in the JBoss CLI documentation.
Note: The CLI represents the configuration as a tree structure; the JBoss CLI documentation
refers to the elements of the tree as nodes or resources interchangeably, and this section on
the CLI follows this terminology. Do not confuse a node in the CLI with a FAS node.
Starting the CLI
1. Change to the directory containing the CLI:
cd <install dir>/bin
2. Run:
./jboss-cli.sh
3. Connect to the FAS that you have configured as master:
connect <fas address>
where <fas address> is the IP address or host name of the FAS host you want to connect to.
4. The CLI will prompt you for the user name and password. It uses the same credentials as
the Management Console, the ones that you specified during installation.
To terminate a CLI session type quit.
Using the CLI
Operation requests consist of the following parts:
An address, prefixed with a slash (/)

an operation name, prefixed with a colon (:)
an optional set of parameters, contained within parentheses (())
Note: The CLI supports tab-completion for node types and names, operation names, property
names and, in some cases, values. That is, you can start typing the name or value and then
press tab. Where there is only one possible option, it completes the name or value. Where there
is more than one possible option, it lists the options.
The following sections describe how to build operations on the command line.
Determining the Address
The current node path is indicated in the command line prompt. The default value is /, that is, the
root node. If you do not specify an address, the operation will be executed against the current
node path.
Operations are performed on resources. Resources often have child resources. For example, the
resource /profile=ha has a set of child resources of type subsystem, for example,
/profile=ha/subsystem=sip. The address of the resource is made up of a series of name-value
pairs that include the address of any parent resources.
To see what resources are available under the current node, use the ls command.
Determining the Operation Name
You can use the :read-operation-names command on any node to list the available operations.
For example, run from an ID certificate group in the trustmgmt subsystem, the command returns
something like the following:
[[email protected]:9999 identity-certificate-group=mgmt-server-group]
**:read-operation-names**
"outcome" => "success",

"result" => [
"add",
"change-password",
"generate-keypair",
"import-certificate",
"import-keypair",
"query-expiring-certs",

"read-attribute",
"read-children-names",
"read-children-resources",
"read-children-types",
"read-operation-description",
"read-operation-names",
"read-resource",
"read-resource-description",
"remove",
"undefine-attribute",
"whoami",
"write-attribute"
]
Determining any Parameters
You can use the read-operation-description command on an operation to determine the

parameters required for the it:
**:read-operation-description(name=generate-keypair)**
{
"result" => {
"operation-name" => "generate-keypair",
"description" => "Generates a private/public key pair. Returns the generated
key pair in PEM format - the first entry is the private key, and the second is
the self-signed certificate",
"request-properties" => {
"expiry-date" => {
"type" => STRING,
"description" => "The expiry date (yyyy-mm-dd) for the generated key pair",
"expressions-allowed" => true,
"required" => false,
"nillable" => true,
"min-length" => 10L,
"max-length" => 2147483647L
},
"subject-dn" => {
"type" => STRING,
"description" => "The distinguished name for the generated key pair",
"expressions-allowed" => true,

"required" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
}
},
"reply-properties" => {},

"read-only" => false
}
Running an Operation
A full operation, including the address, uses the following format:
[node-type=node-name (/node-type=node-name)*] : operation-name ['('[name=value

[, name=value]*]')'] [{header (;header)*}]
For example, the command to change the SIP call logging level to DEBUG is:
/profile=ha/subsystem=logging/logger=sip.calls/:write-
attribute(name=level,value=DEBUG)
If you plan to run a number of commands against a particular resource, you can change to that
resource node and run the commands from the node, to save you having to specify the node on
each command. To change the node, you can use the change node command: cn or cd:
cd profile=ha/subsystem=logging/logger=sip.calls/
The command prompt changes to look like:
[host:port /logger=sip.calls]
You can then omit the address to run an operation against the current node:

:write-attribute(name=level,value=DEBUG)
Start with ./ to execute an operation against a child resource of the current node. For example,
you can run the following command against the subsystem=logging node to update the child
resource logger=sip.calls:
./logger=sip.calls:write-attribute(name=level,value=DEBUG)
If you have changed nodes away from the root, you can start with / to execute an operation
against the root node:
/:read-resource
For more information on the CLI, type help on the CLI command line.
Running a CLI Script from a File
The above examples show CLI being used in interactive mode. The CLI can also run commands
loaded from a script. For example, to load the CLI commands in a file called read-all.cli and pipe
the output to a file called results.txt, use the following command:
./jboss-cli.sh --file=read-all.cli > results.txt
The following shows the content of an example read-all.cli script:
# read-all.cli
#
# connect to host controller (or you could pass
# -- controller=<ip> flag to cmd)
connect 192.168.1.234
# this recursively reads config, including runtime metrics -

# could be expensive (100+Kb of data)
:read-resource(recursive=true,include-runtime=true)

Running Commands in Batch Mode
You can also run multiple commands in a single batch. In batch mode, all operations must run
successfully; otherwise, a failure of any operation will cause a rollback of all operations. The
following commands are available in batch mode:
Command Description
Start a batch. Any commands subsequently

entered will not be run until run-batch is
batch
invoked. Can also be used to restore a held
back batch.
run‑batch Run all commands in batch.
Saves the current batch, and can be recalled

holdback‑batch (string batch‑name)
at a later time during the connected session.
Discards the current batch without executing

discard‑batch
it.
move‑batch‑line (int from, int to) Moves a line in a batch to a different position
remove‑batch‑line (int line) Removes a command from the list
Replaces an existing line with the new

edit‑batch‑line (int line, string command)
command text
Clears all commands but remains in batch

clear‑batch
mode
list‑batch Lists all commands in a batch
Batches can be run in both interactive mode or from a CLI script.

File System
During installation, FAS creates a directory structure below the installation directory:
Directory Description
For running JEE Application clients

appclient
(unsupported feature).
Scripts for starting FAS, CLI, and JConsole.

bin The files in this directory are detailed in the
Files in the bin Directory section.
bundles OSGI bundles directory (unsupported feature)
docs Contains XSD schema
domain Contains configuration and log files.
Contains configuration files. See the Files in

domain/configuration
the domain/configuration Directory section.
Development application router configuration

domain/configuration/dars
(unsupported feature)
domain/configuration/domain_xml_history Backups of domain.xml
domain/configuration/host_xml_history backups of host.xml
Contains identity and trust certificate files for

domain/configuration/security
TLS
FAS data directory containing uploaded

domain/data
content (such as applications).
Logs associated with the host controller and

domain/log
process controller (not server processes).
domain/servers Contains folders specific to each server.
domain/servers/appserver‑/ First AS folder (name will vary). There may be

several directories like this, each with its own

hostname, and duplicating the structure of
directories within this one.
domain/servers/appserver‑/data Content and data required by subsystems.
domain/servers/appserver‑/log Logs for this AS.
domain/servers/appserver‑/tmp AS’s virtual file system and working directory.
domain/servers/loadbalancer‑ LB folder (name will vary).
domain/servers/loadbalancer‑/data Content and data required by subsystems.
domain/servers/loadbalancer‑/log Logs for this LB.
domain/servers/loadbalancer‑/tmp LB’s virtual file system and working directory.
Management server folder. This server hosts

domain/servers/management
the License Server.
domain/servers/management/data Content and data required by subsystems.
domain/servers/management/log Logs for the management server.
Management server’s virtual file system and

domain/servers/management/tmp
working directory.
The location of modules. A module can be a

modules
subsystem or a set of Java libraries
Set of scripts and configuration. Used for init.d/

resources
service startup.
Contains the JAR file executable used to

Uninstaller
uninstall Fusion Application Server.
HTML displayed by Web system at root

welcome-content
context.
Files in the domain/configuration Directory
The domain/configuration directory is the most important directory, as it contains the two files
that define the domain configuration, domain.xml and host.xml, together with a number of
.properties files:

File Description
This file is managed on the Domain Host Controller and

pushed to slave host controllers when they start. The
slave host controllers do not use the domain.xml file (it is
kept in memory).
This file is not normally edited directly; you should use

the CLI or Management Console to change domain
configuration. As well as being safer, using the CLI or
Management Console usually means that a server
restart is not required for the changes to be applied.
The file contains the following information:
● A full list of the subsystems used by the domain.

domain.xml
● Domain level system properties.
● A set of profiles. Each profile defines configuration for

a subset of systems.
● A set of interfaces (for example, management, public).
● A set of socket binding groups that defines which ports

to use.
● A set of server groups. This defines the configuration

for the server group (for example, JVM settings and
server group level system properties), but not the
members of the server group.
Slave host controllers cache the domain.xml file in

domain.cachedremote.xml memory, and use the cached file if they cannot retrieve
the configuration from the Domain Host Controller.
host.xml A companion configuration file to domain.xml. While the

domain.xml file is identical on all hosts in a domain, the
host.xml file is different for each host.

The file contains configuration for the following:
● Security realms and authentication details.
● Interfaces (for example, which IP address to bind to).
● Which Domain Host Controller to connect to (can be

local or remote).
● Server processes on this machine, including which

server group to join, whether to automatically start, and
whether to use port offsets.
● The name of the host and server processes.
These files aren’t normally used but might be useful if

hostmaster.xml and
the role of the host needs to be switched, for example,
hostslave.xml
from slave to master.
Used briefly (by the host controller) during startup,

logging.properties
before the logging subsystem is initialized.
Contains the IP address that the management and

fas.properties public interfaces bind to. This is useful if the IP address
of the host changes.
Provides storage for user names and passwords for the

mgmtusers.properties Management Realm. Alternative approaches are
possible.
Contains authentication for the Application Realm. This

realm is configured in the host.xml file, but is unused,
applicationroles.properties and and these files are empty by default. Applications may
applicationusers.properties choose to use roles, user names, and passwords from
the Application Realm, in which case entries are needed
in these files.
Files in the bin Directory

The files in the bin directory are used for things like starting the AS, LB and JConsole,
connecting to JMX, and adding users:
File Description
Adds users to the mgmt-users.properties or application-

adduser.sh users.properties files. See the Files in the domain/configuration
Directory section.
For running applications’ JEE Application Client Container

appclient.sh
(unsupported feature).
Can be used to start the AS and LB.
This file is useful in a development environment, as it displays a

fas.sh
console log and Ctrl+C will quickly kill the server.
On a production system, use system services instead.
Starts the CLI, which can be used to edit most of the configuration
values in the domain.xml and host.xml files. It can connect to a local
jbosscli.sh
or remote host controller. The CLI can also be started in GUI mode.
See the Command Line Interface (CLI) section.
The standard Java JConsole requires additional classes to connect to

the FAS’s JMX interfaces. These scripts add the necessary libraries
to the classpath.
jconsole.sh is for connecting to the host controller’s JMX interface.

jconsole.sh and
jconsoleas.ssh jconsole-as.sh is for connecting to the AS’s JMX interface.
Makes an educated guess at the JMX service URL.
Does not have the JBoss CLI JMX extension (this script can only
connect to the host controller). See the Monitoring using JMX section.
JBoss diagnostics reporter. Collects information about what is

jdr.sh installed, in a form suitable for diagnostics. See the Diagnostics
section for information about the data collected by this script.

The vault allows passwords and other sensitive data to be masked
vault.sh
rather than being stored in plain text.
wsconsume.sh These files help to automatically generate JAX-WS clients and

and wsprovide.sh services from a WSDL Web service definition file.

This section describes how to start and stop server processes, and how to add, remove, and
configure ASs and LBs in a FAS cluster.
All of the nodes in a FAS cluster, and all of the server processes in a FAS node (that is, AS, LB,
and SNMP Agent) can be run independently of each other; however, the master node plays the
most important role. Specifically:
Configuration changes such as application deployment or un-deployment require that the

master node is running, since only the master node runs the management server process.
Slave nodes receive updated configuration from the master. If the master node is not
running, the slaves will use cached configuration and then periodically make attempts to
connect to the master to get configuration updates.
We therefore recommend that you start the master node before the slaves or the other
processes. The start-up order of these other processes is unimportant.
Starting a FAS Node
During installation, you can choose to start the FAS services automatically - see the Fusion
Application Server Installation Guide.
Once FAS is installed, you can start and stop FAS from the command line, either as a service (if
you installed it as a service), or using a script.
Starting a FAS node starts whatever server processes it finds on the node. Thus, if an AS and an
LB are both present, it will start both.
As a Service
If you have created an Operating System service to run FAS (see the Fusion Application
Server Installation Guide for details on creating a service either during or after installation), you
can start and stop it from the command line:
service fas start
service fas stop

You can also restart and examine the status:
service fas restart
service fas status
Using the Script
You can also start FAS using the supplied script:
<install dir>/bin/fas.sh
Starting and Stopping Server Processes
You can start and stop any server process in a domain using the Management Console:
1. Launch the Management Console - see the Starting the Management Console section.
2. From the top right menu, select Runtime.
3. From the top left menu, select the host that is running the server process that needs starting
or stopping.
4. From the menu on the left, select Server Instances:
5. In the main content area, select the server process you want to start or stop.

6. Click the Stop button. When the server process has stopped, it will show a circle with a line
through it in the Active column:
To start a stopped server process, click the Start button.
Note: Because the service does not stop immediately upon clicking the Stop button, it is possible
to try to start a service while it is still stopping, which will result in an error. It is advisable to wait
for the service to stop (up to a minute) before trying to start it again.
Adding Load Balancers
You can add additional nodes containing an LB to a multibox cluster. You can also add an LB to
an existing host on which only an AS was originally installed. Both procedures are described
below.
: The cluster element discovery mechanism in FAS uses multicast based on Classful
addressing. You must ensure that all hosts in the cluster have addresses in the same Classful
subnet, even if your network infrastructure is configured with Classless addressing and multicast
will span Classful subnets.
Adding a Load Balancer to the Cluster

1. Run the FAS installer on the new host (see Fusion Application Server Installation Guide),
ensuring that you select the following options:
Topology type: Multibox

Installation Options: Slave and only Load Balancer
Load Balancer Cluster Address: Public FQDN of the cluster
Cluster ID: Same as for master node.
If you did not set the Cluster ID when installing the master node, you can leave this blank to use
the default. If it was set explicitly, that value must be used.
2. Restart FAS on the master node.
Adding a Load Balancer to an Existing Node
2. In the top right menu, select Server.
3. In the top left menu, select the host to add an LB to.
4. In the left hand menu, select Server Configurations:
5. Click Add:

1. Enter the server process name.
2. Select lb-server-group.
3. Set the port offset to 0.
4. Select the Auto Start checkbox.
6. Click Save .
Configuring Load Balancers
You can configure LB properties using the Management Console or the CLI, using the lb profile.
Editing LB Properties using the Management Console
2. From the top right menu, select Profiles.
3. From the top left menu, select the lb profile.
4. In the left hand menu, expand Load Balancer, and select Configuration.
5. Select the Properties navigation tab.
6. The properties are listed in the Key column. Click on the cell in the Value column of the
property you wish to edit:

7. Enter the new value and press Return.
Editing LB Properties using the CLI
1. Start the CLI (see the Starting the CLI section).
2. Display the list of LB properties which you can configure:
/profile=lb/subsystem=lb/:read-resource(recursive=true)
3. Edit the value you wish to change:
/profile=lb/subsystem=lb/property=<property>/:write-attribute(name=value,value=<new
value>)
where is the property you want to change, and is the value you want to set it to. For the list of
properties see the LB Properties section.
LB Properties
Property Description
The name of the cluster to which the LB

cluster-name
belongs

com.alicecallsbob.loadbalancer.
The alias of the LB’s identity certificate store
http.ssl.keyStoreAlias for HTTPS.
gov.nist.javax.net.ssl.
The alias of the LB’s identity certificate store
keyStoreAlias for secure SIP.
gov.nist.javax.sip.LOG_ Set to true if you want to capture message

content in the log.
MESSAGE_CONTENT
Default is false.
Maximum size of a SIP message received

gov.nist.javax.sip.MAX_ over UDP. This is used to prevent DoS
attacks.
MESSAGE_SIZE
Default is 10000
gov.nist.javax.sip.MAX_TCP_ Maximum size of a SIP message received

over TCP. This is to prevent DoS attacks.
MESSAGE_SIZE
Default is 2000000.
Default is true, which means that the listener

is re-entrant. In this case the stack manages
gov.nist.javax.sip.REENTRANT_ a thread pool, and synchronously calls the
listener from the same thread that read the
LISTENER message. Multiple transactions may
concurrently receive messages and this will
result in multiple threads being active in the
listener at the same time.
gov.nist.javax.sip.SECURITY_
The name of the class used to provide
MANAGER_PROVIDER certificates to the SIP stack. Do not change.
gov.nist.javax.sip.SILENTLY_ Determines the behavior of the LB when it

receives a message that exceeds either
DROP_LARGE_MESSAGES MAX_MESSAGE_SIZE or

MAX_TCP_MESSAGE_SIZE (depending on
the protocol). If set to true, it silently drops
the message; if set to false, it sends a 513
Message Too Large SIP response.
Concurrency control for number of

simultaneous active threads. Default is 64.
If this is not specified, and the listener is re-

entrant, each event delivered to the listener
is run in the context of a new thread.
If this is specified and the listener is re-

gov.nist.javax.sip.THREAD_ entrant, the stack will run the listener using a
thread from the thread pool. This allows you
POOL_SIZE
to manage the level of concurrency to a
fixed maximum. Threads are pre-allocated
when the stack is instantiated.
If this is specified and the listener is not re-

entrant, the stack will use the thread pool
thread from this pool to parse and manage
the state machine but will run the listener in
its own thread.
Name of the class implementing

gov.nist.javax.sip.TIMER_ thegov.nist.javax.sip.stack.timers.SipTimer
interface. This allows pluggable
CLASS_NAME
implementations of the timer that will take
care of scheduling the various SIP Timers.
This property is set to LOG4J by default,

which means the effective log levels are
determined by log4j. Do not change this
gov.nist.javax.sip.TRACE_LEVEL value; instead logging should be configured
using the Logging subsystem of
the Core subsystem in the lb profile. See
the Configuring Logging section.

The path to the LB’s identity certificate store
https.keystore.file.path
for HTTPS.
The path to the LB’s trust certificate store for

https.truststore.file.path
HTTPS.
The default value is off, which means that

the application is responsible for creating the
dialog if required, and associate it with a
response (provisional or final) of a dialog
javax.sip.AUTOMATIC_ creating request.
DIALOG_SUPPORT If set to on a dialog gets created on a dialog

creating transaction. The first response
having both a From and a To tag creates the
transaction. The first 2xx response to the
transaction will drive the dialog to the
CONFIRMED state.
Sets the fully qualified classpath to the

application supplied Router object that
javax.sip.ROUTER_PATH determines how to route messages when
the stack cannot make a routing decision (ie.
non-sip URIs).
Sets a user friendly name to identify the

javax.sip.STACK_NAM underlying stack implementation to the
property value.
Whether the LB should remove Route

headers meant for itself.
removeRouteHeadersMeantForLB
Default is false. Do not change.
The port used by the Load Balancer to

receive RMI notifications from the ASs
rmiRegistryPort
Default is 2000. Do not change.
The path to the LB’s identity certificate store

sips.keystore.file.path
for SIPS.

The path to the LB’s trust certificate store for
sips.truststore.file.path
SIPS.
Adding Application Servers
You can add additional slave nodes containing an AS to a multibox cluster.
: The cluster element discovery mechanism in FAS uses multicast based on Classful
addressing. You must ensure that all hosts in the cluster have addresses in the same Classful
subnet, even if your network infrastructure is configured with Classless addressing and multicast
will span Classful subnets.
Adding an Application Server to the Cluster
1. Run the FAS installer on the new host (see Fusion Application Server Installation Guide),
ensuring that you select the following options:
Topology type: Multibox
Installation Options: Slave and only Application Server
Load Balancer Cluster Address: Public FQDN of the cluster
Cluster ID: Same as for master node.
If you did not set the Cluster ID when installing the master node, you can leave this blank to use
the default. If it was set explicitly, that value must be used.
2. Restart FAS on the master node
Configuring Application Servers
The main properties which you can configure for an AS are SIP Servlet properties. See the
Configuring SIP section.
Removing an AS or LB
If required, you can remove an AS or an LB server process from a cluster. You should ensure
that at least one AS and one LB remain in the cluster following the removal.

2. From the top right menu, select Server.
3. From the top left menu, select the host from which you want to delete a server process.
4. In the menu on the left, select Server Configurations.
5. In the main content area, select the server process from the table.
6. Click Remove.
7. When the confirmation dialog is displayed, click Confirm to remove the server process from
the cluster:
Disabling Support for RFC 3581
Fusion Application Server implements RFC 3581 (an extension to the Session Initiation
Protocol (SIP) for Symmetric Response Routing). This involves populating the rport parameter
with the port from which FAS received the request, and adding a Received parameter containing
the address from which it received the request.
Some entities, such as Linphone, take these values and use them to populate the contact
header in the INVITE request that it sends out. This would be fine if the entity sent the
REGISTER from the port it was actually listening on, but causes problems if it is sent from an
ephemeral port, as in the case of Linphone.
You can configure Fusion Application Server to disable RFC 3581 behavior by setting the
gov.nist.javax.sip.stack.SUPPORT_RFC3581 property to false. (The default value is true.)

Disabling RFC3581 using the Management Console
3. From the top left menu, select the ha profile.
4. In the left hand menu, expand Sip and select Sip Servlet.
6. Find the gov.nist.javax.sip.stack.SUPPORT_RFC3581 property:
7. Change the value to false.
Disabling RFC3581 using the CLI
2. Change the gov.nist.javax.sip.stack.SUPPORT_RFC3581 property to false:
/profile=ha/subsystem=sip/property=gov.nist.javax.sip.stack.SUPPORT\_RFC3581/:write
-attribute(name=value, value=false)

Viewing Cluster Configuration
You can browse through all of the configuration options for your FAS cluster using the
Configuration Browser in the Management Console. This browser provides a read-only view of
the Dynamic Representation Model, in a tree structure. This may help understand the structure
of resources in the CLI, and allows you to see attributes which you cannot access in the
Management Console.
Open the Management Console, and in the bottom right toolbar, select Tools->Browser:
Expand the nodes in the tree structure on the left, and click on the relevant node. The content
pane displays the configuration details for that node: the Description tab provides a description
of each of the data values applicable to the selected node; the Data tab displays the actual data
values:

Changing Addresses
Addresses can be configured at two levels:
The IP addresses that each node should use
The address the cluster should use when identifying itself externally (in the Contact and
Route SIP headers for instance).
Configuring Addresses on a Node

Address configuration for each node is stored on that node, in the <install
dir>/domain/configuration/fas.properties file. This file contains several properties; the
properties that are important when configuring addresses are:
Property Example Description
LB Internal Traffic IP address on ports

5065 and 7580
lb.bind.address 192.168.2.3
This is the IP address that the LB
server process uses for communication
between cluster elements.

This is the IP address that the LB
server process binds to for HTTP,
HTTPS, SIP, and SIPS traffic on ports
8080, 8443, 5060, and 5061.
lb.public.bind.address 192.168.2.3
See the Changing the LB HTTP

Address to bind to all IP
Addresses section for other options.
AS Service and Internal Traffic IP

address on ports 5080 and 8100
This is the IP address that the AS

server process binds to for HTTP,
HTTPS, SIP, and SIPS traffic from the
jboss.bind.address 192.168.2.3 LBs, as well as for communication
between cluster elements.
Note: It is not currently possible to

configure the addresses for service and
internal traffic separately for the AS
server process.
This is the IP address that the

Management Traffic binds to on port
jboss.bind.address. 9999.
192.168.2.3
management This is used by the CLI and
Management Console, and for
communication between master and
slave host controllers.
The address that management traffic is

jboss.domain.master. bound to on the master node. Only
used on slaves, where it should be the
192.168.2.3
address same as the
jboss.bind.address.management value
on the master.

Typically, the values (other than jboss.domain.master.address) will be the same, unless you
need to split network traffic among different interfaces on the host. jboss.domain.master.address
should be the same for all slaves in the cluster.
Changing the IP Addresses of a Node
1. Edit the <install dir>/domain/configuration/fas.properties file.
2. Edit the values of the addresses that you want to change and save the file.
3. Restart FAS.
4. Check that the ports are bound to the new addresses using a tool such as netstat.
If the check fails:
Check whether the port is in use.
Ensure that FAS started properly.
Look in the server logs for any information as to why the IP address could not be bound.
If you change the master node management bind address (jboss.bind.address.management),

after restarting the node you must then update the fas.properties file on each of the slave nodes
as described below:
1. Update the jboss.domain.master.address property.
2. Restart FAS.
3. Check that the slave node rejoined the master. For instance, check that the host of the slave
node appears in the Management Console.
Configuring the External Address Mode
You can configure how external entities should address the FAS cluster. You can configure the
address modes for SIP and HTTP(S) separately. These settings are:
external-address-mode
Used for HTTP, this will affect the addresses the container provides to applications when they
need to determine the address of the cluster for HTTP, such as when providing URLs to external
clients.

sip-external-address-mode
Used for SIP, it determines the address that FAS uses when it populates the following headers of
outbound SIP:
Contact header, when an application on FAS acts as a UAC or UAS.
Record-Route header, when an application acts as a record routing proxy.
Both external-address-mode and sip-external-address-mode can be set to one of:
cluster
The external-address is a static address as defined in the cluster-address attribute (see the
Configuring the Cluster Address section). When this option is selected, the Record-Route and
Contact headers in SIP messages are populated with an address that will target any LB, and
HTTP also uses this value for its address. This address should be an FQDN which resolves to all
the LBs using DNS. This option requires DNS support in the network.
load-balancer
The external-address is a randomly-selected active LB address. This mode is useful for

deployments that do not support DNS in their SIP infrastructure. It is also useful for single-box
deployments where the machine on which FAS is installed is likely to frequently change
networks, so that the DNS server is not always available.
application-server
The external-address is that of the local AS. This mode is useful for certain development
topologies where IP addresses change often.
By default, both values are set to cluster.
Changing the External Address Modes
2. In the top right menu, select Profiles.
3. In the top left menu, select the ha profile.
5. Select the Configuration navigation tab:

6. Click Edit.
7. In the HTTP External Address Mode or SIP External Address Mode drop-down lists,
select the required option such as load-balancer).
8. Click Save.
Configuring the Cluster Address
If you are using the cluster external address mode, you might need to change the cluster
address when you change other addresses. See the Configuring the External Address Mode
section for an explanation of this mode.
When you change the cluster address, you must typically make changes to the trust subsystem
to ensure that it contains a valid identity certificate that matches the new cluster address. This
will ensure the TLS server identity certificate presented to the HTTP and SIP client matches the
new cluster address.
Changing the Cluster Address using the Management Console

6. Click Edit.
7. In the Cluster Address field, enter the new address.
8. Click Save.
Changing the Cluster Address using the CLI
2. Run the following command:
/profile=ha/subsystem=sip:write-attribute(name=cluster-address,value=<new cluster
address>
where <new cluster address> is the address you want to change the cluster address to.
Configuring the Cluster Name
If your cluster is created with the default cluster name ( ClusterID-<Cluster address> ), and
you subsequently change the cluster address or IP address, the original cluster name does not

get changed. You do not normally need to change it, as long as it is still unique in your
enterprise, and it is identical on each AS and LB in the cluster. You can change the name if
required, however.
Note: While it is possible to change the cluster name through the CLI, the cluster name is used
as the basis of many attributes (for example, the names of Infinispan caches), and these will not
be changed. Therefore, the recommended approach is to find and replace all occurrences of the
old cluster name value in the underlying configuration file, domain.xml.
1. On the master FAS, open the <install dir>/domain/configuration/domain.xml in an

editor.
2. Find each occurrence of the old cluster name and replace it with the new cluster name.
There will typically be around ten occurrences of the cluster name to be changed:
<transport cluster="sessionLocation-ClusterID-192.168.9.14" lock-timeout="60000"/>
would become
<transport cluster="sessionLocation-<new cluster name>" lock-timeout="60000"/>
where is the new name of the cluster.
3. Save the file
4. Restart the master FAS, and then restart FAS on all the slave nodes to pick up the changes.
The cluster name on each AS and LB in the cluster must match, otherwise the ASs will not be
able to register with the LBs.
Changing the LB HTTP Address to bind to all IP Addresses
By default, the LB only listens on one network interface for all traffic: that is, HTTP, HTTPS, SIP,
and SIPS. Using the CLI, you can configure the LB to listen for HTTP and HTTPS on all IPv4
addresses. Once the HTTP and HTTPS bindings are changed to bind to all interfaces, traffic can
be sent to http://<any_bound_ip>:8080 and https://<any_bound_ip>:8443 .
1. Connect to the CLI (see the Starting the CLI section).
2. Run the following commands:
/socket-binding-group=lb-sockets/socket-binding=http:write-
attribute(name=interface,value=all)

/socket-binding-group=lb-sockets/socket-binding=https:write-
attribute(name=interface,value=all)
3. Restart FAS on each node to pick up the new configuration.
The HTTP and HTTPS bindings for the LB will now be to all interfaces ( 0.0.0.0).
Managing Frequently Changing IP Addresses

When running FAS on a development machine, it is likely that your IP address will be changing
frequently. There are two ways to help manage this:
If you do not need FAS to send and receive SIP or HTTP traffic to and from other machines,
you can use the loopback address. See the Using the loopback Address section
Otherwise, you should set the external address modes to use the load-balancer option (this
step will avoid you having to update the cluster address each time the address changes),
and then update the fas.properties file with details of the new IP address each time it
changes, as described below. See the Configuring the External Address Mode section for
details of how to change the mode.
Note: The following instructions assume that FAS is running as a single box installation.
To Change the IP Address in the fas.properties file
1. Edit the <install dir>/domain/configuration/fas.properties file.
2. Edit the value of the jboss.bind.address property to the new IP address.
3. Edit the value of the jboss.bind.address.management property to the new IP address.
4. Edit the value of the jboss.domain.master.address property to the new IP address.
5. Save the file.
6. Restart the FAS service.
Using the loopback Address
For single-box installations, you might want to install FAS using the loopback address (127.0.0.1)
to avoid having to change the bind address when the host machine’s IP address changes. You
can configure FAS to bind to the loopback address by editing the jboss.bind.address (as

described in the To Change the IP Address in the fas.properties file section) to be the loopback
address.
Binding to the loopback address means that FAS will not be externally addressable, so all
interactions with FAS (SIP messages, administration) must originate from that machine.
If the loopback address is used, for the AS and LB to communicate with each other they must
use the FILE_PING discovery protocol. You can set this using the CLI:
1. Connect to the CLI (see the Starting the CLI section).
/profile=ha/subsystem=jgroups/stack=tcp:add-protocol(type=FILE_PING)
/profile=ha/subsystem=jgroups/stack=udp:add-protocol(type=FILE_PING)
/profile=lb/subsystem=jgroups/stack=tcp:add-protocol(type=FILE_PING)
/profile=lb/subsystem=jgroups/stack=udp:add-protocol(type=FILE_PING)
Reverting the Changes
If at some point using the loopback address is no longer appropriate, you must remove the
FILE_PING discovery protocol, and then set the jboss.bind.address to an appropriate IP
address.
The FILE_PING discovery protocol can be removed with the following CLI commands:
/profile=ha/subsystem=jgroups/stack=tcp:remove-protocol(type=FILE\_PING)
/profile=ha/subsystem=jgroups/stack=udp:remove-protocol(type=FILE\_PING)
/profile=lb/subsystem=jgroups/stack=tcp:remove-protocol(type=FILE\_PING)
/profile=lb/subsystem=jgroups/stack=udp:remove-protocol(type=FILE\_PING)
When you have run these commands and edited the jboss.bind.address as required, restart FAS
to pick up the changes.

You can deploy several types of application to the Fusion Application Server:
Application Type File Format
Application Type File Format
SIP sevlet WAR
Converged Application (SIP Servlet(s) and HTTP Servlet(s)) WAR
JEE Application Module EAR
JAR files and Java resources such as property files JAR
Note: FAS does not support SAR files.
You can deploy multiple applications on a cluster using the Management Console; once
deployed, you can configure application properties in the same way. You can also configure
datasources for those applications which need them (see the Configuring Datasources section).
Deploying Applications
Deployments can be managed through the Management Console.
Deploying an Application
3. In the left hand menu, expand Domain and select Manage Deployments.
4. Select the Content Repository navigation tab:

5. Click Add to display the Upload dialog:
6. Choose the application that you want to deploy, and click Next:

Any type of file can be uploaded to the FAS, but you will normally upload WAR or EAR files.
7. Edit the name if required (usually you can accept the default), and click Save.
The uploaded file will appear in the Content Repository.
8. Select the application that you have just uploaded (files in the Content Repository are in
alphabetical order of their names), and click Assign:
9. Select the server group you want to deploy the application to. In most instances, SIP
applications will be deployed to the main-server-group. Applications should not be deployed
to the lb-server-group.

10. Click Save.
The application is now uploaded and deployed to a server group. The Assignments column
should show 1 against the name of the application.
Updating an Application
5. Select the application you wish to update in the list, and click Update:

6. Choose the application that you want to deploy, and click Next:
Make sure that you choose a file containing a newer version of the application you are updating,
as FAS cannot distinguish a newer version of the same application from an unrelated application.
7. Click Save.
The application will be uploaded to FAS, replacing the selected application, and assigned to any
server groups it was already assigned to.
Undeploying an Application

5. Select the application you want to undeploy, and click Remove:

6. Click Confirm to remove the application from FAS. It will no longer appear in the Content
Repository.
Note: Deployed applications can depend upon other deployed applications. If you remove an
application without removing any applications which depend on it, those applications will
probably malfunction. If in doubt, you can disable an application first, to check if it is safe to
remove it; see the Enabling or Disabling an Application section.
Enabling or Disabling an Application
4. Select the Server Groups navigation tab:
5. Click the View link in the Options column of the main-server-group row:

6. Select the application you want to disable, and click the En/Disable button:
7. Click Confirm to disable the application.
When disabled, the tick in the Enabled column will disappear. If the application is disabled,
clicking the En/Disable button will enable it.
Application Backups

You can configure FAS to store backups of each deployed artifact. The backups are stored in the
directory <install dir>/domain/deployment\_backups on the master node. Each time it
uploads a file (whether it is new or an update to an existing application), FAS stores a backup in
this directory with the name <filename>-<YYYYMMDDhhmmssmmm> where <YYYYMMDDhhmmssmmm>
is a timestamp in ISO order with millisecond precision and no separators or timezone. You can
configure how many backups are stored for each one by setting the value of
jboss.domain.backups.max in the <install dir>/domain/configuration/fas.properties file.
The value should be 0 or higher, with 0 indicating no backups should be stored. The default
value is 5.
Configuring Application Properties
Applications that can be deployed to Fusion Application Server can expose their properties for
configuration in the Management Console in two different ways: using system properties, or
using the Application Configuration Framework. This section describes both methods. The
documentation for your application should describe the properties that can be configured and
how to configure them.
Configuration using System Properties

System properties are used by some applications as part of their configuration; for example
some FCSDK samples require some system properties to be added. (See the FCSDK
documentation for details of the required system properties.) To add system properties:
2. Application properties can be added at any of the following four levels (in order of
precedence):
i. domain level
Applies to all server processes running on all hosts within the domain:
a. Click Profiles in the top right menu
b. In the left hand menu, expand General Configuration and click System Properties
ii. server group level
Applies to all server processes within a server group:

a. Click Server in the top right menu
b. In the left hand menu, expand Server and click Server Groups
c. Select the Server Group in the main content area, and choose the System Properties
tab below it
iii. host level
Applies to all the server processes running on a specific host:
a. Click **Server** in the top right menu, and select the host in the top left
menu
b. In the left hand menu, expand **Host Settings** and click **Host
Properties**
iv. server level
Applies to a specific server process:
a. Click **Server** in the top right menu and select the host in the top left
menu
b. In the left hand menu, select **Server Configurations**
c. Select the server process in the main content area, then select the
**System Properties** tab below
The most common place to set a system property is at server group level, because applications
are deployed to a server group. In the appropriate System Property page:

To edit a system property, click the cell in the Value column of the property you want to
change, and enter the new value.
To remove a system property, select the property and click the Remove link.
To add a system property, click the Add button to bring up the Create System Property
dialog:
Enter the Name and Value, and click Save.
Changes made to system properties are immediately available to applications.
Configuration using the Application Configuration Framework
Alternatively, applications can use the Application Configuration Framework (ACF) to manage
their configuration. This offers validation and publishing hooks that allow the application to check
that configuration settings are valid, and to be informed when configuration settings have
changed.

If an application has been developed to use the ACF, its configuration can be managed using the
CLI or Management Console.
Managed and Unmanaged Applications
An application may be capable of being managed by the ACF, without actually being managed.
In order to manage its properties, you must first manage the application:
2. From the top right menu, choose Profiles.
4. In the left hand menu, expand Subsystems and Sip, and select Application Config:
5. Select the application you want to manage and click the Manage button. A dialog appears:

6. Click Confirm to manage the application. The Status column will read MANAGED, and
there will be an Unmanage button:
You can unmanage a managed application by clicking Unmanage. If you unmanage a

previously-managed application, this deletes any overridden properties set by the administrator
or product installer. Values return to their default values, and the properties are no longer
editable.
Managing ACF Applications using the Management Console

4. In the left hand menu, expand Subsystems and Sip, and select Application Config:
The applications which are using the ACF are displayed in the top of the main content area. If
there is more than one, you will need to select the application to see its properties in the lower
part of the main content area.
5. Click on the cell in the Value column for the property you wish to edit.
When you press Enter , or move the focus away from the
edited cell, it validates the property value and displays any errors. Values are not immediately
published.
6. Repeat with all the properties you want to change.
7. Click Save.

This tries to validate and save all the properties. In this step, the application validates the
property set as a whole; if the validation is successful, the Management Console publishes the
properties: that is, it sends the property set to the application and informs it of the change. If any
of the values are invalid, it displays an error and does not make any changes.
Managing ACF Applications using the CLI
2. Run:
/profile=ha/subsystem=config:list-apps()
to get a list of applications which can be managed using the ACF:
{
"result" => undefined,
"server-groups" => {"main-server-group" => {"host" => {"master-192.168.9.14" =>
{"192.168.1.234-1" => {"response" => {
"result" => [("SomeApp" => {
"description" => "Provides sip routing adaptation",
"status" => "MANAGED"
})]
}}}}}}
The status of the application in the above example is MANAGED, therefore its properties can be
modified. If it was UNMANAGED, you would need to manage it before setting its properties.
To manage an application:
/profile=ha/subsystem=config/application=<application
name>:add(description="description")
(You must add a description if you manage the application using the CLI.)
To unmanage an application:
/profile=ha/subsystem=config/application=<application name>:remove()

To view an application’s properties:
/profile=ha/subsystem=config/application=<application name>:describe
This will return the properties:
{
"server-groups" => {"main-server-group" => {"host" => {"master-192.168.9.14" =>
{"192.168.1.234-1" => "response" => {
"result" => [{"properties" => {
"externalRegistrarUrl" => {
"description" => "The SIP URI of the external registrar",
"value" => "192.168.1.100",
"type" => "String",
"status" => "SET"
},
"internalUserPattern" => {
"description" => "A regular expression pattern to match all SIP users that
should be handled by the internal registrar",
"value" => "^1.\*",
"defaultValue" => "^1.\*",
"type" => "String",
"status" => "NOT\_SET"
}
}}]
}}}}}}
To validate a property:
/profile=ha/subsystem=config/application=<application name>/property=<property
name>:validate(value=<new value>)
The outcome (success, or failed and a reason) will be returned in the response.
To add a property:
name>:add(value=<value>)

Use add to set one of the exposed properties which has not been set before; if it has already
been set, use update.
To remove a property:
/profile=ha/subsystem=config/application=<application name>.property=<property
name>:remove
To change a property:
name>:update(value=new value>)
Use update to change an exposed property that has previously been set using add; if it has not
been set before, use add.
To publish the changes:
When you have made all the changes to the properties that you want, you must publish them,
which saves them and pushes them to the FAS server processes.
/profile=ha/subsystem=config/application=<application name>:validate()
/profile=ha/subsystem=config/application=<application name>:publish()
Co-hosting Applications
The JSR 289 SIP specification allows for only one SIP application router per container. This
makes it difficult to install or deploy more than one SIP product to a single container. The Fusion
Application Server supports the ability to have multiple application routers deployed at the
same time, facilitating the co-hosting of multiple SIP products.
FAS introduces a concept of a SIP application router domain. Each application router can be
associated with a number of domains. When a SIP request enters FAS, FAS checks the domain
that the SIP message is addressed to, and selects the application router with an application
router domain that matches. If the domain is not explicitly configured as an application router
domain of one of the application routers, FAS selects the application router which is configured
as the default.

Each deployable artifact (for example FCSDK’s gateway.ear) is associated with its own
application router, which sends SIP to the servlets within the artifact. Each application router
must register with the Application Router Registry module of FAS. If a servlet in an artifact acts
as a UA and generates an outbound SIP message, that message will also pass through the
artifact’s application router.
Note: When co-hosting multiple applications, ensure that a reverse lookup on any IP address in
the FAS cluster can only resolve to a single application router domain. Otherwise, a remote
application could perform a reverse lookup on one of the IP addresses, and resolve it to a
domain which FAS associates with a different application; in that case, any SIP message sent by
the remote application would go to an application which it was not intended for.
See the Fusion Application Server Architecture Guide for more information on the Application
Router Registry and Application Router selection.
Configuring AR Details in the Management Console
4. From the menu on the left, expand Sip and select Application Routers:

A list of any existing application routers is displayed in the bottom of the main content area,
together with the Controlled Domains to which they apply.
5. Click the Add button:
6. Enter the name of the Application Router.
7. If you want this to be the default Application Router, select the Is Default checkbox. Only
one AR can be the default.
8. Click Save.
9. Select the Application Router you have just added, and the Controlled Domains tab below.
10. Click the Add button on the Controlled Domains tab:
11. Enter the Controlled Domain to which the AR will apply, and click Save.
FAS will route SIP to Application Routers according to the domain in the Request URI of the
INVITE, so the Controlled Domain should be an IP address or the domain part of a SIP address.
12. If your new application router is not the default, you must specify which application should
use this application router. Select the Application Artefacts tab and click Add:

13. Enter the name of the deployed application file for the application that should use this AR,
and click Save.
Configuring AR Details in the CLI
2. Type:
/profile=ha/subsystem=sip/app-router=
and press Tab to get a list of installed application routers.
3. Run:
/profile=ha/subsystem=sip/app-router=<app router name>:read-resource
to get a list of an application router's properties:

"result" => {
"default" => true,
"application-artefact" => {"test.ear => undefined},
"controlled-domain" => {"192.168.1.100" => undefined}
}
The response illustrates an application router with a single controlled domain (192.168.1.100)
and a single artifact (test.ear), and set as the default application router.

To add an application router:
/profile=ha/subsystem=sip/app-router=<app router name>:add
To remove an application router:
/profile=ha/subsystem=sip/app-router=<app router name>:remove
To set an application router to be the default:
/profile=ha/subsystem=sip/app-router=<app router name>:write-

attribute(name=default,value=true)
To add a controlled domain to an application router:
/profile=ha/subsystem=sip/app-router=<app router name>/controlled-domain=

<controlled domain name>:add
To remove a controlled domain from an application router:
/profile=ha/subsystem=sip/app-router=<app router name>/controlled-domain=

<controlled domain name>:remove
To add an artifact for an application router:
/profile=ha/subsystem=sip/app-router=<app router name>/application-artefact=

<application name>:add
To remove an artifact for an application router:
/profile=ha/subsystem=sip/app-router=<app router name>/application-artefact=

<application name>:remove
If a resource you are trying to add already exists, or a resource which you are trying to remove
does not, you will receive an error response:
{
"outcome" => "failed",
"failure-description" => {"domain-failure-description" => "JBAS014803:
Duplicate resource [
(\"profile\" => \"ha\"),
(\"subsystem\" => \"sip\"),
(\"app-router\" => \"my-app-router\"),
(\"controlled-domain\" => \"my-controlled-domain\")

]"},
"rolled-back" => true
}
Configuring Datasources
Some applications (for instance, some of the Fusion Client SDK samples) that you can run on
FAS require the use of a database.
The standard way to access a database is by using a datasource. To create a datasource, you
need to:
install the JDBC driver
create the datasource
configure the datasource
test the connection
Each of these is described here.
Installing the JDBC Driver
A JDBC-4 compliant JDBC driver file must be deployed using the Management Console:
1. Download the relevant JDBC driver.
For example, the MySQL JDBC driver can be obtained from:
http://dev.mysql.com/downloads/connector/j/
The Oracle driver can be downloaded from:
http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-112010-090769.html
The driver file must be available on the machine that you are accessing the Management
Console from, as the Browse function can only access the local file system.

4. From the left hand menu, select Manage Deployments.
5. Click Add.
6. Select the JDBC driver JAR file which you have just downloaded.
7. Click Next.
8. Click Save.
9. Click Assign.
10. Select the groups you want to add the driver to.
In most cases, this will be main-server-group, but there may be occasions when you need to
make a datasource available to one of the other groups.
11. Click Save.
Creating the Datasource

1. In the top right menu, select Profiles.
2. Select the profile you want to work with from the top left menu.
3. From the menu on the left, expand Connector, and select Datasources:

4. Click Add:
5. Enter the name of the data source (e.g. TestDS), and it’s JNDI name (e.g.
java:jboss/datasources/TestDS).
6. Click Next:

7. Select the JDBC driver you have just deployed.
8. Click Next:
9. Enter the connection URL (e.g. jdbc:mysql://<host>:3306/<schema> - the format varies

with the JDBC driver in use).
10. Enter the user name and password for the database, and the security domain if needed.
11. Click Done.
12. Restart the AS (see the Starting and Stopping Server Processes section).
Configuring the Datasource
To configure the datasource, it must be disabled; you cannot configure an enabled datasource.

2. Select the profile you want to work with from the top left menu.
3. From the menu on the left, expand Connector, and select Datasources:
4. Select the datasource you want to configure, and if it is enabled (if there is a tick in the
Enabled column), click the Disable button, then Confirm in the Modify Datasource dialog:
5. Configure Transaction Isolation:

i. Select the Connection tab in the lower part of the main content area.
ii. Click Edit.
iii. From the Transaction Isolation drop down list, select a value appropriate to your
application:
iv. Click Save.
6. Configure the Connection Pool:
i. Select the Pool tab in the lower part of the main content area:
ii. Click Edit.
iii. Set the Min Pool Size and Max Pool Size.
iv. Click Save.
7. Click Enable, then Confirm in the Modify Datasource dialog.

Testing the Connection
You can test the datasource using the CLI:
2. Run:
/host=<host name>/server=<server process>/subsystem=datasources/data-source=

<datasource name>:test-connection-in-pool()
where <host name> is the host (usually either localhost or master-<ip address> ), <server
process> is the name of the AS or other server process (e.g. appserver-localhost), and
<datasource name> is the name of the datasource you want to test.
You should get a success message returned:
/host=master-192.168.1.234/server=192.168.1.234-1/subsystem=datasources/data-
source=MyDS:test-connection-in-pool()
{
"result" => [true]
}
For more information on configuring datasources in JBoss7, see

<https://docs.jboss.org/author/display/AS7/Admin+Guide#AdminGuide-Datasources>

Licensing
This section describes how to use the License Server included in FAS to apply licenses for
products which run on FAS.
Note: Fusion Application Server itself does not need a license.
Managing Licenses
Some applications that you install onto Fusion Application Server might be supplied with a
usage license. These licenses must be applied using the License Server, which is installed on
the master node. When installed, the configuration option for the License Server is added to the
Management Console. You can also manage licenses using the Command-Line Interface (CLI).
As well as details about what is licensed, and how many of them (or how much of it) are allowed
by the license, each license has a start date and an end date. The product is only licensed
between those dates.
You can use the License Server to add and remove product licenses, and to view details of any
active or inactive licenses. CBA Support supplies licenses as XML files. You should save the
license file to a location that the Management Console can access.
When a licensed application is first installed, the licensing state will be ERROR. You must apply
the required license to correct this.
SNMP Traps
The License Server will raise SNMP traps when one of the licenses that it is managing changes
state. The state of a license can be:
State Description
ACTIVE The product is licensed by this license.
The current date is before the start of the license. The license will
NOT_STARTED
become ACTIVE on the date the license starts.
EXPIRED The license has expired.

EXPIRING_SOON The license is due to expire in 30 days or less.
See the Configuring SNMP section for details on how to receive these traps.
Managing Licenses using the Management Console
Viewing License Details using the Management Console
3. From the top left menu, select the management profile.
4. In the left hand menu, expand License Management and select Licenses:
Licenses that are currently active are displayed in the Active Licenses list; otherwise, they are
displayed in the Inactive Licenses list.
5. To view the details of a license, select it and click View:

Click Cancel to dismiss the dialog.
Adding a License using the Management Console
1. Obtain a license from CBA Support, and ensure that it is available on the machine you are
accessing the Management Console from.

6. Click the Upload License button to display the Upload dialog:
7. Click Browse, navigate to the directory containing the license file, select it, and click Add.
If the license is active, it is applied to your product and listed in the Active Licenses
table
If the license is inactive, it is listed in the Inactive Licenses table
8. Restart the AS which is hosting the application to which the license is being applied (see the
Starting and Stopping Server Processes section).

Removing a License using the Management Console
5. Select the license you want to remove, and click Remove.
Managing Licenses using the CLI
2. Run:
/profile=management/subsystem=license-server:read-resources
to get details of the License Server:

{
"result" => {
"host" => "master-192.168.1.234",
"product" => undefined,
"server" => "192.168.1.234-management"
}
}
The returned details contain the name of the host (master-192.168.1.234 in the example above,
and <host> in the following commands) and server process (192.168.1.234-management
above, and <server process> in the following commands) that the License Server is running
on. You will need these for other operations.
To add a license:
/host=<host>/server=<server process>/subsystem=license-server:add-license(path=
<path to license file>)
where is the path on the local machine to the license file.
To get a list of all existing licenses:
/host=<host>/server=<server process>/subsystem=license-server:read-
resource(recursive=true,include-runtime=true)
which will return information including the product name and the license name:
{
"result" => {
"host" => "master-192.168.1.234",
"server" => "192.168.1.234-management",
"product" => {"SomeProduct" => {
"active-license" => "33322a55-0f39-4216-bb72-17b369ab9990",
"loaded-license" => {"33322a55-0f39-4216-bb72-17b369ab9990" => {
"activated" => "20/02/2013 12:00 AM",
"customer-id" => "Internal",
"expires" => "05/02/2014 12:00 AM",
"counted-feature" => {"users" => {
"allocated" => "0",
"allowed" => "1000",
"display-name" => "Maximum number of users"

}
},
"uncounted-feature" => {"grace-period" => {

"content" => "30",
"display-name" => "Grace period in days"
}}
}}
}}
}
}
The important things are the product name (SomeProduct above, and <product name> in the
following commands) and the license name (33322a55-0f39-4216-bb72-17b369ab9990 above,
and <license id> in the following commands), which are needed for other commands.
To get a list of products:
/host=<host>/server=<server process>/subsystem=license-server:read-children-
resources(child-type=product)
which returns a list with less complete information:
{
"result" => {"SomeProduct" => {"loaded-license" => {"33322a55-0f39-4216-bb72-
17b369ab9990" => undefined}}}
}
To see licenses for a specific product:
/host=<host>/server=<server process>/subsystem=license-server/product=<product
name>:read-resource(recursive=true,include-runtime=true)
To see the details for a specific license:
/host=<host>/server=<server process>/subsystem=license-server/product=<product
name>/loaded-license=<license id>:read-resource(recursive=true,include-
runtime=true)
To remove a license:

/host=<host>/server=<server process>/subsystem=license-server:remove-
license(licenseId=<license id>,productName=<product name>)
Connecting to a different License Server
By default, ASs connect to the License Server on the local Domain Host Controller. If you have a
deployment containing more than one cluster, you might want to control all of your licenses from
a single License Server, which means that ASs in the other clusters will need to connect to the
License Server on a Domain Host Controller other than the local one. This can be done either
using the Management Console or the CLI. Each procedure is described below.
Connecting to different License Server using the Management Console
1. Launch the Management Console for the domain which needs to connect to a different
Domain Host Controller for licensing - see the Starting the Management Console section.
4. From the menu on the left, expand Subsytems and License Client, and select License
Server:

5. Click Edit and enter the new License Server URL. It should be in the form
http://<license server host name>:9100 .
6. Click Save.
7. Restart the AS on the master node for the changes to take effect (see the Starting and
Stopping Server Processes section).
8. Repeat the procedure for each other domain which needs to connect to a different Domain
Host Controller for licensing.
Connecting to different License Server using the CLI

1. Start the CLI (see the Starting the CLI section).Connect to the master node of a domain
which needs to connect to a different Domain Host Controller for licensing.
2. Run:
/profile=ha/subsystem=license-client:write-attribute(name=license-server-url,value=
<new license server URL>)

The license server URL must be in the format http://<license server host name>:9100 . The
response should be:
{
"server-groups" => {"main-server-group" => {"host" => {"<master name>" => {"
<server name>" => {"response" => {
"response-headers" => {
"operation-requires-restart" => true,
"process-state" => "restart-required"
}
}}}}}}
3. Restart the AS on the master node for changes to take effect.
4. Repeat the procedure for every other domain which needs to connect to a different Domain
Host Controller for licensing.

Configuring SNMP
CBA applications that run on Fusion Application Server can generate SNMP event data
(traps). This data can provide valuable usage and diagnostic information to administrators and
network operations personnel.
For example, an application that monitors changes to a critical resource might raise an
asymmetric trap when the resource changes. Similarly, you might have an application that
monitors the availability of specific resources (such as the memory, or some other limited
resource). When that resource runs low, the application might set a warning state and send a
Set trap. Once that resource returns to acceptable levels, it sends a Clear trap.
For details of the architecture of the SNMP subsystem, see the Fusion Application Server
Architecture Guide.
If you need to change the configuration details for the SNMP Agent after installing FAS, you can
do so by modifying the attributes defined in the snmp_subsystem within the management profile
using the JBoss CLI, and then restarting the SNMP service.
You can optionally configure the SNMP Agent to send notifications to multiple SNMP trap
receivers, each with its own SNMP protocol version, IP address, and port. The installer can only
configure a single receiver, but you can add extra receivers to the configuration after installation
by adding trap-target entries for the snmp_subsystem using the JBoss CLI, and then restarting
the SNMP service (see the Configuring SNMP Trap Targets section).
The Fusion Application Server platform itself can also raise SNMP notifications. These are
detailed in the Fusion Application Server SNMP Traps section.
Configuring the SNMP Agent
An SNMP Agent runs as part of the Host Controller process on each FAS node. The SNMP
Agent sends the event data to an SNMP client of your choice. An SNMP client is not supplied
with Fusion Application Server: you must install your own client and supply the IP address of
the server on which the client is running when you install FAS and SNMP Agent.
If you need to change the configuration details for the SNMP Agent, such as the location of the
SNMP client or the transport protocol used, or if you need to add additional SNMP trap receivers,
you can do so using the JBoss CLI.

You can change some properties at the SNMP subsystem level, and other properties can be set
for a specific SNMP trap target:
/profile=management/subsystem=snmp\_subsystem/:write-attribute(name=<attribute-
name>,value=<new-value>)
The attributes you can change are:
Attribute Details
port The default port is 8161, but can be changed to any valid port number.
The protocol used for sending the traps. Can be udp or tcp. If the protocol is
protocol
not specified, udp is used.
The polling period in seconds which the SNMP Agent uses to check for
poll‑period changes to JMX attributes. When it detects a change, it sends a symmetric
trap.
For example, to change the port used to 1061, you would use the following command:
/profile=management/subsystem=snmp_subsystem/:write-attribute(name=port,value=1061)
If you make any changes to the SNMP options, you must restart the SNMP service:
/profile=management/subsystem=snmp\_subsystem/:restart-snmp
You can also change the security options for SNMP - see the Configuring SNMP Trap Security
section.
Configuring SNMP Trap Targets
To add an address for receiving traps, you add an SNMP trap target:
/profile=management/subsystem=snmp\_subsystem/trap-target=<target
name>/:add(protocol=<snmp protocol>,ip=<target ip>,port=<target port>)
where
<target name> is the ID of the trap target (a name for identification purposes)
<snmp protocol> is the SNMP protocol to use for this target. This must be one of

SNMPv1
SNMPv2c
SNMPv3
If the protocol is omitted, it defaults to SNMPv2c.
<target ip> is the IP address of the trap target.
<target port> is the port number which the trap target is listening on.
For example, to add a target with an ID of local, you might use a command like:
/profile=management/subsystem=snmp\_subsystem/trap-
target=local/:add(protocol=SNMPv2c,ip=127.0.0.1,port=1062)
The properties for each trap target can be changed using a command that specifies the target-
name:
/profile=management/subsystem=snmp\_subsystem/trap-target=local/:write-
attribute(name=port,value=1063)
If any changes are made to the SNMP trap target options, restart the SNMP service:
Use an SNMP client that implements the ALARM-MIB file. You can download the file from a site
such as http://www.simpleweb.org/ietf/mibs/. You must then import this file, along with any MIB
files supplied with applications that you will deploy and which will raise traps, into your SNMP
client tool.
For the Fusion Application Server traps, you must import the following MIB files into your
SNMP client:
AS-PLATFORM.MIB
AS-LICENSING.MIB
These files can be found in the <install dir>/docs/mibs directory.

Fusion Application Server SNMP Traps
There are a number of SNMP traps that might be raised when significant events occur within the
FAS cluster. Each of the following SNMP traps for FAS are symmetric; this means that each trap
contains Set when an issue is detected, or Clear when the issue is resolved:
Set Trap Name Description
A slave AS could not connect to the

Domain Host Controller, suggesting
platformSetSlaveDomainConnectionDown that the Domain Host Controller is not
running. Applies to multi-box
deployments only.
The server group has no active

platformSetServerGroupDown
server processes
The SNMP Agent failed to connect to

a server process. This could be an
AS, LB, or Management Server; it is
platformSetServerConnection
identified by the resourceId in the
notification. (See the Decoding the
Resource ID section.)
Set for any server process state

change for an AS, Management
platformSetServerState
Server or LB. The server process has
either stopped or a restart is required.
An LB has no ASs registered with it.

This trap is fired only when an LB is
platformSetNodesNotRegisteredWithLoadbalancer
restarted at a time when there are no
ASs running.
The Clear traps are called platformClearSlaveDomainConnectionDown, etc.
When the issue is resolved, the associated Clear trap is raised; for example, if the
platformSetServerGroupDown trap was raised, the platformClearServerGroupDown trap is
raised when at least one server in the server group starts, signifying that the issue is resolved.
There is also an asymmetric trap, platformAbnormalServerShutdown. This trap is raised every
time an AS or LB shuts down unexpectedly. By default, when an unexpected shutdown is
detected the Host Controller will restart that server. This trap ensures that administrators are
alerted to multiple restarts that might affect service, so that they can investigate the issue.
If FAS is running a product which requires a license, the following traps may be raised as the
license changes state:
Trap Name Description
A license has changed state to something other than ACTIVE.

The new state may be one of:
● NOT_STARTED
asLicensingSetState
● EXPIRED
● EXPIRING_SOON
asLicensingClearState The state of the license has changed to ACTIVE.
The content of these traps includes the Resource ID and the State. The Resource ID encodes
information about the product whose license has changed state: the server process (which is
always management), the product ID, and the license ID.
See the Licensing section for further details.
Example Scenarios
If all of the ASs in a server group go down, no traffic can be processed for that server group,
FAS raises the platformSetServerGroupDown trap.
If the management server process on the Domain Host Controller goes down, the licensing
subsystem becomes unavailable, so FAS raises the platformSetServerConnection trap. It
might also raise the platformSetServerState, as the server state changes from the running
state.
If a slave Host Controller loses connection to the Domain Host Controller, the configuration
on that might become stale, so FAS raises the platformSetSlaveDomainConnectionDown
trap.
If a slave Host Controller reinstates a connection to the Domain Host Controller, FAS raises
the platformSetServerState trap (restart required state).
Decoding the Resource ID
The resource ID identifies a FAS resource. It consists of a prefix which identifies FAS itself,
followed by a single digit which identifies either the Host Controller itself, or one of two tables; if it
is a table, it is followed by an index identifying the member of that table.
All the table and scalar OIDs for the FAS trap resources start with 1.3.6.1.4.1.7377.100:
Resource ID Resource
1.3.6.1.4.1.7377.100.0 Host Controller
1.3.6.1.4.1.7377.100.1 Server Process table
1.3.6.1.4.1.7377.100.2 Server Group table
For the tables, the indexes are keys consisting of an encoded string (containing the server
process name for the server process table, or the server group name for the server group table).
The encoded string that makes up the index has a number representing the number of
characters in the string, followed by the ASCII character numbers that make up the string.
For example, for a server process named Hello, the resource ID would be:
1.3.6.1.4.1.7377.100.1.5.72.101.108.108.111
where:
1.3.6.1.4.1.7377.100.1 indicates the server process table.
5 is the length of the string (Hello), followed by:
72 (ASCII H)
101 (e)
108 (l)
108 (l)
111 (o)
Traps Raised on FAS Startup
When a FAS cluster is first started, a number of traps are raised. This is because the system has
no history of traps raised, so the status of each node is tested. If the status is fine, a Clear trap
will be raised, regardless of any previous state. Therefore, on start-up, FAS will raise at least the
platformClearNodesNotRegisteredWithLoadbalancer and platformClearServerGroupDown traps.
As the nodes in a FAS cluster start in an undefined order, it is likely that it will raise some Set
traps, closely followed by the associated Clear traps.
Configuring SNMP Trap Security
By default, where applications raise SNMP traps, SNMPv2 traps are generated. You can
optionally change this to SNMPv3 traps on installation; these traps can be secured, but are
insecure by default. This section describes how SNMPv3 traps can be secured.
You can also restrict access to SNMP managed objects for any SNMP protocol version. This is
done using the View Access Control Model (VACM). This is described in the SNMP View Access
Control section.
SNMP security levels and users are defined as properties of the snmp_subsystem, and can be
configured using the CLI. To get a list of all the properties in the SNMP subsystem, use:
/profile=management/subsystem=snmp\_subsystem/:read-resource(recursive=true)
All of the values starting snmp4j.agent.config are related to SNMPv3 security; there are a great
many of them, and only some of these options are discussed in this section.
Configure them using a command like:
/profile=management/subsystem=snmp\_subsystem/property=<property name>/:write-
attribute(name=value,value=<property value>)
After any change to the SNMP subsystem or properties, restart the SNMP service:
SNMP Security Levels and Users

You can implement SNMPv3 User-based Security Model (USM) security at one of three levels;
there are three users specified by default, each one corresponding to one of the three levels,
using specific authentication and encryption algorithms:
User Maximum Security Level Description
SHADES authPriv Authorization (SHA) and encryption (DES)
SHA authNoPriv Authorization (SHA) without encryption
unsec noAuthNoPriv Neither authorization nor encryption
These users are defined by the SNMP properties snmp4j.agent.cfg.oid.1.3.6.1.6.3.15.1.2.2.1,

snmp4j.agent.cfg.index.1.3.6.1.6.3.15.1.2.2.1.0 (SHADES),
snmp4j.agent.cfg.index.1.3.6.1.6.3.15.1.2.2.1.1 (SHA), and
snmp4j.agent.cfg.index.1.3.6.1.6.3.15.1.2.2.1.2 (unsec), together with their associated properties
(snmp4j.agent.cfg.value.1.3.6.1.6.3.15.1.2.2.1.0.0,
snmp4j.agent.cfg.value.1.3.6.1.6.3.15.1.2.2.1.0.1, etc. - note that the 1.3.6.1.6.3.15.1.2.2.1 part
is constant across the user definitions). The only values in the user definitions which should be
changed are the passwords (SHADESAuthPassword, SHADESPrivPassword, and
SHAAuthPassword).
Other values in the SNMP subsystem may be changed. For instance, to change the SNMPv1
read access to unrestricted, use:
/profile=management/subsystem=snmp\_subsystem/property=snmp4j.agent.cfg.value.1.3.6
.1.6.3.16.1.4.1.0.1/:write-attribute(name=value,value={s}unrestrictedReadView)
Implementing SNMPv3 Security
The following properties control which security level and user the SNMPv3 messages use:
snmp4j.agent.cfg.value.1.3.6.1.6.3.12.1.3.1.2.2
snmp4j.agent.cfg.value.1.3.6.1.6.3.12.1.3.1.2.3
To set the user of the SNMPv3 messages, use:
.1.6.3.12.1.3.1.2.2/:write-attribute(name=value,value=<user>)
where <user> is one of SHADES, SHA, or unsec.
To set the security level, use:
.1.6.3.12.1.3.1.2.3/:write-attribute(name=value,value=<level>)
where <level> is one of:
Value Level Description
1 noAuthNoPriv Can be specified for any of SHADES, SHA, or unsec
2 authNoPriv Can be specified only for SHADES or SHA
3 authPriv Can be specified only for SHADES
After making changes to the SNMP subsystem properties, restart the SNMP service - see the
Configuring SNMP Trap Security section.
For every SNMP Agent that an NMS SNMP management client will be receiving traps from, the
management client will need to perform an SNMP GET on the
snmpFrameworkMib.snmpFrameworkMIBObjects.snmpEngine.snmpEngineID
(.1.3.6.1.6.3.10.2.1.1.0) for that SNMP Agent. This engineID will be used to set up the USM user
for the management client.
For every SNMP Agent, the management client will need a USM entry containing the following:
EngineID,USER[,SHA,auth passphrase][,DES, priv passphrase]
The details of this configuration will depend on the SNMP client being used. The following
configuration has been tested with net-snmp, using the snmptrapd tool (set up your own client
with the equivalent settings in the way that your client expects).
For snmptrapd, put these settings in the /usr/etc/snmp/snmptrapd.conf file:
authCommunity log,execute,net public

createUser -e <engineID> SHADES SHA <SHADESAuthPassword> DES
<SHADESPrivPassword>
createUser -e <engineID> SHA SHA <SHAAuthPassword>
createUser -e <engineID> unsec
authUser log,execute,net SHADES
authUser log,execute,net SHA
authUser log,execute,net unsec noauth
where <SHADESAuthPassword>, <SHAAuthPassword>, and <SHADESPrivPassword> should be
replaced by the real passwords set in the SNMP subsystem configuration, and <engineID> is
the value returned by the SNMP GET described above.
SNMP View Access Control
You can restrict access to SNMP managed objects for any SNMP protocol version. This is done
using the View Access Control Model (VACM).
The vacmSecurityToGroupTable (at property snmp4j.agent.cfg.oid.1.3.6.1.6.3.16.1.2.1) defines

the default SNMP Agent. It contains indexes at properties
snmp4j.agent.cfg.index.1.3.6.1.6.3.16.1.2.1.0, snmp4j.agent.cfg.index.1.3.6.1.6.3.16.1.2.1.1,and
so on. These indexes map a combination of security model and security name to a group (at the
properties snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.2.1.0.0,
snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.2.1.1.0, etc.). The group is used to define an access
control policy.
The index is made up of the integer representing the security model, the length of the string
representing the security name, and the security name itself, for example:
3.5.’unsec’
for a security model of 3 and the five character security name unsec.
The security model may be:
0 - Reserved for any
1 - SNMPv1
2 - SNMPv2
3 - User Based Security Model (USM) used by SNMPv3
The security name is the community string for SNMPv1 or SNMPv2, or the USM user name for
SNMPv3 (i.e. SHADES, SHA, or unsec - (see the SNMP Security Levels and Users section).
For instance, these entries map the SHADES user (using the USM security model) to the
v3group:
"snmp4j.agent.cfg.index.1.3.6.1.6.3.16.1.2.1.1" => {"value" =>

{o}3.6.'SHADES'"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.2.1.1.0" => {"value" => {s}v3group"}:
...
By default, the groups are:
v1v2cgroup
v3group
The default access rights for groups are defined by another table (at
snmp4j.agent.cfg.oid.1.3.6.1.6.3.16.1.4.1). The indexes into this table (at
snmp4j.agent.cfg.index.1.3.6.1.6.3.16.1.4.1.0, etc.) contain a group name, a context prefix, a
security model, and a security level. For example:
7.’v3group’.0.3.1
means a 7 character group name (which is v3group), a zero length context string (context strings
are not currently used, so all are 0), the security model is 3 (USM), and the security level is 1
(noAuthNoPriv).
In the default configuration the following index entries are defined:
10.’v1v2cgroup’.0.2.1 - SNMPv2, noAuthNoPriv (SNMPv2 ‘public’)
10.’v1v2cgroup’.0.1.1 - SNMPv1, noAuthNoPriv (SNMPv1 ‘public’)
7.’v3group’.0.3.3 - USM, authPriv (SNMPv3 ‘SHADES’)
7.’v3group’.0.3.2 - USM, authNoPriv (SNMPv3 ‘SHA’)
7.’v3group’.0.3.1 - USM, authPriv (SNMPv3 ‘unsec’)
Three of the values associated with each index contain the access levels for read, write, and
notify access for each group:
.1={s}unrestrictedReadView
.2={s}unrestrictedWriteView
.3={s}unrestrictedNotifyView
You can either set these entries to the value above, or leave them blank to prevent that particular
access to the managed object.
Thus the entries:

{o}7.'v3group'.0.3.3"}:
...
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.1.1" => {"value" =>
{s}unrestrictedReadView"}:
{s}unrestrictedWriteView"}:
{s}unrestrictedNotifyView"}:
...
define the v3group as having unrestricted access for read, write, and notify, while:

{o}10.'v1v2cgroup'.0.2.1"}:
...
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.1.1" => {"value" => {s}"}:
{s}unrestrictedWriteView"}:
...
defines the v1v2cgroup as having unrestricted write access, but no access for read or notify.
For each entry in the access table, set the appropriate read, write, and notify views. For
example, if you want to allow all groups to be able to raise notifications, but only v3group with
USM, authPrivsecurity, to allow reads and writes, the following configuration would achieve it:
"snmp4j.agent.cfg.oid.1.3.6.1.6.3.16.1.4.1" => {"value" => 6:6"}:

"snmp4j.agent.cfg.index.1.3.6.1.6.3.16.1.4.1.0={o}10.'v1v2cgroup'.0.2.1"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.0.0" => {"value" => {i}1"}:
{o}7.'v3group'.0.3.3"}:
{s}unrestrictedReadView"}:
{s}unrestrictedWri"teView"}:
{o}10.'v1v2cgroup'.0.1.1"}:
{o}7.'v3group'.0.3.2"}:
{o}7.'v3group'.0.3.1"}:
{o}7.'v3group'.0.4.1"}:
Configuring Logging
There are three main Log4J loggers configured for Fusion Application Server:
SIP call logger
HTTP logger (for LBs only)
Root logger
The SIP and HTTP loggers each have their own log category. If you need a different logging
level for those types of log, you should change the log level for the appropriate category. There
are a number of other categories that each have their own logging level, but these do not
normally need to be changed.
Increasing logging levels will affect performance; we recommend that you change the logging
level back to the default as soon as you have resolved your problem.
For any packages that do not have a specific logger category defined with a logging level, the
level set for the root logger is used.
By default, SIP and HTTP logging is size-based, which means that log files rotate when the log
file reaches a specified size (which is 100 MB by default). When the active log reaches the
maximum size, FAS backs it up with a suffix of .1 and creates a new log file. When the new log
file reaches the maximum size, the log with a suffix .1 changes to have a suffix of .2, and the
most recent log becomes the backup with a suffix of .1. The log files rotate in this way up to the
specified maximum backup index (which is 5 by default), after which FAS deletes older logs.
You can change the logging from rotating when the log file reaches a specified size to rotating
after a specified time period, for example each day (see the Changing to Periodic Logging
section).
Configuring SIP Call Logging
The SIP call logger writes log items to the calls.log file, which is in the <install
dir>/domain/servers/<server process name>/log directory, where <server process name>
is the name of the AS or LB server process.
SIP call logging is size-based; log files rotate when they reaches a specified size, which by
default is 100 MB; when the number of backup files reaches the maximum number (5 by default)
the oldest is deleted. You can edit these values as described in the To Configure the Log Files for
SIP Call Logging section.
With call logging enabled, the ASs produce a SIP message log entry for each SIP message
handled. The log entries include the following information:
Timestamp
Call-ID
Method or Condition Code
CSeq header
From header
To header
SIP call logging is set to INFO level by default. If you need to change this, do so at the category-
level using the sip.calls category. Call logging is extremely useful for tracing faults in a system,
and there is only a small negative impact from having it enabled. However, if required, call
logging can be turned off by changing the logging level (see the To Change the SIP Call Logging
Level section ).
To Configure the Log Files for SIP Call Logging

3. Select the profile from the top left menu (you can log SIP calls on either the lb or ha
profiles).
4. From the menu on the left, expand Core and select Logging.
5. Select the Handler navigation tab.
6. Select Size in the menu immediately below the tabs.
7. Select SIP_CALLS_FILE:
8. Click Edit.
9. To change the maximum size of the log files, edit the Rotate Size value.
10. To change the number of backup files that are stored, edit the Max Backup Index value.
11. Click Save.
Important: There is a logging level defined for the handler, but we recommend that this is not
changed here, but at the category level, as described in the To Change the SIP Call Logging
Level section.
To Change the SIP Call Logging Level

3. Select the profile from the top left menu (you can log SIP calls on either the lb or ha
profiles).
5. Select the Log Categories navigation tab.
6. Select the sip.calls category:
7. Click Edit.
8. From the Log Level drop down list, select the required logging level.
9. Click Save.
Configuring HTTP Logging
LBs have an additional log handler that logs HTTP and Web socket traffic passing through the
LB. The HTTP logger writes log items to the http.log file, which is in the <install
dir>/domain/servers/<lb name>/log directory, where <lb name> is the name of the LB server
process.
HTTP logging is size-based; log files rotate when the log file reaches a specified size, which is
100 MB by default; when the number of backup files reaches the maximum number (5 by
default) the oldest is deleted. You can edit these values (see the To Configure the Log Files for
SIP Call Logging section), selecting the HTTP_FILE handler entry from the lb profile.
HTTP logging is set to INFO level by default. If you need to change it, do so in the same way as
described in the To Change the SIP Call Logging Level section, selecting the
com.alicecallsbob.lb.http_logs category from the lb profile.
Configuring the Root Logging Level
If there is no specific log handler for a category, log messages are written to the server.log file at
<install dir>/domain/servers/<server process name>/log directory; there is one server.log
file for each server process.
If there is no category-level logging for a package, it logs messages at the level of the root
logger. To change this:
3. Select the profile you want to work with from the top left menu. There is an independent root
logger for each profile, including the management profile. To change the root logging level
for ASs, select the ha profile; to change the root logging level for LBs, select lb.
5. Select the Root Logger navigation tab:
6. Click Edit.
7. From the Log Level drop down, select the new logging level.
8. Click Save.
9. Restart the AS (see the Starting and Stopping Server Processes section) for the changes to
take effect.
Configuring a Logging Category
To define a specific level of logging for some messages, create a logging category for those
messages. For example, if you do not want a particular type of SIP message to be logged (ACK
messages, for instance), you can create a logging category for that message type
(sip.calls.ACK) and set the level lower than that of its parent category (sip.calls in this case). You
do not need to create a category for every message type; those without a specific category log
with the level of their parent category.
To Configure a Logging Category
3. Select the profile from the top left menu (e.g. lb or ha).
6. Click Add to show the Add Log Categories dialog:
7. Enter the name of the category.
For SIP call message types, the name of each category must start with sip.calls and
end with the message type in upper case letters. For instance, sip.calls.BYE creates a
category for BYE messages.
For informational messages from the FAS Java code, the name of the category should
be that of the Java package or class which is logging the message. There are some
existing categories defined in this way, but you should not need to create one unless
asked to do so by CBA Support.
8. Select the logging level from the Log Level drop down list, e.g. DEBUG.
9. Click Save.
Changing to Periodic Logging
By default, the log files rotate when they reach a specified size. You can change this to have
them rotate after a specified time period (for example each day).
After changing to periodic logging, you should restart the AS (see the Starting and Stopping
Server Processes section).
To Create a Periodic Log Handler

3. Select the profile from the top left menu.
5. Select the Handler navigation tab.
6. Select Periodic in the menu immediately below the tabs:
7. Click Add to bring up the Add Periodic Rotating File Handlers dialog:
8. Enter a name for the new logging handler (this can be anything, though it should be unique).
9. In the File Path, enter the name of the file to save the logs in.
10. In the Suffix field, enter a suffix for backed-up files. This should be a date-time format string
of the type used by the java.text.SimpleDateFormat class (see
http://docs.oracle.com/javase/7/docs/api/index.html?java/text/SimpleDateFormat.html for
details about this class). It should be suitable for the time period you want to use: for
example, to create daily logs, use the suffix yyyy-MM-dd.
11. Click Save.
12. Select the new file handler, and click Edit.
13. Select both the Append and Auto Flush checkboxes.
14. Click Save.
To Use the Periodic Logging Handler for Root Logging
1. Select the Root Logger navigation tab.
2. Select the Handlers tab in the Details section:
3. Click Add to bring up the Add Name dialog:
4. Select the periodic logging handler from the Name drop down list, and click Save.
The default size based logging handler will still be active. To remove it, select the FILE handler
and click Remove.
To Use the Periodic Logging Handler for SIP Call Loging

2. Select the sip.calls logger category.
3. Select the Handlers tab in the Details section:
4. Click Add to bring up the Add Name dialog:
5. Select the periodic logging handler and click Save.
The default size based logging handler will still be active. To remove it, select the
SIP_CALLS_FILE handler in the table, and click Remove.
SNMP Logging
The SNMP Agent in each Host Controller also produces its own log. When it receives an alarm
or event from a FAS server process or application, the SNMP Agent not only sends an SNMP
trap, but also writes it to the alert.log. The log file is in the <install dir>/domain/log directory.
As with the other Fusion Application Server logs, SNMP Agent logging is size-based.
SNMP Agent diagnostic logging is output to the <install dir>/domain/log/host-

controller.log .
Licensing Logging
The License Server which runs in the Management server process also produces its own log file.
Every 60 seconds, for each licensed product, it will log the product name, the name of the
licensed feature, the number of licenses used and available, and the peak number of used
licenses in the last 24 hours:
2016-11-23 10:08:27,576 : product=sa feature=users limit=8 used=0 peakUsed(24h)=0
By default, licensing log entries go to the <install

dir>/domain/servers/management/log/licensing.log file. If necessary, you can change this
by editing the LICENSING_FILE logger in the Management Console.
Logging for a Specific Period
To help you identify any issues you may experience, FAS provides a script to capture call logs
and statistics for a specific period. The logcapture.sh script is installed in the <install
dir>/bin directory, and can be used to capture the following information:
FASconfiguration
vmstat output
Java memory
Thread dumps
Network traffic (in a .pcap file)
The logging script runs until it is stopped, allowing you to reproduce any problem scenarios
during this time. When you stop the logging script, the information you require is captured in a
series of log files, which are archived into a .tar file:
./logcapture.sh –all –tar-file output.tar
You can define which information is captured by adding a selection of the following arguments
when you run the script:
Option Description
-f, ‑‑tar‑file The name of the output .tar file. This option is mandatory.
-c, ‑‑config Includes configuration files
-t, ‑‑threads Includes thread dumps (output of jstack)
-m, ‑‑memory Includes a heap memory dump (output of jmap) for all processes
-n,
Prevents the output directory from being cleaned up
‑‑do‑not‑clean
-p,
Captures network traffic in a .pcap file
‑‑capture‑pcap
-v, ‑‑vmstat Includes vmstat output
-a, ‑‑all Includes all the options
Forces memory and stack dumps even if a process is hung. Only

-F, ‑‑force
meaningful if -t, -m, or -a are also included.
-h, ‑‑help Displays online help
To Capture Logs for a Specific Period
1. Set the logging levels appropriately (see the Configuring the Root Logging Level section).
2. Run the command:
./logcapture.sh -a -f example.tar
The console will display the message:
\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
\* Capturing files to directory logcapture.remp-LGR \*
\* Press <CTL>-C when ready to tar up captured files \*
\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
Note: The final three characters of the directory name (LGR in the above example) will change
each time the script is run, as this is a temporary directory.
3. Reproduce any scenarios which were causing issues.
4. Press Ctrl-C to stop the logging script. The output files will be collected in example.tar,
which (for the -a option used above) has the structure:
./vmstat.out
./tcpdump.pcap
./FAS/
./FAS/log/
./FAS/log/alert.log
./FAS/log/process-controller.log
./FAS/log/host-controller.log
./FAS/configuration/
./FAS/configuration/host-master.xml
./FAS/configuration/mgmt-users.properties
./FAS/configuration/application-roles.properties
./FAS/configuration/fas.properties
./FAS/configuration/host.xml
./FAS/configuration/domain.xml
./FAS/configuration/host-slave.xml
./FAS/configuration/logging.properties
./FAS/configuration/application-users.properties
./FAS/servers/
./FAS/servers/loadbalancer-acb-fas-1/
./FAS/servers/loadbalancer-acb-fas-1/log/
./FAS/servers/loadbalancer-acb-fas-1/log/server.log
./FAS/servers/loadbalancer-acb-fas-1/log/boot.log
./FAS/servers/loadbalancer-acb-fas-1/log/http.log
./FAS/servers/loadbalancer-acb-fas-1/log/calls.log
./FAS/servers/loadbalancer-acb-fas-1/heap.bin
./FAS/servers/loadbalancer-acb-fas-1/thread.dump
./FAS/servers/management/
./FAS/servers/management/log/
./FAS/servers/management/log/server.log
./FAS/servers/management/log/boot.log
./FAS/servers/management/heap.bin
./FAS/servers/management/thread.dump
./FAS/servers/appserver-acb-fas-2/
./FAS/servers/appserver-acb-fas-2/log/
./FAS/servers/appserver-acb-fas-2/log/server.log
./FAS/servers/appserver-acb-fas-2/log/boot.log
./FAS/servers/appserver-acb-fas-2/log/calls.log
./FAS/servers/appserver-acb-fas-2/heap.bin
./FAS/servers/appserver-acb-fas-2/thread.dump
./FAS/servers/appserver-acb-fas-1/
./FAS/servers/appserver-acb-fas-1/log/
./FAS/servers/appserver-acb-fas-1/log/server.log
./FAS/servers/appserver-acb-fas-1/log/boot.log
./FAS/servers/appserver-acb-fas-1/log/calls.log
./FAS/servers/appserver-acb-fas-1/heap.bin
./FAS/servers/appserver-acb-fas-1/thread.dump
Creating a Log Archive
If at any point you want to examine the call logs in detail (for example if there is a specific issue
that you want to investigate, or want CBA Support to investigate), you can create a log archive
by running the log-archiver.sh script, which you can find in the <install dir>/bin directory.
The script takes no arguments:
./log-archiver.sh
and puts the following files in an archive called fas-logs.zip:
messages.xml
Contains a collection of all of the message.log files found in the AS’s log directory.
processingDecisions.log
Contains entries from the AS’s server.log file that contain a message ID and with a logging level
of INFO or higher.
server.log files for all the server processes (AS, LB, and Management Server) on the node.
call.log files for the AS and LB server processes running on the host that the file was created
on.
The archive contains most of the logs useful for troubleshooting, and it is more convenient to
download the archive than all the individual log files.
Note: In a multi-box setup, to collect the logs for the whole FAS cluster, run the log-archiver script
on each host in the cluster.
Configuring Security
Access to the Management Console and the CLI is controlled using a common infrastructure. By
default, local access (that is, from the node itself) is not restricted, but remote access is restricted
by credentials (the administrator username and password) specified during installation. By
default, the same credentials are used by slave FAS nodes to communicate with the master
node.
This section does not describe Trust Management. For details of Trust Management
configuration, see the Configuring Trust Management section.
Controlling Access to the Management Interfaces
Remote access to the Management Console and the CLI is restricted by the credentials stored in
the <install dir>/domain/configuration/mgmt-users.properties file. This file consists of
one or more lines with the following format:
<user name>=<password hash>
When installing FAS, you are asked for an administrator username and password, and the
installer adds these credentials to this file. If you want to add any further users, you must add
them manually using the add-user.sh script.
In addition to accessing the CLI and Management Console, by default the same credentials are
used by slave nodes to communicate with the master node. This is all configured automatically
on installation.
Changing the Local User Credentials

The procedure described below should only be used when FCSDK (or any product which
includes and uses FCSDK) is not installed. If it is installed, FAS and FCSDK share the account,
and you should only change the credentials using the FCSDK web UI (see the FCSDK
Administration Guide for details). Also note that if FCSDK has configured LDAP as its security
mechanism, then users can also log into the FAS administration interfaces using LDAP-provided
credentials; the page on the FCSDK web GUI for changing credentials and login mechanisms
applies to both FAS and FCSDK.
To change the local user credentials, use the <install dir>/bin/change-local-admin.sh
script. This script gives you with the option to change the username and password of the
administrator; there can only be one administrator:
./change-local-admin.sh
\------------------------------------------------------------------------------
-
This utility will allow you to change the local admin username and/or password.
\------------------------------------------------------------------------------
-
First please authenticate using the current local username and password.
Username: **admin**
Password:
Authentication successful.
The current admin username is 'admin'.

Would you like to change this username? yes/no **yes**
New username: **administrator**

Re-enter new username: **administrator**
Username updated to 'administrator'
Would you like to change the password for 'administrator'? yes/no **yes**
New password:
Re-enter new password:
Password updated
Things which you must type are shown in this font; display from the script is shown like this. You
also need to type the password at the prompt - the script does not echo the password to the
screen.
Adding a New User
There is an add-user.sh script provided in the <install dir>/bin directory which adds users to
either the mgmt-users.properties or the application-users.properties file. The application-
users.properties file contains users in the ApplicationRealm realm, which is available for use by
applications (see the Files in the domain/configuration Directory section), but is otherwise not
used. Normally, you will want to create users in mgmt-users.properties.
1. Log onto the FAS master node and run:
<install dir>/bin/add-user.sh
2. The display will show:
What type of user do you wish to add?

a) Management User (mgmt-sers.properties)
b) Application User (application-users.properties)
(a):
Unless you have an application which uses the application realm, you can accept the default (a)
by pressing Enter .
Enter the details of the new user to add.

Realm (ManagementRealm) :
Management users will normally be in the ManagementRealm realm, so again you can accept
the default by pressing Enter .
Username :
Enter the user name, such as user1, and press Enter
Password:
Enter the password to use for the user, and press Enter
Re-enter Password
Enter the password again, and press Enter .
About to add user 'user1' for realm 'ManagementRealm'
Is this correct yes/no?
If the information is correct, type yes to add the user.
Added user 'test' to file 'mgmt-users.properties'
Is this new user going to be used for one AS process to connect to another AS
process e.g. slave domain controller?
If this user is to be used solely for access to the Management Console and CLI, enter no
If you are creating this user on the master node to be used by slave nodes to communicate
with the master node, type yes
9. If you typed yes above, the display will show:
To represent the user add the following to the server-identities definition <secret
value="jeGioqQA91p7SQBLdwW6SrhSeM="/>
Press any key to continue…
The secret value is a Base64 encoded password hash. Make a copy of it - you will need it when
you alter the credentials on the slave nodes.
Changing the Credentials used between Master and Slave

You can provide the same set of credentials for all slave nodes (that is, all slaves use the same
user name), or use different credentials for each one (each slave has its own user name); the
decision will be based on the security needs of each deployment.
To use new credentials on a slave FAS node, you must first run the procedure in the Adding a
New User section on the master node, making a note of the secret value; then edit two files on
the slave node, host.xml and fas.properties:
host.xml
1. Open the <install dir>/domain/configuration/host.xml file in an editor.
2. Find the part of the contents which look like:
<security-realm name="ManagementRealm">
<server-identities>
<secret value="YWRtaW5pc3RyYXRvcg=="/>
</server-identities>
<authentication>
<local default-user="$local" />
<properties path="mgmt-users.properties" relative-
to="jboss.domain.config.dir"/>
</authentication>
</security-realm>
3. Replace the existing value property of the <secret> element with the one you noted when
you added the user.
4. Save the file.
fas.properties
1. Open the <install dir>/domain/configuration/fas.properties file in an editor.
2. Change the value of the domain.controller.user property to be the username of the user you
created on the master node for this slave:
domain.controller.user=user1
3. Save the file.
4. Restart the slave node to use the new credentials.
Resetting Administrator Credentials
If you have FCSDK installed, or something which uses FCSDK, you should follow the procedure
for resetting the Administrator credentials in the FCSDK Administration Guide. Administrator
credentials are shared between FAS and FCSDK, and only the FCSDK procedure will reset them
correctly.
If you have forgotten the administrator credentials, you can reset them to the defaults by setting
a system property, which will reset the credentials on the next login attempt:
1. Add the system property appserver.admin.password.reset=true in the <install

dir>/domain/configuration/fas.properties file.
2. Restart the FAS master node
3. Start the CLI (see the Starting the CLI section) or navigate to the Management Console (see
the Starting the Management Console section), and attempt to log in .
Note: The login will fail; this is expected behavior.
4. Remove the system property appserver.admin.password.reset from the <install

dir>/domain/configuration/fas.properties file.
5. Restart the FAS master node.
Login is now re-enabled, and the credentials have been reset to their default values.
Configuring TLS Cipher Suites
On installation, a default list of enabled cipher suites is configured for both HTTPS and SIPS
traffic.
For HTTPS traffic on ASs and the Management Server, the list of enabled cipher suites is
specified in the fas.properties file, in a property called openssl.cipher.suites, which has a default
value of:
ALL:!SSLv2:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM
For SIPS traffic on ASs, and both SIPS and HTTPS traffic on LBs, the list of enabled cipher
suites is specified in the fas.properties file in a property called jsse.cipher.suites, which has a
default value of:
SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_3DES_E
DE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_
EDE_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_12
8_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA
You can configure these global values (for example, if you want to remove one of the cipher
suites for all server processes), by editing the values in the fas.properties file.
If you want to configure the list of enabled cipher suites for individual server processes (for
example, to enable different cipher suites for each server process type), you can do so using the
CLI (see the Command Line Interface (CLI) section). For the CLI commands needed to make
these changes, see the HTTPS section and the SIPS section.
HTTPS
For ASs and the Management Server, the list of supported HTTPS cipher suites is specified by
the cipher-suite attribute of the HTTP connector’s <ssl> element, in the web subsystem. By
default, this is set to the variable openssl.cipher.suites.
Note: JBoss ‘native’ connectors are used; the format of the list of supported cipher suites must
conform to the OpenSSL Cipher List Format. See
http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT.
To specify the HTTPS cipher suites for ASs, use a command like the following, which replaces
the variable with the required list of cipher suites:
/profile=ha/subsystem=web/connector=https/ssl=configuration/:write-
attribute(name=cipher-
suite,value=ALL:\!aNULL:\!ADH:\!eNULL:\!LOW:\!EXP:RC4+RSA:+HIGH:+MEDIUM)
To change the HTTPS cipher suites for the Management Server, use a command like the
following:
/profile=management/subsystem=web/connector=https/ssl=configuration/:write-
attribute(name=cipher-
suite,value=ALL:\!aNULL:\!ADH:\!eNULL:\!LOW:\!EXP:RC4+RSA:+HIGH:+MEDIUM)
For LBs, the list of supported HTTPS cipher suites is specified in a property called
com.alicecallsbob.loadbalancer.http.ssl.cipherSuites. By default this is set to the variable
jsse.cipher.suites.
To specify the supported HTTPS cipher suites for LBs, use a command like the following:
/profile=lb/subsystem=lb/property=com.alicecallsbob.loadbalancer.http.ssl.cipherSui
tes/:write-
attribute(value=TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA,SSL\_RSA\_WITH\_3DES\_EDE\_CBC\_S
HA,TLS\_DH\_anon\_WITH\_AES\_128\_CBC\_SHA,SSL\_DH\_anon\_WITH\_3DES\_EDE\_CBC\_SHA
)
SIPS
For SIPS, the list of supported cipher suites is specified by a property called
gov.nist.javax.net.ssl.cipherSuites for both ASs (in the ha profile) and LBs (in the lb profile). By
default this is set to the variable jsse.cipher.suites.
To specify a list of supported SIPS cipher suites for ASs, use a command like the following,
which replaces the variable with the required list of cipher suites:
/profile=ha/subsystem=sip/property=gov.nist.javax.net.ssl.cipherSuites/:write-
)
To specify the list of supported SIPS cipher suites for LBs, use a command like the following:
/profile=lb/subsystem=lb/property=gov.nist.javax.net.ssl.cipherSuites/:write-
)
Enabling and Disabling TLS v.1 and 1.1
Older versions of Transport Layer Security, as well as versions of its predecessor, SSL, have
been found to be insecure. FAS provides scripts to enable and disable them in HTTPS traffic to
and from the FAS.
To disable TLS v.1 and 1.1 (as well as SSL):
<install dir>/resources/disable-tlsv1.x.sh <admin\_user> <admin\_password>
To enable them:
<install dir>/resources/enable-tlsv1.x.sh <admin\_user> <admin\_password>
where <admin\_user> is the admin user (see the Controlling Access to the Management
Interfaces section), and <admin\_password> is the password for that user.
Note:
You must run these scripts on each node in the cluster.
You will need to restart FAS on each node after running the script, for the changes to take
effect.
Configuring Trust Management
By default, Fusion Application Server is configured to use Transport Layer Security (TLS).
Using TLS enables servers to verify the identities of both the server and client through exchange
and validation of their digital certificates, as well as encrypt information exchanged between
secure servers using public key cryptography, ensuring secure, confidential communication
between two entities.
Data is secured using key pairs containing a public key and a private key. The owner encrypts
the sent data using the recipient’s public key, which can then be decrypted only with the private
key in the pair. Encryption alone provides no proof of the identity of the sender of the encrypted
information, however. Certificates address this problem by also providing a digital signature, an
electronic means of verifying a resource’s identity.
To prove its identity, a resource requests a certificate from a Certification Authority (CA). The
issued certificate is then signed with the CA’s private key, and should be added to the resource’s
identity certificate store. A certificate typically contains the following information:
Owner’s public key
Owner’s name
Expiration date of the public key
Name of the issuer (the CA that issued the certificate)
Serial number of the certificate
Digital signature of the issuer
This certificate can then be sent to other resources to establish trust with that resource. The
receiving resource should add the CA certificate to their trust certificate store. For two-way
trusted communication, certificates should be exchanged between resources.
If both entities trust the same CA, this allows them to establish a bond of identity and trust
between them.
Using Certificates with FAS
The components within a FAS cluster should implicitly trust each other, so you should provision
all nodes within a FAS cluster with certificates signed by the same trusted CA.
The installation process provisions the servers with temporary certificates which have a CN
(Common Name) reflecting the cluster address that you specified when installing each
component; this defaults to the host’s IP address for a single box installation, but you could have
specified an FQDN. The temporary certificates all have a common signer, so each of the nodes
within the cluster can communicate over TLS with the others.
After installation, you should replace the temporary certificates with certificates that have been
signed by a third-party Certification Authority (CA) or by a SCEP server. The CN in the updated
certificates should reflect the fully-qualified DNS name of cluster. If all of the cluster components
share the same CN, it will only need one signed certificate.
As external data is sent to and from the Load Balancer nodes, the LBs need to know which
external hosts are trusted. To trust an external host, the certificate of the CA that signed the
external host’s certificate must be added to the LB’s trust certificate store, and the external host
will need to add the certificate of the CA that signed the LB’s certificate to its trust certificate
store. Any communications with that host can then be trusted.
Where your deployment has no Load Balancer node, external data is sent to your Application
Server nodes. In this case, your Application Server nodes also need a trust certificate store.
Managing Certificates
Certificates can be managed using the Management Console, and you can manage the
certificates for multiple Certificate Groups. The Management Console enables you to perform
the following functions:
view identity certificates
create and sign new identity certificates using SCEP
create certificate signing requests (CSRs) for third-party CAs
replace existing identity certificates (for example, when they are about to expire, or the CN
value has changed)
replace expired identity certificates
view trust certificates
import trust certificates
To work with certificates, you must know the security password; the default password is changeit,
but the installer can set this to a different value.
Note: Certificates are initially created on the node hosting the Domain Host Controller, and are
then automatically copied to all the nodes in the cluster.
Identity and Trust Certificate Groups
An identity certificate is a certificate that can be used to identify a host. The CN of these
certificates will usually contain either:
A fully-qualified name which can be resolved in DNS. This name may resolve to one or more
machines.
The IP address of the machine.
Identity certificates are managed in identity certificate groups. The installer creates the
following identity certificate groups:
mgmt-server-group - for the node which runs the Domain Host Controller, the Management
Console, and the License Server.
main-server-group - for the Application Server nodes.
main-loadbalancer-group - for the Load Balancer nodes.
The main-server-group and main-loadbalancer-group require a certificate for each transport type
(SIPS and HTTPS) in the group, as shown in the image above. As the Domain Host Controller is
only a management interface, the mgmt-server-group only needs an HTTPS certificate.
Trust certificates are managed in trust certificate groups. By default, there is a single trust
certificate group, which can be used throughout the cluster.
When the Management Console creates certificates, it saves them in identity certificate group
and trust certificate group directories on the node hosting the Domain Host Controller; they are
automatically copied to each FAS node in the cluster, and to any new nodes added to the cluster.
Configuring with Certificates signed by a CA

If you want to generate a new identity certificate to be signed by a third-party CA, you must
generate a Certificate Signing Request (CSR) (see the Generating a Certificate Signing
Request section), send the generated CSR to the third-party CA (see the Sending a CSR to an
External CA for Signing section), and then import the signed certificate (received from the CA)
into the identity certificate group (see the Importing a Signed Certificate section).
Normally you will choose an existing certificate to be signed by the CA, but sometimes you may
need to generate a new certificate; see the Generating a New Identity Certificate section.
Note: Certificates can also be signed by a SCEP server. See the Configuring with Certificates
signed by a SCEP Server section.
Generating a Certificate Signing Request
4. In the menu on the left, expand Subsystems and Trust Management, and select ID
Certificates.
5. In the Identity Certificate Group section, select the identity certificate group that contains the
certificate that you want to be signed:
6. In the Identity Certificate Group Management section, select the certificate that you want
signed, and click Generate CSR.
7. Enter the password and click Next to show the Generate CSR dialog:
8. Enter the security password in the Challenge Password field.
9. Change the Subject DN as required.
In most cases, the DN for the existing certificate will be what you want, but if you need to change
it, the CN value in the DN should reflect that of the SIP domain; for example CN=192.168.1.234,
or CN=example.net. If you wish to add an organizationName attribute, you can enter the DN as
e.g. O=acme.com,CN=example.net.
10. Add entries to the Subject Alternative Name field.
In most cases the Subject Alternative Names for the existing certificate will be what you want, but
if you want to add entries, you can add records for each IP address (e.g. IP:172.16.1.8) or host
name (e.g. DNS:foo.bar.com) which will be used to access the machine.
11. Click Generate. A dialog showing the generated CSR will be displayed:
12. Select the generated text, including the starting and ending tags (—–
BEGIN_CERTIFICATE_REQUEST—– and —–END_CERTIFICATE_REQUEST—–), copy
it, and paste it into a text editor and save the file.
13. Click Close.
Sending a CSR to an External CA for Signing
The procedure for getting your certificate signed by a third-party CA depends upon the
requirements of that CA. See the guidance from the CA.
Importing a Signed Certificate
When you receive the signed certificate back from your CA, you must import it into the correct
identity certificate group:
Certificates.
certificate that has been signed:
6. Select the certificate which has been signed by the CA. This must be the same one that you
selected when you generated the CSR.
7. Click Import to bring up the Import Certificate dialog:
8. Enter the security password in the Password field.
9. Open the certificate you have received from the CA in a text editor, select all the contents,
including the start and end tags, copy them, and paste them into the Encoded Certificate
field.
10. Click Import.
Once the certificate is imported, the window will update to display any changed certificate details,
such as the issuer DN and the expiry date.
11. Restart each node in the cluster for the changes to take effect.
Configuring with Certificates signed by a SCEP Server

If you want to generate a new certificate that is signed using the SCEP protocol, there is a single
UI operation, which performs the CSR generation, sending, receiving, and importing steps
automatically; see the Generating a SCEP-Signed Certificate section.
Before you can perform this procedure, you must configure FAS with the details of a server that
implements the SCEP protocol, such as an EJBCA server; see the Configuring FAS to use the
SCEP protocol section.
Normally you will choose an existing certificate to be signed by the SCEP server, but sometimes
you may need to generate a new certificate; see the Generating a New Identity Certificate
section.
Configuring FAS to use the SCEP protocol
4. In the menu on the left, expand Subsystems and Trust Management, and select SCEP
Configuration:
5. Click Add to bring up the New SCEP Configuration dialog:
6. Enter the values:
Field Description
Name A name for this SCEP configuration
The SCEP server CGI URL. A typical value for an EJBCA server might
be:
Url
http://ejbca.example.com:8080/scepraserver/scep/pkiclient.exe
Profile The value of the SCEP profile, or identity, that you want to use
The string that will be prefixed to the CN= value when constructing the
Subject Distinguished Name in the X509 certificate. For example, if this
Subject DN Prefix field is set to C=GB,O=Cafex,OU=Test, then the resulting DN might be:
C=GB,O=Cafex,OU=Test,CN=example.com
7. Click Save.
Generating a SCEP-Signed Certificate
Certificates.
certificate that you want to be signed:
6. In the Identity Certificate Group Management section, select the certificate that you want
signed, and click SCEP Sign.
This will generate the CSR, send it to the SCEP server (which will sign and return it), and import
the returned certificate into the identity certificate group directory automatically.
Configuring LBs with Trust Certificates
External traffic typically flows into FAS through the LBs. To allow TLS connections to the LBs
from external entities that use identity certificates signed by a CA that is not currently recognized,
a certificate from the unknown CA must be added to the trust certificate group.
Importing a Trust Certificate
4. In the menu on the left, expand Subsystems and Trust Management, and select Trust
Certificates:
5. In the Trust Certificate Group section, select the trust certificate group that you want to
import the trust certificate into.
6. Click Import to bring up the Import Certificate dialog:
7. Enter a meaningful name into the Name field.
The name should preferably indicate the CA whose certificate is being imported.
8. Enter the security password in the Password field.
9. Open the certificate from the unknown CA in a text editor, select all the contents, including
the start and end tags, copy them, and paste them into the Encoded Certificate field.
10. Click Import.
Configuring the DHC with an Identity Certificate

The Domain Host Controller and License Server, which are installed on the same host, must also
have an identity certificate containing the CN of that host. The installation process provisions this
host with a default, self-signed, identity certificate, in the management-group identity certificate
group. You should replace this certificate with an alternative certificate signed by a third-party
Certification Authority (CA) or a SCEP server.
Follow the instructions in either the Configuring with Certificates signed by a CA section or the
Configuring with Certificates signed by a SCEP Server section, choosing the mgmt-server-group
Identity Certificate Group, and the https Identity Certificate (by default, this is the only identity
certificate in this group).
Replacing an Identity Certificate

You would typically need to replace an identity certificate when it has expired.
To replace a certificate, follow the instructions in either the Configuring with Certificates signed
by a CA section or the Configuring with Certificates signed by a SCEP Server section, choosing
the certificate you want to replace. These instructions will obtain a new certificate (signed by
either a CA or the SCEP server), and replace the existing one with it.
Exporting an Identity Certificate

You can create a backup copy of a certificate by exporting it.
Certificates.
certificate to be exported:
6. Select the identity certificate you want to export.
7. Click Export. The Management Console will ask for the certificate password.
8. Enter the certificate password and click Export:
9. Copy the text, paste it into a text editor, and save the file.
10. Click Close.
Removing a Trust Certificate
You would typically remove a trust certificate to prevent TLS connections from machines that use
identity certificates signed by a specific CA that you no longer trust.
4. In the menu on the left, expand Subsystems and Trust Management, and select Trust
Certificates:
5. In the Trust Certificate Group section, select the trust certificate group that contains the trust
certificate you want to remove.
6. In the Trust Certificate Management section, select the Trust Certificate you want to remove.
7. Click Remove:
8. Click Confirm.
9. Restart each host in the cluster for the changes to take effect.
Generating a New Identity Certificate
Certificates.
5. In the Identity Certificate Group section, select the identity certificate group that you want to
add a certificate to:
6. In the Identity Certificate Group Management section, click Generate Keypair to show the
Generate Keypair dialog:
7. Enter a value for the Name, preferably indicating the component and transport type which
the new certificate is to be used for. For example, a certificate for SIP traffic on LBs could be
named sip-lb.
8. Enter the Subject DN value (please see page 6 of

<https://www.ietf.org/rfc/rfc4514.txt> for attribute types). The CN value in the DN
should reflect that of the SIP domain; for example CN=192.168.1.234, or CN=example.net.
(If the LBs are in a different domain to the ASs, use the domain applicable to the component
type that the new certificate is for.)
If you wished to add an organizationName attribute, you can enter the DN as e.g.
O=acme.com,CN=example.net.
9. Enter an Expiry Date, using either the date picker or by entering it manually in the form
yyyy-mm-dd.
10. Enter the security Password.
11. Enter Subject Alternative Name records for each IP address (e.g. IP:172.16.1.8) or host
name (e.g. DNS:foo.bar.com) which will be used to access the machine.
The cluster IP address will be added by default, and in many cases you will need no other
entries. You can add other entries (not shown in the screenshot) by scrolling down, but in most
cases you can leave these at their default values.
12. Click Generate.
The Management Console will add a new entry with the specified name to the list of certificates.
Configuring SIP
The Fusion Application Server contains a SIP subsystem, which you can configure.
The attributes described in this section have not all been validated with FAS; it is therefore
recommended that you consult CBA Support before making any changes to them.
Configuring the SIP Servlet Subsystem
The SIP Servlet subsystem exposes many different attributes for configuration. All of the
attributes have default settings, so configuration of them is optional. These attributes can be
configured using the Management Console or the CLI.
Configuring the SIP Servlet Subsystem using the Management Console
4. From the menu on the left, expand Sip and select Sip Servlet.
The basic SIP Servlet attributes are displayed at the top of the main content pane. These are the
attributes that you are most likely to need to change; for example External Address Mode, as
discussed in the Changing the External Address Modes section, and Cluster Address, as
discussed in the Changing Addresses section.
6. To view other attributes, which are less likely to require a configuration change, click on the
expand icon ( ) by the Advanced heading.
Note: To see a description of all the attributes, click the Need Help? link on the right.
7. To edit an attribute, click Edit.
Note: If the advanced attributes were displayed when you clicked Edit, all of the attributes are
available to edit. If they were not displayed, only the basic attributes are available to edit.
8. Edit the attribute values as required and click Save.
The pane reverts back to view mode, displaying the updated values.
9. Restart the ASs to pick up the new configuration.
Configuring the SIP Servlet Subsystem using the CLI

2. To return a list of the SIP subsystem attributes that can be configured, use:
/profile=ha/subsystem=sip/:read-resource
The list includes all of the SIP attributes, including the SIP connectors, which are described in the
Configuring SIP Connectors section, and the SIP stack properties, which are described in the
Configuring the SIP Stack section.
3. Edit an attribute with:
/profile=ha/subsystem=sip/:write-attribute(name=<attribute name>, value=<attribute

value>)
where <attribute name > is the name of the attribute, and <attribute value> is the new
value.
4. Restart the AS nodes to pick up the new configuration.
Configuring SIP Connectors
You can also configure the SIP connectors (for example, to allow the static address of LBs to be
set, or if you change external ports or IP addresses). All of the attributes have default settings, so
configuration of them is optional.
Configuring SIP Connectors using the Management Console

5. Select the Connectors navigation tab:
6. In the Available Sip Connectors section, select the connector that you want to edit.
The attributes of the connector will show in the Selection section. To see a description of the
attributes, click the Need Help? link on the right.
7. Click Edit.
8. Edit the attribute values, and click Save.
You will see the updated values in the Available Sip Connectors section.
9. Restart the AS to pick up the new configuration.
Configuring the SIP Connectors using the CLI

2. To list the current value for a connector, use:
/profile=ha/subsystem=sip/connector=<connector>:read-resource()
where <connector> is the SIP connector name ( sip-udp, sip-tcp, sip-tls, or sip-ws).
3. Edit a value with:
/profile=ha/subsystem=sip/connector=<connector name>:write-attribute(name=
<attribute name>, value=<attribute value>)
where <connector> is the SIP connector name, <attribute name> is the name of the
attribute, and <attribute value> is the new value.
4. The changes will be pushed to each host in the cluster. Restart all the hosts to pick up the
new configuration.
Configuring the SIP Stack
FAS uses the NIST SIP stack (that is, the reference implementation of the JAIN SIP API). The
NIST SIP stack has a number of optional configuration properties (the names of which begin with
gov.nist.javax.sip), which can be configured using the Management Console or the CLI. Using
the Management Console, you can also remove an existing property or add a new one.
The following table lists some of the properties that could be edited to tune your FAS cluster. The
default values listed below reflect the values in a FAS installation, so some might differ from the
default values of the native NIST stack; not all are set, so if you wish to set them, they may need
to be added. For a full description of options, refer to the NIST SIP stack documentation.
Option Default Description
gov.nist.javax.sip.LOG_
Set to false if you do not want to
true
MESSAGE_CONTENT capture message content in the log.
gov.nist.javax.sip. false Set to true to enable merged requests

loop detection:
AUTOMATIC_DIALOG_
● If the request has no tag in the To
ERROR_HANDLING
header field, the UAS core must check
the request against ongoing
transactions.
● If the From tag, Call-ID, and CSeq

exactly match those associated with an
ongoing transaction, but the request
does not match that transaction, the
UAS core generates a 482 (Loop
Detected) response and passes it to the
server transaction.
Maximum size of content that a UDP

gov.nist.javax.sip. connection can read. This is to prevent
10000 DoS attacks launched by writing to a
MAX_MESSAGE_SIZE
UDP connection until the server can’t
handle any more data.
gov.nist.javax.sip. Maximum size of content that a TCP

connection can read. This is to prevent
MAX_TCP_
2000000 DoS attacks launched by writing to a
TCP connection until the server can’t
MESSAGE_SIZE
handle any more data.
gov.nist.javax.sip. This value defines the size in bytes that

the AS uses as the MTU (UDP
MTU_SIZE Maximum Transmission Unit). The AS
follows the rules outlined in RFC 3261
regarding using the MTU to determine
whether a UDP request could become
fragmented, and whether to avoid this
by upgrading the protocol used from
UDP to TCP. If it upgrades the
message, but cannot set up the new
TCP channel (for example if the next
hop doesn't support TCP), the AS falls
back to using UDP; however,
fragmentation (particularly over WANs)
might cause problems (for example, if
parts of a message are dropped, or
delivered in the wrong order). If this
property is not set, it will default to
1500, which means that messages
larger than 1300 bytes (that is, 1500 –
200 buffer) will be upgraded.
Set this value to a value larger than the

value of gov.nist.javax.sip.MAX_
MESSAGE_SIZE to disable upgrade;
the AS will then drop, rather than
upgrade, a UDP message greater than
the MAX_MESSAGE_SIZE.
Set to false to close the server socket

after a server transaction goes to the
TERMINATED state. This allows a
gov.nist.javax.sip. server to protect against TCP-based
DoS attacks launched by clients.
CACHE_SERVER_
true
When set to true, the stack will keep the
CONNECTIONS socket open to maximize performance,
at the expense of thread and memory
resources, but leaving itself open to
DoS attacks.
Set to false to close the server socket

after a client transaction goes to the
gov.nist.javax.sip.
TERMINATED state. This allows a
CACHE_CLIENT_ client to release any buffers, threads,
true
and socket connections associated with
CONNECTIONS a client transaction after the transaction
has terminated, at the expense of
performance.
Concurrency control for the number of

simultaneous active threads. If not
specified, each event delivered to the
listener is run in the context of a new
gov.nist.javax.sip.
thread.
CACHE_CLIENT_
64 If specified, the stack will run the
listener using a thread from the thread
CONNECTIONS
pool. This allows you to manage the
level of concurrency to a fixed
maximum. Threads are pre-allocated
when the stack is instantiated.
gov.nist.javax.sip.MAX_
Maximum number of simultaneous TCP
CONNECTIONS connections handled by the stack.
Maximum size of the server transaction
SERVER_ table. Requests are selectively dropped
5000
if the table size goes over 80% of this
TRANSACTIONS size.
Maximum number of active client
CLIENT_ transactions before the caller blocks
unlimited
and waits for the number to drop below
TRANSACTIONS a threshold.
gov.nist.javax.sip.MAX_ Maximum time in seconds before

sending a response to a server
LISTENER_RESPONSE_
120 transaction. If a response is not sent
within this time period, the stack will
TIME
delete the transaction.
A typical value is dependent on early

dialog timeout; for example, 180
seconds could be a good default
maximum time that an INVITE
transaction is supposed to live in the
gov.nist.javax.sip.MAX_ stack. This is to avoid any leaks in
whatever state the transaction can be
-1 (infinite)
TX_LIFETIME_INVITE in, even if the application misbehaves.
When the maximum time is reached, a
timeout event is sent to the application
listener, so that the application can take
action, and the transaction is removed
from the stack after a typical lingering
period of 8s.
gov.nist.javax.sip.MAX_ -1 (infinite) A typical value is dependent on T1; for

example, 2 * T1 could be a good default
TX_LIFETIME_ maximum time (in seconds) that a non-
NON_INVITE INVITE transaction is supposed to live
in the stack. This is to avoid any leaks
in whatever state the transaction can be
in, even if the application misbehaves.
When the maximum time is reached, a
timeout event is sent to the application
listener, so that the application can take
action, and the transaction is removed
from the stack after a typical lingering
period of 8s. There is a specific property
for non-INVITE transactions because a
non-INVITE transaction is short-lived as
compared to INVITE, and so can be
collected more eagerly to save on
memory usage.
This option is relevant for incoming

TCP connections to prevent starvation
at the server. This defines the timeout in
milliseconds between successive reads
gov.nist.javax.sip. after the first byte of a SIP message is
read by the stack. All the SIP headers
-1 (off)
READ_TIMEOUT must be delivered in this interval, and
each successive buffer must be of the
content delivered in this interval. By
default, the stack is open to starvation
attacks and the client can be as slow as
it wants to be.
gov.nist.javax.sip. false This flag is added in support of Load

Balancers or failover managers, where
CANCEL_CLIENT_ you might want to cancel ongoing
transactions from a different stack than
TRANSACTION_
the original stack. When set to false, the
CHECKED CANCEL client transaction is not
checked for the existence or state of the
INVITE when you send the CANCEL
request, allowing you to CANCEL an
INVITE from a different stack. You can
also create a CANCEL client
transaction late and send it out after the
INVITE server transaction has been
terminated. This will, however, result in
protocol errors.
Setting the flag to true enables you to

avoid common protocol errors.
This property controls the size of the

gov.nist.javax.sip. UDP buffer used for receiving SIP
messages. If the buffer capacity
RECEIVE_UDP_
65536 overflows under load, the messages are
dropped, causing retransmissions,
BUFFER_SIZE
further increasing the load, and causing
even more retransmissions.
This property controls the size of the

UDP buffer used for sending SIP
gov.nist.javax.sip.SEND_ messages. If the buffer capacity
65536 overflows under load, the messages are
UDP_BUFFER_SIZE
dropped, causing retransmissions,
further increasing the load, and causing
even more retransmissions.
gov.nist.javax.sip.
How much time in milliseconds
CONGESTION_ messages are allowed to wait in the
8000
queue before being dropped due to the
CONTROL_TIMEOUT stack being too slow to respond.
gov.nist.javax.sip.TCP_ When using TCP, your phones or clients

usually connect independently, creating
POST_PARSING_ their own TCP sockets. Sometimes,
however, SIP devices are allowed to
THREAD_POOL_SIZE
tunnel multiple calls over a single
socket. In the stack, each TCP socket
has its own thread. When all calls are
using the same socket, they all use a
single thread, which leads to severe
performance penalty. This option
instructs the SIP stack to use a thread
pool and split the CPU load between
the number of threads specified. The
processing is split immediately after the
parsing of the message. It cannot be
split before the parsing because in TCP
the SIP message size is in the Content-
Length header of the message, and the
access to the TCP network stream has
to be synchronized. Additionally, in TCP
the message size can be larger. This
causes most of the parsing for all calls
to occur in a single thread, which might
have an impact on the performance in
trivial applications using a single socket
for all calls. In most applications, it
doesn't have any performance impact. If
the phones or clients use separate TCP
sockets for each call, this option doesn't
have much impact, except the slightly
increased memory footprint caused by
the thread pool.
It is recommended that you disable this

option, either by setting it to 0 or leaving
it blank. Disabling this option avoids
closing the TCP socket when something
fails because we must keep processing
other messages for other calls.
Note: This option relies on accurate

Content-Length headers in the SIP
messages. It cannot recover once a
malformed message is processed,
because the stream iterator will not be
aligned anymore. Eventually, the
connection will be closed.
Maximum time that the original
transaction for which a forked response
is received is tracked. This property is
only relevant to dialog stateful
applications (User Agents or B2BUA).
gov.nist.javax.sip.MAX_ When a forked response is received in
this time interval from when the original
FORK_TIME_SECONDS
INVITE client transaction was sent, the
stack will place the original INVITE
client transaction in the response and
deliver that to the application. The event
handler can get the original transaction
from this event.
Maximum time that a dialog can remain

in the early state (before it receives a
final response).
gov.nist.javax.sip. Note: In order to avoid a memory leak

associated with certain downstream
EARLY_DIALOG_ parallel forking scenarios, a dialog in
180 the early state will be torn down if it
TIMEOUT_
receives no responses for 180 seconds.
SECONDS This may cause problems in similar
sequential forking scenarios, where the
container attempts to create a derived
session from the original forked
session, which no longer exists.
gov.nist.javax.sip.
Controls the priority of the threads
THREAD_PRIORITY started by the stack
gov.nist.javax.sip. A property that will clean up Dialog and

Transaction structures aggressively to
true
AGGRESSIVE_CLEANUP improve memory usage and
performance (up to 50% gain).
Minimum time between keep-alive pings
gov.nist.javax.sip.MIN_
(CRLF CRLF) from clients. If pings
KEEPALIVE_ -1 (do not arrive with less than this frequency a
respond) CRLF CRLF reply will be sent; if they
TIME_SECONDS arrive with greater frequency they will
be rejected.
gov.nist.javax.sip.
The number of ticks before a dialog that
DIALOG_
64 does not receive an ACK receives a
Timeout notification.
TIMEOUT_FACTOR
Comma-separated list of protocols to

gov.nist.javax.sip.TLS_ SSLv3, use when creating outgoing TLS
SSLv2Hello, connections. Some servers do not
CLIENT_PROTOCOLS
TLSv1 support SSLv2Hello, so override to
SSLv3, TLSv1 if necessary.
Valid values are Enabled, Want, or

Disabled. Set to Enabled if you want the
SSL stack to require a valid certificate
gov.nist.javax.sip.TLS_ chain from the client before accepting a
Enabled connection. Set to Want if you want the
CLIENT_AUTH_TYPE
SSL stack to request a client Certificate,
but not fail if one isn't presented. A
value of Disabled does not require a
certificate chain.
gov.nist.javax.sip.
RELIABLE_ Value in seconds that is used as the

default keep-alive timeout. (See also
CONNECTION_ http://tools.ietf.org/html/rfc5626#section-
4.4.1.)
KEEP_ALIVE_TIMEOUT
gov.nist.javax.sip.SSL_ Value in seconds that is used as the

default timeout for performing the SSL
HANDSHAKE_TIMEOUT Handshake. This prevents bad clients
which connect without sending any data
from blocking the server.
Configuring the SIP Stack using the Mangement Console
5. Select the Properties navigation tab:
6. Click on a cell in the Value column to edit it.
The new value is saved automatically when you press Enter or click outside the cell.
7. Restart the AS to pick up the new configuration.
Configuring the SIP Stack using the CLI
2. Edit an attribute using the command:
/profile=ha/subsystem=sip/property=<property name>/:write-attribute(name=value,
value=<property value>)
where <property name> is the name of a property, and <property value> is the new value.
3. Restart the AS nodes to pick up the new configuration.
Configuring JGroups
Fusion Application Server uses Infinispan to share state between cluster elements, and
Infinispan in turn uses JGroups as the transport mechanism for sharing this state. JGroups uses
multicast to discover other nodes, and then uses TCP to share state between nodes. Each
cluster has a unique cluster ID (set during installation), and nodes do not share state with other
nodes unless the cluster IDs match. Nodes only accept discovery requests from nodes with the
same cluster ID, but if you have several distinct clusters in the same subnet, you will see warning
messages in the log, stating that discovery requests have been rejected because the cluster IDs
do not match.
To avoid these warning messages, you can use the following process to set the multicast
address and port for JGroups, so that each cluster is restricted to a specific address and port.
You will first need to decide which multicast addresses and ports each cluster will use.
To set the multicast address and port for a cluster:
3. From the menu on the left, expand General Configuration section select Socket Binding:
It doesn’t matter which profile you select for this change, as the settings you will change here are
not related to a specific profile.
4. In the ha-sockets row, click View->:
5. Select jgroups-mping in the Available Socket Bindings section, and click Edit.
6. Expand the Multicast section:
7. Edit the Multicast Port or Multicast Address values as required.
If you edit the address, replace the whole string with the new address. For example, to set the
address to 230.0.0.10, replace the whole string ${jboss.default.multicast.address:230.0.0.4} with
230.0.0.10.
8. Click Save.
9. In the lb-sockets row, click View->.
10. Repeat the previous steps.
The multicast address and port of jgroups-mping must match on the ha-sockets and lb-sockets.
Configuring Performance
HA Performance Options
There are a number of options which control the flow of data between nodes in a multi-box
cluster, and which you can configure to improve performance or stability.
Load Balancer Transaction Data
The timeout for removing transaction data from the cache can be configured by adding the
following configuration properties to the LBs:
transaction-data-expiry
The time to wait for a transaction to complete before removing it from the cache (default value
90).
transaction-data-expiry-time-units
The time units in which the previous value is expressed (default value MINUTES). Valid values
are:
DAYS
HOURS
MINUTES
SECONDS
MILLISECONDS
MICROSECONDS and NANOSECONDS will be accepted, but will be rounded down to the
nearest millisecond
Values are not case sensitive.
To add the values to the LBs:
3. From the top left menu, select the lb profile.
4. In the left hand menu, expand Subsystems and Load Balancer, and select Configuration.
6. Click Add to bring up the Create Load Balancer Property dialog:
7. Enter the Name and Value fields for the transaction-data-expiry property.
8. Click Save.
9. Repeat the above for the transaction-data-expiry-time-units property, if you did not enter the
transaction-data-expiry value in minutes.
10. Restart the LB to pick up the changes.
Application Server Failure Detection Timeout

FAS uses JGroups for failure detection. You can configure the time after which a node is
considered to be unavailableby modifying values in the JGroups stacks:
timeout
The time to wait for a node to respond to a heartbeat ping in milliseconds (default value 2000).
max_tries
The number of times to retry connecting to a node before deciding it is unavailable (default value
4).
Do this by modifying the values under the <FD> element for the appropriate JGroups stack in
the domain.xml file (udp or tcp for the profile in use), which is in the
<install_dir>/domain/configuration directory:
1. Open the domain.xml file in a text editor.
2. Look for a line like:
<subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="tcp">
3. Inside the <subsystem> element above, look for elements like:
<stack name="udp">
or
<stack name="tcp">
as required.
4. Inside the <stack> element, look for:
<protocol type="FD">
5. Inside the <protocol> element, modify the values of the <property> elements:
<property name="timeout">2000</property>
<property name="max\_tries">4</property>
as required.
6. Save the file.
7. Restart FAS.
JVM Options
There are a number of JVM settings which you can edit to improve FAS performance. For
example, you can change the maximum heap size or the maximum permgen size (or metaspace
size in Java 1.8 or higher).
For ASs and LBs in a development environment, the default JVM parameters usually work well.
Increasing the AS heap size to 2048m is usually more than sufficient for most co-hosted
application deployments. If the AS process requires more than 2048M, we recommend a 64-bit
system.
For LB processes, the memory allocated to the JVM can be smaller than that of the ASs.
To configure the LB JVM parameters independently of the AS settings, configure the JVM
settings at the server process level; see the Editing JVM Settings at the Server Process Level
section. If you want the JVM settings to be the same for both ASs and LBs, you can configure
them at the host level; see the Editing JVM Settings at the Host Level section.
Editing JVM Settings at the Host Level
3. From the top left menu, select the host.
4. From the menu on the left, expand Host Settings and select JVM Configuration:
5. If there is more than one JVM configuration, select the one you wish to change from the
Available JVM Configurations section.
6. Click the Edit button in the Selection section.
7. Change the options by editing the fields:
Note: The Permgen Size and Max Permgen Size fields are only relevant when using a Java
runtime version less than 1.8. Newer versions of Java have replaced the PermGen space with
MetaSpace, which can be configured by adding one or both of the following options to the JVM
Options field:
\-XX:MetaspaceSize=<nnn>
and
\-XX:MaxMetaspaceSize=<nnn>
where <nnn> is a size expressed in GB, MB, or KB, and suffixed by the appropriate letter (e.g.
32g, 256M).
8. Click Save.
9. Restart the FAS host for the changes to take effect.
Editing JVM Settings at the Server Process Level

4. From the menu on the left, expand Server and select Server Configuration.
5. Select the configuration you want to change from the Available Server Configurations
section, and click on the JVM Configuration tab beneath:
6. Click the Edit button.
7. Change the options by editing the fields:
Note: The Permgen Size and Max Permgen Size fields are only relevant when using a Java
runtime version less than 1.8. Newer versions of Java have replaced the PermGen space with
MetaSpace, which can be configured by adding one or both of the following options to the JVM
Options field:
\-XX:MetaspaceSize=<nnn>
and
\-XX:MaxMetaspaceSize=<nnn>
where <nnn> is a size expressed in GB, MB, or KB, and suffixed by the appropriate letter (e.g.
32g, 256M).
8. Click Save.
9. Restart the server process for the changes to take effect.
Configuring Garbage Collection

Fusion Application Server is configured to use G1 garbage collection for all processes. The
configuration options for G1 are stored in the domain.xml file, inside the <jvm-options>
element. There is a separate set for each server group:
<jvm-options>
<option value="-server"/>
<option value="-XX:+UseG1GC"/>
<option value="-XX:MaxGCPauseMillis=50"/>
<option value="-XX:+HeapDumpOnOutOfMemoryError"/>
<option value="-XX:HeapDumpPath=./heapdump\_as.hprof"/>
<option value="-XX:MetaspaceSize=256m"/>
<option value="-XX:MaxMetaspaceSize=256m"/>
</jvm-options>
You can change these options by editing the domain.xml file directly, or from the Management
Console:
4. From the menu on the left, expand Server and select Server Groups.
5. In the Available Group Configurations section, select the server group you wish to change
the garbage collection options for, and click the JVM Configuration tab below.
6. Click the Edit button.
7. Add or change options in the JVM Options field:
For instance, you might wish to change the value of the -XX:MaxGCPauseMillis setting; this
setting controls the maximum time for a pause while garbage collection takes place.
8. Restart the affected server processes (ASs if you have changed the main-server-group, LBs
for the lb-server-group) for the changes to take effect.
There are a number of other garbage collection options that can be configured but are not
included in the domain.xml file by default. See the Oracle documentation at
http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/G1GettingStarted/ for details of
these options. If you are changing several options on several server groups, you might find it
more convenient to edit the domain.xml file directly, and restart all the FAS nodes.
Configuring FAS HA without Multicast
FAS relies on multicast to discover the elements that are in a multi-box cluster, but some
deployment environments (such as Amazon AWS) do not support multicast. The following
instructions show how you can configure a multi-box FAS installation to work in an environment
that does not allow multicast.
Note: We recommend that multicast should be used in deployment if possible. This procedure
should only be used if multicast is not an option.
You need to configure the JGroups subsystem on the master FAS node to use TCP Ping instead
of UDP multicast, so that FAS uses TCP sockets to discover the other nodes. You must set the
JGroups default-stack to TCP, and add TCPPING to the TCP stack configuration; the TCPPING
configuration contains a list of the FAS components. You need to do this for ha, management,
and lb profiles.
Note: The IP addresses and other properties in the TCPPING configurations given here are
examples only; see the JGroups documentation for TCPPING for further details.
Before Changing the Configuration
1. Make a backup copy of the <install dir>/domain/configuration/domain.xml file
2. Stop all FAS cluster nodes.
Find the Configured TCP Ports
1. Open domain.xml in a text editor, and search for the <socket-binding-groups> element.
2. The configuration to note is the following:
<socket-binding-groups>
<socket-binding-group name="ha-sockets" default-interface="public">
...
<socket-binding name="jgroups-tcp" port="7600" />
...
</socket-binding-group>
<socket-binding-group name="lb-sockets" default-interface="public">
...
<socket-binding name="jgroups-tcp" port="7580" />
...
</socket-binding-group>
</socket-binding-groups>
3. Note the port numbers used by jgroups-tcp socket binding in both the ha-sockets and lb-
sockets socket binding groups. ha-sockets maps to the ha profile, and lb-sockets to the lb
profile. In the above example, the port numbers are:
ha-sockets - 7600
lb-sockets - 7580
Configuring the HA Profile
1. Search domain.xml for the element:
<profile name="ha">
2. Within the <profile> element find the element:
You can find this line by searching for node-type=”AS”, and finding the <subsystem> element
which contains the <stack> element which contains the <transport> element which has this
attribute. Note that you will find two such stacks - one for UDP and one for TCP; ensure you are
working with the correct stack (the one which has the default-stack attribute is set to tcp as
above).
3. Inside the <subsystem> element, find the <stack name="tcp"> element.
4. We want to use TCPPING, rather than MPING, so remove the MPING configuration line:
<protocol type="MPING" socket-binding="jgroups-mping"/>
from the <stack> element.
5. Add the TCPPING configuration to the <stack> element:
<protocol type="TCPPING">
<property name="initial\_hosts">
192.168.0.1[7600],192.168.0.1[7580],192.168.0.2[7600],192.168.0.2[7580]
</property>
<property name="num\_initial\_members">1</property>
<property name="port\_range">3</property>
</protocol>
where the initial_hosts property is a comma-separated list of the IP addresses and port numbers
of all the nodes in the cluster (including the master node) which need to be pinged (if both an LB
and an AS are present on a cluster node, both will need to be pinged on the port numbers
discovered in the Find the Configured TCP Ports section). The num_initial_members property is
the number of responses to wait for; see the JGroups documentation for TCPPING for further
details.
The above example represents a two-box cluster where each box runs both an LB and an AS.
TCP pings are sent to 192.168.0.1 and 192.168.0.2 on all the ports within the port_range,
starting at 7600 (looking for the AS) and 7580 (looking for the LB).
Configuring the LB Profile
This procedure is essentially similar to configuring the ha profile.
<profile name="lb">
You can find this line by searching for node-type=”LB”, and finding the <subsystem>
element which contains the <stack> element which contains the <transport> element
which has this attribute. Note that you will find two such stacks - one for UDP and one for
TCP; ensure you are working with the correct stack (the one which has the default-stack
attribute is set to tcp as above).
5. Add the TCPPING configuration to the <stack> element; e.g.:
<protocol type="TCPPING">
<property name="initial\_hosts">
192.168.0.1[7600],192.168.0.1[7580],192.168.0.2[7600],192.168.0.2[7580]
</property>
<property name="num\_initial\_members">1</property>
<property name="port\_range">3</property>
</protocol>
where the initial_hosts property is a comma-separated list of the IP addresses and port numbers
of all the nodes in the cluster (including the master node) which need to be pinged (if both an LB
and an AS are present on a cluster node, both will need to be pinged on the port numbers
discovered in the Find the Configured TCP Ports section). The num_initial_members property is
the number of responses to wait for; see the JGroups documentation for TCPPING for further
details.
Configuring the Management Profile
This procedure is essentially similar to configuring the ha and lb profiles.
<profile name="management">
You can find this line by searching for node-type=”MGMT”, and finding the <subsystem>
element which contains the <stack> element which contains the <transport> element which
has this attribute. Note that you will find two such stacks - one for UDP and one for TCP; ensure
you are working with the correct stack (the one which has the default-stack attribute is set to tcp
as above).
5. Add the TCPPING configuration to the <stack> element; e.g.: ```

6. 168.0.1[7600],192.168.0.1[7580],192.168.0.2[7600],192.168.0.2[7580] 1 3 2000 ``` where
the initial\_hosts property is a comma-separated list of the IP addresses and port numbers
of all the nodes in the cluster (including the master node) which need to be pinged (if both
an LB and an AS are present on a cluster node, both will need to be pinged on the port
numbers discovered in the [Find the Configured TCP Ports](#find-the-configured-tcp-ports)
section). The num\_initial\_members property is the number of responses to wait for; see the
JGroups documentation for TCPPING for further details.
After Changing the Configuration
1. Copy the edited domain.xml file to the <install dir>/domain/configuration directory on

each of the other FAS nodes in the cluster.
This is safe - domain.xml contains no host-specific configuration
2. Restart the FAS nodes (see the Managing Cluster Components section).
Monitoring
Monitoring using JMX
The host controller exposes MBeans over JMX, using the port 9999 (this is the same port used
for the native management interface).
In order for JConsole, or another JMX client, to connect, the client must have additional JBoss
remoting classes on the classpath. A script (jconsole.sh) is provided in the <install dir>/bin
directory which will add these classes to the classpath when starting JConsole. Since the
management port is secured, you will also need to provide the truststore containing the CA
certificate being used by FAS, which is in the <install‑dir>/domain/configuration/security/default-
trust directory.
1. Run the jconsole.sh script from the master FAS node (all on a single line):
<install dir>/bin/jconsole.sh ‑J‑Djavax.net.ssl.trustStore=<install

dir>/domain/configuration/security/default‑trust/truststore.jks
‑J‑Djavax.net.ssl.trustStorePassword=<password>
where is the password for the truststore; by default, this is changeit.
2. Connect to the FAS host as a remote process:
The connection URL takes the form: service:jmx:remoting-jmx://<fas address>:9999 , and
the default Username and Password are admin and changeit.
3. When JConsole is connected, it displays the usual JVM information, the MBeans which are
exposed, and an extra JBoss CLI tab.
From the MBeans tab, you can access the HotSpotDiagnostic and Threading MBeans:
You can use these to dump the heap (the file name is the first argument, and the file will be
saved in the <install dir> directory), dump threads (these are dumped to an interactive
window), find deadlocked threads, and so on.
The MBeans are available to applications hosted in a server process which calls
ManagementFactory.getPlatformMBeanServer.
On the JBoss CLI tab, you can access the some of the same objects and their properties as you
can from the CLI.
Right click the name of an object or attribute to access the operations availablee. In most cases,
you will find it most convenient to change these using the CLI(see the Command Line Interface
(CLI) section), which are more comprehensive; or the Management Console, for commonly
changed settings (see the Management Console section), which is less comprehensive but more
convenient.
Diagnostics
Fusion Application Server provides a script for collecting diagnostic information from a server
for further offline investigation. Running it produces a ZIP file containing configuration and
runtime information that might help you to diagnose problems:
1. Log on to the machine running FAS.
2. Change to the <install dir>/bin directory.
3. Run:
./jdr.sh
4. If prompted, enter an administrator username and password.
A ZIP file called sosreport-<host>-<date-time> is created in the <install dir>/bin
directory, where <host> is the host name, and <date-time> is the local date and time in ISO
format without separators (yyyyMMddHHmmss).
The ZIP file contains the following information:
Configuration files (such as domain.xml and host.xml) and backups.
Logs for the host controller, process controller, and each server process.
Metadata about what modules are installed and what resources’ dependencies are
configured (module.xml files).
Management interface configuration (configuration.json file).
Other configuration files (such as thread dump information).
Core Dumps
In a production system, core dumps are normally disabled. To enable core dumps from FAS (for
all users), edit the /etc/security/limits.conf file, and add the lines:
\* soft core unlimited
\* hard core unlimited
commenting out any existing lines relating to the core item.
Ports
The following diagram shows the ports used by the Fusion Application Server cluster
components:
LB Ports
Port Purpose Notes
5060 SIP UDP/TCP
5061 SIP TLS
8080 HTTP
8443 HTTPS
5065 SIP communication between LB and AS internal, distributed installations
5066 SIP communication between LB and AS internal, distributed installations
4427 State sharing between LB and AS internal, distributed installations
8070 JBoss OSGI port internal
57580 JGroups failure detection internal
7580 JGroups replication internal
AS Ports
Port Purpose Notes
5080 SIP UDP/TCP
5081 SIP TLS
5082 SIP-WS (SIP over WebSockets)
8100 HTTP
8463 HTTPS
4447 State sharing between AS and LB internal, distributed installations
5065 SIP communication between AS and LB internal, distributed installations
5066 SIP communication between AS and LB internal, distributed installations
57600 JGroups failure detection port internal
45700 JGroups multicast port for MPING internal
7600 JGroups replication port internal
Management Server Process Ports
Port Purpose Notes
9100 HTTP (License Server)
9463 HTTPS (License Server)
5447 Remoting (JNDI/EJB/JMX)
Host Controller Ports
Port Purpose Notes
9990 Web Administration interface
9999 Management REST port (used by CLI and other processes)
8161 SNMP listener
Glossary
Term Description
This is a framework offered by applications to manage their

configuration. Unlike managing application configurations using
Application
standard system properties, this framework offers validation and
Configuration
publishing hooks that allow the application to check that
Framework (ACF)
configuration settings are valid, and to be informed when
configuration settings have changed.
Used for co-hosting multiple products on the same FAS cluster.

Application Router Where each product has its own application router and set of
Registry applications, the application router registry determines which
application router a request is sent to.
Server process running in FAS to which applications are deployed,

Application Server
and which executes the application logic. It is a JSR 289-compliant
(AS)
application server.
Application Server
FAS node running at least an AS server process.
node (AS node)
Group of FAS nodes, of which one is the master and the others are
Cluster
slave nodes.
A unique name within the enterprise that a cluster is known by.

Cluster name Specifying the cluster name when adding a new AS or LB adds that
component to the specified cluster.
Datasource The connection set up to a database from a server.
A set of Server Groups that can be managed from a single point.

Essentially equivalent to a cluster, though a cluster is more physical
Domain
(a set of host machines or virtual servers), while a domain is more
logical (a set of Server Groups).
Domain Host A Host Controller that is in charge of all the others in a cluster, and
Controller the point from which the Server Groups in a domain are managed.
Dynamic Model
A tree-structure representation of the FAS attributes that can be
Representation
configured.
(DMR)
A combined SIP and HTTP application development and delivery

Fusion Application platform that can be used in multiple network architectures, ranging
Server (FAS) from the smallest enterprise applications to carrier-scale IMS
environments using SIP and HTTP.
Host or virtual server running FAS, and which is part of a FAS

FAS node
cluster.
Host Controller The FAS process that provides the management interfaces.
A certificate that proves a resource’s identity, usually signed by a

Identity Certificate
Certification Authority. Used in TLS.
A scalable, highly available data store and distributed data grid

Infinispan platform that provides distributed cache capabilities and state
replication.
The Java API for XML Web Services. It is a Java programming

JAX-WS language API for creating web services, and is part of the Java EE
platform.
A graphical monitoring tool to monitor Java Virtual Machine (JVM)

JConsole
and java applications both on a local or remote machine.
A toolkit for reliable messaging. It can be used to create groups of

JGroups
processes whose members can send messages to each other.
A server process running within FAS. It is a largely stateless proxy

Load Balancer (LB) for both SIP and HTTP that routes new requests to an AS server
process.
Load Balancer
A FAS node running at least an LB server process.
node (LB node)
In a managed domain each application server instance is a member

Managed domain of a server group. You can manage multiple server groups within a
domain.
Management A server process running on the FAS master node in a cluster (and
Server only on the FAS master node).
The traffic from the CLI, Management Console and from

Management traffic
communication between master and slave host controllers.
The FAS node that hosts the Domain Host Controller, which the CLI
Master node
and Management Console connect to to manage the cluster.
Java Management Extensions (JMX) is a Java technology that

supplies tools for managing and monitoring applications, system
MBeans
objects, devices and service oriented networks. Those resources are
represented by objects called MBeans (for Managed Bean).
The reference implementation of the JAIN-SIP API. JAIN-SIP is a

low level protocol API for SIP. NIST stands for National Institute of
NIST SIP stack
Standards and Technology. JAIN stands for Java APIs for Intelligent
Networks.
The FAS process that manages the lifecycle of the other processes -
Process Controller
starting, stopping, and restarting as appropriate.
A profile is a set of subsystems (for example, logging, web, SIP,

Profile
Infinispan) together with their configuration.
A logical construct used by the AS to group sessions. Each AS

creates a fixed number of segments when it starts. The assignment
Segments
of Segment ID to AS is shared via Infinispan and known to all FAS
nodes.
Server processes across one or more hosts are grouped into Server
Server Group Groups. Applications are deployed to Server Groups, so all hosts in
a Server Group will have the same set of applications deployed.
A process running in FAS (AS, LB, or Management). Unfortunately

Server Process
referred to as a server in the Management Console.
Service traffic HTTP, HTTPS, SIP, and SIPS traffic.
The FAS nodes within a cluster that are not the Master are slaves,
Slave which receive their configuration changes from the Domain Host
Controller running on the Master node.
SNMP Agent A process integrated with each Domain Host Controller and Host
Controller that collects information from the FAS platform, and
applications hosted on FAS, and exposes this to the external
Network Management System. SNMP stands for Simple Network
Management Protocol.
A state resulting from network issues that prevent some AS nodes

Split brain from communicating with other AS nodes in the cluster, forming
separate subgroups.
A certificate from an external host that enables secure

Trust certificate
communication with that host. Used in TLS.
An abstraction layer on top of a more concrete file system that

Virtual File System
allows client applications to access different types of file systems in
(VFS)
a uniform way.
The Web Services Description Language is an XML-based interface

WSDL description language that is used for describing the functionality
offered by a web service.

FAS Administration Guide

Uploaded by

Copyright:

Available Formats

FAS Administration Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FAS Administration Guide

Uploaded by

Copyright:

Available Formats

FAS Administration Guide

YRP1-508, 3-4 Hikari-no-Oka Yokosuka-Shi, Kanagawa, 239-0847, Japan

All rights reserved.

Document version: 2.6

For technical support or other queries, contact CBA Support at:

For our worldwide corporate office address, see:

https://www.cba-japan.com (Japanese) https://www.cba-gbl.com (English)

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 2

Fusion Application Server Architecture Guide

Fusion Application Server Installation Guide

Fusion Application Server Administration Guide

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 3

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 4

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 5

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 6

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 7

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 8

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 9

Domains, Server Groups, Server Processes, and Profiles

Managing Cluster Components

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 10

The operational status of FAS components is exposed using JMX MBeans.

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 11

By default, FAS is configured to use Transport Layer Security (TLS).

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 12

Server Groups and Server Processes

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 13

An AS process, belonging to the main-server-group.

An LB process, belonging to the lb-server-group.

The installer creates three default profiles:

Contains the default configuration for the ASs in the main-server-group.

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 14

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 15

Before using the Management Console to configure FAS, ensure that:

Starting the Management Console

To launch the Management Console, open the following URL in a browser:

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 16

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 17

See the Managing Profiles section.

See the Managing Servers section.

See the Managing Runtime Configuration section.

Profiles, if the main navigation selection is Profiles.

Hosts, if the main navigation selection is Servers.

Server Processes, if the main navigation selection is Runtime.

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 18

5. Main content area

6. Messages and notifications area

The toolbar contains the following general operations:

Closes the current management session.

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 19

The FAS installer creates and configures three profiles:

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 20

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 21

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 22

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 23

2. Select Server Instances in the third navigation pane.

3. Select the loadbalancer server process in the main content area

Command Line Interface (CLI)

Before using the CLI to configure FAS, ensure that:

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 24