Resetting wasadmin password

I recently inherited a TADDM environment where I needed to work with WebSphere in order to integrate TADDM with Active Directory.

Unfortunately, no one knew the password for wasadmin, so I couldn't access the Websphere Admin's console. Time was pressing, the other guy was not available and my knowledge of WebSphere administration is limited to what's written in the TADDM and TBSM documentation (hint: very little!)

I followed the following routine. It worked for me.

1. I needed to configure WebSphere not to use security:
   1. I found the file security.xml under /cell directory.
   2. I edited it, so that under the security:Security tag I changed enabled="true" to enabled="false"
2. Now, I needed to restart the WebSphere so it would reset it's security.
3. The following is the "proper" routine to stop WebSphere:
   1. <WAS_HOME>/profiles/ctgAppSrv01/bin/stopServer.sh MXServer -username wasadmin -password wasadmin
   2. <WAS_HOME>/profiles/ctgAppSrv01/bin/stopNode.sh -username wasadmin -password wasadmin
   3. <WAS_HOME>/profiles/ctgDmgr01/bin/stopManager.sh -username wasadmin -password wasadmin
4. Of course, not having the password meant I couldn't stop the processes. Well, that's what kill -9 is for...
5. Starting WebSphere is easier:
   1. <WAS_HOME>/profiles/ctgDmgr01/bin/startManager.sh
   2. <WAS_HOME>/profiles/ctgAppSrv01/bin/startNode.sh
   3. <WAS_HOME>/profiles/ctgAppSrv01/bin/startServer.sh MXServer
6. Now, when I access the Integrated Solutions Console (http://server:9060/ibm/console/login.do) then I'm no longer asked for a password
7. I login as wasadmin and recreate all the security I need...

I think (hope) this is more-or-less what a WebSphere expert would do too!

-- Robert

Atlantis... Found... or Not

Yesterday, British tabloids reported the discovery of the Lost Continent of Atlantis! The discovery was made, not by intrepid explorers, but by searching Google Earth's maps:

Can you see the highways on the bottom of the Ocean?

View Larger Map

Well, it seems that these highways are simply the paths of the oceanographic ships which mapped the area - Plato can rest easy, his hoax has not been discovered :)

Link to the tabloid "The Sun"

Link to better explanation.

 

-- Robert

Finding unassociated Situations

In ITM, after you have created a new situation, you must do two things to it:

1. You must distribute it to one or more agents. This will determine where a situation runs. i.e you can limit it to specific servers or run it on all of them.
2. Associate it with some node in a tree in the TEP Portal. This is so that when the situation activates (fires, become true) you will see it in the portal console.

The problem then starts when you want to be sure that all your situations have been distributed and associated properly. The first problem is simpler - you can use a SOAP call on the TEMS to fish out the list of situations and their distributions. The second problem is slightly more complex. The TEPS database hold the list of all situations and associations - but a list of unassociated situations - which are the ones which will not show up even if they become true.

Recently I was at a customer and needed to verify that all situations were indeed associated. I remember seeing something that showed this, but my searching skills betrayed me and I wrote this out quickly. If anyone does have a link- feel free to send it.

Being a quick-and-dirty job (and being rusty with my Perl), this script will only work on the environment it was written for - Windows/SQLServer, but it should be easy to convert
Also, I committed the crime of using system calls in Perl, instead of SOAP and SQL calls embedded in the code - so sue me :)

#!/user/local/bin/perl
# This script will list situations which exist but are not associated with any portal navigator item.
# It is limited to Windows systems running SQLServer, but can easily be modified for any OS/DB combination. :)
# Part 1 - list all situations from TEMS
# Part 2 - list all situation associations from TEPS
# Part 3 - Find which situations exist in part 1 but not part 2
#
# Robert Barron Feb-2009

my $sSitListFile = "SitList.txt";
my $sSitAssocFile = "SitAssocList.txt";
my $sTEMSHOST = "x.x.x.x";
my $sTEMSUser = "xxxxxx"
my $sTEMSPassword = "xxxxxx";
my $sTEPSHOST = "x.x.x.x";
my $sTEPSUser = "xxxxxx"
my $sTEPSPassword = "xxxxxx";

# Part 1
#  login to TEMS and pull out a list of situations

system ("tacmd login -s " . $sTEMSHOST . " -u " . $sTEMSUser . " -p " . $sTEMSPassword);
if (-e $sSitListFile) {
    unlink ($sSitListFile);
}

#Run tacmd listsit and extract the first  string from each line.
# NOTE: This line must be modified if you are using situation names with spaces in the middle (ITM 6.2.1+)
system ("for /f %i in ('tacmd listsit') do \@echo %i >> " . $sSitListFile);
open (File, $sSitListFile ) || die "Could not open " . $sSitListFile ."\n";

while (<File>) { #Strip any \n or spaces from the situation string
    chop;
    $tmp = $_;
    $tmp =~ s/^\s+//;
    $tmp =~ s/\s+$//;
    push(@arrAllSits, $tmp );
}
close (File);

# Part 2
# login to TEPS database and pull out the situation associations.
if (-e $sSitAssocFile) {
    unlink ($sSitAssocFile);
}
system ("sqlcmd -S " . $sTEPSHOST . " -U " . $sTEPSUser . " -P " . $sTEPSPassword . " -d teps -Q\"select distinct(name) from teps.KFWTMPLSIT\" > " . $sSitAssocFile );
open (File, $sSitAssocFile) || die "Could not open " . $sSitAssocFile . "\n";
while (<File>) { #Strip any \n or spaces from the situation string
    chop;
    $tmp = $_;    
    $tmp =~ s/^\s+//;
    $tmp =~ s/\s+$//;
    push(@arrAssocedSits, $tmp);
}
close (File);

