Re: PortOffset for o.a.karaf.shell.ssh

[Jarek Gawor <jg...@gmail.com>]

I don't think turning off remote shell is a solution for this issue.
Remote shell is one of the interesting and useful features of Geronimo
3.0. Turning off the remote shell also might have some impact on GEP
as there is a JIRA open on using ssh terminal in Eclipse to connect to
the server.

We should be able to write a small gbean that starts the ssh server
manually and reports the correct port number. The gbean would just
need to update the org.apache.karaf.shell configuration in config
admin with the right port information and obtain SshServer instance
from the shell bundle using Blueprint API and then create an instance
of SshServerFactory and start it.

Jarek

On Wed, Aug 31, 2011 at 2:58 AM, Rex Wang <rw...@gmail.com> wrote:
> I opened GERONIMO-6134 to track this issue.
>
> Currently, as Russell said, I just set karaf.startRemoteShell=false by
> default, except the debug mode.
>
> thanks,
>
> -Rex
>
> 2011/8/31 David Jencks <da...@yahoo.com>
>>
>> Hi Rex,
>> I don't have a good idea how to do something like this in karaf.  It would
>> have to work through config admin since any service opening a socket should
>> get the port from config admin (the shell does).  So I think we would need
>> some kind of config admin administration tool that would shift all the port
>> values by some constant.  I haven't looked into anything about how to
>> implement something like this.
>> thanks
>> david jencks
>> On Aug 30, 2011, at 2:29 AM, Rex Wang wrote:
>>
>> Hi Devs
>>
>> I send this mail to only Geronimo mailing list because I hope we could
>> discuss it first before we request this ability in karaf.
>>
>> Currently, in Geronimo 3.0, all the port/portoffset settings have been
>> unified in config-substitutions.properties like before, except the settings
>> for o.a.karaf.shell.ssh.
>> karaf.shell.ssh can help user access our shell from remote through the
>> port 8101. In Geronimo startup script, by setting
>> CONSOLE_OPTS=-Dkaraf.startLocalConsole=true -Dkaraf.startRemoteShell=true,
>> we can enable this feature. It retrieves the settings in
>> /etc/org.apache.karaf.shell.cfg from config admin service.
>> However, it did not define the port offset value. If user wanna start 2
>> server instances in one machine, he has to manually set the portoffset in
>> config-substitutions and also modify the "sshPort" in the
>> /etc/org.apache.karaf.shell.cfg. Otherwise, the port 8101 will only work for
>> the server instance that start later.
>>
>> The question is, if we want karaf add the ability to set the port offset,
>> how do we hope them implement it? They indeed can simply add a setting in
>> org.apache.karaf.shell.cfg named "sshPortoffset" to do this. But our user
>> still need change 2 places if they want to change the portoffset. Shall we
>> persuade them to add the ability to load the settings from a location(i.e.
>> var/config-substitutions.properties for us) or there are better practices?
>>
>> David, IIRC, you ever mentioned you hope get rid of the
>> config-substitutions in future geronimo. Then how to unify the portoffset
>> settings, that is, changing in one place will make all components take the
>> effect?
>>
>> Any insights?
>>
>> thanks,
>> --
>> Lei Wang (Rex)
>> rwonly AT apache.org
>>
>
>
>
> --
> Lei Wang (Rex)
> rwonly AT apache.org
>

Re: PortOffset for o.a.karaf.shell.ssh

[David Jencks <da...@yahoo.com>]

Hi Russell,

I agree with what you say except that the osgi config admin service is not related to the geronimo-specific var/config-substitution.properties system, and I think we need to move towards using config admin instead of a geronimo-specific admin service.  osgi config admin deals with, roughly speaking, sets of configuration info per osgi service.  So to do something like the port offset we need something that interacts with config admin, recognizes any setting for any service that is a port, and shifts it.  If it can recognize that its a port :-) it can also report it on demand.  In a more osgi oriented future we will also need a new way to recognize that the server is "fully started" and I guess that could trigger listing all the used ports.

thanks
david jencks

On Sep 1, 2011, at 7:01 AM, Russell E Glaue wrote:

