Hi Ancoron,
I have not looked at your implementation yet. Based on what you have
written, it sounds impressive. It does solve the issue of exposing the
underlying OSGi commands to end user in a very extensible way and we
should definitely consider this for GlassFish. I have one outstanding
issue though. I am still looking for a way to provide a Gogo shell like
interface to user as it allows user to much more powerful scripting. Can
we add something like an osgi-shell command and which just gives works
as an I/O mechanism for the underlying shell running in the server?
Thanks,
Sahoo
On Thursday 12 July 2012 02:29 AM, Ancoron Luciferis wrote:
> Hi together,
>
> I just did a quite different way of handling this issue and still have
> every Felix shell command (whether from upstream or custom ones) at my
> hands:
>
> 1.) don't deploy/start the remote shell
> 2.) provide a simple asadmin sub-command that acts as a bridge between
> the GlassFish administration interface and the Felix Shell
>
> This way we just have to manage GlassFish security and yet have the
> ability to execute every command that is registered to the Felix shell,
> like this (gogo version - standard):
>
> $ ./bin/asadmin -t felix frameworklevel
> Level is 3
>
> ...or with the felix shell instead of gogo:
>
> $ ./bin/asadmin -t felix startlevel
> Level 3
>
> ...it allows as many arguments as you like:
>
> $ ./bin/asadmin -t felix find weld
> START LEVEL 3
> ID State Level Name
> [ 14] [Active ] [ 1] Weld integration for glassfish (3.1.2)
> [ 143] [Resolved ] [ 1]
> org.glassfish.main.web.weld-integration-fragment
> [ 193] [Resolved ] [ 1] Weld OSGi Bundle (1.1.4.Final)
>
> ...
>
> I've just pushed the latest code and did a small release for this artifact.
>
> You can get it here (it doesn't require any additional stuff but needs
> GlassFish 3.1.2 at least - OSGi core 4.3):
>
> https://oss.sonatype.org/content/repositories/releases/org/ancoron/glassfish/asadmin/org.ancoron.glassfish.asadmin.felix.shell/1.0.5/org.ancoron.glassfish.asadmin.felix.shell-1.0.5.jar
>
> ...the code is here:
>
> https://github.com/ancoron/gf-samples/tree/master/asadmin-ext/felix-shell
>
>
> Cheers,
>
> Ancoron
>
>
> On 07/11/2012 05:09 PM, Sahoo wrote:
>> Hi Tang,
>>
>> Thanks for looking into it. With this proposal, once the remote shell is
>> enabled, the security issue described in the bug still remains. Can you
>> think of any way to make the port secured such that only users
>> authneticated using glassfish admin user name& password can access the
>> port.
>>
>> Thanks,
>> Sahoo
>>
>>> Dear Sahoo, Tom
>>>
>>> About GLASSFISH-16998 and GLASSFISH-13006, I have a design idea
>>> and want to discuss with you.
>>>
>>> My design idea is as following:
>>>
>>> 1 "Turn off" org.apache.felix.shell.remote bundle
>>> Just as Richard S. Hall said:
>>>
>>> "From an OSGi perspective, the way to administratively turn off a bundle
>>> is to stop it or not deploy it. "
>>>
>>> I think that Stoping shell.remote bundle is a better way on the current
>>> gf architecture.
>>>
>>> Because on the current gf's code, GlassFishActivator class and
>>> GlassFishActivator.startPostStartupBundles() have not been existed, I
>>> think that the better way is to modify OSGiGlassFishRuntimeBuilder.build
>>> method and add the logic to stop org.apache.felix.shell.remote bundle
>>> behind "framework.start()" .
>>>
>>> 2 provide a way to administratively turn on shell.remote bundle
>>>
>>> Just as said on GLASSFISH-13006, felix shell is also important not only
>>> for framework developers(re-develop based gf), but also for OSGi app
>>> developers.However, also need to consider people who are not interested
>>> in OSGi. In addition, considering administrative and security aspects, I
>>> think that:
>>>
>>> Supporting a admin cli command for turning on shell.remote bundle,
>>> liking the following:
>>>
>>> asadmin start-felixremoteshell --telnet.port<portvalue> --portsavedfile
>>> <filepath>
>>>
>>> About design of the command,
>>> 1) --telnet.port is optional, if not inputing, gf will select an unused
>>> port randomly.
>>> 2) after executing the command, gf will display the port value on
>>> os-related shell window in order to let the user to know the port.
>>> 3) --portsavedfile is optional, if not inputing, gf will save the port
>>> value on a file of "user.home" by means of enciphering the port value.
>>> 4) when executing the command again, if user does not input port value,
>>> gf will firstly read port value from the portsavedfile, and if can't
>>> get the port value from the portsavedfile, then, executing the logic of
>>> 1) and updating the portsavedfile.
>>>
>>> --Best Regard!
>>> --Tang
>>>