by Sandra Jones
Had an issue where the TEPS GUI could be logged into with no problems, however when the command tacmd tepslogin was used with the same user id it failed with the error message KFWITM220E
In the TepsLoginCLI_0.log was seen:
com.ibm.tivoli.itm.login.TepsLogin validateTepsUserCredentials
SEVERE: Credentials authorization request failed with error code -103
com.ibm.tivoli.itm.login.TepsLogin main
SEVERE: Exception caught:
KFWITM220E Request failed during execution.
at com.ibm.TEPS.REST.Client.RestDataBus.execute(RestDataBus.java:1017)
at com.ibm.TEPS.REST.Client.RestDataBus.executeRequest(RestDataBus.java:401)
at com.ibm.TEPS.REST.Client.RestDataBus.executeRequest(RestDataBus.java:282)
at com.ibm.TEPS.REST.Client.QueryModelRestMgr.executeRequest(QueryModelRestMgr.java:238)
at candle.fw.model.PBasedRequest.execute(PBasedRequest.java:894)
at candle.fw.model.PBasedRequest.execute(PBasedRequest.java:869)
at candle.fw.util.TepDataProvider.authorizeUser(TepDataProvider.java:451)
at candle.fw.util.TepDataProvider.authorizeUser(TepDataProvider.java:311)
at com.ibm.tivoli.itm.login.TepsLogin.validateTepsUserCredentials(TepsLogin.java:771)
at com.ibm.tivoli.itm.login.TepsLogin.run(TepsLogin.java:370)
at com.ibm.tivoli.itm.login.TepsLogin.main(TepsLogin.java:141)
com.ibm.tivoli.itm.login.TepsLogin main
SEVERE: KUICTL099E The tepsLogin command failed because an unexpected error occurred. Please consult the C:\IBM\ITM\logs\TepsLoginCLI_0.log log file to determine the cause of the error.
It was checked that the local host was set correctly in the hosts file on the machine.
It needs to be set like:
127.0.0.1 localhost.localdomain localhost
Also made sure that the ip address and hostname was defined correctly in the Hosts file.
This pmr was complicated with the fact that there were issues sending a full pdcollect.
This meant rather than just checking environment files it was a matter of questioning what needed to be looked at next.
It should be remembered we do not just ask for a pdcollect for the sake of it, it does give us a lot of incidental information that
helps with diagnosis, even if it does seem a lot of information to send.
Another file helped show the issue: TepsLoginCLI_KCJRAS1.LOG
the error could be seen as:
5827c5d0.2b73a840-(null)main:DataBusProxy,0,"DataBusProxy.login()") Login failed
(5827c5d0.2b922cc0-(null)main:DataBusProxy,0,"DataBusProxy.connect()") binding to WebService failed.
(5827c5d0.2b922cc0-(null)main:DataBusProxy,0,"DataBusProxy.connect()") Login failed
(5827c5d0.2bb0b140-(null)main:DataBusProxy,0,"DataBusProxy.connect()") com.ibm.TEPS.JSON.SystemException: Login failed
at com.ibm.TEPS.REST.Client.DataBusProxy.login(DataBusProxy.java:843)
at com.ibm.TEPS.REST.Client.DataBusProxy.connect(DataBusProxy.java:1001)
at com.ibm.TEPS.REST.Client.DataBusProxy.bind(DataBusProxy.java:893)
at com.ibm.TEPS.REST.Client.DataBusProxy.getDataBusProxy(DataBusProxy.java:116)
at com.ibm.TEPS.REST.Client.RestDataBus.bindToManager(RestDataBus.java:1435)
at com.ibm.TEPS.REST.Client.RestDataBus.execute(RestDataBus.java:810)
at com.ibm.TEPS.REST.Client.RestDataBus.executeRequest(RestDataBus.java:401)
and just above this were the lines:
(5827c5cc.292fd2c0-(null)main:DataBusProxy,0,"DataBusProxy.connect()") setting host hera1.nn.nn.com port 15200 protocol http
(5827c5cc.293f1500-(null)main:DataBusProxy,0,"DataBusProxy.connect()") uid = gjones
(5827c5cc.294e5740-(null)main:DataBusProxy,Rev=1.19,"DataBusProxy.login()") Entry
(5827c5cc.294e5740-(null)main:DataBusProxy,Rev=1.19,"DataBusProxy.sessionInfo()") Entry
(5827c5cc.294e5740-(null)main:DataBusProxy,Rev=1.19,"DataBusProxy.call(HashMap, JSONObject)") Entry
(5827c5cc.2a333900-(null)main:DataBusProxy,0,"DataBusProxy.call(HashMap, JSONObject)") HTTP request is:/TEPSREST/JSONDataBus?CALLTYPE=4
(5827c5d0.2b45e180-(null)main:DataBusProxy,0,"DataBusProxy.call(HashMap, JSONObject)") Exception: java.net.ConnectException: Connection refused: connect
(5827c5d0.2b45e180-(null)main:DataBusProxy,0,"DataBusProxy.call(HashMap, JSONObject)") Exit: null
A check then of the netstat showed port 15200 was not reported as listening.
Checking this with customer, no port had been intentionally changed, so next was to request the \IBM\ITM\IHS\conf\httpd.conf file .
Note: this is a file that is not collected by a pdcollect so you could be asked for it separately.
It was found in this file the line for the listen port had been commented out:
# IPv4 support:
# Listen 0.0.0.0:15200
The lines was changed to read:
# IPv4 support:
Listen 0.0.0.0:15200
Then the TEPS was restarted, and the tacmd tepslogin then worked correctly.
Note: there is a line in the file for IPv4 and one for IPV6 so there must have be a possible change at some point, but in this case both lines were commented out.
There can be a number of issues in this area, depending on the level of authorization that is applied, but these files mentioned should help indicate the area to look into.