Environment Preparation

The domain will look like the below architecture:

On three VMs:

• vmjboss: master, hosting the Domain Controller
• vmjboss1: slave1
• vmjboss2: slave2

I already installed JBoss EAP 7.0.0 on these VMs under $JBOSS_HOME, and created the domain according to the above architecture. If you need any help to create the domain please check this blog.

Start the Domain

I started the domain, I can see that both slaves joined the master:

[Host Controller] 16:53:44,707 INFO  [org.jboss.as.domain.controller] (Host Controller Service Threads - 36) WFLYHC0019: Registered remote slave host "slave1", JBoss JBoss EAP 7.0.0.GA (WildFly 2.1.2.Final-redhat-1)
[Host Controller] 16:54:28,710 INFO  [org.jboss.as.domain.controller] (Host Controller Service Threads - 37) WFLYHC0019: Registered remote slave host "slave2", JBoss JBoss EAP 7.0.0.GA (WildFly 2.1.2.Final-redhat-1)

On slave1 and slave2, you should see the below in the logs:

[Host Controller] 16:54:26,644 INFO  [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0148: Connected to master host controller at remote://vmjboss:9999
[Host Controller] 16:54:26,689 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1) (Host Controller) started in 13192ms - Started 43 of 44 services (13 services are lazy, passive or on-demand)

Create Server Group

Now, our domain is up and running, we will create the ServerGroup named GroupHA.
You can use the –command argument to provide a single CLI command to execute. The management CLI will terminate once the commands have completed.

[jboss@vmjboss ~]$ $JBOSS_HOME/bin/jboss-cli.sh -c --controller=vmjboss:9990 --command="/server-group=GroupHA:add(profile=ha,socket-binding-group=ha-sockets)"
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}

To build a cluster the profile should be ha or full-ha where needed subsystems are configured by default:

• Infinispan: An architecture used for caching objects and also replicating objects between caches. The Infinispan subsystem provides caching, state replication, and state distribution support.
• JGroups: A framework for nodes to communicate with each other using either UDP or TCP.

For more information about profiles read this blog 😉

Create Servers

From the master, create the server1 on slave1:

[jboss@vmjboss ~]$ $JBOSS_HOME/bin/jboss-cli.sh -c --controller=vmjboss:9990 --command="/host=slave1/server-config=server1:add(group=GroupHA,socket-binding-port-offset=100)"
{
    "outcome" => "success",
    "result" => {
        "step-1" => {"outcome" => "success"},
        "step-2" => {"outcome" => "success"},
... 
        "step-255" => {"outcome" => "success"},
        "step-256" => {"outcome" => "success"}
    },
    "server-groups" => undefined
}

The port-offset is set to 100 to avoid port conflict with other instances running on the same VM/IP address.

Create the server2 on slave2:

[jboss@vmjboss ~]$ $JBOSS_HOME/bin/jboss-cli.sh -c --controller=vmjboss:9990 --command="/host=slave2/server-config=server2:add(group=GroupHA,socket-binding-port-offset=200)"
{
    "outcome" => "success",
    "result" => {
        "step-1" => {"outcome" => "success"},
        "step-2" => {"outcome" => "success"},
... 
        "step-255" => {"outcome" => "success"},
        "step-256" => {"outcome" => "success"}
    },
    "server-groups" => undefined
}

Both servers have been assigned to the server group GroupHA created before.

Start both servers:

[jboss@vmjboss ~]$ $JBOSS_HOME/bin/jboss-cli.sh -c --controller=vmjboss:9990 --command=":start-servers(blocking=true)"

{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}

What blocking=true means?
In fact, if blocking=true is set your command will hang or wait until the operation on the server side returns and tells the CLI that the operation is complete.

Cluster Creation

A cluster is a collection of servers that communicate with each other in such a way that they improve the availability of services by providing the following capabilities:

• High Availability (HA): a service has a very high probability of being available.
• Scalability: a service can handle a large number of requests by spreading the workload across multiple servers.
• Failover: if a service fails, the client can continue processing its tasks as another cluster member takes over the client’s requests.
• Fault Tolerance: a server can guarantee correct behavior even if fail over occurs.

The most common way to achieve scalability and high availability is to use the following together:

• Load balancer: Often a piece of hardware, or a service like Apache httpd.
• Data replication services: A service such as memcached or a framework (Infinispan)

Application Preparation

To take advantage of the high availability features of clustered servers, an application first has to be marked as being distributable. To do so, include the tag in the web.xml for the application. The following is extracted from the web.xml of my cluster.war application:

<?xml version="1.0"?>
  <web-app ...>
    <distributable/>
  </web-app>

Application Deployment

Now, I will deploy the cluster.war application on the Server Group GroupHA, so on all servers assigned to this Server Group.

[jboss@vmjboss ~]$ $JBOSS_HOME/bin/jboss-cli.sh -c --controller=vmjboss:9990 --commands="deploy /opt/data/cluster.war --server-groups=GroupHA,deployment-info --name=cluster.war"
NAME        RUNTIME-NAME 
cluster.war cluster.war  

SERVER-GROUP       STATE     
GroupHA            enabled

As you can see the output of deployment-info, the cluster.war application has been deployed and enabled on GroupHA, so on server1 and server2.

Go, and check the slave1 and slave2 logs, you should see:
On slave1:

[Server:server1] 17:45:51,095 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 68) WFLYUT0021: Registered web context: /cluster
[Server:server1] 17:45:52,662 INFO  [org.infinispan.CLUSTER] (remote-thread--p11-t1) ISPN000310: Starting cluster-wide rebalance for cache cluster.war, topology CacheTopology{id=1, rebalanceId=1, currentCH=DefaultConsistentHash{ns=80, owners = (1)[slave1:server1: 80+0]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[slave1:server1: 40+40, slave2:server2: 40+40]}, unionCH=null, actualMembers=[slave1:server1, slave2:server2]}
[Server:server1] 17:45:52,681 INFO  [org.infinispan.CLUSTER] (remote-thread--p11-t1) ISPN000310: Starting cluster-wide rebalance for cache routing, topology CacheTopology{id=1, rebalanceId=1, currentCH=DefaultConsistentHash{ns=80, owners = (1)[slave1:server1: 80+0]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[slave1:server1: 40+40, slave2:server2: 40+40]}, unionCH=null, actualMembers=[slave1:server1, slave2:server2]}
..
[Server:server1] 17:45:55,104 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 65) WFLYSRV0010: Deployed "cluster.war" (runtime-name : "cluster.war")

On slave2:

[Server:server2] 17:45:52,454 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000094: Received new cluster view for channel hibernate: [slave1:server1|1] (2) [slave1:server1, slave2:server2]
...
[Server:server2] 17:45:53,777 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 66) Initializing Mojarra 2.2.12-jbossorg-2  for context '/cluster'
[Server:server2] 17:45:55,334 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 66) WFLYUT0021: Registered web context: /cluster
[Server:server2] 17:45:55,451 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 65) WFLYSRV0010: Deployed "cluster.war" (runtime-name : "cluster.war")

Which means that a cluster has been created once your distributable application has been deployed on servers server1 and server2 (members of the server group GroupHA).

The application is available from server2:

The application is also available from server1:

Now, you can easily create new server(s) and assign it/them to GroupHA, the application cluster.war will be deployed on it and server3 will join the cluster automatically.

Now, data is replicated between the cluster members, but we will better see clustering benefits with a LB on top. That’s will be the topic of our my next blog, I will show you how to configure JBoss EAP to play as Load Balancer, in the meanwhile don’t hesitate to ask questions 😉

Take care and stay safe 🙂

L’article JBoss EAP 7 – Cluster in Domain mode est apparu en premier sur dbi Blog.

How this default configuration arrive in my domain?

As explained before we use the default domain.xml and (host.xml, host-master.xml or host-slave.xml) to create a domain, in fact, the default configuration created is there 😉

Server groups preconfigured in domain.xml

In the domain.xml you will find below configuration:

    <server-groups>
        <server-group name="main-server-group" profile="full">
            <jvm name="default">
                <heap size="1000m" max-size="1000m"/>
            </jvm>
            <socket-binding-group ref="full-sockets"/>
        </server-group>
        <server-group name="other-server-group" profile="full-ha">
            <jvm name="default">
                <heap size="1000m" max-size="1000m"/>
            </jvm>
            <socket-binding-group ref="full-ha-sockets"/>
        </server-group>
    </server-groups>

This means that two server groups are configured already.

Servers configured in host*.xml

host-master.xml

No servers defined, which is normal because it is not recommended to have servers on the master host.

host.xml

    <servers>
        <server name="server-one" group="main-server-group">
        </server>
        <server name="server-two" group="main-server-group" auto-start="true">
            <socket-bindings port-offset="150"/>
        </server>
        <server name="server-three" group="other-server-group" auto-start="false">
        </server>
    </servers>

host-slave.xml

    <servers>
        <server name="server-one" group="main-server-group"/>
        <server name="server-two" group="other-server-group">
            <socket-bindings port-offset="150"/>
        </server>
    </servers>

So, depending on which preconfigured file is used servers are configured in your domain…

How to clean default configuration?

You have two choices:

Update xml preconfigured files

The idea is to update the xml files before you start the domain and remove this default configuration on each host. which means:
Remove all lines between

    <server-groups>

and

    </server-groups>

from domain.xml

Remove all lines between

    <servers>

and

    <servers>

from host.xml or host-slave.xml

Be careful, servers are assigned to server groups, so if you remove the server groups you have to remove related servers, if not this will cause issues because server groups will not be found!

Clean default configuration after domain start

Start your domain and connect to the CLI:

[jboss@vmjboss ~]$ $JBOSS_HOME/bin/jboss-cli.sh -c --controller=vmjboss:9990
[domain@vmjboss:9990 /] 

You need first to stop servers then remove them:

[domain@vmjboss:9990 /] /host=slave1/server-config=server-one:stop(blocking=true)
{
    "outcome" => "success",
    "result" => "STOPPED"
}
[domain@vmjboss:9990 /] /host=slave1/server-config=server-one:remove             
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}

Repeat the operation on all servers all hosts.

Now, you will be able to remove default server groups:

[domain@vmjboss:9990 /] /server-group=main-server-group:remove
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}

Repeat the operation to remove all default server groups

Configure the domain

Define server groups

Server groups already explained in this blog.

To define a server group you should at least know:
– Which profile is needed (default, full, full-ha, ha)
– Which socket-binding-group according to your profile (standard-sockets, full-sockets, full-ha-sockets, ha-sockets)
– socket-binding-port-offset if needed

You can create a server groups via CLI or console, here the CLI Command to create an HA server groups:

[domain@vmjboss:9990 /] /server-group=HA-GROUP:add(profile=ha,socket-binding-group=ha-sockets)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}

Define servers

Servers already explained in this blog.

To create a server you should at least know:
– On which host?
– Assigned to which group?

The server is created in a host and assigned to a server groups, below the command line to create a server:

[domain@vmjboss:9990 /] /host=slave1/server-config=server1:add(group=HA-GROUP,socket-binding-port-offset=100,auto-start=true)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}

Now you know how to clean default servers and server groups, and how to create yours according to your need. Don’t hesitate to ask questions 😉

L’article JBoss EAP 7 – Domain Configuration est apparu en premier sur dbi Blog.

To understand JBoss EAP domain architecture we need to understand all components of the below domain example:

In the previous figure, the light gray boxes represent machines, they could be either physical or virtual machines. Now, let’s try to explain each component:

Host controller

It is a process running on each machine involved in the domain, this process relays configuration information, runtime status, and management commands to EAP server instances on that particular machine, it is the entry point on the machine. The host controller interacts with the domain controller (explained below) to ensure each server instance is configured according to the policies of the domain. On the other hand, a host controller doesn’t perform application servers tasks, this is done exclusively by server instances.

The configuration file for a host controller is host.xml, and can be found under $DOMAIN_HOME/configuration. There are important settings in this file, for example, server configurations.

By default, a host controller instance is named as its machine host name, but this can be overridden by using the name attribute in the host top-level element, at the beginning of the host.xml configuration file, for example:

<host name="slave1" xmlns="urn:jboss:domain:4.1">

This name will be displayed in the Management Console and CLI.
Be careful, when a host is stopped it doesn’t appear anymore in the Management Console and CLI!

Domain controller

In a managed domain, one of the host controller instances is configured to act as the central management point, so it act as the domain controller. In the previous figure the host managed by the domain controller does not have any server instances. This is a recommended approach, but it is possible because a domain controller is also a host controller so it could directly manage its own server instances.

To denote that a host controller is a domain controller (master host) add the following to its host.xml configuration file between the managenemt and interfaces elements as shown below:

<host name="master" xmlns="urn:jboss:domain:4.1">
	...
	</management>
	<domain-controller>
		<local/>
	</domain-controller>
	<interfaces>
	...
</host>

In fact, the domain-controller element informs a host controller where to find the domain controller. If a host controller is supposed to be the master for its managed domain, use the local element, if not:

<domain-controller>
	<remote security-realm="ManagementRealm">
		<discovery-options>
			<static-discovery name="primary"
			protocol="${jboss.domain.master.protocol:remote}"
			host="${jboss.domain.master.address}"
			port="${jboss.domain.master.port:9999}"/>
		</discovery-options>
	</remote>
</domain-controller>

The master address and port can be set in the host.xml configuration file or passed as parameter to start the slave host and override these values. Please note that at the same location of host.xml two other preconfigured files host-master.xml and host-slave.xml can be found.

The white field next to the host controllers, means that any host controller could be configured as a replacement domain controller in case the original one is unavailable, this can’t be automated and require manual operation and will be detailed and tested in a separated blog. If a domain controller fails, the host controllers simply keep trying to reconnect until the domain controller comes back again. Note that the server instances are NOT affected if a domain controller fails.

Server Group

A server group is a collection of servers that are managed and configured as one. It provide a logical grouping that impacts configuration settings, for example:

• A profile is assigned to a server group, all server instances in this server group will have the same profile.
• Applications are deployed and activated only to server groups, applications will be deployed to all server instances in this group.

Server groups are defined in the domain.xml configuration file of the domain controller! A server group require at least a profile and a socket binding group to be created. Then, servers are assigned to the server group inherits its configuration from the server group. For example, if a server group has the default profile, the servers assigned to this server group can’t be clustered because this need the ha or full-ha profiles. On the other hand, you can override some server group configuration for a specific server, for example, jvm parameters.

Server

A server instance runs inside a dedicated Java Virtual Machine (JVM) and runs only application code not management services, I mean comparing to a standalone instance which runs the Management Console and the Management API under the same JVM that runs applications.

In a managed domain, a server instance should be created on one and only one host, and assigned to one and only one server group.

Process controller (not shown in the above schema)

A process running on a host machine that starts host controllers and server instances on that particular machine. In fact, on any one of the machines starting a host controller (with or without domain controller) you should have two processes:
Process Controller

jboss    10281 10200  2 21:47 pts/0    00:00:00 java -D[Process Controller] -server -Xms64m -Xmx512m -XX:MaxMetaspaceSize=256m 
-Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true 
-Dorg.jboss.boot.log.file=/opt/install/master/log/process-controller.log -Dlogging.configuration=file:/opt/install/master/configuration/logging.properties 
-jar /opt/install/eap-7.0.0/jboss-modules.jar -mp /opt/install/eap-7.0.0/modules org.jboss.as.process-controller ..

Host Controller

jboss    10294 10281 18 21:47 pts/0    00:00:04 java -D[Host Controller] -Dorg.jboss.boot.log.file=/opt/install/master/log/host-controller.log 
-Dlogging.configuration=file:/opt/install/master/configuration/logging.properties -server -Xms64m -Xmx512m -XX:MaxMetaspaceSize=256m 
-Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -jar /opt/install/eap-7.0.0/jboss-modules.jar 
-mp /opt/install/eap-7.0.0/modules org.jboss.as.host-controller ...

CLI and Management Console

The Command Line Interface (CLI) and Management Console are a management tools for a managed domain or standalone server. These tools allow users to connect to the domain controller or a standalone server and execute management operations. I am not going to speak a lot about the management tools, the most important point here is to understand that these tools deal only with the domain controller as shown in the above figure.

Hope that this blog helped you to improve your knowledge on domain architecture in JBoss EAP, in next blogs I will talk more in depth about the domain mode with use cases. Meanwhile, don’t hesitate to ask if you have any question!

