TKLM - Things To Know Part 1

DB2 Password and TKLM Data Source Out of Sync

On systems such as Linux or AIX, you might need to change the password for the DB2® Administrator user ID. The login password for the DB2 Administrator user ID and the DB2 password for the user ID must be the same.

The Tivoli Key Lifecycle Manager Installation program installs DB2 and prompts the installing person for a password for the user named tklmdb2. Additionally, the DB2 application creates an operating system user entry named tklmdb2. For example, the password for this user might expire, requiring you to resynchronize the password for both user IDs.

Typically you can identify if the DB2 ID password is no longer in sync with the data source password when you see this error when accessing TKLM through the GUI

 

Before you can change the password of the DB2 Administrator user ID, you must change the password for the system user entry. To resolve the password sync issue follow these steps:

Note: The original IBM document is located here.

1.     Log on to Tivoli Key Lifecycle Manager server as root.

2.     Change user to the tklmdb2 system user entry. Type:

su <gc>tklmdb

3.     Change the password. Type:

passwd

Specify the new password.

4.     Exit back to root.

exit

5.     In the TIP_HOME/bin directory, use the wsadmin interface that the WebSphere® Application Server provides to specify the Jython syntax.

./wsadmin.sh -username TIPAdmin -password mypwd -lang jython

6.     Change the password for the WebSphere Application Server data source:

a.     The following command lists the JAASAuthData entries:

wsadmin>print AdminConfig.list('JAASAuthData')

The result might like this example:

(cells/TIPCell|security.xml#JAASAuthData_1396539704930)

(cells/TIPCell|security.xml#JAASAuthData_1396539705604)

b.    Type the AdminConfig.showall command for each entry, to locate the alias tklm_db. For example, type on one line:

print AdminConfig.showall ('(cells/TIPCell|security.xml#JAASAuthData_1396539704930)')

The result is like this example:

[alias tklmdb]

[description "TKLM database user J2C authentication alias"]

[password *****]

[userId ustklmdb]

And also type on one line:

print AdminConfig.showall ('(cells/TIPCell|security.xml#JAASAuthData_1396539705604)')

The result is like this example:

[alias tklm_db]

[description "TKLM database user j2c authentication alias"]

[password *****]

[userId ustklmdb]

c.     Change the password for the tklm_db alias that has the identifier JAASAuthData_1396539705604:

print AdminConfig.modify('JAASAuthData_list_entry', '[[password passw0rdc]]'

For example, type on one line:

print AdminConfig.modify

('(cells/TIPCell|security.xml#JAASAuthData_1396539705604)',

'[[password <password>]]')

d.    Change the password for the tklmdb alias that has the identifier JAASAuthData_1396539704930:

print AdminConfig.modify('JAASAuthData_list_entry', '[[password passw0rdc]]'

For example, type on one line:

print AdminConfig.modify

('(cells/TIPCell|security.xml#JAASAuthData_1396539704930)',

'[[password <password>]]')

e.     Save the changes:

print AdminConfig.save()

f.     Exit back to root.

exit

g.    In the TIP_HOME/bin directory, stop the Tivoli Integrated Portal application. For example, as TIPAdmin, type on one line:

stopServer.sh server1 -username tipadmin -password passw0rd

The result is like this example:

ADMU0116I: Tool information is being logged in file

//opt/IBM/tivoli/tiptklmV2/profiles/TIPProfile/logs/server1/stopServer.log

ADMU0128I: Starting tool with the TIPProfile profile

ADMU3100I: Reading configuration for server: server1

ADMU3201I: Server stop request issued. Waiting for stop status.

ADMU4000I: Server server1 stop completed.

h.     Start the Tivoli Integrated Portal application. As the Tivoli Integrated Portal administrator, type on one line:

 startServer.sh server1

i.      In the TIP_HOME/bin directory, use the wsadmin interface that the WebSphere Application Server provides to specify the Jython syntax.

./wsadmin.sh -username tipadmin -password mypwd -lang jython

j.      Verify that you can connect to the database using the WebSphere Application Server data source.

i.       First, query for a list of data sources. Type:

print AdminConfig.list('DataSource')

The result might be like this example:

"TKLM DataSource(cells/TIPCell/nodes/TIPNode/servers/server1|resources.xml#DataSource_1396539707355)"

"TKLM scheduler XA Datasource(cells/TIPCell/nodes/TIPNode/servers/server1|resources.xml#DataSource_1396539709814)"

"Tivoli Common Reporting Data Source(cells/TIPCell|resources.xml#DataSource_1396539473259)"

DefaultEJBTimerDataSource(cells/TIPCell/nodes/TIPNode/servers/server1|resources.xml#DataSource_1000001)

ttssdb(cells/TIPCell|resources.xml#DataSource_1396539429750)

ii.      Type:

print AdminControl.testConnection('TKLM DataSource(cells....)')

For example, type on one line:

print AdminControl.testConnection (‘TKLM DataSource(cells/TIPCell/nodes/TIPNode/servers/server1|resources.xml#DataSource_1396539707355)')

iii.     Test the connection on the remaining data source. For example, type:

print AdminControl.testConnection (‘TKLM scheduler XA Datasource(cells/TIPCell/nodes/TIPNode/servers/server1|resources.xml#DataSource_1396539709814)')

iv.    In both cases, you receive a message that the connection to the data source was successful. For example:

WASX7217I: Connection to provided data source was successful.

DBMEMPERCENT...Where'd That Come From?

I was having performance issues with a couple TSM 6.2 servers and could not find anything that pointed to the issue. I'm not one to call support unless I'm totally stumped and cannot find help through the web, but this time I finally relented and made the call. The issue was problems with backups failing repeatedly and when researched we were getting internal server errors along with DB table errors. IBM support asked for some DB2 log files and within 30 or so minutes had identified the problem.

TSM has a server option I have never used or heard of that had somehow been set that adversely affected all backups. Somehow the option DBMEMPERCENT was set in the dsmserv.opt file. This option tells TSM what percentage of the overall server's memory it can allocate for use. The default is AUTO and would have been fine, but somehow DBMEMPERCENT was set to 10 in the dsmserv.opt. Which means out of 16GB of RAM I was only using 1.6GB?!?!? How'd that happen? I didn't set it, none of my coworkers remember setting it, so where did it come from? IBM support stated the default was AUTO so the option was manually set. Since I had never used this option and its 6.x specific, I never would have looked for it. Good thing I called support.

db2adutl Error

I recently had an issue with a client and storage agent upgrade that resulted in problems with the db2adutl utility being unable to return any data. Here's the errors:

Retrieving

Error: Begin query image failed with TSM return code 136

Error: Get next image failed with TSM return code 2041

I pretty much knew what caused the error, the problem was how to fix it. The cause was due to an upgrade of the TSM client on the DB2 server that (after further investigation) could not support the more current TSM Storage Agent. An OS patch would have to be applied, however, that could not be done without an outage. Our only option was to roll the client back to a supported TSM client / storage agent level. The problem was that while attempting to figure out a better solution than rolling back the client the DB2 database had run a backup.  When the client API was rolled back it could not "interpret" the new API's backup causing the db2adutl errors.

Support suggested renaming the node or the file space (file space is better since you don't have to stop and start db2 to reset the password as you would with the new node name). I didn't want to have to do either. The backups taken since the rollback were good, but db2adutl couldn't return the list of backups as long as the objects done with the newer API were still present. Luckily I have been dealing with Oracle admins long enough to have a solid grasp on manually deleting objects on the TSM server. When Oracle DBA's neglect their RMAN duties, I pulled out my trusty delete object command and I was able to remove the backup objects from the period of time that the new API had been used. Once completed db2adutl was able to immediately see it's backups and return a list of what was available.

TSM 6.1 & 6.2 DB2 Issue

I had a TSM server crash mutliple times over the course a week and after working with Tivoli support and sending them the core files, it was determined that the following error was the cause. Interesting, in that I never thought about the connections from TSM to the DB2 DB. So to summarize, the current connection from TSM to DB2 is not a TCP based but IPC and AIX has a limitation of 1024 IPC connections to DB2 otherwise the application in question (TSM in this case) can crash. The following link has directions on how to convert TSM to DB2 connections to TCP to eliminate this issue.

TSM Server 6.x - Move OS's

An interesting question was asked on ADSM.org on whether TSM 6.x could be moved from Windows to AIX since the DB is now DB2. I know DB2 has the db2move utility, but would TSM support this? Could you run that and copy all your needed config files? My thinking is that TSM still has too many distinct nuances that set it apart from real DB2 that it would not work, but I haven't heard whether it is supported. Anyone out there tried it?