I can access the remote server without problem and I would like to send bwcli command which is a CLI of Broadworks server. I am using a shell code to send the command.
Normally if i want to enter the cli I type bwcli but it is not recognized when doing it remotely so I am sendig this sudo -u bworks /usr/local/broadworks/bw_base/bin/bwcli
instead like this:
#! /usr/bin/expect
expect ":"
send "sudo -u bworks /usr/local/broadworks/bw_base/bin/bwcli\r"
expect ">"
send "?\r"
expect "AS_CLI>"
My playbook is done like this:
-script: /home/ansible/playbooks/David/get_command.sh >> bwcli_login.log
When the playbook is ran it shows OK=1 changed=1 unreachable=0 failed=0.
So I am assuming that it works,but when I go to open "bwcli_login.log" I find it empty.
This is only my first step in the code I would like when I enter the CLI the I send some other commands to retrieve some information for the server. And it is annoying that I am stuck at the first step :(
I appreciate if somebody can tell me why the file output file is empty? What I am doing wrong?
Is it works when you manually run the script on the remote server without ansible ?
You can execute a script with different user without using sudo su <username> in your script, also check/share the output from ansible with stdout_lines, it will be easier to debug.
script:
#! /usr/bin/expect
expect ":"
send "/usr/local/broadworks/bw_base/bin/bwcli\r"
expect ">"
send "?\r"
expect "AS_CLI>"
ansible:
- name: run script
script: /home/ansible/playbooks/David/get_command.sh
become: yes
become_user: bworks
register: out
- debug: var=out.stdout_lines
Have you tried to use ansible expect_module ?
I am not famialer with BroadWorks at all, but maybe you can try to do something like the below example.
You will need:
The command module takes command to run,
responses - Mapping of expected string/regex and string to respond with. If the response is a list, successive matches return successive responses.
http://docs.ansible.com/ansible/latest/expect_module.html
I am not sure if the below example it is what you need or if it will work, just something to work with.
- name: expect test
expect:
command: /usr/local/broadworks/bw_base/bin/bwcli
response:
'>': "?\r"
You must consider that when in the BroadWorks CLI, the 'cd' command acts similarly to the equivalent shell command to navigate from one CLI context to the other. However, I'm not sure there is a root as in 'send "cd /Monitoring/Report"\r'.
To get back in the root of the CLI, you could use: 'send "qa; cd Monitoring/Report;"\r' instead.
Furthermore to verify that you moved to the right CLI context, you might want to ' expect "Monitoring/Report>"' intead of '>'.
Note that expect could be used to define functions.
I had the same issue. I found that you need to run the bwcli command with the -nobash option.
Playbook:
- name: Play 1
hosts: mediaservers
tasks:
- name: Play - 1 change to bwcli using script
script: /etc/ansible/bwcli.sh
args:
executable: /usr/bin/expect
register: bwcli_output
- debug: var=bwcli_output
Expect Script
#!/usr/bin/expect
# This will set a timeout for each send command sent to remote server
set timeout 20
spawn bash
send "bwcli -nobash\r";
expect "*_CLI*"
send "int;snmp;v3u\r"
expect "*V3Users*"
send "delete bwems\r"
expect "*Warning: The SNMP Agent needs to be restarted*"
send "get\r"
expect "*_CLI*"
send "exit\r"
expect "*Yes*\r"
send "Yes\r"
expect eof
Related
I'm writing a script that will scp a tar file from my local server to a remote host. Since the script generates the file through a pre-requisite process, the name is generated dynamically. My script needs to take the name of the file and pass it to scp for transfer.
#!/usr/bin/expect -f
spawn scp test.$(date +%y%m%d_%H%M).tar user#IP-ADDRESS:/destination/folder
set pass "password"
expect "password: "
send -- "$pass\r"
expect eof
I've tried setting the filename as a variable but keep seeing the same error:
can't read "(date +%y%m%d_%H%M)": no such variable
while executing "spawn scp test.$(date +%y%m%d_%H%M).tar user#IP-ADDRESS:/destination/folder"
$(date +%y%m%d_%H%M) is not a Tcl command. If you use expect, you have to learn Tcl. To get a formatted date in Tcl, use the clock command. Also, interpolation of the result from a command in Tcl is not done by $(....), but by [....]. You can find examples for this construct here.
Decided to go another route since the team was able to provision a new Artifactory repo for this binary and alike. However, to the advice provided here I was able to make a few discoveries which I used to fix my issues:
I also had a password with $ symbol and that also caused a world of issues.
#!/bin/bash
TEST=$(date +%y%m%d_%H%M)
/usr/bin/expect <<eof
set password {pas\$word}
spawn scp "$TEST" user#IP-ADDRESS:/destination/folder
expect "*password:"
send "$pasword\r"
expect eof
I'd like to automate getting diagnostic files from a controller that responds to ssh commands, like e.g.
ssh diag#controller tarred > diags.tgz
Unfortunately, I have to type a password to make the above command go through.
What have I considered to get around that:
using ssh keys: not possible, since I can't login to the controller, it just expects commands and doesn't offer a shell
using ssh-pass package: I don't have admin rights on the machine and can't install packages
using "expect": works to some extent, but the resulting file is corrupted.
Here's the "expect" script I've used:
#!/usr/bin/expect -f
log_user 0
set timeout 300
spawn ssh diag#controller tarred
expect "?assword:"
send "unrealpassword\r"
expect \r\n
log_user 1
expect eof
The script makes sure that only the required output gets stored with the "log_user" commands until eof is encountered.
I've piped this script to a file and that file is corrupted, i.e. it's either too short (because of a timeout?) or too long (?).
Any idea about what goes wrong here.?
I am trying to let non-admin users run a script in a shared environment that requires root privileges. I was going to build either an AppleScript or Automator application that invokes expect in order to pass the login credentials (yes, I know the dangers, it will all be execute only). However I get the login to work, but the shell script I am trying to run doesn't seem to be executing, since it returns instantly. I am new to expect and I believe I have an error in my script. Ideas anyone?
#!/usr/bin/expect
set timeout 60
set password "MyPass"
set command "bash /Applications/mampstack-5.4.36-0/ctlscript.sh start"
eval spawn login admin
expect "assword:"
send "$password\n"
expect "$"
send "$command\n"
expect "$"
send exit
expect "$"
send exit
Don't do it that way. Instead, edit /etc/sudoers to add the following lines (or, on a default config of MacOS, you can create a file in /etc/sudoers.d with the following content):
# allow use by GUI apps (AppleScript, Automator), which don't have a TTY
Defaults:%staff !requiretty
# on MacOS, all humans are members of the staff group
%staff ALL=(ALL) NOPASSWD: /Applications/mampstack-5.4.36-0/ctlscript.sh start
...then, have your AppleScript or Automator code run:
sudo -u admin /Applications/mampstack-5.4.36-0/ctlscript.sh start
...which will require no password at all.
I'm trying to automate a startup of a specific service with bash
When the service is started with init.d (/etc/init.d/openvpn.custom) it is promting for username and then password - and then it connects
The auth-user-pass from-file is not possible with the installed version, and it cannot be upgraded because of dependencies
So i'm trying to write a simple bash scripts that executes the init.d script, sleeps for a bit, inputs the username, returns, sleeping a bit, inputting the password - you'll get the flow.
like http://pastebin.com/qWHX7Di5
I've experimented with echo, but it doesent seem to work
This is for a rather legacy firewall i'm asked to keep connected.
Is this even possible?
I would use expect instead of bash. You can still call it from within bash if you need to do other tasks as well.
In expect, the script would be something like the following (untested):
#!/usr/bin/expect -f
set username "username"
set password "password"
spawn /etc/init.d/openvpn.custom start
expect "Username:"
send "$username\r"
expect "Password:"
send "$password\r"
expect eof
You'd want to change the expect "Username:" & expect "Password:" lines to match the actual login prompts that are output by your init.d script.
See the expect man page for further details.
You can try using a here-doc:
/path/to/init.d << END
$username
$password
END
Using the following shell code for remote telnet request:
{
sleep 5
echo admin
sleep 3
echo pass
sleep 3
echo ls
sleep 5
echo exit
} | telnet 172.16.1.1
I want to check if telnet connection was successful or not. Trying to use $?:
echo $?
But it always returns "1", even if telnet connection was OK.
Telnet is exceptionally difficult to script in this way, there is a high degree of asynchronicity with the time it takes to establish a connection and for your intended actions to complete. expect was created for exactly this kind of purpose. You launch a program, like telnet, then declare a series of expectations - eg, when 'username: ' is emitted from the program, and an action to trigger (eg: typing in the username).
There are also libraries or wrappers for expect in many languages:
python expect
ruby expect
perl expect
Here is an example that drives telnet to make an HTTP HEAD request:
set timeout 20
spawn telnet localhost 80
expect "Connected to "
send "HEAD / HTTP/1.0\r\n\r\n"
expect "HTTP 200 OK"
Given all of this, I feel I must point out that telnet is considered insecure. Ssh is a much better choice and supports better choices for authentication (eg: public/private key auth), restrictions for commands that can be run (via .ssh/authorized_keys). With ssh, and ssh-keys set up, your script reduces to a single shell command:
ssh user#hostname ls
ssh has great support for safe, secure remote command execution.
If I'm remembering correctly, this expect script does what you're doing above.
#!/usr/bin/expect
spawn telnet 172.16.1.1
expect username:
send admin
expect password:
send pass
expect "\$ "
send ls
expect "\$ "
send exit
Here's a useful link for getting started: http://oreilly.com/catalog/expect/chapter/ch03.html