L’article JBoss EAP 7 – Domain Architecture Understanding est apparu en premier sur dbi Blog.

Modules

A module basically provides code (Java Classes) to be used by EAP services and/or by applications. Modules are loaded into an isolated Classloader, and can only see classes from other modules when explicitly requested. In fact, all code running is run inside modules, I mean by code the code provided by the core and the Application code.

Moreover, an application can see a module that exposes a particular version of an API. So, an application developer may control this manually and it can be very useful. But by default, EAP 7 automatically decides which modules to expose to an application, based on its use of JEE APIs.

All modules available in an EAP 7 installation are folders inside JBOSS_HOME/modules:

• Modules for EAP 7 Product under: JBOSS_HOME/modules/system/layers/base folder.
• Modules for third-party products under: JBOSS_HOME/modules/system/layers folder.
• Local modules folders added by a system administrator should be under: JBOSS_HOME/modules.

Inside one of the module folders listed above, a module name is used to create a folder tree. For example, the module named:

• org.wildfly.extension.undertow is under JBOSS_HOME/modules/system/layers as org/wildfly/extension/undertow.
• com.oracle is under JBOSS_HOME/modules as com/oracle.

Extensions

A module that provides features and capabilities to the application server is called an extension, or let’s say that the extension is the reference of a module in .xml configuration files.
For example, the module org.wildfly.extension.undertow is referenced as below in the standalone.xml file:

<server xmlns="urn:jboss:domain:4.1">
    <extensions>
		...
		<extension module="org.wildfly.extension.undertow"/>
		...
	</extensions>
	...

So, Extensions are added to an EAP instance using the “extension” element, which appears at the beginning of the EAP main configuration files : standalone.xml or domain.xml.
Adding an extension to the configuration files does not make that extension module loaded and active, it make the extension available for management. For example, clustering configurations can be done if the related extensions are available, but the related modules will only be loaded and activated when an application that requires clustering services is deployed. Which is really a good point for JBoss!

Subsystems

An extension management model provides one or more subsystems. When an extension is added to an EAP instance, the capabilities and attributes of the subsystems provided by the extension management model are configured within the “subsystem” element in the EAP configuration file.
Most of the time, an extension module provides a single subsystem, but a subsystem use multiple extension modules… For example:

• org.wildfly.clustering.web.infinispan extention module is used by the infinispan subsystem, which use also using org.wildfly.clustering.server:

  <subsystem xmlns="urn:jboss:domain:infinispan:4.0">
  	<cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
  		...
  	</cache-container>
  	<cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
  		...
  	</cache-container>
  	...
  

• org.jboss.as.clustering.jgroups extension module is used by the jgroups subsystem.

In fact, each subsystem has its own XML schema to define what is allowed within its element. All EAP 7 subsystem schema definitions can be found in the JBOSS_HOME/docs/schema folder:

[jboss@vmjboss ~]$ ls -rtl
total 8312
-rw-rw-r-- 1 jboss jboss   5604 Apr 18  2016 xml.xsd
-rw-rw-r-- 1 jboss jboss  33107 Apr 18  2016 wildfly-undertow_3_1.xsd
-rw-rw-r-- 1 jboss jboss  31295 Apr 18  2016 wildfly-undertow_3_0.xsd
-rw-rw-r-- 1 jboss jboss  26467 Apr 18  2016 wildfly-undertow_2_0.xsd
-rw-rw-r-- 1 jboss jboss  24042 Apr 18  2016 wildfly-undertow_1_2.xsd
-rw-rw-r-- 1 jboss jboss  22155 Apr 18  2016 wildfly-undertow_1_1.xsd
-rw-rw-r-- 1 jboss jboss  20317 Apr 18  2016 wildfly-undertow_1_0.xsd
-rw-rw-r-- 1 jboss jboss  54521 Apr 18  2016 jboss-as-infinispan_4_0.xsd
-rw-rw-r-- 1 jboss jboss  55506 Apr 18  2016 jboss-as-infinispan_3_0.xsd
-rw-rw-r-- 1 jboss jboss  55006 Apr 18  2016 jboss-as-infinispan_2_0.xsd
-rw-rw-r-- 1 jboss jboss  49219 Apr 18  2016 jboss-as-infinispan_1_5.xsd
-rw-rw-r-- 1 jboss jboss  48569 Apr 18  2016 jboss-as-infinispan_1_4.xsd
-rw-rw-r-- 1 jboss jboss  47823 Apr 18  2016 jboss-as-infinispan_1_3.xsd
-rw-rw-r-- 1 jboss jboss  47555 Apr 18  2016 jboss-as-infinispan_1_2.xsd
-rw-rw-r-- 1 jboss jboss  42567 Apr 18  2016 jboss-as-infinispan_1_1.xsd
-rw-rw-r-- 1 jboss jboss  42144 Apr 18  2016 jboss-as-infinispan_1_0.xsd
-rw-rw-r-- 1 jboss jboss  14994 Apr 18  2016 jboss-as-jgroups_4_0.xsd
-rw-rw-r-- 1 jboss jboss  14734 Apr 18  2016 jboss-as-jgroups_3_0.xsd
-rw-rw-r-- 1 jboss jboss   9042 Apr 18  2016 jboss-as-jgroups_2_0.xsd
-rw-rw-r-- 1 jboss jboss   7368 Apr 18  2016 jboss-as-jgroups_1_1.xsd
-rw-rw-r-- 1 jboss jboss   6558 Apr 18  2016 jboss-as-jgroups_1_0.xsd
...

All subsystems can be configured using the CLI or the Management Console, I don’t recommand the manual xml update especially in this case! The management tools will make the update properly when needed.

Profiles

A profile is a group of subsystems configurations, by default there are four predefined profiles can be used in Standalone mode and Domain mode:

• default: Is the basic subsystem but the most commonly used one, including logging, security, datasources, infinispan, weld, webservices, and ejb3…
• ha: Contains the exact same subsystems as the default profile, with the addition of clustering capabilities, provided mainly by the jgroups subsystem.
• full: Is similar to the default profile, but notably adds the messaging (messagingactivemq) and a few other less used subsystems.
• full-ha: Is same as the full profile, but with the addition of clustering capabilities.

Of course, you can create new profiles, either from scratch or cloned from the ones provided out-of-the-box.

Standalone vs Domain mode

As said before, four profiles are configured by default on Standalone and Domain mode, but where the profiles are configured is diffrent:

Standalone
In the JBOSS_HOME/standalone/configuration folder you can find four standalone configuration files:

• standalone.xml: which has the default profile configured.
• standalone-ha.xml: which has the ha profile configured.
• standalone-full.xml: which has the full profile configured.
• standalone-full-ha.xml: which has the full-ha profile configured.

By default the standalone.sh script will start an instance with default profile so using standalone.xml, if you want to start an instance with another profile you have to give the .xml configuration file as parameter, to use full-ha profile:

$JBOSS_HOME/bin/standalone.sh --server-config=standalone-full-ha.xml

So a standalone server instance can easily be started with more or less subsystems available, it is up to you to choose the needed profile.

Domain
In the domain the story is a little bit different, four profiles mentioned before exist in the domain.xml file:

<profiles>
    <profile name="default">
		... <!-- Subsystems configuration -->
	</profile>
    <profile name="ha">
		... <!-- Subsystems configuration -->
	</profile>
    <profile name="full">
		... <!-- Subsystems configuration -->
	</profile>
    <profile name="full-ha">
		... <!-- Subsystems configuration -->
	</profile>
</profiles>

Then when you create a server group you need to specify a profile, which will be the same for all servers in this group.

I hope that this blog will help you to understand the terms evoked (Modules, Extensions, Subsystems, and Profiles) and relationships between them. If any question remain don’t hesitate to ask

L’article JBoss EAP 7 – Modules, Extensions, Subsystems, and Profiles est apparu en premier sur dbi Blog.

Environment preparation

In my case I will prepare three hosts, below prerequisites should be verified, so make sure that:

• you have the same JBoss version on three hosts
• they are in the same local network
• they can access each other via different TCP/UDP ports, sometimes firewall may cause some issues at this level.

As said, I will have :
Three hosts:

• One master : run as domain controller.
• Two slaves (slave1, slave2) : will run under the domain management of master.

