Friday 5 February 2016

UPGRADING AND PATCHING THE JBOSS EAP

One of the biggest advantages, besides the support for the Red Hat JBoss Enterprise Middleware are the access to continuous updates and bug fixes. In previous versions, minor patches could not be applied automatically, also updates or bug fixes had to be installed manually, by changing individual configuration files and replacing Java Archives.
Since version 6.2 the Command Line Interface of the JBoss Enterprise Application Platform (EAP) contains a command to apply minor updates and patches without changing individual files manually.

JBoss patches are released in two forms.
Asynchronous updates: one-off patches which are released outside the normal update cycle of the existing product. These may include security patches, as well as other one-off patches provided by Red Hat Global Support Services (GSS) to fix specific issues.

Planned updates: These include cumulative patches, as well as micro, minor or major upgrades of an existing product. Cumulative patches include all previously developed asynchronous updates for that version of the product.

High level  Patch installation Steps:

1. Download the patch zip file from the Customer Portal at https://access.redhat.com/downloads/
2. From the Management CLI, apply the patch with the following command including the appropriate path to the patch file:
syntax :: patch apply /path/to/downloaded-patch.zip
 3. Restart the JBoss EAP 6 server for the patch to take effect:
syntax : shutdown --restart= true

-----------------------------------------------------------------------------------------------
                                    Detailed Steps  
-----------------------------------------------------------------------------------------------

1.Check version

[domain@192.168.1.12:9999 /] version
JBoss Admin Command-line Interface
JBOSS_HOME: /u03/local/opt/jboss-eap-6.2
JBoss AS release: 7.3.0.Final-redhat-14 "Janus"
JBoss AS product: EAP 6.2.0.GA
JAVA_HOME: null
java.version: 1.7.0_75
java.vm.vendor: Oracle Corporation
java.vm.version: 24.75-b04
os.name: Linux
os.version: 2.6.18-194.el5

2. Before patching   take a snapshot: Run the take-snapshot operation to capture a copy of the current server configuration
[domain@192.168.1.12:9999 /] :take-snapshot()
{
    "outcome" => "success",
    "result" => "/u03/local/opt/jboss-eap-6.2/mydomain/master/configuration/domain_xml_history/snapshot/20160205-104031406domain.xml"
}

3.Apply a patch through CLI on master domain:

[domain@192.168.1.12:9999 /] patch --host=master apply /u03/local/opt/jboss-eap-6.2/bin/jboss-eap-6.2.4-patch.zip  --override-modules
{
    "outcome" : "success",
    "response-headers" : {
        "operation-requires-restart" : true,
        "process-state" : "restart-required"
    },
    "result"  : null,
     "server-groups"   : null
}

4.Restart the JBoss EAP 6 host/server for the patch installation to take effect.

[domain@192.168.1.12:9999 /] /host=master:shutdown(restart=true)
{"outcome" => "success"}
[domain@192.168.1.12:9999 /]

5. Apply a patch through CLI on Slave domain:

Before patching take a snapshot Run the take-snapshot operation to capture a copy of the current server configuration.

[domain@192.168.1.12:29999 /] /host=slave02:take-snapshot()
{
    "outcome" => "success",
    "result" => "/u03/local/opt/jboss-eap-6.2/mydomain/slave2/configuration/host_xml_history/snapshot/20160205-111016532host-slave.xml",
    "server-groups" => undefined
}
[domain@192.168.1.12:29999 /]

Apply a patch on Slave 
[domain@192.168.1.12:29999 /] patch --host=slave02 apply /home/jboss/Desktop/jboss-eap-6.2.4-patch.zip  --override-modules
{
    "outcome" : "success",
    "response-headers" : {
        "operation-requires-restart" : true,
        "process-state" : "restart-required"
    }
    "result"  : null,
     "server-groups"   : null
}

Restart the slave for the patch installation to take effect.

[domain@192.168.1.12:29999 /] /host=slave02:shutdown(restart=true)
{"outcome" => "success"}
[domain@192.168.1.12:29999 /]

Note: after a patch has been applied, the jars picked up at runtime are picked up from the EAP_HOME/modules/system/layer/base/.overlays/$PATCH_ID/$MODULE directory.The original files are left in EAP_HOME/modules/system/layers/base/$MODULE. The patching mechanism cripples the original jar files for security reasons. This means that if you apply a patch which updates a module, the original module's jar files are altered to be unusable. If the patch is rolled back, the original files will be reverted back to a usable state.

check version after path applied:

[domain@192.168.1.12:29999 /] version
JBoss Admin Command-line Interface
JBOSS_HOME: /u03/local/opt/jboss-eap-6.2
JBoss AS release: 7.3.4.Final-redhat-14 "Janus"
JBoss AS product:  EAP 6.2.4.GA
JAVA_HOME: null
java.version: 1.7.0_75
java.vm.vendor: Oracle Corporation
java.vm.version: 24.75-b04
os.name: Linux
os.version: 2.6.18-194.el5
[domain@192.168.1.12:29999 /]

Patch history 

You can display the information about the history of the installed patches using the patch history command. Additionally the patch info command can show you all currently installed patches.

[domain@192.168.1.12:9999 /]patch  info --host=master
{
    "outcome" : "success",
    "result" : {
        "cumulative-patch-id" : "jboss-eap-6.2.4.CP",
        "patches" : ["eap-624-bz1281945"],
        "version" : "6.2.4.GA",
        "addon" : null,
        "layer" : {"base" : {
            "cumulative-patch-id" : "layer-base-jboss-eap-6.2.4.CP",
            "patches" : ["BZ1281945"]
        }}
    }
}

This information(history) are stored in the .installation directory inside the JBOSS_HOME directory of the JBoss Application Server. Be careful manipulating this directory, because changed files and the last configuration to perform a rollback are stored in this directory. However, it is always recommendable to make a backup before applying a patch.

[jboss@middlewaretech jboss-eap-6.2]$ cd /u03/local/opt/jboss-eap-6.2/.installation
[jboss@middlewaretech .installation]$  ls -ltr
total 12
drwxr-xr-x 4 jboss dba   4096 Feb  1 16:14 layers
drwxr-xr-x 4 jboss dba   4096 Feb  1 16:14 patches
drwxr-xr-x 4 jboss dba   4096 Feb  1 16:21 identity.conf

[jboss@middlewaretech .installation]$ cd patches
[jboss@middlewaretech .installation]$ ls -l
 drwx------. 4 jboss dba   4096 Feb  1 16:21 eap-624-bz1281945
drwx------. 4 jboss dba   4096 Feb  1 16:14 jboss-eap-6.2.1.CP
drwx------. 4 jboss dba   4096 Feb  1 16:14 jboss-eap-6.2.2.CP
drwx------. 4 jboss dba   4096 Feb  1 16:14 jboss-eap-6.2.3.CP
drwx------. 4 jboss dba   4096 Feb  1 16:14 jboss-eap-6.2.4.CP

Rollback the patches:

1. From the Management CLI, use the patch info command to find the ID of the patch that is to be rolled back.
  • For cumulative patches, the patch ID is the value of the first cumulative-patch-id shown in the patch info output.
  • Individual security or bug fix patch ID's are listed as the value of the first patches shown in the patch  info output, with the most recently applied individual patch listed first.

2. From the Management CLI, rollback the patch with the appropriate patch ID from the previous step.
syntax : patch rollback --patch-id = PATCH_ID  --host=master  --reset-configuration= TRUE  --override-all

3. Restart the JBoss EAP 6 server for the patch rollback to take effect:

-----------------------------------------------------------------------------------------------
                                    Detailed Steps  
-----------------------------------------------------------------------------------------------
Run the rollback command:

[domain@10.128.157.7:9999 /] patch rollback --patch-id=jboss-eap-6.2.4.CP --host=master --reset-configuration=true  --override-all
{
    "outcome" : "success",
    "response-headers" : {
        "operation-requires-restart" : true,
        "process-state" : "restart-required"
    }
}

When the patch is roll backed, the application server/host requires a restart, also executable with the CLI.
[domain@192.168.1.12:9999 /] /host=master:shutdown(restart=true)
{"outcome" => "success"}
[domain@192.168.1.12:9999 /]






Tuesday 2 February 2016

Configuring Apache in front of JBoss Application Server Using mod_jk

This article provides a step by step guide on configuring Apache HTTP server as the Web server in front of the JBoss application server.

Apache servers balances the load among the JBoss applications servers via the mod_jk connector. The Jboss servers are configured in a cluster and hence when a server goes down, the subsequent user requests can be forwarded to a different server.

Why to Configure Apache HTTP server in front of JBoss Application Server?
  • Application servers are good at hosting Web applications, but they are not as good when it comes to serving static content, providing load balancing, URL rewriting, security etc. Following are some of the advantages of using Apache HTTP web server in front of an application server such as JBoss.
  • Apache is a high performance and highly secure Web server with advanced features
  • Apache comes with a lot of extension modules providing essential hosting features such as logging, virtual hosting, URL rewriting etc.
  • Apache can be used as a load balancer distributing load across multiple JBoss instances. Mod_jk connector supports advanced load balancing configurations.
  • A single Apache server instance can serve multiple domains using virtual hosting and at the same time they can all be serviced by different JBoss servers. This ensures process isolation for web applications hosted in each domain.
Apache to JBoss Request Routing – How It Works?

There are two different ways of configuring Apache to JBoss routing. One is to use the Tomcat connector available for Apache called the mod_jk connector. This is an Apache module specifically written by Tomcat team. This module routes the Apache to JBoss request via the AJP (Apache Jserv Protocol).

Second method is to use an Apache module called mod_proxy. This proxy can either use HTTP or AJP for routing request from Apache to JBoss. The advantage of mod_proxy is that it is available as a built in module in Apache 2.x versions.

When it comes to load balancing and failure detection, mod_jk is better than mod_proxy. The only disadvantage is the need to separately deploy  mod_jk module.

In either case, if the Apache connector is using AJP protocol, the AJP protocol listener must be enabled on the JBoss server. By default JBoss binds AJP service to the port 8009. Whenever a request is received by Apache, it looks at the AJP module configuration file(workers.properties) and if the request is intended for the JBoss server, the request is routed through AJP protocol to the port 8009(Please see the diagram above).


Configuring Apache to JBoss HTTP Request Routing Using Mod_Jk
  • The mod_jk HTTP connector has a single component, the mod_jk.so module loaded by the web server. This module receives client requests and forwards them to the container, in this case JBoss EAP 6. JBoss EAP 6 must also be configured to accept these requests and send replies back to the web server.
  • In order for JBoss EAP 6 to be able to communicate with the Apache HTTP server, it must have the AJP/1.3 connector enabled
  • In a managed domain, in server groups using the ha and full-ha profiles, and the ha or full-ha socket binding group. The other-server-group server group is configured correctly in a default installation.
  • In a standalone server, the standalone-ha and standalone-full-ha profiles are configured for clustered configurations.

To configure mod_jk integration, Download tomcat-connectors from the Tomcat site. 

[jboss@middlewaretech mod_jk]$ tar -zxvf tomcat-connectors-1.2.32-src.tar.gz
[jboss@middlewaretech mod_jk]$ cd tomcat-connectors-1.2.32-src/native/
[jboss@middlewaretech native]$ ./configure --with-apxs=/u03/local/opt/httpd-2.2.31/bin/apxs --enable-api-compatibility

Here /u03/local/opt/httpd-2.2.31/ is HTTP_HOME directory

[jboss@middlewaretech native]$ make
[jboss@middlewaretech native]$ make install


after completed this activity you will get mod_jk.so file in /u03/local/opt/httpd-2.2.31/modules/mod_jk.so

[jboss@middlewaretech modules]$cd /u03/local/opt/httpd-2.2.31/modules

[jboss@middlewaretech modules]$ ls -ltr
-rwxrwxr-x 1 jboss dba 878259 Feb  2 02:35 mod_jk.so

 if get it , going well
Installation part has been completed, let's start configuration part

Now create a new file named mod-jk.conf inside apache/conf folder. Add the following content to this file. 

LoadModule jk_module /u03/local/opt/httpd-2.2.31/modules/mod_jk.so
JkWorkersFile conf/workers.properties
JkShmFile logs/mod_jk.shm
JkLogFile logs/mod_jk.log
JkLogLevel info
JkMount /app/* server1
JkMount /app/* server2

The directive JkMount here ensures that all HTTP requests with context /app/ are forwarded to the server1 & server2 application server configured in workers.properties (see below).
Open httpd.conf in apache/conf folder and add the following line at the end of the file. This enables the mod-jk.conf file as an extension to the default configuration file.

Include conf/mod-jk.conf

Create a new file workers.properties inside apache/conf folder. Add the following content to the file. Note that the name of the JBoss node (server1, server2) corresponds to the JkMount configuration in mod-jk.conf file. The host in this case is given as 192.168.1.12 since I have the JBoss running on the same machine. In actual deployments replace 192.168.1.12 with the ip address/host name of the JBoss machine.

worker.list=server1,server2

# Define server1
# modify the host as your port & host IP or DNS name.
worker.server1.port=8089
worker.server1.host=192.168.1.12
worker.server1.type=ajp13

# Define server2
# modify the host as your  port & host IP or DNS name.
worker.server2.port=8039
worker.server2.host=192.168.1.12
worker.server2.type=ajp13

The above configuration indicates that there are two application server machine available for handling requests in the 192.168.1.12 and it is available through AJP protocol via port 8089 & 8039.
Restart apache and JBoss and access your Web application through Apache server using this 
URL – http:// 192.168.1.12:80/app.