geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: GShell Update
Date Sun, 30 Nov 2008 05:48:28 GMT

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


Mime
View raw message