Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

problem the OpenSession in an Expect Script

24 views
Skip to first unread message

pvinn...@gmail.com

unread,
Sep 17, 2015, 4:19:07 PM9/17/15
to
Hello,
I am tasked with solving a problem with Expect script. I'm a newbie to the Tcl/TK, Expect world.
We have this script for installing software remotely, that has been working for quite a while. Recently, there has been an upgrade in the environment to Linux 1.6, and the script stopped working.
It looks like the following is failing:

if {[OpenSession $HostID $UserName $Password $Prompt $HostID $CONNECTION_TYPE]!=1} {
LogMessage e "Cannot determine uname information : Could not open session to $HostID"
set timeout $oTimeout
return -1
}
Can anyone please give some insight as to why it is failing? Is there an alternative to OpenSession providing same functionality?
Any help is greatly appreciated.
TIA,
Prasad Vinnakota

Rich

unread,
Sep 17, 2015, 6:56:21 PM9/17/15
to
pvinn...@gmail.com wrote:
> Hello,
> I am tasked with solving a problem with Expect script. I'm a newbie
> to the Tcl/TK, Expect world.

> We have this script for installing software remotely, that has been
> working for quite a while.

> Recently, there has been an upgrade in the environment to Linux 1.6,
> and the script stopped working.

There is no such thing as "Linux 1.6". There might be some distro
(i.e., Redhat) which might be at version 1.6, but a specific distro is
not "Linux".

> It looks like the following is failing:

> if {[OpenSession $HostID $UserName $Password $Prompt $HostID $CONNECTION_TYPE]!=1} {
> LogMessage e "Cannot determine uname information : Could not open session to $HostID"
> set timeout $oTimeout
> return -1
> }

> Can anyone please give some insight as to why it is failing? Is there
> an alternative to OpenSession providing same functionality?

"OpenSession" appears to likely be a command defined in the expect
script itself, because it is not a standard command provided by the
expect package. so you will have to look elsewhere within the expect
script to find the definition of "OpenSession" to see what operations
it performs.

However, the log error message the author included gives you some
clues. It seems to be expecting a certian output from the uname
command, and either uname is not installed (unlikely, but possible) or
the format output for the new uname has changed in some subtle way from
your old environment and it is causing the expect script to fail.

Bezoar

unread,
Sep 18, 2015, 10:21:25 AM9/18/15
to
Prasad:

Expect has some functions that you can set to enable debugging. so prior to the call to OpenSession set the following:

exp_internal 1 ;
log_user 1;

with these set to 1 you will get volumnous debugging output and you should resolve the problem. Likely because you have recently upgraded the linux box, and because it is alsor likely the connection is via ssh, you should check to see if the sshd daemon is enabled and running. Recent linux distros use systemctl rather than the traditional init.d means of starting services. If it is RedHat then I think ckconfig command will still work to determine if the sshd daemon will automatically start at the runlevel you use. Because you pass the password then certificates are likely not used so check that the user has an entry in /etc/passwd and a password in /etc/shadow. In /etc/passwd make sure the user has a login shell (e.g. /bin/bash ) and not /sbin/nologin. There is a possibility that the new linux distro may not allow antiquated password hashes like md5 but rather some version of SHA password hashes. So rather than copying the users password line from an old linux box to the new you may need to use the passwd command to set the password(you'd have to know the password in that case, and you should as its somewhere in the script). And if the user is root( as you did mention it was for software upgrade/install) check the sshd config where it is likely that root login is configured to be disabled by default ( /etc/sshd/sshd_config ). Check the firewall settings to see if the ssh port is open. I could go on but I'm sure the debugging output will pin the problem down pretty quickly.
0 new messages