what OS user are you running this as?
is there a mapping entry for this user in the users or users.local file on the appserver?
if you run an 'agentinfo' as this OS user against the appserver what do you get ?
I think this error can happen if you dont have proper ACLs on the server you are running the compliance module. Check if the user running this module has correct mapping on the appserver Acls.
Please try restarting the agent on your app server machine.
Why would that help ?
Not sure if it's the same issue, but there's a scenario where the agent is installed (and started) before NSH is installed on the app server machine. As a result, the agent process' PATH does not include the NSH path. When the Compliance Content installer tries to verify the app server version (using nexec), that command fails.
Restarting the agent will simply ensure that it gets the latest PATH, which includes the nsh commands.
I’d only expect that to be an issue on a windows system, since on a unix box they are installed together, and also this is an upgrade, so the path should already be there from the previous install.
Did anyone get a solution for this? I am seeing exactly the same issue on one of the environments that I am trying to upgrade the Content on, I am installing on Linux RS 5.7, and installing directly on the Appserver, I have selected multi-Appserver Setup and have confirmed that both agents are 188.8.131.52 and both agents are running.
I am using the BLAdmin account and BLAdmins RBAC role.
Disregard my last, we had an nsh proxy configured in the secure file
Can you expand on that please?
What change did you need to make to resolve the issue?
Thanks & Regards,
Hi Jim within the /usr/lib/rsc secure file we had the following
I commented out the second line and added
Then saved the secure file
Once the Content Installer completed you revert the secure file back to the original settings
iain - what you did was configure your nsh client to use a nsh proxy. this means when the content installer tries to communicate w/ the appserver(s) over nsh it's using your blade credentials to do so and there are likely mapping entries in the rsc files for your blade user and role. if you don't use the proxy you do not send across your blade user and role and instead you send the OS user name you logged in as and started the installer as. since there is likely no mapping for that user you get a permission denied message or similar. so you could add an entry in the users.local to map that username to administrator/root on your appserver, or you could add something in exports to map all connections to root/administrator.
so for example, if you login to your box as 'Administrator' and run the content installer, and don't use the nsh proxy, then you need to put this:
in the users.local files on your appserver(s). that means anyone who logs into their system as 'Administrator' can get nsh access to this box as Administrator. there are some ways to limit it noted in the admin guide.