Disable Global Security in WebSphere Application Server

Had to do this at a customer location today, because their security group had an issue defining the cell’s security certificates. Personally, I’ve also had to do this because I brought up old cells I couldn’t remember the passwords too, or took over work for colleagues who didn’t leave very detailed notes at all.

If you need to disable security to regain access or control over your WebSphere cell, you can do this on the WSAdmin command line (where $USER_INSTALL_ROOT is the path to your deployment manager profile)

$USER_INSTALL_ROOT/bin/wsadmin.sh -conntype NONE
wsadmin> securityoff wsadmin> $AdminConfig save

Once you’ve done that, start (or restart) your DeploymentManager, and confirm you can log into the Integrated Solutions Console without a password (you’ll be prompted for a username still, enter anything or simply leave it blank).

Then, manually sync your nodes. To do that, for each node: shut down the node agent and any servers running on that node. Then execute (where $USER_INSTALL_ROOT is the path to your node profile)

$USER_INSTALL_ROOT/bin/syncNode.sh dmgr_host dmgr_soap_port

Your cell is now running without global or application security. Any applications which rely on application security may not function properly until you reenable security – but this will allow you to regain access to the cell and configure as needed.

Scripted EAR Deployment for WebSphere Application Server

IBM WebSphere provides a lot of great scripting support, which is an absolute necessity in today’s agile world. If your shop requires automated build, deployment, and testing of your JEE applications, you’ll want to make the most out of it and automate deployment to WebSphere Application Server so your testing is done on the same platform as your production hosting.

Today I’ll show you two ways to automate deployment: first, using an Ant script to deploy to a single-server — perfect for deploying to WAS For Developers on your development workstation; second, using a wsadmin jython script to deploy to a server cluster — for moving your applications into your QA and Production environments.

(Side Note — you are taking advantage of WebSphere For Developers, right? It’s free… learn more here)

Automating Deployment with Ant

A lot of people don’t realize that WebSphere ships with a copy of Apache Ant (WAS7 ships with Ant 1.6.5), and skip right to Jython for WebSphere scripting. While this is certainly a valid option, it adds an extra layer of complexity to your development and testing cycles which just isn’t necessary. WebSphere provides a set of Ant tasks which make it possible to do almost anything via Ant script, including the ability to invoke wsadmin scripts written in Jython or JACL if you’ve already got them in place.

Here’s a simple Ant script which shows how to deploy an EAR to your WAS Server using WebSphere’s InstallApplication task

<?xml version="1.0" encoding="UTF-8"?>
<project name="demo" default="main">
   <property environment="env"/>
   <property name="appName" value="SampleApplication"/>

   <taskdef name="installApplication"   
        classname="com.ibm.websphere.ant.tasks.InstallApplication"/>

   <taskdef resource="net/sf/antcontrib/antcontrib.properties">
      <classpath>
       <pathelement location="./lib/ant-contrib-1.0b3.jar"/>
      </classpath>
   </taskdef>

   <target name="determineWASLevel">
      <loadfile property="was.product" 
          srcFile="${env.WAS_HOME}/properties/version/WAS.product"/>

      <propertyregex property="was.level"
                     input="${was.product}"
                     regexp="(([0-9]{1}\.){3}[0-9]{2})"
                     select="\1"/>
   </target>

   <target name="main" depends="determineWASLevel">
      <echo message="Installing ${appName} to WebSphere ${was.level}."/>
      <echo message="WAS_HOME: ${env.WAS_HOME}"/>

      <installApplication   wasHome="${env.WAS_HOME}"
                            ear="${appName}.ear"
                            connType="SOAP"
                            host="localhost"
                            user="wsadmin"
                            password="wsadmin"
                            failonerror="true"/>
   </target>
</project>

This script does relies on Ant Contrib for the propertyregex task, which I use to parse out the WAS Level… this is done purely for debug and demonstration purposes, and can be removed if you like.

The important things here from a application deployment perspective are:

  1. The taskdef for installApplication, which is implemented by the com.ibm.websphere.ant.tasks.InstallApplication class.
  2. The invocation of the installApplication task, which specifies not the connection type, host, and username/password to use to connect to the server.

To invoke it, simply call “ws_ant” which ships with WebSphere:

    $WAS_HOME/bin/ws_ant.sh

You can deployWithAntDemo.tgz, which contains the ant-contrib library and this build script. Please feel free to modify and use it however you like!

