Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
If these machines really are RHEL why aren't you using the support you've paid for?
That's not a rhetorical question. However, regardless of the answer, I'm writing to discourage the use of "expect". There must have been an article or podcast mentioning it, because there have been a lot of people bringing it up recently instead of using safer methods.
For safety, ease of use, and efficiency, I'd use special-purpose keys with or without an agent instead of "expect".
Code:
mkdir -m 700 redhat_keys
cd redhat_keys
for sys in $(cat redhat); do ssh-keygen -t rsa -b 2048 -f uptime_rsa_${sys} -N '' ; done
sed -i 's#^#command="/usr/bin/uptime -p" #' uptime*.pub
Then put the public keys on their respective target hosts using "ssh-copy-id" and verify that you can log in using the keys.
Thereafter all you have to do is log in using the keys to get the uptime:
Code:
cd redhat_keys
for sys in $(cat redhat);
do echo "ssh to $sys ...";
ssh -i ./uptime_rsa_${sys} -o IdentitiesOnly=yes $sys;
done;
Last edited by Turbocapitalist; 09-27-2016 at 05:30 AM.
There are interesting tools to automate some part of this process. I transfer keys to my servers so I can ssh without passwords, then us mpssh to generate the data for additional filtering. When using mpssh you have a hosts file ( in ~/.mpssh ) that lists the hosts you will work on, optionally separated into lists using labels.
There are other tools similar to mpssh (dsh, etc) that work on multiple hosts, either in parallel or sequentially).
This is not the kind of thing I would use expect to automate. That said, I can see how it might well work as an exercise used to get someone to LEARN expect! Could this be a teaching/mentoring issue?
Google searches finally found something that works more to what I want (for now -- {now I need to get it to ready encrypted password})
------------------------------
#! /usr//bin/expect
set timeout 20
set user [lindex $argv 0]
set password [lindex $argv 1]
set prompt "$ "
;# -- main activity
proc dostuff { currenthost} {
;# do something with currenthost
send -- "ls -lrt\r"
return
}
;# -- start of task
set fd [open ./hostlist r]
set hosts [read -nonewline $fd]
close $fd
foreach host [split $hosts "\n" ] {
spawn /usr/bin/ssh $user@$host
while (1) {
expect {
"no)? " {
send -- "yes\r"
}
"password: " {
send -- "$password\r"
}
"$prompt" {
dostuff { $host }
break
}
}
}
expect "$prompt"
send -- "exit\r"
}
expect eof
Replaced send -- "ls -lrt\r" with send -- "uptime\r" : to get the result I was looking for.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.