problem with repotools-jts.sh -syncUsers
CLM 4.0.0.1
Red Hat 5.x
Oracle 10g
I logged in as an admin and made some changes in CLM.
There were new users added to LDAP.
I logged in to the Linux box and tried to run repotools-jts.sh -syncUsers:
./repotools-jts.sh -syncUsers repositoryURL=https://address:9443/jts adminUserId=parameter adminPassword=parameter
and I get:
CRJAZ1357E Failed to login into the server 'https://address:9443/jts'. Check the login credentials.
3 answers
I have seen this only in cases where I mistyped the user ID, or the password. Are you sure the account and password provided work? Do other repotools commands have the same issue?
Comments
We have similar issues because we have multiple LDAP server behind the lDAP server address. They are served by DNS round robin with a DNS TimeToLive of 15 min.
So we don't know exactly which LDAP server is serving the authentication request and which one is used during LDAP synch etc...
We found out, that two of our six LDAP servers were not working correctly, and that gave us such random results.
We found out with:
> nslookup ldap.company.net
This showed 6 servers
We tested with a
> ipconfig /flushdns
to get a new IP address of another LDAP server.
As a workaround we have a small scheduled job, which tries to logon and if it fails it does an "ipconfig /flushdns" and writes into a logfiles which IP address was not working. (So we have a statistic, we can show our IT provider.). This job runs evry two minutes in our environment. This can alo be used as an Heartbeat of Jazz and send an e-mail to a sysadmin if it is not working for two/three times.
BTW: we switch off case-sensitivity in all advanced settings of all CLM applications. In Active Directory LDAP this is always case-insensitive and in WAS it's the default.
So we don't know exactly which LDAP server is serving the authentication request and which one is used during LDAP synch etc...
We found out, that two of our six LDAP servers were not working correctly, and that gave us such random results.
We found out with:
> nslookup ldap.company.net
This showed 6 servers
We tested with a
> ipconfig /flushdns
to get a new IP address of another LDAP server.
As a workaround we have a small scheduled job, which tries to logon and if it fails it does an "ipconfig /flushdns" and writes into a logfiles which IP address was not working. (So we have a statistic, we can show our IT provider.). This job runs evry two minutes in our environment. This can alo be used as an Heartbeat of Jazz and send an e-mail to a sysadmin if it is not working for two/three times.
BTW: we switch off case-sensitivity in all advanced settings of all CLM applications. In Active Directory LDAP this is always case-insensitive and in WAS it's the default.