First, I installed JBoss EAP 7 on three VMs under /opt/install/jboss-eap-7, I configured some environment variables to make the blog readable 😉

Configure and start the Domain

Interface configuration

On Master
Define below environment variables:

JBOSS_HOME=/opt/install/eap-7.0.0
DOMAIN=/opt/install/master

Copy the domain folder as below:

cp -rp $JBOSS_HOME/domain $DOMAIN

Update the host.xml configuration:

vi $DOMAIN/configuration/host.xml

We need to change the address to the management interface so slaves could connect to master. My master’s host is vmjboss, so I change the config to:

<interfaces>
    <interface name="management">
        <inet-address value="${jboss.bind.address.management:vmjboss}"/>
    </interface>
    <interface name="public">
        <inet-address value="${jboss.bind.address:vmjboss}"/>
    </interface>
</interfaces>

On slaves
Steps below for slave1, repeat the same for slave2 🙂

Define below variables environment:

JBOSS_HOME=/opt/install/eap-7.0.0
DOMAIN=/opt/install/slave1

Update the host.xml configuration:

vi $DOMAIN/configuration/host.xml

First we need to set the hostname, I change the name property as below:

<host xmlns="urn:jboss:domain:4.1" name="slave1">

Then we need to modify domain-controller section so slave can connect to master’s management port:

    <domain-controller>
        <remote protocol="remote" host="${jboss.domain.master.address:vmjboss}" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm"/> 
    </domain-controller>

As we know, vmjboss is the address of master.

Finally, we also need to configure interfaces section and expose the management ports to public address:

<interfaces>
    <interface name="management">
        <inet-address value="${jboss.bind.address.management:vmjboss1}"/>
    </interface>
    <interface name="public">
        <inet-address value="${jboss.bind.address:vmjboss1}"/>
    </interface>
</interfaces>

Now, if you start JBoss on master, slave1 and slave2 you will see the slaves cannot be started with following error:

[Host Controller] 17:44:01,967 WARN  [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0001: 
Could not connect to remote domain controller remote://vmjboss:9999 -- java.lang.IllegalStateException: 
WFLYHC0043: Unable to connect due to authentication failure.

Because we haven’t properly set up the authentication between master and slave yet. we need to create the same user/password on master and slaves then use it for domain management authentication, let’s move to the security configuration.

Security configuration

On master and slaves, use the script add-user.sh to create the user as explained below:

[jboss@vmjboss ~]$ $JBOSS_HOME/bin/add-user.sh

What type of user do you wish to add? 
 a) Management User (mgmt-users.properties) 
 b) Application User (application-users.properties)
 (a): a

Enter the details of the new user to add.
Using realm 'ManagementRealm' as discovered from the existing property files.
Username : slave
Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file.
 - The password should be different from the username
 - The password should not be one of the following restricted values {root, admin, administrator}
 - The password should contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
Password : 
Re-enter Password : 
What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[  ]: jboss
About to add user 'slave' for realm 'ManagementRealm'
Is this correct yes/no? yes
Added user 'slave' to file '/opt/install/eap-7.0.0/standalone/configuration/mgmt-users.properties'
Added user 'slave' to file '/opt/install/eap-7.0.0/domain/configuration/mgmt-users.properties'
Added user 'slave' with groups jboss to file '/opt/install/eap-7.0.0/standalone/configuration/mgmt-groups.properties'
Added user 'slave' with groups jboss to file '/opt/install/eap-7.0.0/domain/configuration/mgmt-groups.properties'
Is this new user going to be used for one AS process to connect to another AS process? 
e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
yes/no? yes
To represent the user add the following to the server-identities definition <secret value="UGFzc3cwcmQh" />

Notice the four lines Added user ‘slave’, you will see that the user has been added to $JBOSS_HOME and note to the $DOMAIN. So we need to override files under $DOMAIN (for master and slaves):

cp -p $JBOSS_HOME/domain/configuration/mgmt* $DOMAIN/configuration/.

The user added will be used by the slaves to connect to the master and being registered. So, one further step remain to tell the slaves to use this user, update the $DOMAIN/configuration/host.xml onlz on slaves:

<domain-controller>
    <remote protocol="remote" host="${jboss.domain.master.address:vmjboss}" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm" username="slave"/>
</domain-controller>

And change the security-realms section as following:

<management>
    <security-realms>
        <security-realm name="ManagementRealm">
            <server-identities>
                    <secret value="UGFzc3cwcmQh" />
            </server-identities>
            <authentication>
			...

To confirm the configuration start the domain using the same below command (on master and slaves):

$JBOSS_HOME/bin/domain.sh -Djboss.domain.base.dir=$DOMAIN

You should see in the master log:

[Host Controller] 18:10:20,554 INFO  [org.jboss.as.domain.controller] (Host Controller Service Threads - 35) WFLYHC0019: Registered remote slave host "slave1", JBoss JBoss EAP 7.0.0.GA (WildFly 2.1.2.Final-redhat-1)
...
[Host Controller] 18:12:22,534 INFO  [org.jboss.as.domain.controller] (Host Controller Service Threads - 35) WFLYHC0019: Registered remote slave host "slave2", JBoss JBoss EAP 7.0.0.GA (WildFly 2.1.2.Final-redhat-1)

Connect to the domain created:

Using Command Line Interface:

[jboss@vmjboss ~]$ $JBOSS_HOME/bin/jboss-cli.sh -c --controller=vmjboss:9990
[domain@vmjboss:9990 /] 

Using the console, url : http://vmjboss:9990/console

As you can see, some servers (and groups) have been created by default. This should be cleaned to create wanted servers and groups. This will be the topic of my next blog, see you there 😉

L’article JBoss EAP 7 – Domain creation est apparu en premier sur dbi Blog.

First of all, you have to install JBoss, I installed the JBoss EAP 7.0.0 on /opt/JBoss-eap-7.

In the JBoss home directory there is a standalone folder, which is the default standalone instance location. So, the below command will start a default standalone instance with a default profile (standalone.xml):

/opt/install/jboss-eap-7/bin/standalone.sh

Don’t execute it, to keep the default folder as it is for future usage.

Scenario 1: Two Standalone instances on one VM

We will create two copies of standalone folder and rename them as node1 and node2 as shown below:

cp -rp /opt/install/jboss-eap-7/standalone /opt/install/node1
cp -rp /opt/install/jboss-eap-7/standalone /opt/install/node2

It is recommended to put instance folder outside the JBoss home directory.

Below commands will start both JBoss nodes in a cluster:

/opt/install/jboss-eap-7/bin/standalone.sh -c standalone-ha.xml -Djboss.server.base.dir=/opt/install/node1 -Djboss.bind.address=vmtestjboss -Djboss.bind.address.management=vmtestjboss -Djboss.node.name=node1 -Djboss.socket.binding.port-offset=1

/opt/install/jboss-eap-7/bin/standalone.sh -c standalone-ha.xml -Djboss.server.base.dir=/opt/install/node2 -Djboss.bind.address=vmtestjboss -Djboss.bind.address.management=vmtestjboss -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=2

Where:
-c : is for server configuration file to be used, it could be –server-config
-Djboss.bind.address and -Djboss.bind.address.management : are for binding address
-Djboss.server.base.dir : is for the path from where node is present
-Djboss.node.name : is the name of the node – should be different for both nodes
-Djboss.socket.binding.port-offset : is for the port offset foe each node, it should be different for both nodes because they are running on the same host.

We keep the default value of jboss.default.multicast.address (230.0.0.4), change it if you want to have multiple clusters on the same network.

Once both nodes come up properly you would not see in the log any information saying that they are in a cluster until you deploy a clustered application, but what is a clustered application?
In fact, to take advantage of the high availability features of clustered JBoss instances, an application first has to be marked as being distributable. To do so, include the distributabletag in the web.xml, as shown below:

<?xml version="1.0"?>
    <web-app ...>
        <distributable/>
    </web-app>
...

To deploy the application on both instances, use the Command Line Interface (CLI):
For node 1:
Use the port 9991, which is = DEFAULT MANAGEMENT HTTP PORT (9990) + PORT OFFSET (1).

[jboss@vmtestjboss ~]$ /opt/install/jboss-eap-7/bin/jboss-cli.sh -c --controller=vmtestjboss:9991
[standalone@vmtestjboss:9991 /] deploy /opt/install2/cluster.war

Then check the log and notice the below line:

20:48:59,638 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000094: Received new cluster view for channel server: [node1|0] (1) [node1]

For node 2:
Use the port 9992, which is = DEFAULT MANAGEMENT HTTP PORT (9990) + PORT OFFSET (2).

[jboss@vmtestjboss ~]$ /opt/install/jboss-eap-7/bin/jboss-cli.sh -c --controller=vmtestjboss:9992
[standalone@vmtestjboss:9992 /] deploy /opt/install2/cluster.war

Then check the log and notice the below line:

20:49:59,524 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000094: Received new cluster view for channel ejb: [node1|1] (2) [node1, node2]

The application deployed is clustered now.

Scenario 2: Two Standalone instances on two VMs

Here I have two VMs (vmtestjboss01 and vmtestjboss02), when JBoss EAP 7 is installed on both VMs, create just a single copies of standalone folder in respective VMs then start the instance:
– On vmtestjboss01:

cp -rp /opt/install/jboss-eap-7/standalone /opt/install/node1

/opt/install/jboss-eap-7/bin/standalone.sh -c standalone-ha.xml -Djboss.server.base.dir=/opt/install/node1 -Djboss.bind.address=vmtestjboss01 -Djboss.bind.address.management=vmtestjboss01 -Djboss.node.name=node1 -Djboss.default.multicast.address=230.0.0.5

– On vmtestjboss02:

cp -rp /opt/install/jboss-eap-7/standalone /opt/install/node2

/opt/install/jboss-eap-7/bin/standalone.sh -c standalone-ha.xml -Djboss.server.base.dir=/opt/install/node2 -Djboss.bind.address=vmtestjboss02 -Djboss.bind.address.management=vmtestjboss02 -Djboss.node.name=node2 -Djboss.default.multicast.address=230.0.0.5

-Djboss.socket.binding.port-offset is not needed here because we are working on two VMs, so we will not have port conflict.
-Djboss.default.multicast.address is specified here because I want to isolate this cluster from the one already configured by default (230.0.0.4)

Deploy the clustered application as explained in the first scenario.

When you have JBoss running on two separate machines, you will see the join indications on both machines so you know they are talking. But going to http://vmtestjboss01:8080/cluster and http://vmtestjboss02:8080/cluster shows no indication of session replication between the two machines. It seems like they are completely separate, whereas when you run two nodes both on the same machine it works very well. This will be explained and solved in a next blog related to session replication.

Don’t hesitate to share your experience with JBoss clusters on standalone instances!

L’article JBoss EAP 7 – Cluster in Standalone mode est apparu en premier sur dbi Blog.

Unfortunately for us, the D2 JMS logs are using DEBUG by default for everything so it might represent some big files at the end of the day as soon as you start working more than XXX concurrent users. Worse than that, the D2 JMS logs, which are in DEBUG, are considered as INFO from the JBoss point of view and therefore, if you are using JBoss with INFO log level, it will print all the DEBUG information from the D2 JMS logs. Of course you could still set the JBoss level to WARN so it would remove all the DEBUG but in this case, you will also be missing the INFO from the JBoss as well as the D2 JMS sides which might include some pretty important information like for example the assurance that the D2.Lockbox can be read properly (no problems with the passwords and/or fingerprint).

So what to do about it? Well there is a JVM parameter that can actually be used to force the JBoss Server to read and use a specific logback.xml file. For that, simply update the startMethodServer.sh script as done below. I will use the logback.xml file that is present by default right under ServerApps.ear and that I will customize to get the best out of it.

First of all, I’m updating the content to add some things. Here is a template for this file:

[dmadmin@content_server_01 ~]$ cd $DOCUMENTUM_SHARED/wildfly9.0.1/server/
[dmadmin@content_server_01 server]$ logback_file="$DOCUMENTUM_SHARED/wildfly9.0.1/server/DctmServer_MethodServer/deployments/ServerApps.ear/logback.xml"
[dmadmin@content_server_01 server]$ 
[dmadmin@content_server_01 server]$ # Here I'm updating the content of the default file to add custom patterns, log level, console output, aso...
[dmadmin@content_server_01 server]$ vi ${logback_file}
[dmadmin@content_server_01 server]$ 
[dmadmin@content_server_01 server]$ cat ${logback_file}
<?xml version="1.0" encoding="UTF-8"?>

<configuration scan="true" scanPeriod="60 seconds">

  <appender class="ch.qos.logback.core.rolling.RollingFileAppender" name="RootFileAppender">
    <file>/tmp/D2-JMS.log</file>
    <append>true</append>
    <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
      <level>debug</level>
    </filter>
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
      <fileNamePattern>/tmp/D2-JMS-%d{yyyy-MM-dd}.log.zip</fileNamePattern>
      <MaxHistory>5</MaxHistory>
    </rollingPolicy>
    <layout class="ch.qos.logback.classic.PatternLayout">
      <pattern>%d{"yyyy-MM-dd HH:mm:ss,SSS z"} [%-5p] (%t) - %-45(%C{44}) : %m%n</pattern>
    </layout>
  </appender>

  <appender class="ch.qos.logback.core.ConsoleAppender" name="RootConsoleAppender">
    <layout>
      <pattern>[%-5p] - %-45(%C{44}) : %m%n</pattern>
    </layout>
  </appender>

  <root>
    <level value="${logLevel:-info}"/>
    <appender-ref ref="RootFileAppender"/>
    <appender-ref ref="RootConsoleAppender"/>
  </root>

</configuration>
[dmadmin@content_server_01 server]$

Then once you have your template logback.xml file, you need to force JBoss to load and use it otherwise it will just be ignored. As mentioned above, here is the JVM parameter to be added:

[dmadmin@content_server_01 server]$ 
[dmadmin@content_server_01 server]$ grep "JAVA_OPTS=" startMethodServer.sh
JAVA_OPTS="$USER_MEM_ARGS -Djboss.server.base.dir=$JBOSS_BASE_DIR -Dorg.apache.coyote.http11.Http11Protocol.SERVER=MethodServer"
[dmadmin@content_server_01 server]$ 
[dmadmin@content_server_01 server]$ sed -i 's,^JAVA_OPTS="[^"]*,& -Dlogback.configurationFile=$JBOSS_BASE_DIR/deployments/ServerApps.ear/logback.xml,' startMethodServer.sh
[dmadmin@content_server_01 server]$ 
[dmadmin@content_server_01 server]$ grep "JAVA_OPTS=" startMethodServer.sh
JAVA_OPTS="$USER_MEM_ARGS -Djboss.server.base.dir=$JBOSS_BASE_DIR -Dorg.apache.coyote.http11.Http11Protocol.SERVER=MethodServer -Dlogback.configurationFile=$JBOSS_BASE_DIR/deployments/ServerApps.ear/logback.xml"
[dmadmin@content_server_01 server]$

Once done, you can customize some values like the path and name of the log file, the number of files to keep, the log level you want to use, aso. Here are some commands to do just that:

[dmadmin@content_server_01 server]$ 
[dmadmin@content_server_01 server]$ d2_log="$DOCUMENTUM_SHARED/wildfly9.0.1/server/DctmServer_MethodServer/logs/D2-JMS.log"
[dmadmin@content_server_01 server]$ 
[dmadmin@content_server_01 server]$ # Commands to update some values on this pattern file using the ${d2_log} variable
[dmadmin@content_server_01 server]$ sed -i "s,<file>.*</file>,<file>${d2_log}</file>," ${logback_file}
[dmadmin@content_server_01 server]$ sed -i "s,<fileNamePattern>.*</fileNamePattern>,<fileNamePattern>${d2_log}-%d{yyyy-MM-dd}.zip</fileNamePattern>," ${logback_file}
[dmadmin@content_server_01 server]$ sed -i "s,<MaxHistory>.*</MaxHistory>,<MaxHistory>180</MaxHistory>," ${logback_file}
[dmadmin@content_server_01 server]$ sed -i "s,<level>.*</level>,<level>info</level>," ${logback_file}
[dmadmin@content_server_01 server]$

With the above done, you can just restart the JMS and afterwards, you will have a new file created D2-JMS.log at the location specified and with the log level specified.

