Re: [9fans] consterm

["ron minnich" <rminnich@gmail.com>]

I use xcpu for a lot of what you are talking about. I'm using it now
on a small PNFS cluster I built. If I want interactive access ...
xcpu <some nodes> /bin/bash

done. And the bash comes from my machine so, if the nodes are busybox
nodes (they usually are) then I need not worry that they don't have my
binaries.

But, that said, I keep cursing my bad luck in not having a real cpu on
linux. I could use your consterm for things I'm doing. I'm finding
that xcpu is fine for some things, but cpu really is nicer. I'm
considering adding namespace support to xcpu so that when you start
(e.g.) a shell via xcpu, once the shell starts up, its namespace is
there. Hmm, I just recreated cpu -- save that I can run without the
name space stuff -- it's optional. And, cpu doesn't do the nice tree
spawn stuff that Lucho put into xcpu.

Note that we did this on bproc, 5 years ago, and it was pretty nice.
We could define the namespace for a process, and then start the
process up on 1024 nodes and have them all start with the desired
namespace. Handy!

one thing you can't easily do on cpu, though, that xcpu is nice for:
xcpu md,d1,d2,d3 fdisk /dev/sda

(gets me 4 parallel interactive fdisk's on the four nodes md,d1,d2,d3
-- it seems weird but worked wonderfully well. cpu is just not set up
to do this type of thing, and neither would your consterm be).

It seems to me from watching it that the real weight in 'cpu' is in
the all the stuff that gets run when you log in, not necessarily cpu
itself. That's not too hard to get around.

All this points (to me) to the fact that we have not really reached
the final answer on the things we want to do with remote access. Or,
maybe, there's no final answer at all.

ron