-
-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Concrete Minimal Shell Implementation #79
Comments
Hmm, that's not the behaviour I'd expect for the minimal shell -- could I see what your invocation looks like? |
Sure, by the way my code runs from a Windows 10/ Windows 2012 Jump clients that run python 2.7.15 environment. I basically have a Wrapper/Bridge Class that wraps around the ShShell class to run the commands:
I essentially have a batch cmd script that wraps around the python script. On the command line you type: I use argparse to get the command line parameters being passed at the windows command prompt, which passes it onto to a controller class which instantiates and executes the EsxiNode class I shared above. I was doing some testing today printing out what the different Spur shell Types generate and this is what I see:
It looks like both shells are converting the commands from string obj to unicode string obj. Just curious for my understanding why is it necessary to do this unicode conversion? |
Unicode is used to make compatibility between Python 2 and 3 easier, and also to avoid encoding errors. When you run a command, could you check the values of:
|
Thanks for the advice. So I added some print statements to check the values along the way. Here is the output of the commands as it passes a long the ShellType and ShShell Classes:
To me it looks like the problem is how the command is being sent down the wire to iDRAC environment as
As a test I modified the
Re-ran the command and it worked:
The command is being passed as a single unquoted string. I know the iDRAC is a stripped down Linux that uses BusyBox but also implements the Server Management Command Line Protocol (SM CLP) Specification which is a general out-of-band hw management command prompt. From reading the Dell docs I believe is the command line prompt you are dropped into when you establish an SSH session to the iDRAC environment directly. I believe a lot of other Server HW platforms uses this as well (HP iLO/IBM IMM2) but I'm not 100% certain since it's been so long since I've worked on them. So I guess the questions would be: Should Spur include a separate Base It would be nice if Spur offered this type of base functionality to user's out of the box? |
Thanks for the details. Just to clarify one of your earlier messages: when is Does the shell you're describing support any escaping? Adding in another shell type, or parameterising the existing shell type, seems reasonable. |
So that seems to only get generated if I instantiate the ShellType classes myself like below but forget to split the string to an array. That was how I was initially doing my testing to try to understand what the ShellType classes were generating for a command. That's what tipped me off that the single quotes were what was causing the problem. I only realized that after I did the extra testing your were describing to do.
When I split the string properly like so Yeah, it does this is the following regarding escaping from the SM CLP Specification:
But me personally I've never had to escape anything. It's typically used to run simple verb commands with options for CRUD type operations regarding the Server HW. The command line processor is a simple message/response architecture. It's meant for simple actions nothing advanced. |
Hmm, the simplest thing might be to add an argument to shell_type = MinimalShellType(escape=lambda arg: arg) |
Good point, I didn't think of that. I guess it would make the
That would mean we would need to modify the
Or do we leave that as is and have users that want the custom escaping to instantiate the |
I'd leave |
Thanks! I'll file a Pull Request this weekend with the code changes. |
Hi Michael,
I've been using the Spur library this past couple months to build some tools to remotely manage scaled out systems in our lab. It's a good tool, offers a high enough API that I don't need to work with Paramiko directly but low enough that I don't need the extra abstraction that Fabric offers.
I mostly work on Dell Platform and sometimes we need to log into the out-of-band embedded system management environment(DRAC/iDRAC) to manage and monitor the HW. I tried using the out-of-box ssh.MinimalShellType included with the library but I found that the iDRAC kept failing with command syntax problems. After some digging and troubleshooting I found that the MinimalShellType was still escaping the string being passed in
When I printed out what the MinimalShellType class was generating for a command it was something like this:
'r' 'a' 'c' 'a' 'd' 'm' 'g' 'e' 't' 's' 'y' 's' 'i' 'n' 'f' 'o'
Which the on-board DRAC environment did not understand so it considered it a Syntax Error. To workaround it what I did was subclassed the ssh.MinimalTypeShell Class and created my own DracMinimalShellType class that overrides the generate_run_command() method. The only real change I made to that method was to NOT escape the string passed to the Shell class using the escape_sh(). It just passes it on through
That way what get's executed is:
"racadm getsysinfo"
Is it to be expected that the library is still escaping the string for MinimalShellTypes? If not, I can submit a pull request to fix that.
If it is, what is your stance on including concrete MinimalShellType implementations like I did above in the Spur Library? Or do you think that should stay higher level in the application using the Spur library? If we do include it the only other required change would be to include the concrete implementation in the ssh.ShellTypes class:
Looking forward to hearing what you think.
Thanks,
Danny
The text was updated successfully, but these errors were encountered: