13 Replies Latest reply on Jun 13, 2006 2:51 PM by Greg Kullberg

    NSH User ID

      Does anybody know how to tell, from within an NSH shell, what userid will be used to communicate with agents?


      If I run id[/I] it just gives me the user from the OS.

        • 1. Re: NSH User ID

          The command you want to use is agentinfo. It

          can be used in two ways:

          agentinfo host1 host2 ...


          host% cd //host1
          host1% agentinfo

          In each case the output is something to the effect

          Agent Release :
          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


          • 2. Re: NSH User ID

            Hi Thomas,


            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.

            • 3. Re: NSH User ID

              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 - 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).

              • 4. Re: NSH User ID

                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:


                From nsh1:

                USWSCO31337% cd //lxwsit871/

                cd: no authorization to access host: //lxwsit871/


                From nsh3:

                USWSCO31337% cd //lxwsit871/

                lxwsit871% ls

                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 - 10693 0/0 (Knotta): agentinfo: Host not authorized

                02/24/05 13:17:15.400 INFO rscd - 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).

                • 5. Re: NSH User ID

                  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)?

                  • 6. Re: NSH User ID

                    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:


                    -g, --group

                    print only the group ID


                    -G, --groups

                    print only the supplementary groups


                    -n, --name

                    print a name instead of a number, for -ugG


                    -r, --real

                    print the real ID instead of effective ID, for -ugG


                    -u, --user

                    print only the user ID



                    We could add an additional option for id:


                    -b, --bladelogic

                    print the BladeLogic Role:User

                    • 7. Re: NSH User ID

                      I like Andrews -b option.

                      • 8. Re: NSH User ID

                        If you use nexec -e you get the correct Role:User ouput.


                        nexec -e id

                        • 9. Re: NSH User 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).

                          • 10. Re: NSH User ID

                            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.

                            • 11. Re: NSH User ID

                              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.

                              • 12. Re: NSH User ID

                                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?

                                • 13. Re: NSH User ID

                                  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.