remote execution with TCL
k:arel
command
currently, i'm trying to remote login via the [exec] command:
exec $::env(SHELL) -c "rlogin myserver; ..."
executing this TCL script, makes my konsole hang (probably because it
expects input from me; no CTRL+C escape possible!)
reading the TCL wiki and searching this group ("
rlogin shell -expect -spawn" gave little solution) i only came up with
one clear solution:
1. installing [expect] and using it in combination with the [spawn]
command
yet other options may be possible:
2. i log in at the server and run the script, which will be central
installed, from this server
3. i make a special module which will be executed from within a bash
script, which logs in at the servers and yet executes the particular
TCL command
all of these options are not acceptable:
1. we're supposed to avoid extra installations and if there will be
any, the less the better (i already pushed Tix forward)
2. we don't know on which server the script will be executed because
this option is to be set in the TCL GUI
3. this is dragging the problem to a different location and is not a
solution
am i missing something here?
should i push the admins to installing expect?
Donal K. Fellows
If possible, use ssh (or plink on Windows) instead of rlogin/rsh, as it
is easier to automate and secure as well. (Arguments that "it's behind
a firewall so it doesn't need to be secure" end up producing a system
that is fragile; any breach of security becomes a catastrophic system
failure. Real secure systems use security in depth.) If your admins are
resisting installing ssh daemons on their servers (!) it's time to
either get new admins or pack your bags and leave yourself. Once you
are using ssh, automating login becomes fairly easy (you have to do
some futzing around with RSA keys, but you can set that up once and
expect it all to work cleanly from there on.)
Ideally, you should arrange for whatever code you run on the remote end
to *not* require interactive user input. Staging a file across using
scp/pscp and then using that as the input is much easier to make work.
Once you're doing that, you should be able to make the whole thing not
require any input under any circumstances, and if you're just parsing
output, it's much easier to automate processing.
If that's still not possible, and you really need interactive control
over the remote end, expect *at the local end* is the best approach.
But for many tasks (especially ones that are largely sysadmin tasks)
running small non-interactive commmands over many ssh connections (a
few per connect, as determined by what is a meaningful unit of work
from your application's PoV) works nicely.
If, having gone through all this brain-dump of mine, you still want to
mix together expect and rlogin, send another message to this newsgroup
giving a few more details. :-)
Donal.
eck...@web.de
Eckhard
k:arel
it ever by secure enough?) and the ssh daemons are installed and usable
when using [ssh] my command would look something like:
proc main {} {
#...
set dir "./DIR/"
set login "ssh myserver"
set path "set path=(\$path /path/to/dir)"
exec $::env(SHELL) -c "$login ; $path ; PROG < input_PROG > mylog ;
$dir/compiled_res"
#...
}
if {[catch main err_msg]} {
#...
}
(well, you asked for more code... ;-) )
it would be hard using [ssh] without supplying a password or something
else, i guess.
even if you can automate it as much as possible, when ssh ones asks for
user input, the program will hang
you may ask yourself: why login at another PC?
it's a platform issue...
i've got another challenge for you
Picture this:
you have a list of servers and you want the cpu-load and number of
users logged in;
for this:
1. you need to remote login to each server
2. run the commands (a combination of [ps] and [awk] on Linux)
3. capture the output and feed it back to the TCL script
4. exit the server
this way it isn't possible to make an all-containing command like
above, because feedback is required
knowing this, the only option available for TCL is using [expect] in
combination with [spawn]
thus an install is required :-(
Donal K. Fellows
private key in your local ssh-agent and the public key in the right
spot in the .ssh/authorized_keys file on the target file, and away you
go. Secure, passwordless login.
If necessary, pass the -n flag to ssh so that failure to use the key
results in immediate failure and not a hang. You'll probably want the
-q flag too (except when debugging, when -v is much more useful.)
This all leads to a solution more like this:
exec scp scriptToRun.sh user@remotehost:scriptToRun.sh
set result [exec ssh -nq user@remotehost /bin/sh -c scriptToRun.sh]
That's pretty straight-forward, yes?
Donal.
k:arel
using ssh with key pairs is no option here: we're in an evironment
where the GUI is run on a PC any where in the building by a special
(large) group of users
the GUI should be able to connect with about 5 different servers (not
at the same time)
if we would use ssh, it implies that every user should create a key for
every server
though it isn't necessary to create a key on each PC they would work
with, because the home directories are central managed
options remaining are:
* using expect in combination with rlogin
* using Tcl-DP
* using sockets and writing my own TCL application
expect and Tcl-DP both need to be installed, so we prefer here the
third solution (sockets)
in that case, the client would dynamically build up the command(s) and
contact a service on the server
this service, written in C, runs on a dedicated port and executes the
command one by one with the system() function and sends back the
output:
or by first redirecting it to a file and then reading it,
or by using the popen() function
the client reads from the socket and evaluates the result (maybe write
it to konsole)
after the commands are run, the server/client closes the connection
actually, it's a simplified, self written Tcl-DP
Cameron Laird
k:arel <kare...@gmail.com> wrote:
>sorry for the late reply but i've been studying some possibilities
>
>using ssh with key pairs is no option here: we're in an evironment
>where the GUI is run on a PC any where in the building by a special
>(large) group of users
>the GUI should be able to connect with about 5 different servers (not
>at the same time)
>
>if we would use ssh, it implies that every user should create a key for
>every server
>though it isn't necessary to create a key on each PC they would work
>with, because the home directories are central managed
>
>options remaining are:
>* using expect in combination with rlogin
>* using Tcl-DP
>* using sockets and writing my own TCL application
>
>expect and Tcl-DP both need to be installed, so we prefer here the
>third solution (sockets)
[still more]
.
.
There's a lot in this description I don't understand.
I use ssh hourly withOUT keys (more keyed ssh-ing than in the past, but
I haven't hit 100% yet). While I've tried several times to understand
how your situation *requires* keys, I haven't yet figured it out--so I
conclude perhaps you're still mistaken on that point.
I don't understand the "expect ... need[s] to be installed" claim. I
*think* you're saying that installation of Expect on the five client
consoles where end-users might find themselves is ... an issue. Per-
haps you're not aware that, with the latest release of ActiveTcl,
Expect is bundled (!). If you have current ActiveTcl at all, you have
Expect.
k:arel
>
sorry, i've tried my best to explain it
it sure is a complicated situation
> I use ssh hourly withOUT keys (more keyed ssh-ing than in the past, but
> I haven't hit 100% yet). While I've tried several times to understand
> how your situation *requires* keys, I haven't yet figured it out--so I
> conclude perhaps you're still mistaken on that point.
>
i don't think its very save that in company everyone could ssh to any
server available and execute a certain script
isn't that the whole reason why those keys are invented?
> I don't understand the "expect ... need[s] to be installed" claim. I
> *think* you're saying that installation of Expect on the five client
> consoles where end-users might find themselves is ... an issue. Per-
> haps you're not aware that, with the latest release of ActiveTcl,
> Expect is bundled (!). If you have current ActiveTcl at all, you have
> Expect.
>
that's indeed what i meant: the installation of the Expect (or other
extra) packages should be avoided
we're not running ActiveTcl here, only TCL 8.3 and Tixwish 8.1.8.3
but now considering the socket solution, the security flaw remains
actually it's getting larger: if you're able to contact the server and
send through any command, the possibilities are determined by the user
priveleges of the user that started the service on the server
Arjen Markus
at least akin to your problem:
http://www.dedasys.com/articles/customized_downloads.html
Regards,
Arjen
Cameron Laird
k:arel <kare...@gmail.com> wrote:
.
.
.
>i don't think its very save that in company everyone could ssh to any
>server available and execute a certain script
>isn't that the whole reason why those keys are invented?
.
.
It's possible to configure ssh to require passwords, rather than
keys; in fact, I find the password-requiring ssh easier than key-
ed ssh. In any case, there is at least one more choice beside
ssh-with-keys and everyone-can-get-in-without-restriction.
Benjamin Riefenstahl
"k:arel" writes:
> if we would use ssh, it implies that every user should create a key
> for every server though it isn't necessary to create a key on each
> PC they would work with, because the home directories are central
> managed
I don't understand the problem? The keys are just files, so you can
even create them *for* the users. Each user only needs one key. You
also can create just one single key for all and install a copy on each
user machine. If you prepare keys for the users you will probably
want to use keys with empty pass-phrases, but that is still more
secure than putting a password into some script, because keys are
longer and more random than passwords plus they are usually stored in
a secure place.
benny
k:arel
but i'm wondering if that's a good solution considering the facts:
* the path or source has to be set
* there must be multiple commands send true
* all the output of the commands should be send back to the client,
evaluated and, if OK, the next command will be send
i find this hard to do with ssh: if you need to set the path, you're
required to do this every (!) time you send through a command
also capturing the output is no piece of cake
so i started checking out the possibility of using a C implemented
service
for you guys, i've created a shedule with Graphviz available here:
http://users.skynet.be/nijs.vanheusden/_rommel/rem_exec.ps
(PostScript format)
when using C, executing a command, redirecting it to a fifo and reading
out this fifo to the client is a walk in the park
but, there comes another issue now: the security; any user may send any
command and this will be executed
for this i can use PAM
at least, that's what i'm going to try: the user name and password must
cross the network, which requires some encryption and fed to PAM on the
server
am i hitting a wall here?
i really have no idea...
Benjamin Riefenstahl schreef:
Benjamin Riefenstahl
"k:arel" writes:
> i understand what you mean when talking about ssh
> but i'm wondering if that's a good solution considering the facts:
> * the path or source has to be set
> * there must be multiple commands send true
> * all the output of the commands should be send back to the client,
> evaluated and, if OK, the next command will be send
I didn't see any of this before (I might have missed it, such things
are known to have happened ;-).
> i find this hard to do with ssh: if you need to set the path, you're
> required to do this every (!) time you send through a command
The computer does the work. Just capture your requirements in a Tcl
proc or script or whatever.
> also capturing the output is no piece of cake
Just do
set result [exec ssh $host $script]
and it's "captured" in "result". What am I missing?
If you don't want to encapsulate your commands in individual shell
scripts, executed individually, you can start a service on the other
side as in (untested code):
set pipe [open |[list ssh $host tclsh $serverscript] r+]
Use "puts $pipe $cmd" and "gets $pipe" to communicate. $serverscript
would have to exist on the other side, of course or you can put just
it there with scp before executing it. The script would accept
commands as lines using "gets stdin" and return results as lines using
"puts". In the simplest case the server script would just use "eval"
to execute the commands as Tcl scripts, and it would have a proc
predefined for each command that you need.
> so i started checking out the possibility of using a C implemented
> service for you guys,
You should of course use whatever gets you where you want to go
fastest.
You can expect Tcl answers in a Tcl newsgroup, though ;-)
benny