#Part3
%found=();
@arrNotAssoced =();

#build lookup table
foreach $item (@arrAssocedSits) {$found {$item} = 1}

# find elements which are in @arrAllSits and not in @arrAssocedSits
foreach $item (@arrAllSits) {
    unless ($found{$item}) {
        #it's not in %found, so print
        print ($item ."\n");
    }
}

This script will print out the list of situations which exist but are not associated with any navigator item.

-- Robert

Search before you post!

If you spend some time on the TEM10 mailing list, you'll find out two things:

1. These guys know a lot about Tivoli.
   
2. These guys don't like answering simple questions which have already been answered before!

Unlike the Developerworks forum, where you can simply enter a search term at the top of the screen, there's no obvious way to search TME10.

Try at the official site or at the not-so-official-but-simpler-site.

Anyway, before asking a question, try giving these sites a peek - if it's been answered before, you'll save yourself time.

-- Robert

Too Many Nodes

Recently I came to a customer I hadn't visited in some time.

On the main screen of the ITM system, when we chose Windows Systems we got KFWITM455E Request to 732 nodes exceeds the limit of 200. The workspace most mostly empty. The problem is pretty obvious and so is the solution - de-install Tivoli agents!

Seriously though, the recommended practice in this case is probably to split your servers into smaller groups (MSLs) and create a workspace for each one.

If you, like me, are lazy and simply want to see all the servers in one place, you can change the KFW_REPORT_NODE_LIMIT parameter.

On Unixes, go to cq.ini. On Windows open the the Tivoli Services Manager, right-click the TEPS -> Advanced -> Edit ENV file.

Find the KFW_REPORT_NODE_LIMIT parameter and change it to something suitable.

CAREFUL! The parameter is commented out and you must uncomment it. recycle the TEPS and Voilà!

The workspaces may take much longer to load though now. That's the advantage of smaller MSLs.

-- Robert

Asterix and the Great... Sellout?

It seems that the great Asterix is in for a big change : Albert Uderzo, illustrator and, since 1977, only begetter of the Asterix series of books, has retired and sold his rights to Hachette Livre.

His daughter Sylvie has accused him of selling out to "those who would negate all the values he taught me: independence, fraternity, conviviality and resistance". I must agree.

In a more optimistic mood - and with more information, I might consider this good news. Perhaps new blood could rejuvenate Asterix, whose last few adventures have not been very good. However, I must admit that few intellectual properties are improved by being managed by others rather than their creators.

Neither James Bond nor Sherlock Holmes have been returned to their original heights. I hope Asterix will prove me wrong.

:(

Link to Asterix in Wikipedia.

-- Robert

What is TADDM stuck doing?

Yesterday I ran a discovery in an environment and after the sensors finished scanning the servers, the topology builder started it's work.

2%..4%..6%..9%..11%...75%.

It breezed through the first percentiles quickly and smoothly, but stuck on 75% for ages. Eventually we left and came back the next day.
The good news is that it completed successfully.

I don't like not knowing what and why computers are doing something. Why did it get stuck on 75% but nowhere else?
The percentiles that the topology builder show us are now percentiles such as displayed when copying a file. I.e. 9% doesn't mean that 9% of the work has been done, it means that 4 "steps" have been completed. So TADDM was stuck on the step represented by 75%.

per this Note, the various steps are represented in the file $COLLATION_HOME/dist/etc/TopologyBuilderConfigurationDefault.xml and there are nearly 40 steps.

Each step represents the topology builder generating the dependencies and links for a sensor. Part of creating a brand-new sensor is updating this file, so that after the discovery is done the topology builder will fold the items found by the new sensor into the list of links it holds.

Here are the sensors and the percentile they are represented by:

2 DatabaseServerCleanupAgent
4 ComputerSystemConsolidationAgent
6 ComputerSystemTypeAgent
9 RuntimeGcAgent
11 DeletedObjectGcAgent
13 SystempConsolidationAgent
16 VmwareVirtualCSConsolidationAgent
18 J2EEServerDeploymentAgent
20 AppServerClusterAgent
23 JDBCDependencyAgent
25 JBossClusterAgent
27 WeblogicClusterAgent
30 OracleAppClusterAgent
32 OracleDependencyAgent
34 WebConnectionDependencyAgent
37 WebSphereConnectionDependencyAgent
39 SAPDependencyAgent
41 SoftwareHostReferenceAgent
44 DNSServiceAgent
46 LDAPServiceAgent
48 DNSDependencyAgent
51 NFSDependencyAgent
53 HostDependencyAgent
55 ConnectionDependencyAgent
58 GenericAppAgent
60 AppDefinitionAgent
62 AppDescriptorAgent
65 ObjectDisplayNameAgent
67 DiscoveryLogCleanupAgent
69 DominoConnectionAgent
72 DominoClusterDomainAgent
74 PortableAgentWrapper
76 l2.L2Agent
79 l2.CDPAgent
81 CompositeCreationAgent
83 MQServerAgent
86 CitrixAgent
88 ExchangeDependencyAgent
90 VCSDependencyAgent

Seeing as I was stuck on 75% I see that the L2 (communications layer 2) sensor was very busy. In retrospect this makes prefect sense, since this discovery was the first time I found a new type of switch in the environment. It makes sense that the builder would take much longer for this step than when I'm only discovering servers.

What happens after step 90%?

I don't know. I'll try to find out and let you know!
If anyone does know, please drop a line

-- 2011 Update

In TADDM 7.2.x, the log file dist/log/TADDM.log details each step, so if your discovery is stuck on step x, just check the last line of the log and you'll see what class the Topology Builder is working on.

-- Robert