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.
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. 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? How is this different
from just ssh-ing into the machine from a normal terminal session and
running gshell?
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?
Many thanks!
david jencks
On Nov 28, 2008, at 5:44 PM, Jason Dillon wrote:
Its been a while, I have been in a lillte bit of a slump. But, some
really cool things have happened in the past weeks which gave me a
nice kick in the ass to move forward.
Thanks to Guillaume Nodet (aka gnodet) GShell now has... SSH
support! Yes you can now use your native/local sshd client to make
a connect to a remote gshell server... which means that if an admin
starts a sshd command on a Geronimo server, then one can ssh into
Geronimo and execute commands.
This is really the basic vision behind gshell... and well, it here
now... an industry accepted secure method to run textual commands on
a remote system! As a previous unix system administrator, I can
tell you... this feature is very powerful... certainly a leg up on
any other app server on the market.
BUT...
To really make it successful... we need more commands. IMO it would
be good if we can find a way to implement web-console and gshell-
console functionality with a common code-base. Most functionality
implemented via the web-based console can easily represented via
gshell, though granted some more thought needs to be applied to deal
with the interface limitations. For example, one can render a page
to collect several inputs at once where a gshell command needs to
prompt for each item in sequence.
I think we can invent some api to allow a gui or tui to be used...
not sure what that is yet, but my guy tells me its going to be
possible.
(A) Web is powerful... (b) Text (ssh) is also powerful. Some
consumers prefer A others do more with B. The current webconsole,
which IMO is quite simple to use provides *A* to folks, but in my
experience more advanced users tend to automated/script in which *B*
is the preferred method.
With GShell I think we are in a very unique position to provide the
*best* ssh/cli administration interface to our application server.
Actually the functionality has been there for a while, though the
new gshell code does simplify things and add some nice new feautres.
To be clear, this is an enterprise feature, as casual users want gui
things, so like an installer, then app icons to run the app, run the
console, etc... But IMO the powerusers who run their enterprise
applications on Geronimo... they might have 100-1k geronimos nodes
and shell-based admin scripting is the only way to operate,... short
of writing custom GUI muck to manage all those systems and their
data... its custom. But by adopting the unix culture which so many
admins are already familiar really opens the door to the use of G in
these sophisticated environments.
* * *
Anyways back to the update. We have SSH/SSHD support! The other
RSH/RSHD stuff is done. cause the new bits are so much better. .
GShell has very rich VFS support, you can cd,ls,pwd,cp all based on
Apache Commons VFS. This means that you can use these commands to
easily transfer configuration files to remote systems (ie. use cp
from a supported filesystem)
Logging configuration can also be updated via the shell now too.
You can set the level of a logger, or add context to thre NDC or
MDC... or reconfigure everything from a new log4j configuration file.
Some other new commands include:
hostname
grep
find
There is still work which is planned for the shell parser to make
better use of command execution results, loop and other common
things which a script might do.
This release of Ghell has knowledge of an artifact repository, and
provides commands to install new plugins dynamically. Installation
will download new artifacts to the repository and load them from
there, The plugin system is still in the works, but right now you
can install new plugins and list those already installed. More work
on the plugin framework is going on, so expect more changes here.
* * *
Nothing is ever perfect... but we try to get close. In that process
along the lines we wan to release the codebase when its relatively
stable/usable. GShell is once again to that point. Short of a few
SNAPSHOT dependencies we are very close to a release.
On the repo issue, I had switched to Apache Ivy. It was smaller and
faster, but it didn't allow the local ache to be m2 compatible, so I
abstracted the artifact resolution stuff to allow Ivy, Maven or
Mercury to be used. Using Maven for now, until Mercury is released,
though from all accounts it looks like the Ivy impl is the fastest
and slimmest impl, users need to describe what they need.
* * *
Short of it all is... a new GShell is on the horizon. look for it
and vote.
I'm working on integration into the latest server tree... maybe
more ;-)
--jason