Note: It is possible to use your own version of Ant if necessary; for instance, if the rest of your system requires Ant 1.8.2 for new tasks. This is not supported or recommended by IBM — but I’ll cover how to do it in a later post.

Automating Deployment with wsadmin in Jython

For more complex deployment scenarios, it may be advantageous to write a Jython script and invoke it using wsadmin, WebSphere scripting environment.

Here’s a sample Jython method you can use to deploy an EAR to an application server cluster:

def installSystemApp(cluster, appname):
  cell = AdminControl.getCell();
  cellName = "WebSphere:cell=" + cell
  earPath=appname + ".ear"
  installTarget = [ "-cluster", cluster ]
  MapModulesToServers = [[".*", ".*", cellName + ",cluster=" + cluster ]]

  options = [  "-nopreCompileJSPs",
    "-distributeApp",
    "-noreloadEnabled",
    "-noprocessEmbeddedConfig",
    "-usedefaultbindings",
    "-zeroEarCopy",
    installTarget,
    "-MapModulesToServers",  MapModulesToServers,
    "-appname",  appname,
  ]

  AdminApp.install(earPath, options)
  print "INFO: installed " + appname + " to " + msg

You would obviously want to include this method in a more complete Jython script; perhaps one that parsed command line parameters provided by an automated build system that includes the full path to the EAR (this method assumes Current Working Directory).

Either method for automating deployment is going to give you a lot of flexibility to improve your automated build and test infrastructures — a critical component of any Agile software operation.

Running WAS as a ‘regular’ User

If you’re like me, you like to install WebSphere in a system-wide WAS_HOME on your development system, such as the default:

/opt/IBM/WebSphere/AppServer

However, you also:

  1. Want to integrate WebSphere with your IDE
  2. Don’t want to run your IDE as “root” just so you can start/stop the server, access logs, etc.
  3. Find it mildly frustrating having to run everything using sudo

Here’s a couple quick steps that will allow you to work with your existing WebSphere installation as your regular user. What we’ll do is create a new group, wasdev, add your user to that group, and then give that group full permissions to WAS_HOME.

sudo groupadd wasdev
sudo usermod -a -G username wasdev   
sudo chgrp -R /opt/IBM/WebSphere
sudo chmod -R g+u /opt/IBM/WebSphere

Then just log-out and back in to refresh your group permissions, and voila! You now have full control over you WAS install with regular user permissions.

This is also great in production environments, where you really shouldn’t be running services as “root” anyway.

Note: Even though my WAS_HOME is /opt/IBM/WebSphere/AppServer, I chose to change the group and permissions on the parent directory instead. This also covers the UpdateInstaller, which will allow me to apply fix-packs with regular user permissions later!

Installing WebSphere Application Server v7

In this entry, we’ll walk through installing WebSphere Application Server v7, applying the latest fix-packs. In the next entry, we’ll install Feature Packs to enable advanced functions in your application server environment. (Installing in a headless environment? Check out my guide to installing WebSphere silently, here: Silent Installation of IBM WebSphere v7 + Feature Packs in a Headless Environment)

This guide is specifically geared towards building a development system for implementing and testing applications; but the steps are applicable for any WAS v7 environment. The test system is an Ubuntu 10.10 Desktop system on an i386 platform, but again, the steps are very much the same across other “distributed platforms” (ie Windows, Linux, AIX and HPUX).

Prerequisites:

To start, there are several things we’ll need to obtain:

  1. WebSphere Application Server v7 for Developers — this is optional if you already have WAS installation media, otherwise, you can download it for free here: http://www-01.ibm.com/software/webservers/appserv/was/featurepacks/modernbatch/. Keep in mind that the free WebSphere for Developers is only available for 32-bit Linux or Windows platforms.
  2. IBM Update Installer — you will use this to apply fixpack updates to your application server. Download it here: http://www-01.ibm.com/support/docview.wss?uid=swg24020446

Note: If you’ve never downloaded software from IBM before, you may want to register for an account. The process takes only a few minutes, and is only required the first time. For subsequent downloads, you can simply login again. While you can proceed without creating an account, you’ll need a username and password later to install additional feature packs anyway.

Note: The downloads will go quicker if you take advantage of IBM’s Download Director, which requires a Java-plugin in your web browser. On Ubuntu, enable Canonical-Partners in your software sources list, then run: sudo apt-get install sun-java6-jdk sun-java6-plugin

