the server is registered w/ a hostname or the ip?
if it's registered w/ the hostname, what ip does a nslookup from the appserver return?
It is registered thru hostname
It is actually returning me the correct IP as it is in the server
Now, after decommisioning the server and adding it back, the server is unable to discover in DNS
Is the correct ip returning via a nslookup from the appserver?
z0*****@bll**********:/home_dir/z0******> nslookup tcmktd******
but bladelogic was referencing 10.97.10.114 earlier, now after adding it is unable to discover in DNS
The appserver maintains a DNS cache.
Edit the NSH/br/java/lib/security/java.security file – make some changes to the settings noted in this link:
to change the dns cache settings
restart the appserver
Good to know these settings.. Since it requires root access to change the settings from default cache value 10, i'm unable to make the changes.
I think it should be set to '0' right ? so that this issue never repeates.
U think Bladelogic is unable to come out of the cache entry which it is referencing to earlier ? now, due to some reasons the server IP got changed but BL is still referencing the old one ?
Since we cache indefinitely because of the underlying java settings the only way to pickup the new ip would be to restart the appserver. I believe the cache still honors the ttl on the dns record so if it expires then we should request it again and then pickup the new value.
Thanks Bill, I'm waiting to restart the app servers with maintenance window.
meanwhile i'm also pushing here to set settings to 'do not cache'
By default it was set to 10 seconds, by setting to ZERO is there any harm?
The problem is going no where.. I did restart the BL app server but even after doing it the result is same
The error message this time when trying to push ACL "No authorization", i did update the ACL files and also tried pasting from working host but no go. Any other solution ?
what is in the rsc files? most importantly, is there a mapping for the user running the ACL Push job and any other jobs that are failing ?
Glad to inform that after restarting the servers (TCMKTDCP*** and TCMKTDCP*****) the issue got fixed.
We came to know that there was a configuration change for these 2 Big IP servers. The change in IP address was not able to resolve in BL.
As you advised on java.security settings, we are still thinking if it hampers any .. (don't cache setting).
Can you throw light on this? Is there any harm if at all
There is nothing wrong in ACL files.
"No authorization to access host" generally means you have accessed the target server but the rsc files have denied you access to that server.
so once you confirm that the name resolution is working properly, can you now push acls ?
we've had similar problems a few weeks ago in our BSA 8.2 Environment, changing Settings in the java.security file didn't help either. We finally solved the Issue by stopping the NSCD Daemon on all Application Servers.
Maybe this is helpful for someone despite the fact that this is an older Discussion.