The command you want to use is agentinfo. It
can be used in two ways:
agentinfo host1 host2 ...
host% cd //host1
In each case the output is something to the effect
Agent Release : 22.214.171.124
Hostname : hostname
Operating System: Linux 2.4.21-15.0.4.ELsmp
*User Permissions: 502/56055 (bladmin/bladmin)*
Security : Protocol=5, Encryption=TLS1
Host ID : 45AB190B
# of Processors : 8
License Status : Licensed for NSH/CM
Thanks for that, but agentinfo returns the userid that you are impersonating on an agent, not the userid you are connecting with.
It is the userid I am connecting with, that will be compared against ACLs in order to determine the impersonation and level of access, that I want.
The reason (That I guess I should have given in my original post!) is that we have a situation at CG where authorisation should be OK, but isn't and I want to check which user I am connecting as to rule that out as a possible cause.
I know you mentioned the "id" command above but that should really give you the info you need. The only time it shouldn't work would be if you've launched an NSH custom command (in which case your user would actually be the ROLE:USER that you're logged in as instead of the system user or if you were using SRP proxy (for the same reasons as custom commands).
What you can do though is look at the agent log that's rejecting you. You should see something like this:
02/24/05 11:05:21.002 WARN rscd - 10.20.21.14 128 SYSTEM (sdaley): agentinfo: Host not authorized
The entry between the () is the user the agent thinks you're coming in as (so in the above example, you'd be sdaley).
I agree with the requests, here is what you can do to replicate the inability in nsh to know who you will claim to be when connecting to RSCD agents. I ran this on a Windows XP computer, but should be the same for all OSes.
1. Run nsh locally on your desktop (logged in as Knotta)
2. Connect to Ops Manager using Config Manager (logged in as RBACAdmins:RBACAdmin)
3. Select a server and perform the usual "nsh here" custom command.
The nsh from 1 and nsh from 3 will attempt to be different users when contacting a remote server:
USWSCO31337% cd //lxwsit871/
cd: no authorization to access host: //lxwsit871/
USWSCO31337% cd //lxwsit871/
bin dev home media opt root sbin srv ...
The rscd.log knows that the seperate windows are different users:
02/24/05 13:16:58.543 WARN rscd - 126.96.36.199 10693 0/0 (Knotta): agentinfo: Host not authorized
02/24/05 13:17:15.400 INFO rscd - 188.8.131.52 10695 0/0 (RBACAdmins:RBACAdmin): nsh: nsh
How do you determine inside nsh who you would connect as when talking with remote servers? I can see not being able to change this setting for security reasons, but knowing who you are is a "good thing" (tm).
Would everyone agree that the correct solution is to override the "id" command to correctly report either the OS User (in cases where NSH is launched from outside the custom commands/srp proxy) or the Role:User (in cases where it is launched from within custom commands/srp proxy)?
for historical purposes and compatibility with other scripts that use id, I would prefer a separate command or a command line option for id. Some forms of id already take options:
print only the group ID
print only the supplementary groups
print a name instead of a number, for -ugG
print the real ID instead of effective ID, for -ugG
print only the user ID
We could add an additional option for id:
print the BladeLogic Role:User
I like Andrews -b option.
If you use nexec -e you get the correct Role:User ouput.
nexec -e id
Good idea and it should work in many cases. However, it did not work on my desktop because it does not have rscd installed (its not a server to be managed by BL).
I tried this and it didn't work for me for two reasons:
1. nexec will only connect (& work) if your authentication with a remote rscd agent is good.
This means that if you are having problems connecting, you can't check what Role:Userid you are attempting to connect with.
2. It only gives me root anyway. I tried this with an nsh shell started from a command line and with one started from CM.
A need for this showed up again, where the client would like to change the behavior of an nsh script job based on the role that runs the script.
Has anyone had difficulties with this in 7.0? I am used to being able to run the 'NSH Here' command and having that pass the ROLE:USER credentials through the local NSH where you've launched the GUI. However, when I look at the agent logs, I'm only seeing an entry for root with 'host not authorized' messages.
If I add an entry for root, I can then run the 'NSH Here' command successfully. I just can't seem to get 'NSH Here' to pass ROLE:USER. Anyone else seeing this?
This doesn't seem to be a reproducable error for us anymore. We had just finished upgrading the app server from 7.0 to 7.0.1, and after restarting the app server and client, and re-launching a new session to the app server, we are now seeing the correct ROLE:USER entries in our rscd.logs.
It's strange through, the old incorrect entries are there from before, and while we're performing the same actions as we were before, the correct ROLE:USER entries are showing up and we can NSH Here no problem. Must have been some sort of caching issue.