anandraj Archive

Security Vulnerability in your WebApplication (CVE 2017-9805)

Researchers have identified a major security flaw (CVE 2017-9805) in the Apache framework (Apache Struts REST Plugin) which could allow the hackers to inject malicious code to either steal critical customer data or cause service disruption of any server running an application built using the Struts framework and using the popular REST communication plugin.

This vulnerability is designated by CVE 2017-9805.

Versions affected:  Versions released since 2008.

Fix:  Upgrade the Apache Framework to 2.3.34 and 2.5.13.

https://struts.apache.org/announce.html

Further reading:

https://lgtm.com/blog/apache_struts_CVE-2017-9805_announcement

Changing default session timeout Jboss 7

JBoss Enterprise Application Platform 6 has a default session bean timeout of 30 minutes, which is configured in standalone/configuration/standalone.xml

The default HTTP session timeout can’t be modified in EAP 6.

To override default value for your own application, follow the below approaches:

  1. Add an entry in the application web.xml file:
 <web-app>
               <session-config>
                         <session-timeout>15</session-timeout>
               </session-config>
</web-app>

 

2. Programmatically override the session timeout for a particular session.

HttpSession session = request.getSession();
session.setMaxInactiveInterval(10*30);

Note:  In older versions of Jboss Application Server ex. Version 5, it provided a provision of overriding the global session time out setting from the Jboss web.xml file under the location $JBOSS_HOME \server\default\deploy\jboss-web.deployer

 

<session-config>
      <session-timeout>30</session-timeout>
</session-config>

Further reading:

https://access.redhat.com/site/documentation/en-US/JBoss_Web_Framework_Kit/2.2/html/Seam_Reference_Guide/ch27s07.html

 

Cheers,

Wonders Team

JConsole for monitoring Weblogic Application Server 12c

Performance and high availability of production systems are critical for any business. Hence there is a plethora of monitoring tools available in the market that helps you to monitor your production systems, generate alerts, and trigger emails in down time situations. Few commercially available monitoring tools in the market are wily introscope, Appdynamics etc.

For further details on wily introscope.

http://www.numeroreal.com.br/Manuais/uploads/CA%20Wily%20Introscope.pdf

For further details on Appdynamics.

https://www.appdynamics.com/solutions/appdynamics-java-monitoring/oracle-weblogic-monitoring

Apart from commercially available monitoring tools, there are few freely available monitoring tools like jconsole, jhat, jstack and weblogic’s very own JRMC, WLDF (For performance monitoring).

This post is a sample illustration of how we can configure Jconsole with WebLogic Application Server for monitoring.

What is JConsole?

The JConsole graphical user interface is a monitoring tool that complies to the Java Management Extensions (JMX) specification. JConsole uses the extensive instrumentation of the Java Virtual Machine (Java VM) to provide information about the performance and resource consumption of applications running on the Java platform.

References:

http://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html

 

How do I configure Jconsole with weblogic application server?

Local server monitoring:

  1. Set the classpath by running setDomainEmv.cmd from <WLS_DOMAIN_HOME>\bin
  2. Start Jconsole.exe  ( Alternatively you can execute it from from the default java location :  C:\Program Files\Java\jdk1.6.0_45\bin\)
  3. Select the Weblogic Server instance from the local process list.

 

Jconsole Weblogic Application Server 1

Jconsole Weblogic Application Server 1

4: Monitor the server nitty-gritty details:

Jconsole Weblogic Application server 2

Jconsole Weblogic Application server 2

 

 

Remote Server Monitoring using JConsole:

  1. Update the setDomainEnv.cmd  with the below parameters in the JAVA_OPTIONS and restart the Weblogic Server

For non- authenticated user and non – ssl mechanism:

-Dcom.sun.management.jmxremote

-Dcom.sun.management.jmxremote.port=9001

-Dcom.sun.management.jmxremote.ssl=false

-Dcom.sun.management.jmxremote.authenticate=false

 

For authenticated SSL mechanism:

-Dcom.sun.management.jmxremote.ssl=true

-Dcom.sun.management.jmxremote.password.file=jmxremote.password

-Djavax.net.ssl.keyStore=/home/user/.keystore

-Djavax.net.ssl.keyStorePassword=myKeyStorePassword

-Dcom.sun.management.jmxremote.ssl.need.client.auth=true

-Djavax.net.ssl.trustStore=/home/user/.truststore

-Djavax.net.ssl.trustStorePassword=myTrustStorePassword

-Dcom.sun.management.jmxremote.registry.ssl=true

2. Set the classpath and start JConsole