> 
> 
> On 08/31/2011 10:18 PM, Jarek Gawor wrote:
>> On Wed, Aug 31, 2011 at 11:07 PM, Shawn Jiang <ge...@gmail.com> wrote:
>>> 
>>> 
>>> 
>>> We just turn it off by default,  the user can still open it easily if they
>>> want.
>> 
>> Is it? What does the user need to do today to turn it back on? Modify
>> the geronimo script? I think a system property set on the command line
>> wins over the property set in etc/system.properties.
> 
> Ideally
> 1. the SSH Service is on by default
> 2. It uses the admin config service - i.e. var/config-substitutions.properties
> 3. a command line option can turn it off or on and change the binding port
> 4. a configuration in var/config-substitutions.properties can turn it off or on
> 5. the ssh service's bind port appears in the list of services in the server
> startup output.
> 
> None of these are currently done.
> 
> The problem was expressed that though we want the ideal, no one knows right know
> how to make karaf work in this way. This means we need two configuration files,
> one for karaf and one for the rest of Geronimo if we want the SSH service to be
> configurable. This results in a non-conformity - not using a single
> configuration file for all parts of the Geronimo Server.
> 
> So to avoid confusion with first-time users who are expecting the conformity of
> all services using the single configuration file, we turn the ssh service off by
> default. In this way, when Geronimo is shipped, it is shipped with conformity in
> using the single configuration file for the Geronimo Server.
> 
> Then we add a JIRA to have this issue made into the ideal configuration.
> 
> In the mean time, those of use who are no novice with Geronimo, and looking for
> the additional service, can read and become aware of the current issue and
> modify the secondary and non-conforming configuration file to turn the service
> on and use it.
> 
> 
> IMO - all services should conform with the config admin service, otherwise be
> turned off by default (with option to turn on) until it can be made to conform.
> In full releases, non-conformities will cause issues I think we should avoid. If
> this was a snapshot, then perhaps the non-conformity could persist, as it did
> with the ActiveMQ issue (GERONIMO-5987), though it was a show-stopper issue for me.
> 
> 
>> 
>>>> Turning off the remote shell also might have some impact on GEP
>>>> as there is a JIRA open on using ssh terminal in Eclipse to connect to
>>>> the server.
>>> 
>>> Because GEP will start the server with it's own way to control the ssh
>>> server.   I believe the impact here is limited to GEP.
>> 
>> I was thinking about using GEP with a remote server.
>> 
>> Jarek
> 

Re: PortOffset for o.a.karaf.shell.ssh

[Russell E Glaue <rg...@cait.org>]

On 08/31/2011 10:18 PM, Jarek Gawor wrote:
> On Wed, Aug 31, 2011 at 11:07 PM, Shawn Jiang <ge...@gmail.com> wrote:
>>
>>
>>
>> We just turn it off by default,  the user can still open it easily if they
>> want.
> 
> Is it? What does the user need to do today to turn it back on? Modify
> the geronimo script? I think a system property set on the command line
> wins over the property set in etc/system.properties.

Ideally
1. the SSH Service is on by default
2. It uses the admin config service - i.e. var/config-substitutions.properties
3. a command line option can turn it off or on and change the binding port
4. a configuration in var/config-substitutions.properties can turn it off or on
5. the ssh service's bind port appears in the list of services in the server
startup output.

None of these are currently done.

The problem was expressed that though we want the ideal, no one knows right know
how to make karaf work in this way. This means we need two configuration files,
one for karaf and one for the rest of Geronimo if we want the SSH service to be
configurable. This results in a non-conformity - not using a single
configuration file for all parts of the Geronimo Server.

So to avoid confusion with first-time users who are expecting the conformity of
all services using the single configuration file, we turn the ssh service off by
default. In this way, when Geronimo is shipped, it is shipped with conformity in
using the single configuration file for the Geronimo Server.

Then we add a JIRA to have this issue made into the ideal configuration.

In the mean time, those of use who are no novice with Geronimo, and looking for
the additional service, can read and become aware of the current issue and
modify the secondary and non-conforming configuration file to turn the service
on and use it.


IMO - all services should conform with the config admin service, otherwise be
turned off by default (with option to turn on) until it can be made to conform.
In full releases, non-conformities will cause issues I think we should avoid. If
this was a snapshot, then perhaps the non-conformity could persist, as it did
with the ActiveMQ issue (GERONIMO-5987), though it was a show-stopper issue for me.


> 
>>> Turning off the remote shell also might have some impact on GEP
>>> as there is a JIRA open on using ssh terminal in Eclipse to connect to
>>> the server.
>>
>> Because GEP will start the server with it's own way to control the ssh
>> server.   I believe the impact here is limited to GEP.
> 
> I was thinking about using GEP with a remote server.
> 
> Jarek

