I am trying to run a series of commands to configure a vlan on a Dell EMC OS10 server using Paramiko. However I am running into a rather frustrating problem.
I want to run the following
# configure terminal
(config)# interface vlan 3
(conf-if-vl-3)# description VLAN-TEST
(conf-if-vl-3)# end
However, I can't seem to figure out how to achieve this with paramiko.SSHClient().
When I try to use sshclient.exec_command("show vlan") it works great, it runs this command and exits. However, I don't know how to run more than one command with a single exec_command.
If I run sshclient.exec_command("configure") to access the configuration shell, the command completes and I believe the channel is closed, since my next command sshclient.exec_command("interface vlan ...") is not successful since the switch is no longer in configure mode.
If there is a way to establish a persistent channel with exec_command that would be ideal.
Instead I have resorted to a function as follows
chan = sshClient.invoke_shell()
chan.send("configure\n")
chan.send("interface vlan 3\n")
chan.send("description VLAN_TEST\n")
chan.send("end\n")
Oddly, this works when I run it from a Python terminal one command at a time.
However, when I call this function from my Python main, it fails. Perhaps the channel is closed too soon when it goes out of scope from the function call?
Please advise if there is a more reasonable way to do this
Regarding sending commands to the configure mode started with SSHClient.exec_commmand, see:
Execute (sub)commands in secondary shell/command on SSH server in Python Paramiko
Though it's quite common that "devices" do not support the "exec" channel at all:
Executing command using Paramiko exec_command on device is not working
Regarding your problem with invoke_shell, it's quite possible that the server needs some time to get ready for the next command.
Quick-and-dirty solution is to "sleep" shortly between the individual send calls.
Better solution to is to wait for command prompt before sending the next command.
Related
Now I am using VMware is based on ubuntu (named OS-1).
When I operate the another VMware (OS-2 is also based on ubuntu) in OS-1,
I would like to send command (OS-1) for executing specific script file from OS-1 to OS-2 and also receive the stdout from OS-2.
Is it possible?
OS-1 :
Receiving the specific command for executing the test.py from webserver.
Sending the command such as "python test.py" to OS-2.
OS-2 :
Receiving the command from OS-1.
Returning the stdout result to OS-1 such as "test script"
*** WebServer(in OS-1) ---> OS1 ---> OS2
test.py
print("===========");
print("test script");
The most obvious solution is to create internal network between those two virtual machines.
When those machines are connected it would be relatively simple to execute command, i.e you may use ssh (hint https://stackoverflow.com/a/3586168/3188346).
It is worth to note that this solution will work if you decide to use other VMs provider or dedicated servers.
Currently I am having an issue with trying to run a process/script in the background[The master starts it on the minion]
The script is something like this:
#!/bin/bash
nohup ping 8.8.8.8 >/dev/null&
And I call it from the master with:
Process-Name:
service.running:
- name: Script-Name
- enable: True
For some reason it gets stuck on the master,I've read a little bit on this issue[it has happenned before apparently] and tried their solutions on it but apparently nothing involving the service state seems to work.
Is there anyway to work around this?
In short, you should configure your script as system daemon first (SysV init.d script, or systemd unit, or ... depends on OS).
Details
The service.running function requires properly configured system service ~ daemon.
For example, on RHEL-based Linux, if you don't see your script name in the output of one of these commands, you should configure it as proper service first (which is a separate topic):
# systemd
systemctl list-units | grep your_service_name
# SysV init.d
chkconfig --list | grep your_service_name
And because you want to start it in background, cmd.run function is not the right tool either:
It will only report successful start of the script without waiting for its completion results.
It will also start new instance of your script every time.
However, if all you simply want is to "fire and forget", use cmd.run.
I just encountered and circumvented a problem in Matlab, but I'm still wondering why this happens, and I also want to leave the information here for future reference.
In Matlab's Parallel Computing Toolbox, the command matlabpool local starts a local pool of Matlab workers which are then used transparently to speed up commands like parfor by distributing processing onto the different CPU cores. I tried to do so on a Linux machine which I connected to through ssh from my home Linux computer. I used ssh without X forwarding because the script I wanted to run only computes and saves the result, but does not produce graphical output.
The problem: matlabpool hung forever, without any indication of the cause. I restarted the remote machine, restarted Matlab, checked for license problems, without result.
The problem was resolved however when I closed ssh and logged back in, this time including the -X option for X11 forwarding – even though then I started Matlab with the -nodesktop option.
Does anyone have an idea why matlabpool on Linux appears to depend on access to X11?
Even though matlabpool starts and communicates with background headless workers, you can still create figures and plots and print/export them as images inside the parfor parallel loop. The following is a valid use case:
matlabpool(..)
parfor i=1:4
plot(..)
print(...)
close(..)
end
To me this suggests that background workers will still depend on graphics capabilities to generate the invisible plots in memory (maybe it's using virtual framebuffers and such). Of course this is just speculation on my part :)
EDIT:
Just to be sure here, can you try the following sequence of commands:
[client]$ ssh -v -x user#server # X11 forwarding disabled
[server]$ unset DISPLAY # clear $DISPLAY variable
[server]$ nohup matlab -nodesktop -nodisplay -noFigureWindows -nosplash \
-r "myscript; quit;" 2>&1 < /dev/null &
Where the script contains a simple parallel test like:
myscript.m
parpool('local',2)
smpd
fprintf('hello from lab#%d', labindex);
end
delete(gcp('nocreate'))
If MATLAB still hangs, try adding the -debug start option:
matlab -debug starts MATLAB and displays debugging information that can be useful, especially for X based problems.
I am running 340 concurrent users to load test on server using jmeter.
But on most of the cases jmeter hangs up and won' t return, even if I try to close the connection it just hangs up. and eventually I have to close the application.
Any idea how to check what is holding the requests and how to check the requests sent by jmeter and find the bottleneck.
Got the following message on closing the thread
Shutting down thread please be patient message
I've hit this several times over the past few years. In each of my cases (may not be in your's) the issue was with the Load Balance (F5) I was sending my traffic through. Basically a property called OneConnect was holding the connections in a time-wait state and never killing the connection.
Run a pack tool like wireshark and see what's happening with the requests.
Try distributed testing, 340 concurrent users is not a big deal, but still you can try if that decreases your pain. Also take a look at the following link:
http://jmeter.apache.org/usermanual/best-practices.html#lean_mean
First check you script is ok with one user.
Ensure you use assertions.
Then run you test following jmeter best practices:
no gui
no costly listeners
You should then be able to see in csv output the longest request and be able to fix your issue.
I also encountered this problem before when I run my JMeter on my laptop(Core 2 Duo 1.5Ghz) it always hang-up in the middle of the processing. I tried to run on another pc which is more powerful than my laptop and its works now smoothly. Therefore, JMeter will run effectively if your pc or laptop has a better specs.
Note: It is also advisable to run your JMeter in non-gui mode.
Example to run JMeter in Linux box:
$ ./jmeter -t test.jmx -n -l /Users/home/test.jtl
I had the
one or more test threads won't exit
because of a firewall blocking some requests. So I had to leap in the firewalls timeout for all blocked request... then it returned.
You are getting this error probably because JVM is not capable of running so many threads. If you take a look at your terminal, you will see the exception you get:
Uncaught Exception java.lang.OutOfMemoryError: unable to create new native thread. See log file for details.
You can solve this by doing Remote Testing and have multiple clusters running, instead of one.
I'm sending a command to a Mikrotik router using Telnet.
telnet 192.168.100.100 -l admin
Password: pass1234
[admin#ZYMMA] > /interface pppoe-server remove [find user=aspeed13]
[admin#ZYMMA] > quit
It works fine.
Now I want to automate it using expect tcl script:
#!/usr/bin/expect --
spawn telnet 192.168.100.100
expect "Login:"
send "admin\r"
expect "Password:"
send "pass1234\r"
expect "\[admin#ZYMMA\] >"
send "/interface pppoe-server remove \[find user=aspeed13\]\r"
expect "\[admin#ZYMMA\] >"
send "quit\r"
It works, but after authentication (line 6: send "pass1234\r") when the Router CLI is loading it freezes for ~10seconds with the following characters ^[[?6c^[[24;3R
Then the scripts runs ok.
My question is why Telnet loads fast when accessed manually and it takes too much time when accessed via expect script? I read in forums about telnet automation they say telnet is slow, but since manually it's too fast why it takes time to load with expect?
What you're seeing is blow-back from terminal negotiation, which is because you're not running in a real terminal. (Strictly, you are – that's expect's magic – but it's not behaving as a normal terminal does.)
The easiest fix is to set the terminal to something else before spawning the telnet session, e.g.:
#!/usr/bin/expect --
set env(TERM) dumb
spawn telnet 192.168.100.100
# Rest of your script goes here ...
Alternatively, you could try to respond correctly to the request to enter VT102 mode and the report of the cursor location (which feels like a lot of work) or you could rewrite your code so that it does everything inside interact (which connects the other end with the real terminal that you're running inside). But if setting an environment variable fixes it, why go to all that extra hassle?
(NB: I suggest setting the terminal to dumb here, but the key is that you want the stupidest terminal that works. Dumb terminals are ideal, because they're just about totally stupid, making it easy to pretend to be them…)
My answer is possibly too late. This is "Telnet autoconfig command"...I was this problem and found at Mikrotik Wiki this solution:
Add +t after login name. This switch autodetect to off.
Example:
send "admin+t\r"
It is works great and not "wait cca 10 sec" after login by expect.
There is link to Mikrotik WiKi help with more "switches":
http://wiki.mikrotik.com/wiki/Manual:Console_login_process#FAQ
P.S.: Sorry for my English.
Did you try with netcat, with telnet emulation enabled?
A little bit late to answer.
But if you want to speed up your character input with expect.
Try to generate the script with "autoexpect" command, which will save the
interaction in a file named "script.exp" in the same directory from where
you ran the command.
For instance:
cd $HOME
autoexpect telnet 192.168.100.100
# some more telnet commands here
exit
All the above commands will be saved in ~/script.exp
About Tcl, I don't know if ths script can be ran via tcl.