jconsole -Djava.class.path=$JAVA_HOME/lib/jconsole.jar:$JAVA_HOME/lib/tools.jar:</code> <code>$WLS_HOME/server/lib/wlfulclient.jar -Djmx.remote.protocol.provider.pkgs=weblogic.management.remote -debug

3. Connect using hostname and port

Jconsole-RemoteProcess1

You will have access to all the details of the remote JVM

For accessing only the MBeans:

If you want to connect only to the JMX MBeans follow the below steps:

1. Login into the Weblogic Admin Console and navigate to the server that needs to be monitored, set the username / password for the IIOP protocols.

Jconsole-RemoteProcess-Mbean1

Jconsole-RemoteProcess-Mbean2

Note: Restart the designated server

2.       Set the classpath and start JConsole.

jconsole -Djava.class.path=$JAVA_HOME/lib/jconsole.jar:$JAVA_HOME/lib/tools.jar: $WLS_HOME/server/lib/wlfulclient.jar -Djmx.remote.protocol.provider.pkgs=weblogic.management.remote -debug

3.       Connect to the server Mbeans using the service URL as below:

service:jmx:rmi:///jndi/iiop://<Hostname>:7001/weblogic.management.mbeanservers.domainruntime

Jconsole-RemoteProcess-Mbean4

 

Note: You would not see other JVM details but only the domain runtime MBeans

Further reading:

http://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html

http://db.apache.org/derby/docs/10.10/adminguide/radminjmxenablepwdssl.html

https://blogs.oracle.com/WebLogicServer/entry/managing_weblogic_servers_with


Common Exceptions:

1. java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.NameNotFoundException [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]

Possible solutions:

Make sure the JMX Service url is correct and the JNDI value is properly mentioned.

2. org.omg.CORBA.NO_PERMISSION:   vmcid: 0x0  minor code: 0  completed: No

Possible solutions:

The server failed to authenticate the IIOP client or the server port is not defined properly.

Change the default IIOP username / password for the weblogic server.

 

Cheers,

Wonders Team.

Auto Deployment and Hot Deployment

Auto Deployment:  

Features provided by the Application Servers in which applications can be automatically deployed / undeployed on to the server. The App Server provides a mechanism where they scan certain folders for the applications for ex. autoDeploy folder in weblogic, deploy folder in tomcat / Jboss etc.

Hot deployment:

The process of adding new components (such as WAR files, EJB Jar files, enterprise Java beans, servlets, and JSP files) to a running server without having to stop the application server process and start it again.  

Hot deployment is mainly used to update the individual modules or jsps/servlets/classes in a module without redeploying the complete app.

Auto Deployments of Web Applications in WebLogic Server:

This is the simplest form of deployment. When enabled the Admin Server periodically scans the autoDeploy folder and deploy all the applications present in there.

Note: This feature is disabled in the production mode.

Production mode of the application server can be changed using the handle –Dweblogic.ProductionModeEnabled=true in the server startup file.

Need of Auto Deployment:

This is a very quick way of deploying the application which can be using during development and unit testing phase to reduce the deployment time.

How to auto Deploy:

1. Start the WebLogic Server domain in development mode.

2. Place the application’s exploded directory structure or archive file in this autodeploy directory.

It is present under $DOMAIN_HOME folder structure.

Hot Deployment (Redeployment Strategies) in Weblogic server:

This can be achieved by using different Redeployment Strategies.

Production Redeployment:  

Production redeployment strategy involves deploying a new version of an updated application alongside an older version of the same application. WebLogic Server automatically manages client connections so that only new client requests are directed to the new version. Clients already connected to the application during the redeployment continue to use the older version of the application until they complete their work, at which point WebLogic Server automatically retires the older application.

In-Place Redeployment:

In-place redeployment immediately replaces a running application’s deployment files with updated deployment files. In contrast to production redeployment, in-place redeployment of an application or stand-alone J2EE module does not guarantee uninterrupted service to the application’s clients. This is because WebLogic Server immediately removes the running classloader for the application and replaces it with a new classloader that loads the updated application class files.

Partial Redeployment of Static Files:

WebLogic Server enables you to redeploy selected files in a running application, rather than the entire application at once. This feature is generally used to update static files in a running Web application, such as graphics, static HTML pages, and JSPs. Partial redeployment is available only for applications that are deployed using an exploded archive directory.

Partial Redeployment of J2EE Modules :

Partial redeployment also enables you to redeploy a single module or subset of modules in a deployed Enterprise Application. Again, partial deployment is supported only for applications that are deployed using an exploded archive directory.

Further reading.

http://docs.oracle.com/cd/E11035_01/wls100/deployment/redeploy.html

Happy Reading.

Wonders Team 🙂

JSP Precompilation in WebLogic Application Server

JSP Precompilation in WebLogic Application Server:

