On Nov 30, 2008, at 1:45 AM, David Jencks wrote:
Hi Jason,
This sounds very cool but I don't understand exactly what the ssh
functionality gets us or what your vision of shared commands between
the web console and gshell looks like.
First some background...
In the beginning there was telnet, then custom protocol (tcp or ssl)
and now there is only ssh. All of these being ways which a user can
remotely connect to gshell and execute commands. The custom protocol
stuff (whisper) had a significant disadvantage in that users had to
have the gshell code-base already installed, with the right version of
java, etc in order to make a connection. With telnet most telnet
terminals worked, but its not a secure protocol so not a viable
enterprise solution. With ssh, any ssh client (java-based or native)
can be used to make a secure connection. And most unix systems do end
up having ssh, so its the perfect solution for cli-savvy administrators.
IIUC right now communication between gshell and a geronimo server is
via jmx, which optionally can be using ssl. Again IIUC there's no
requirement that the geronimo server be on the same machine as gshell.
Correct there is no requirement, but what he have right now is, gshell
launching the server, leaving 2 java processes, so gshell is sitting
"next to" the server. This gshell is ideal for controlling the server
process, so a user might want to connect that that specific gshell jvm
and run a command which would restart the server process, clone the
process or start up a new sever. All this with out having to waste
another jvm per server. Basically the "next to" gshell process
becomes control process. It can even be used to automatically restart
the server if it crashed or wedged.
Another option is to create a GShellGBean which will run shell
commands *inside of" the server jvm. This set of commands may include
running a sshd command, and probably even support an automatic
connection to support the geronimo commands.
GShell now supports a lot of VFS commands to deal with files, so it
makes it very simple to install files, delete files, or even edit
files, and with the TrueZIP components enabled, you can even edit
files inside of jar files. This is all done via GShell commands,
nothing connected to the server via JMX.
We don't have the ability to start a geronimo instance on another
machine at the moment, but once one is started I don't quite
understand what ssh adds to the picture. With the ssh stuff can you
start a gshell + g. server on a remote machine?
AFAIK its not going to be possible to launch new servers on remote
machines unless that remote machine supports some kind of standard
configurable remote process management daemon. And I'm not talking
about [x]inetd or the like. I guess I see gshell as being that
daemon. So if you have say 100 machines to work with, you install
gshell, then configure it to boot up with the system and execute its
sshd command. Then on your remote administration system, you can
easily write a simple script to go to each of those 100 machines, ssh
into them and run the start-server command, or whatever.
With GShell's support for remote repositories, via Apache Ivy or
Apache Maven (maven-artifact v3) you can install the relatively small
(2-3m) GShell, and use remote repos to distribute/update/manage your
application installation.
How is this different from just ssh-ing into the machine from a
normal terminal session and running gshell?
One key difference is that authentication mechanism is not directly
tied to the systems authentication bits. So a user can log into
gshell's sshd w/o needing a *real* user account on the system its
running. Of course you could configure gshell's sshd to use system
auth if you wanted, all depends on how you choose to manage users on
your systems and if you prefer having app + system users unified or
diverse.
Another difference is the number of processes needed in your scenario:
* ssh-ing into the machine, sshd usually forks
* then has to runs your native shell
* probably runs some other muck in the process
* then the shell script to launch gsh
* which runs the jvm script,
* which finally launches a native jvm process)
Where, using GShell's sshd there is no additional processes spawned,
just acquisition of pooled threads. And since GShell is already
loaded, any time spent loading command plugins which might slow down
gsh's boot, has been done, so the sshd gshell is more responsive for
quick operations. And because you are connecting to the same jvm, you
have access to shared state.
Or the memory/resources required to fire up another jvm.
On the matter of SSL vs SSH, I'd say that system administrators are
going to be more familiar with SSH key generation and management than
they are going to be for SSL. And with SSH there is no need to go
muck with keystore passwords (putting them in plain text, ick) or
installing root certificates into a jre, etc.
As for commands, my view is that both gshell commands and web
console portlet code consist of collecting the information needed
for calls to gbean operations. While the portlet code is generally
horrendously complicated and difficult to understand I don't really
see how more of this data-collection-from-the-user code could be
shared between the web console and gshell. Do you have a simple
illustration in mind?
It was just something I had been pondering for what seems like years
now, still not sure. I think what I need to do first is to try and
implement some more commands which implement console/portlet
functionality... especially with ones which list data, that have
buttons on those lists (like the JMS admin stuff for example). Then I
will have a better idea.
But I guess I'm thinking that there might be a way to create a common
model for the data mined from the server, displayed and prompted
for... which could then be used by a portlet or command. This way the
data would be the same in both, just the method of rendering/prompting
would differ.
Anyways, right now its still just a clump of thoughts bouncing around
in my head. Need more practical experience first with it before I can
craft a framework concept out of it. But it seems like it would be a
good idea, as that would enable other console platforms to all use the
same bits. Say if someone wanted to write a Swing console, or a
Eclipse plugin console, etc...
--jason
