Server Names in MAXSESSION table

We found this great blog post  that shows how to set up the server names for cluster members. But that's not the real gem in my eyes, it how to use a variable in the JVM args ${WAS_SERVER_NAME} so that you don't have to hard code each JVM name in every app server config.

Apache The Definitive Guide - Book Review

I just finished Apache The Definitive Guide by Ben Laurie & Peter Laurie and would highly recommend this book to anybody who is administrating an Apache or IBM HTTP Server. Apache The Definitive Guide is a ground up approach to teaching you about the Apache web server platform. After spending the last year moving away from a developer role and into a infrastructure role I learned a lot about the IBM HTTP Server  but still had a lot of questions. The Definitive guide tied a lot of concepts together and removed the once dense fog around the web server component of our infrastructure.

Fixing an invalid Bind account

We have been going through a bunch of password changes and mistakenly change the password on a account in one environment that broke another environment. One of the things I learned (other then never reuse accounts ! ) was that when the bind account is invalid, even the wasadmin account will not be able to access the console. The environment we were working in was development and needing a fix I tried to edit the profiles\Dmgr01\config\cells\Cell01\wim\config\wimconfig.xml and updated the value for bindPassword and the bind account to a value from another instance .  What made this interesting was the fact that I was able to use a encrypted password from a WebSphere 6.1 environment in a WebSphere 7.0 environment. I was also able to update the bind password value with a clear text copy, allowing me access to the console. After I entered the console I went to
Secure administration, applications, and infrastructure > Federated repositories > repository
 and was then able to re encrypt the password by reentering it in the bind password box, clicking apply and then save.

WebSphere System Management & Config

My study notes from the following redbook

System Management Overview
    Terminology

• Stand-alone server environment refers to a single server environment that is not managed as part of a cell. This is your only option for base and express version of WebSphere but Network Deployment can be configured as a stand-alone server. 
• Distributed server environment refers to a environment that has multiple servers that are managed by a deployment manger in the cell. 
• Manage Process refers to deployment manager nodes (and node agents) and application servers. 

Stand-alone Single Server

 Distributed Server Environment 

Java Management Extensions (JMX)

   WebSphere system management functions are based on JMX a standard way to expose management objects. JMX  

  

SECJ0305I Error, Node Agent not Running

This morning I got to work and learned that one of our node agents was not running. What made this unique was that the node agent in question was running on a virtual machine that had recently been moved from one data center to another, across town changing the IP address. After checking the node agent's System.out  I determined that the last time the server been restated the node agent had started successfully.

WSVR0001I: Server nodeagent open for e-business

Puzzled at this point I pinged all three servers from each server and got a reply every time. I then restarted the windows service that was running the node agent and it failed to restart. Looking into the log I discovered a new error stack that started with a

CWWIM4512E The password match failed.

and ended with

SECJ0305I: The role-based authorization check failed for admin-authz operation

I did some goggling and found this tech note from IBM that recommends "restart(ing) the deployment manager, node agents, and servers." This resolved the original issue where the node agent showed as not running but when I tried to restart the node agent service to show what I had done to a peer I got the same error but the node agent status never changed from running in the Deployment manager  : (  I will post a follow up to this issue at a later date (when it is worked out).

Growing access.logs for IBM HTTP Server

While working on some performance issues in Prd we discovered that our web server access.logs were in excess of 2GB and still growing strong. After some research we decided it was time to implement piped logs . We first tried to edit the httpd.conf file for the web server through the WebSphere admin console. We replaced the following 

CustomLog logs/access.log common

with

CustomLog "|bin/rotatelogs logs/access.%Y.%m.%d 86400" common 

Stopped the web server , tried to start it and after a 30 sec pause we got a msg back saying that the web server could not be started. Further research into the log files for the deployment manager and web server did not shed any light on why. After some digging on IBM's support site I found this technote explaining that the full path must be specified. I replaced the above with this, (adjusting the formatting to better fit our needs) and the server started without issue and our log files were now rolling on a 24hr bases.

CustomLog "|C:/IBM/HTTPServer/bin/rotatelogs.exe -l C:/IBM/HTTPServer/logs/access-%a-%m-%d-%Y.log 86400" common 

Maximo 7.5.0.2 and WebSphere 8

We are in the process of setting up Maximo 7.5.0.2 and recently my lead ran across this link from IBM that outlines how to do just that but with WebSphere 8 as the middleware. Currently we have Maximo 7.5 set up with WebSphere 7 but are evaluating upgrading WebSphere to 8. This tech journal from IBM outlines some interesting points on why this might be a good idea. The one that I found the most interesting was the modification to the addnode command providing an add existing option.

Node recovery

A new optional argument for the addNode command, asExisitingNode, makes it easier to move or recover nodes. When this command argument is used, the node is added using the configuration from the Deployment Manager for that node. As a result, a node can be easily moved to a new server and, if need be, there are provisions for changing the host name during this process. In the case of a hardware failure, the node can be easily recovered back to the last configuration reflected in the cell configuration maintained by the Deployment Manager. These two scenarios are depicted in Figure 5.