Performance is paramount for any production system. A few seconds saved at the bottle neck is few seconds gained in the over all performance of the system. Compilation of JSP at runtime in a production environment can infuse an overhead. Hence it is a best practice to pre compile those JSP in such scenarios.

Precompilation offers below advantages:

  1. Enhances the performance by ensuring pre compilation of all the JSPs before deployment of the application.
  2. The Syntax errors in the sciptlet codes and custom tag elements could be detected at the compile time itself rather when the end user is accessing the application.

In WebLogic Server this can be achieved by weblogic.appc tool.

Weblogic.appc:

It’s an utility that generates and compiles the classes needed to deploy EJBs and JSP to WebLogic Application Server. It provides other features like deployment descriptor validations for standards compliance at both individual module level and the application level.

Syntax:

java weblogic.appc [options] <ear, jar, or war file or directory>

 

Using weblogic.appc as ant task:

You can incorporate appc in build.xml using an ant task wlappc..

For Ex:

 <taskdef name="wlappc" classname="weblogic.ant.taskdefs.j2ee.Appc" classpathref="dev.classpath"/>

<target name="jspc-webapps">

<!-- Pre-compile webapp JSP pages to src/web/WEB-INF/classes -->

<wlappc source="${srcweb}" classpathref="dev.classpath" verbose="true">

</wlappc>

</target>

This would ensure that the appc would scan through the web application at the source location and precompile the JSPs.

Further references:

http://docs.oracle.com/cd/E11035_01/wls100/ejb/appc_ejbc.html

 

Happy Readings.  🙂

Wonders Team

Clustering in WebSphere Application Server

Clustering is a very critical aspect of any middleware enterprise application. It provides capabilities of high availability by providing fail over and load balancing mechanism.

This post is a sample demonstration of configuring a cluster in WebSphere Application Server Network Deployment 7.0.

Prerequisites:

Deployment Manager Profile created using profile management tools.

 

Steps:

1. Create Cluster definition.

Log into WAS Admin console — > Servers — > Clusters — > WebSphere application server clusters.

Clustering in WebSphere

Clustering in websphere

Clustering in websphere

 

2. Create cluster members.

Provide the details about the cluster members.

Clustering in WebSphere

 

Define the node on which the cluster member would reside.

Also define whether the server would be generated based on a server template.

You can add additional members to the cluster.

Clustering in WebSphere

Cluster-Complete

Once the cluster is created successfully, it would be in stopped state by default.

3. Make sure the node agent is started.

Go to System administration from left panel — > Node agents — > Check the status.

 

Clustering in WebSphere

Clustering in WebSphere

 

If the Node Agent is not  started, you can execute the below script to start the same.

WAS_HOME/profiles/YOUR_PROFILE_NAME/bin/startNode.cmd

4. Start the cluster.

 

Cluster-Start

 

Further reading:

http://pic.dhe.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.doc%2Finfo%2Fae%2Fae%2Ftrun_wlm_cluster.html

 

Some common issues while configuring a cluster in WebSphere Application Server.

Issues:

1.

Cluster member MyServer1 will not be started because the Node Agent on node Node02 is not active. Cluster members can be started individually from the cluster member collection panel.

Remedy:

Make sure you start the Node Agent.

2.

The node agent on node Node02 must be started to perform the restart operation. Node agents in stopped state cannot be started from the console.

Remedy:

You would need to start the node agent from command line as below.

WAS_HOME/profiles/YOUR_PROFILE_NAME/bin/startNode.cmd

 

3.

 

Caused by: com.ibm.websphere.management.exception.AdminException: ADMU7707E: Failed while trying to determine the Windows Service name for server: nodeagent; probable error executing WASService.exe: com.ibm.websphere.management.exception.AdminException: ADMU7709E: Unexpected exception while processing server: nodeagent; exception = java.io.IOException: Cannot run program “D:\Softwares\bin\WASService.exe”: CreateProcess error=740, The requested operation requires elevation.

 

Remedy:

Check whether the node agent service is present or not. If not create a node agent service as below.

 

WAS_HOME\bin> wasservice -add Dmgr01_NodeAgent

-servername server1 -profilePath “D:\Softwares\profiles\Dmgr01”

-wasHome “D:\Softwares” -logFile “D:\Softwares\profiles\Dmgr01\logs\nodeagent\startNode.log”

-logRoot “D:\Softwares\profiles\Dmgr01logs\nodeagent” -restart true -startType automatic

 

4.

The node LTADKAW7Node01 is not synchronized with the master configuration. This may prevent cluster member MyServer1 from starting correctly.

Remedy: Synchronize the node.

 

Cheers,

Wonders team 🙂