Re: PortOffset for o.a.karaf.shell.ssh

[Jarek Gawor <jg...@gmail.com>]

On Wed, Aug 31, 2011 at 11:07 PM, Shawn Jiang <ge...@gmail.com> wrote:
>
>
>
> We just turn it off by default,  the user can still open it easily if they
> want.

Is it? What does the user need to do today to turn it back on? Modify
the geronimo script? I think a system property set on the command line
wins over the property set in etc/system.properties.

>> Turning off the remote shell also might have some impact on GEP
>> as there is a JIRA open on using ssh terminal in Eclipse to connect to
>> the server.
>
> Because GEP will start the server with it's own way to control the ssh
> server.   I believe the impact here is limited to GEP.

I was thinking about using GEP with a remote server.

Jarek

Re: PortOffset for o.a.karaf.shell.ssh

[Shawn Jiang <ge...@gmail.com>]

On Thu, Sep 1, 2011 at 10:54 AM, Jarek Gawor <jg...@gmail.com> wrote:

> I don't think turning off remote shell is a solution for this issue.
> Remote shell is one of the interesting and useful features of Geronimo
> 3.0.


We just turn it off by default,  the user can still open it easily if they
want.


> Turning off the remote shell also might have some impact on GEP
> as there is a JIRA open on using ssh terminal in Eclipse to connect to
> the server.
>

Because GEP will start the server with it's own way to control the ssh
server.   I believe the impact here is limited to GEP.


>
> We should be able to write a small gbean that starts the ssh server
> manually and reports the correct port number. The gbean would just
> need to update the org.apache.karaf.shell configuration in config
> admin with the right port information and obtain SshServer instance
> from the shell bundle using Blueprint API and then create an instance
> of SshServerFactory and start it.
>

This is a good idea.


>
> Jarek
>
> On Wed, Aug 31, 2011 at 2:58 AM, Rex Wang <rw...@gmail.com> wrote:
> > I opened GERONIMO-6134 to track this issue.
> >
> > Currently, as Russell said, I just set karaf.startRemoteShell=false by
> > default, except the debug mode.
> >
> > thanks,
> >
> > -Rex
> >
> > 2011/8/31 David Jencks <da...@yahoo.com>
> >>
> >> Hi Rex,
> >> I don't have a good idea how to do something like this in karaf.  It
> would
> >> have to work through config admin since any service opening a socket
> should
> >> get the port from config admin (the shell does).  So I think we would
> need
> >> some kind of config admin administration tool that would shift all the
> port
> >> values by some constant.  I haven't looked into anything about how to
> >> implement something like this.
> >> thanks
> >> david jencks
> >> On Aug 30, 2011, at 2:29 AM, Rex Wang wrote:
> >>
> >> Hi Devs
> >>
> >> I send this mail to only Geronimo mailing list because I hope we could
> >> discuss it first before we request this ability in karaf.
> >>
> >> Currently, in Geronimo 3.0, all the port/portoffset settings have been
> >> unified in config-substitutions.properties like before, except the
> settings
> >> for o.a.karaf.shell.ssh.
> >> karaf.shell.ssh can help user access our shell from remote through the
> >> port 8101. In Geronimo startup script, by setting
> >> CONSOLE_OPTS=-Dkaraf.startLocalConsole=true
> -Dkaraf.startRemoteShell=true,
> >> we can enable this feature. It retrieves the settings in
> >> /etc/org.apache.karaf.shell.cfg from config admin service.
> >> However, it did not define the port offset value. If user wanna start 2
> >> server instances in one machine, he has to manually set the portoffset
> in
> >> config-substitutions and also modify the "sshPort" in the
> >> /etc/org.apache.karaf.shell.cfg. Otherwise, the port 8101 will only work
> for
> >> the server instance that start later.
> >>
> >> The question is, if we want karaf add the ability to set the port
> offset,
> >> how do we hope them implement it? They indeed can simply add a setting
> in
> >> org.apache.karaf.shell.cfg named "sshPortoffset" to do this. But our
> user
> >> still need change 2 places if they want to change the portoffset. Shall
> we
> >> persuade them to add the ability to load the settings from a
> location(i.e.
> >> var/config-substitutions.properties for us) or there are better
> practices?
> >>
> >> David, IIRC, you ever mentioned you hope get rid of the
> >> config-substitutions in future geronimo. Then how to unify the
> portoffset
> >> settings, that is, changing in one place will make all components take
> the
> >> effect?
> >>
> >> Any insights?
> >>
> >> thanks,
> >> --
> >> Lei Wang (Rex)
> >> rwonly AT apache.org
> >>
> >
> >
> >
> > --
> > Lei Wang (Rex)
> > rwonly AT apache.org
> >
>



