Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have 47 Linux client machines and one Solaris server machine (all Linux client machines are red-hat 5.1)

all clients perform ssh connection to the server in order to verify if /tmp/generic_error.txt exist in the server

clients do the ssh exactly on 12:00 PM

I see something strange

Some of clients not recognized that /tmp/generic_error.txt exist in the server in spite this file was exist

So my first conclusion is that I can't perform multiple ssh from 47 machine to one server ?

But I don’t sure if I right ?

Please advice what the best process to perform ssh from 47 Linux clients to one server exactly on the same time?

remark - I can’t touch and configure the "ssh key-based authentication" because the Lenox’s machines must have password (part of our security policy)

  • example of the expect script in the linux's clients - this expect verify if /tmp/generic_error.txt exists in the server (this action should be performed exactly on 12:00 PM on all 47 linux clients)

10.10.18.61 - server machine

 expect=`cat << EOF

 set timeout -1
 spawn  ssh  10.10.18.61
       expect {
                 ")?"   { send "yes\r"  ; exp_continue  }

                 word:  {send freenelsonmandela\r}
              }
 expect >  {send "ls /tmp/generic_error.txt\r"}
 expect >    {send exit\r}
 expect eof
 EOF`

exe expect:

expect -c  "$expect"  | grep "generic_error.txt"  | grep -v ls
share|improve this question
    
I would advise against using expect paired with ssh in such a way. You should probably set up (passwordless) public key authentication instead: debian-administration.org/articles/152. It's simpler in the long run, and more secure. –  Eduardo Ivanec Feb 12 '12 at 15:57
    
Yes, expect is probably not a good idea. I don't see in the script that you ever check for the answer for the ls. Idea: You could also copy the file with scp to the local machine. If it's there after the scp, you know it exists on the server. –  AndreasM Feb 13 '12 at 12:17
    
About scp I also must use the expect script in order to automate the password , Any way what’s the alternative for expect? this is only the single way to remote to other machine when need to enter the password –  Eytan Feb 13 '12 at 15:12
    
@Eytan, look at Eduardo's first comment. You can set up SSH key-based authentication, where you don't need to supply a password. It will be MUCH better to do that than trying to manage everything in expect. It probably wouldn't hurt to introduce some slightly randomness on the start time for the job. Yeah, handling 50 simultaneous ssh connection requests at the same time may be OK, but why do it unless you have to? –  cjc Feb 13 '12 at 15:26
    
hi CJC – look about "SSH key-based authentication" the problem is I can’t touch and configure ssh key-based authentication because the Lenox’s machines must have password (internal security policy in our company) this is the fact and I can’t change it , so I must to find other solution ........ –  Eytan Feb 13 '12 at 15:32

1 Answer 1

up vote 0 down vote accepted

If i understand correctly, you have 47 clients that need to know if some file exists on serverhost. And this needs to be run all at the same time.

Lets start with the smallest component, your file test. You can expand this some

This should work with most shells

ls /tmp/file 2>&1 >/dev/null && echo Found || echo Not Found

Or BASH

[ -f /tmp/file ] && echo Found || echo Not Found

You may want to check around more for the shell you are using, likely ksh, and double check its builtins for checking to see if a file is present.

Now slightly outwards, at the end of your expect, you are not doing anything with the results. this is likely the cause of most of your issue. you can access $expect_out(buffer) which will contain what ever was between the last matches.

typically this is used as:

puts "$expect_out(buffer)"
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.