[dmadmin@content_server_01 server]$ $JMS_HOME/server/stopMethodServer.sh
{"outcome" => "success"}
[dmadmin@content_server_01 server]$
[dmadmin@content_server_01 server]$
[dmadmin@content_server_01 server]$
[dmadmin@content_server_01 server]$ $JMS_HOME/server/startJMS.sh
Starting the JMS...
The JMS process has been started.
[dmadmin@content_server_01 server]$ sleep 30
[dmadmin@content_server_01 server]$ 
[dmadmin@content_server_01 server]$ cat ${d2_log}
2018-06-16 17:16:48,652 UTC [INFO ] (default task-6) - com.emc.d2.api.methods.D2Method               : D2Method Main method com.emc.d2.api.methods.D2SubscriptionMethod arguments: {-user_name=dmadmin, -method_trace_level=0, -dcbase_name=Repo1.Repo1, -class_name=com.emc.d2.api.methods.D2SubscriptionMethod, -job_id=080f123450001612}
2018-06-16 17:16:49,668 UTC [INFO ] (default task-6) - com.emc.d2.api.methods.D2Method               : ==== START ======================================================================
2018-06-16 17:16:49,670 UTC [INFO ] (default task-6) - com.emc.d2.api.methods.D2Method               : D2-API v4.7.0070 build 186
2018-06-16 17:16:49,674 UTC [INFO ] (default task-6) - com.emc.d2.api.methods.D2Method               : DFC version : 7.3.0040.0025
2018-06-16 17:16:49,675 UTC [INFO ] (default task-6) - com.emc.d2.api.methods.D2Method               : file.encoding : ANSI_X3.4-1968
2018-06-16 17:16:49,676 UTC [INFO ] (default task-6) - com.emc.d2.api.methods.D2Method               : Arguments : {-user_name=dmadmin, -method_trace_level=0, -docbase_name=Repo1.Repo1, -class_name=com.emc.d2.api.methods.2SubscriptionMethod, -job_id=080f123450001612}
[dmadmin@content_server_01 server]$

Here you have a working D2-JMS.log file with INFO only information and no DEBUG.

Some tips regarding the logback.xml configuration (I put an example of each in the template configuration file above):

• If you want to display the full date, time (with milliseconds) and timezone in the logs, you will need to add quotes like that: <pattern>%d{“yyyy-MM-dd HH:mm:ss,SSS z”} …</pattern>. This is simply because the comma (,) is used normally to separate the timeformat from the timezone you want to display the logs on (E.g.: %d{HH:mm:ss.SSS, UTC}) but it won’t display the timezone on the logs, in this case. So you if want the seconds to be separated from the milliseconds using a comma, you need to quote the whole string. If you want the current timezone to be displayed on the logs, you can usually do it using the “z” (with not too old Java versions)
• By default, you cannot use parentheses in the pattern to enclose parameters (like “%-5p”, “%t”, aso…). This is because parentheses are used to group parameters together to apply formatting to them as part of a group. If you really want to use parentheses on the output, then you have to escape them
• You can define the minimum length of a specific pattern parameter using the “%-X” where X is the number of characters. Using that, you can align the logs as you want (E.g.: “%-5p” for the log level in 5 chars => “DEBUG”, “INFO “, “WARN “, “ERROR”)
• You can also shorten a specific pattern parameter using {X} where X is again the number of characters you would want the output string to be reduced to. It is not an exact value but the logger will do its best to reduce the length to what you want.
• You can use different appenders to redirect the logs to different outputs. Usually you will want a file appender to store everything in a file but you can also add a console appender so it gets stored in your default console output (be it your shell, a nohup file or the server.log). If you do not want the console appender so it gets stored only on the D2-JMS.log file, you can just comment the line ‘<appender-ref ref=”RootConsoleAppender”/>’

You might be wondering why this JVM parameter is not added by default by the Documentum installer since it is a valid solution for this issue, right? Well, I would simply reply that it’s Documentum.

L’article Documentum – How to really configure the D2 JMS logs starting with JBoss/WildFly est apparu en premier sur dbi Blog.

The steps are exactly the same for all JBoss instances, it’s just a matter of checking/updating the right file. In this blog, I will still separate the steps for JMS and IndexAgents but that’s because I usually have more than one IndexAgent on the same FT and therefore I’m also providing a way to update all JBoss instances at the same time using the right commands.

As always, I will define an environment variable to store the password to avoid using clear text passwords in the shell. The generic steps to change a JBoss Admin password, in Documentum, are pretty simple:

1. Store the password in a variable
2. Encrypt the password
3. Backup the old configuration file
4. Replace the password file with the new encrypted password
5. Restart the component
6. Checking the connection with the new password

As you can see above, there is actually nothing in these steps to change the password… We are just replacing a string inside a file with another string and that’s done, the password is changed! That’s really simple but that’s also a security issue since you do NOT need to know the old password… That’s how Documentum works with JBoss…

I. JMS JBoss Admin

For the JMS JBoss Admin, you obviously need to connect to all Content Servers and then perform the steps. Below are the commands I use to set the variable, encrypt the password and the update the password file with the new encrypted password (I’m just overwriting it):

[dmadmin@content_server_01 ~]$ read -s -p "Please enter the NEW JBoss admin password: " jboss_admin_pw; echo
Please enter the NEW JBoss admin password:
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ $JAVA_HOME/bin/java -cp "$DOCUMENTUM_SHARED/dfc/dfc.jar" com.documentum.fc.tools.RegistryPasswordUtils ${jboss_admin_pw}
AAAAENwH4N2fF92dfRajKzaARvrfnIG29fnqf8Kgnd2fWfYKmMd9x
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ cd $DOCUMENTUM_SHARED/jboss7.1.1/server/DctmServer_MethodServer/configuration/
[dmadmin@content_server_01 ~]$ mv dctm-users.properties dctm-users.properties_bck_$(date "+%Y%m%d")
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ echo "# users.properties file to use with UsersRolesLoginModule" > dctm-users.properties
[dmadmin@content_server_01 ~]$ echo "admin=AAAAENwH4N2fF92dfRajKzaARvrfnIG29fnqf8Kgnd2fWfYKmMd9x" >> dctm-users.properties
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ cat dctm-users.properties
# users.properties file to use with UsersRolesLoginModule
admin=AAAAENwH4N2fF92dfRajKzaARvrfnIG29fnqf8Kgnd2fWfYKmMd9x
[dmadmin@content_server_01 ~]$

At this point, the new password has been put in the file dctm-users.properties in its encrypted form so you can now restart the component and check the status of the JBoss Application Server. To check that, I will use below a small curl command which is really useful… If just like me you always restrict the JBoss Administration Console to 127.0.0.1 (localhost only), for security reasons, then this is really awesome since you don’t need to start a X server and you don’t need to start a browser and all this stuff, simply put the password when asked and voila!

[dmadmin@content_server_01 ~]$ cd $DOCUMENTUM_SHARED/jboss7.1.1/server
[dmadmin@content_server_01 ~]$ ./stopMethodServer.sh
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ nohup ./startMethodServer.sh >> nohup-JMS.out 2>&1 &
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ sleep 30
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ curl -g --user admin -D - http://localhost:9085/management --header "Content-Type: application/json" -d '{"operation":"read-attribute","name":"server-state","json.pretty":1}'
Enter host password for user 'admin':
HTTP/1.1 200 OK
Transfer-encoding: chunked
Content-type: application/json
Date: Sat, 15 Jul 2017 11:16:51 GMT

{
    "outcome" : "success",
    "result" : "running"
}
[dmadmin@content_server_01 ~]$

If everything has been done properly, you should get a “HTTP/1.1 200 OK” status meaning that the JBoss Application Server is up & running and the “result” should be “running”. This proves that the password provided in the command match the encrypted one from the file dctm-users.properties because the JMS is able to answer your request.

II. IndexAgent JBoss Admin

For the IndexAgent JBoss Admin, you obviously need to connect to all Full Text Servers and then perform the steps again. Below are the commands to do that. These commands are adapted in case you have several IndexAgents installed. Please note that the commands below will set the same Admin password for all JBoss instances (all IndexAgents JBoss Admin). Therefore, if that’s not what you want, you will have to take the commands from the JMS section but adapt the paths.

[xplore@full_text_server_01 ~]$ read -s -p "Please enter the NEW JBoss admin password: " jboss_admin_pw; echo
Please enter the NEW JBoss admin password:
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ $JAVA_HOME/bin/java -cp "$XPLORE_HOME/dfc/dfc.jar" com.documentum.fc.tools.RegistryPasswordUtils ${jboss_admin_pw}
AAAAENwH4N2cI25WmDdgRzaARvcIvF3g5gR8Kgnd2fWfYKmMd9x
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ cd $XPLORE_HOME/jboss7.1.1/server/
[xplore@full_text_server_01 ~]$ for i in `ls -d DctmServer_Indexag*`; do mv ./$i/configuration/dctm-users.properties ./$i/configuration/dctm-users.properties_bck_$(date "+%Y%m%d"); done
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ for i in `ls -d DctmServer_Indexag*`; do echo "# users.properties file to use with UsersRolesLoginModule" > ./$i/configuration/dctm-users.properties; done
[xplore@full_text_server_01 ~]$ for i in `ls -d DctmServer_Indexag*`; do echo "AAAAENwH4N2cI25WmDdgRzaARvcIvF3g5gR8Kgnd2fWfYKmMd9x" >> ./$i/configuration/dctm-users.properties; done
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ for i in `ls -d DctmServer_Indexag*`; do echo "--$i:"; cat ./$i/configuration/dctm-users.properties; echo; done
--DctmServer_Indexagent_DocBase1:
# users.properties file to use with UsersRolesLoginModule
AAAAENwH4N2cI25WmDdgRzaARvcIvF3g5gR8Kgnd2fWfYKmMd9x

--DctmServer_Indexagent_DocBase2:
# users.properties file to use with UsersRolesLoginModule
AAAAENwH4N2cI25WmDdgRzaARvcIvF3g5gR8Kgnd2fWfYKmMd9x

--DctmServer_Indexagent_DocBase3:
# users.properties file to use with UsersRolesLoginModule
AAAAENwH4N2cI25WmDdgRzaARvcIvF3g5gR8Kgnd2fWfYKmMd9x

[xplore@full_text_server_01 ~]$

At this point, the new password has been put in its encrypted form in the file dctm-users.properties for each IndexAgent. So, the next step is to restart all the components and check the status of the JBoss instances. Just like for the JMS, I will use below the curl command to check the status of a specific IndexAgent:

[xplore@full_text_server_01 ~]$ for i in `ls stopIndexag*.sh`; do ./$i; done
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ for i in `ls startIndexag*.sh`; do ia=`echo $i|sed 's,start(.*).sh,1,'`; nohup ./$i >> nohup-$ia.out 2>&1 &; done
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ sleep 30
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ curl -g --user admin -D - http://localhost:9205/management --header "Content-Type: application/json" -d '{"operation":"read-attribute","name":"server-state","json.pretty":1}'
Enter host password for user 'admin':
HTTP/1.1 200 OK
Transfer-encoding: chunked
Content-type: application/json
Date: Sat, 15 Jul 2017 12:00:35 GMT

{
    "outcome" : "success",
    "result" : "running"
}
[xplore@full_text_server_01 ~]$

If you want to check all IndexAgents at once, you can use this command instead (it’s a long one I know…):

[xplore@full_text_server_01 ~]$ for i in `ls -d DctmServer_Indexag*`; do port=`grep '<socket-binding .*name="management-http"' ./$i/configuration/standalone.xml|sed 's,.*http.port:([0-9]*).*,1,'`; echo; echo "  ** Please enter below the password for '$i' ($port)"; curl -g --user admin -D - http://localhost:$port/management --header "Content-Type: application/json" -d '{"operation":"read-attribute","name":"server-state","json.pretty":1}'; done

  ** Please enter below the password for 'DctmServer_Indexagent_DocBase1' (9205)
Enter host password for user 'admin':
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: application/json; charset=utf-8
Content-Length: 55
Date: Sat, 15 Jul 2017 12:37:35 GMT

{
    "outcome" : "success",
    "result" : "running"
}
  ** Please enter below the password for 'DctmServer_Indexagent_DocBase2' (9225)
Enter host password for user 'admin':
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: application/json; charset=utf-8
Content-Length: 55
Date: Sat, 15 Jul 2017 12:37:42 GMT

{
    "outcome" : "success",
    "result" : "running"
}
  ** Please enter below the password for 'DctmServer_Indexagent_DocBase3' (9245)
Enter host password for user 'admin':
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: application/json; charset=utf-8
Content-Length: 55
Date: Sat, 15 Jul 2017 12:37:45 GMT

{
    "outcome" : "success",
    "result" : "running"
}
[xplore@full_text_server_01 ~]$

If everything has been done properly, you should get a “HTTP/1.1 200 OK” status for all IndexAgents.

L’article Documentum – Change password – 5 – CS/FT – JBoss Admin est apparu en premier sur dbi Blog.

In this blog, I will NOT talk about the Java cacerts because the commands are exactly the same as in the previous blog and they aren’t dependent on the JBoss/WildFly version. As described in the previous blog, the setup of the CPS in HTTPS isn’t described in the official EMC/OTX Documentation (yet). Because of that, I worked with EMC on defining the minimal steps that are required to get one up&running.

So in this blog and just to compare with the previous blog, I will start with setting up a JBoss 7.1.1 in SSL (without the Java cacerts stuff) without using the ConfigSSL.groovy since it’s not able to handle the CPS setup. So as before, I’m starting with defining some environment variables (I’m using the same CPS name) and then stopping the CPS:

[xplore@full_text_server_01 ~]$ cd /tmp/certs/
[xplore@full_text_server_01 certs]$ read -s -p "  ----> Please enter the JKS password: " jks_pw
[xplore@full_text_server_01 certs]$ 
[xplore@full_text_server_01 certs]$ export server_name="Node2_CPS1"
[xplore@full_text_server_01 certs]$ $JBOSS_HOME/server/stop${server_name}.sh
[xplore@full_text_server_01 certs]$ 
[xplore@full_text_server_01 certs]$ mv /tmp/certs/full_text_server_01.jks $JBOSS_HOME/server/DctmServer_${server_name}/configuration/my.keystore
[xplore@full_text_server_01 certs]$ chmod 600 $JBOSS_HOME/server/DctmServer_${server_name}/configuration/my.keystore

In this case with JBoss 7.1.1, the $JBOSS_HOME used above is “$XPLORE_HOME/jboss7.1.1”. So now the commands to configure a JBoss 7.1.1 in HTTPS are the following ones:

[xplore@full_text_server_01 certs]$ cd $JBOSS_HOME/server/DctmServer_${server_name}/configuration/
[xplore@full_text_server_01 configuration]$ cp standalone.xml standalone.xml_bck_$(date +%Y%m%d)
[xplore@full_text_server_01 configuration]$ 
[xplore@full_text_server_01 configuration]$ sed -i 's/inet-address value="${jboss.bind.address.management:[^}]*}/inet-address value="${jboss.bind.address.management:127.0.0.1}/' standalone.xml
[xplore@full_text_server_01 configuration]$ sed -i '/<subsystem .*/a             <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true">n                <ssl name="https" password="'${jks_pw}'" certificate-key-file="'$JBOSS_HOME'/server/DctmServer_'${server_name}'/configuration/my.keystore" cipher-suite="PUT_HERE_SSL_CIPHERS"/>n            </connector>' standalone.xml

And that’s all. As you can see, it’s even easier to setup a JBoss 7.1.1 in SSL that it was with a WildFly 9.0.1. This is a small description of these commands:

• Line 2: Backup of the standalone.xml file
• Line 4: Changing the default IP on which WildFly is listening for the Management Interface (by default 0.0.0.0 which means no restriction) to 127.0.0.1 so it’s only accessible locally
• Line 5: Adding a new connector specific to https and which defines the keystore path, password as well as the SSL Ciphers to be used. Just replace “PUT_HERE_SSL_CIPHERS” with a comma separated list of SSL Ciphers that you want to enable

With the above commands, both HTTP and HTTPS will be enabled. If you want to disable all HTTP communications (which I recommend), then you can just remove the http connector:

[xplore@full_text_server_01 configuration]$ sed -i '/<connector .*name="http" .*socket-binding="http"/d' standalone.xml

Alright so now JBoss 7.1.1 is setup & enabled in HTTPS only as we did for the WildFly setup. At this point, if you start the CPS again and then access the URL in HTTPS, it will work. Then what is the purpose of this blog? Well the URL will work but the issue I faced is that this CPS is actually unusable.

