13 Replies Latest reply: Jun 13, 2006 2:51 PM by gkullberg RSS

NSH User ID

Robin Spinks

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

    or

    host% cd //host1
    host1% agentinfo

    In each case the output is something to the effect

    hostname:
    Agent Release : 6.2.1.118
    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
    Robin Spinks

    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
    Sean Daley

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

  • 4. Re: NSH User ID
    Andrew Knott

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

    02/24/05 13:17:15.400 INFO rscd - 54.23.33.72 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
    Tim Fessenden

    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
    Andrew Knott

    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
    Robin Spinks

    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
    Andrew Knott

    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
    Robin Spinks

    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
    Andrew Knott

    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
    gkullberg

    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
    gkullberg

    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.