On 07/12/2012 07:42 AM, Sahoo wrote:
> 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
Well, I already thought about something like this, but also didn't have
enough time to take a deeper look. As far as I know there will be a
problem because the remote side of asadmin is not ready for streaming
input/output yet, so the first step would be to handle the "interactive
shell" part with a local command, that just issues separate remote commands.
Shouldn't be too hard to do something like this. Give me a second, or
two... :)
However, I fear that in this case the command execution delay imposed by
the asadmin stack will still be there as the local asadmin side seems to
introduce a one second delay to every command. That's why I already
wrote some python scripts for batch tasks which directly use the
asadmin/management rest interface instead of the client (at least in
case I know the remote target), which is much faster.
Cheers,
Ancoron
>
> 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
>>>>
>