When you install a remote CPS, you then need to register it to the PrimaryDsearch so it can be used. If you do not register it, then it just won’t do much so it’s kind of useless. Usually when you install a remote CPS, you will want to register it in HTTP directly in the PrimaryDsearch. This is done in the following way (I’m considering a PrimaryDsearch on the same host with port 9302 in HTTPS):

1. Open the dsearchadmin (E.g.: https://full_text_server_01:9302/dsearchadmin) and login with the JBoss admin account
2. Navigate to “Home > Services > Content Processing Service”
3. Click on the “Add” button
4. Select the “remote” checkbox
5. Set the URL to: http://full_text_server_01:9400/cps/ContentProcessingService?wsdl
6. Set the Instance & Usage according to your needs
7. Click on the “OK” button

If you are using a CPS in HTTP as in the URL mentioned (step 5 – the port might change depending on what you configured), then you will see a pop-up showing that the PrimaryDsearch was able to connect to the CPS and the CPS is now registered. As a side note, for the CPS to be fully usable, you will need to restart the PrimaryDsearch so the status can be changed to green (INITIALIZED).

So what’s the difference when using a CPS in HTTPS-only? Well when you are at the step 5, you will need to use the HTTPS URL of the CPS which is therefore: https://full_text_server_01:9402/cps/ContentProcessingService?wsdl. When you click on the “OK” button at the last step (7), you will not get a pop-up saying that the PrimaryDsearch was able to connect to the CPS but instead you will see a failure message. The exact error message from the pop-up is:

Fail to connect the remote CPS at https://full_text_server_01:9402/cps/ContentProcessingService?wsdl

On this failure pop-up, there is only a OK button and when you click on it, you can see that the CPS hasn’t been registered at all. On the CPS logs, there are absolutely no information related to this issue and on the Dsearch logs, it’s not really much better: the only message that is printed is an INFO message with the following information:

2017-05-01 10:59:02,951 UTC INFO [RMI TCP Connection(5)-147.167.175.209] c.e.d.core.fulltext.indexserver.cps.CPSSubmitter - Begin to connect to CPS at (https://full_text_server_01:9402/cps/ContentProcessingService?wsdl)  with connection 16

That’s all, no errors, nothing. Of course you can enable some debug. For example you can add the “-Djavax.net.debug=ssl” inside the JAVA_OPTIONS of the PrimaryDsearch and the remote CPS, restart them both and then try again. You should be able (if you followed this blog properly) to see that the Dsearch and the CPS are exchanging properly the Hello requests but then the CPS is still not registered.

To solve this issue, there is actually just one small thing that need to be done and that’s updating the web.xml file for the CPS. You just need to add a security-constraint tag inside this file to specify that all pages are now using HTTPS:

[xplore@full_text_server_01 configuration]$ sed -i '/</web-app>/i \n    <security-constraint>n        <web-resource-collection>n            <web-resource-name>secured pages</web-resource-name>n            <url-pattern>/*</url-pattern>n        </web-resource-collection>n        <user-data-constraint>n            <transport-guarantee>CONFIDENTIAL</transport-guarantee>n        </user-data-constraint>n    </security-constraint>' ../deployments/cps.war/WEB-INF/web.xml

When this has been added, the web.xml file for the CPS should look like that:

[xplore@full_text_server_01 configuration]$ cat ../deployments/cps.war/WEB-INF/web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4"  xmlns_xsi="http://www.w3.org/2001/XMLSchema-instance" xsi_schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
        <listener>
        <listener-class>com.emc.cma.cps.management.CPSContextListener</listener-class>
    </listener>
        <listener>
        <listener-class>com.sun.xml.ws.transport.http.servlet.WSServletContextListener</listener-class>
    </listener>
    <servlet>
        <servlet-name>AgentService</servlet-name>
        <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet>
        <servlet-name>ContextRegistryService</servlet-name>
        <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet>
        <servlet-name>ContentProcessingService</servlet-name>
        <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>ContentProcessingService</servlet-name>
        <url-pattern>/ContentProcessingService</url-pattern>
    </servlet-mapping>
    <servlet-mapping>
        <servlet-name>ContextRegistryService</servlet-name>
        <url-pattern>/runtime/ContextRegistryService</url-pattern>
    </servlet-mapping>

    <security-constraint>
        <web-resource-collection>
            <web-resource-name>secured pages</web-resource-name>
            <url-pattern>/*</url-pattern>
        </web-resource-collection>
        <user-data-constraint>
            <transport-guarantee>CONFIDENTIAL</transport-guarantee>
        </user-data-constraint>
    </security-constraint>
</web-app>
[xplore@full_text_server_01 configuration]$

Then simply start/restart the remote CPS and this time, when you register it inside the PrimaryDsearch, you will get the success message!

L’article Documentum – Setup a CPS in HTTPS – Unable to register it est apparu en premier sur dbi Blog.

To be compliant with the customer’s security rule, I had to configure SSL for a JBoss application server that holds the Documentum Foundation Services (DFS). I used the following procedure:

1. Generate a keystore

Change it to a temporary location, e. g. /var/tmp/SSL:

keytool -genkey -dname "cn=dms.test.org, ou=DEV, o=NICE, l=Delemont, s=Switzerland, c=CH" -keyalg "rsa" -validity 730 -alias tomcat -keysize 2048 -keystore dfs.keystore
Enter keystore password:  xxxx
Enter key password for 
        (RETURN if same as keystore password): xxxx

Important:

• always use tomcat for the alias
• enter a validity value, otherwise it will be 90 days

Warning: Due the Bugzilla issue 38217, both keystore and key passwords have to be the same!

2. Create a Certificate request

keytool -certreq -alias tomcat -file jbossDfs.csr -keystore dfs.keystore
Enter keystore password:  xxxx
Enter key password for xxxx

3. Send the jbossDfs.csr file to the service that will signe the certificate

In our case, the customer has its own CA system and will return the signed certificate plus the trusted chain composed of root.cer and user.cer.

4. Import the certificates

Once all needed certificates are delivered, they can be imported into the keystore. Before importing the signed certificate, import the chain one.

4.1 Import the root certificate

keytool -import -alias cert1 -file root.cer -keystore dfs.keystore
Enter keystore password:  xxxx
Owner: CN=....
Issuer: CN=....
Serial number: .....
Valid from: Mon Feb 04 09:23:02 CET 2013 until: Wed Feb 04 09:33:01 CET 2037
Certificate fingerprints:
         MD5:  94:40:.....
         SHA1: D0:10:....Trust this certificate? [no]:  yes
Certificate was added to keystore

4.2 Import the user certificate

keytool -import -alias cert2 -file user.cer -keystore dfs.keystore
Enter keystore password:  xxxx
Certificate was added to keystore

4.3. Import the signed certificate

keytool -import -trustcacerts -alias tomcat -file jbossDfs.cer -keystore dfs.keystore
Enter keystore password:  xxxx
Enter key password for xxxx
Certificate reply was installed in keystore

5. Update server.xml to activate SSL

cd $DOCUMENTUM_SHARED/jboss4.2.0/server/DctmServer_MethodServer/deploy/jboss-web.deployer/

With vi update server.xml:

• uncomment the SSL definition
• set SSLEnabled from false to true
• Change the default password “changeit” to the one you used to secure the keystore password:

maxThreads="150" scheme="https" secure="true"
keystoreFile="${jboss.server.home.dir}/conf/dfs.keystore" keystorePass="xxxx"
clientAuth="false" sslProtocol="TLS" />

6. Change the server.xml permission

If groups and users can read the file, change the file permission to allow only the owner to read/write:

chmod 600 server.xml

7. Copy the keystore to the correct location

cp
/var/tmp/SSL/dfs.keystore
$DOCUMENTUM_SHARED/jboss4.2.0/server/DctmServer_MethodServer/conf/

8. Restart the JBoss server

You can check the server.log to see if everything is starting fine.

9. Test it

Perform a test using using the URL https//dms.test.org:9082/services/core/ObjectService.
The JBoss server now should be ready to manage https requests!
Please note that the client part is not covered in this post.

L’article Configuring the JBoss server to use SSL for Documentum DFS est apparu en premier sur dbi Blog.