Note: Ubuntu uses the dash shell by default, which will cause the WebSphere installation to hang. You’ll want to relink /bin/sh to /bin/bash before proceeding!

Installing WebSphere v7

Extract your installation media, and launch the setup program. You can install WebSphere with regular-user permissions, if you like, however we’ll install it at the system level using administrative permissions by invoking the installer using ‘sudo’:

sudo ./WAS/install

The installation wizard will guide you through the process. Choose “Application Server” as the WebSphere Application Server Environment, and leave administrative security enabled (you’ll be prompted to provide an admin user id and password… for development systems, I usually use just “wsadmin” as the userid and password)

When the installation finishes, you’ll have a new WebSphere Application Server environment installed to /opt/IBM/WebSphere/AppServer (a location we refer to as “WAS_HOME”)

Applying the Latest Fix Packs

IBM periodically releases maintenance updates for WebSphere, called “fix packs.” Before moving on, you’ll want to update your application server to the latest maintenance level. You can find the most recent maintenance level here: http://www-01.ibm.com/support/docview.wss?uid=swg27004980

Click the platform link under the most recent fix pack level to download it. You’ll need to download both the “AppSrv” and “Java SDK” updates for your platform. For example, on my test system, I will download the “32-bit x86 AMD/Intel AppServer” and “32-bit x86 AMD/Intel Java SDK” updates for Fix Pack 15 for Linux.

While we’re waiting for the fix pack to download, let’s install the IBM Update Installer, which is needed to apply the update. Extract the 7.0.0.XX-WS-UPDI-LinuxIA32.tar.gz bundle you downloaded earlier (note: the XX should match your fix pack level!), then launch the Update-Installer Installer, like so:

    sudo ./UpdateInstaller/install

The installation wizard will guide you through the process, very much the same as the WAS Installer. If you left the checkbox checked at the end, then Update Installer will open after the installation; otherwise, you can launch it from the command line, using:

    sudo /opt/IBM/WebSphere/UpdateInstaller/update.sh

The update installer will prompt you for your WAS_HOME location (should be filled in by default), and then for the “maintenance operation.” We’ll choose “Install maintenance pack,” then browse to the folder where we downloaded the two update files (*.pak).

Best Practice: Move the downloaded update files into the UpdateInstaller’s “maintenance” subfolder for safe-keeping. If you need to uninstall them later, or re-install them into another WAS install, you’ll have them handy!

The Update Installer will show you the PAK files it can apply (if you have others that are not compatible with this WAS version, they will be listed, but disabled). Select both the AppServer and Java SDK updates and click Next through the rest of the wizard.

Verify You Application Server Installation

First, let’s verify that the fix pack applied properly, and we’re at the correct maintenance level:

cd /opt/IBM/WebSphere/AppServer
sudo bin/versionInfo.sh

Observe that the installed WAS Level matches your applied maintenance level. For example, if you installed Fix Pack 15, it should report: 7.0.0.15.

Finally, start your application server and connect to the Integrated Solutions Console (sometimes called “admin console”):

    sudo bin/startServer.sh server1

You’ll find the ISC by browsing to: http://localhost:9080/admin

 

Start Developing JEE Solutions using WebSphere

Much of this blog is geared towards a very wide range of readers: from IT Architects with multi-node WebSphere zSeries deployments with hundreds of federated WAS servers, through small business with a single WAS cluster, and even students just learning JEE and don’t know where to get started.

An important question for users of any scale, though, is how do you bring on new developers to build and test solutions without the added licensing cost of another WAS and DB2 Server?

Not to worry – IBM has you in mind.

You can download IBM WebSphere Application Server v7 for Developers at no cost! Additionally, you can grab IBM DB2 Express-C for free as well! Now your development environment can run the same enterprise-class software you use in production at no charge.

Be sure to read the licensing terms for these free editions, of course. The WAS for Developers terms, in particular, state that you can not use it to support production environments, and can only be installed on a developer’s workstation (ie, you can’t grab the free one for the purposes of setting up standalone testing environments shared across your business). You can read more about that on their FAQ, here.

Of course, once you have a WAS v7 Server installed and running, you’ll want to also grab the Feature Pack for Modern Batch to enable batch processing and programming models.

In the next few blog posts, I’ll walk you through getting a development environment up and running with WebSphere v7 – including how to navigate through the variety of tools you’ll need to get up-to-date with the latest fixes and feature packs, as well as DB2 Express-C