-- 
Shawn

Re: PortOffset for o.a.karaf.shell.ssh

[Rex Wang <rw...@gmail.com>]

2011/9/1 Jarek Gawor <jg...@gmail.com>

> I don't think turning off remote shell is a solution for this issue.
>

Hi Jarek,
I don't say it is a solution. I made it off by default to avoid user's
confusing when he installs more than one instance in a single machine.


> Remote shell is one of the interesting and useful features of Geronimo
> 3.0. Turning off the remote shell also might have some impact on GEP
> as there is a JIRA open on using ssh terminal in Eclipse to connect to
> the server.
>
In this situation, eclipse is like a ssh client, right? Then I think it is
user's responsibility to guarantee the function is available in server
before he use this ability in GEP. Just like, if a user want to ssh to a
Linux, he must firstly enable the function in the Linux too.


>
> We should be able to write a small gbean that starts the ssh server
> manually and reports the correct port number. The gbean would just
> need to update the org.apache.karaf.shell configuration in config
> admin with the right port information and obtain SshServer instance
> from the shell bundle using Blueprint API and then create an instance
> of SshServerFactory and start it.
>

Good idea!

-Rex


>
> Jarek
>
> On Wed, Aug 31, 2011 at 2:58 AM, Rex Wang <rw...@gmail.com> wrote:
> > I opened GERONIMO-6134 to track this issue.
> >
> > Currently, as Russell said, I just set karaf.startRemoteShell=false by
> > default, except the debug mode.
> >
> > thanks,
> >
> > -Rex
> >
> > 2011/8/31 David Jencks <da...@yahoo.com>
> >>
> >> Hi Rex,
> >> I don't have a good idea how to do something like this in karaf.  It
> would
> >> have to work through config admin since any service opening a socket
> should
> >> get the port from config admin (the shell does).  So I think we would
> need
> >> some kind of config admin administration tool that would shift all the
> port
> >> values by some constant.  I haven't looked into anything about how to
> >> implement something like this.
> >> thanks
> >> david jencks
> >> On Aug 30, 2011, at 2:29 AM, Rex Wang wrote:
> >>
> >> Hi Devs
> >>
> >> I send this mail to only Geronimo mailing list because I hope we could
> >> discuss it first before we request this ability in karaf.
> >>
> >> Currently, in Geronimo 3.0, all the port/portoffset settings have been
> >> unified in config-substitutions.properties like before, except the
> settings
> >> for o.a.karaf.shell.ssh.
> >> karaf.shell.ssh can help user access our shell from remote through the
> >> port 8101. In Geronimo startup script, by setting
> >> CONSOLE_OPTS=-Dkaraf.startLocalConsole=true
> -Dkaraf.startRemoteShell=true,
> >> we can enable this feature. It retrieves the settings in
> >> /etc/org.apache.karaf.shell.cfg from config admin service.
> >> However, it did not define the port offset value. If user wanna start 2
> >> server instances in one machine, he has to manually set the portoffset
> in
> >> config-substitutions and also modify the "sshPort" in the
> >> /etc/org.apache.karaf.shell.cfg. Otherwise, the port 8101 will only work
> for
> >> the server instance that start later.
> >>
> >> The question is, if we want karaf add the ability to set the port
> offset,
> >> how do we hope them implement it? They indeed can simply add a setting
> in
> >> org.apache.karaf.shell.cfg named "sshPortoffset" to do this. But our
> user
> >> still need change 2 places if they want to change the portoffset. Shall
> we
> >> persuade them to add the ability to load the settings from a
> location(i.e.
> >> var/config-substitutions.properties for us) or there are better
> practices?
> >>
> >> David, IIRC, you ever mentioned you hope get rid of the
> >> config-substitutions in future geronimo. Then how to unify the
> portoffset
> >> settings, that is, changing in one place will make all components take
> the
> >> effect?
> >>
> >> Any insights?
> >>
> >> thanks,
> >> --
> >> Lei Wang (Rex)
> >> rwonly AT apache.org
> >>
> >
> >
> >
> > --
> > Lei Wang (Rex)
> > rwonly AT apache.org
> >
>



-- 
Lei Wang (Rex)
rwonly AT apache.org