Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer;
  b=nC+cNgWGq9Ojg7QxZyr9cPuboJhY3KoPBkZnS2nQmMjBz1cO51IzyT4MgjTkaLEYj9BzKaRsSXt8JI6gjCM47LqsfDS/rubAQakPeT694AHr2AEbw9zy6LI9BfE2EnXQK5M4IwYlk2fH9VYNYbAULg0c1mb8V501SiA0ZXr+yI8=
  ;
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: PortOffset for o.a.karaf.shell.ssh
From: David Jencks <david_jencks@yahoo.com>
In-Reply-To: <4E5F901C.9010906@cait.org>
Date: Thu, 1 Sep 2011 08:53:11 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <AC074AF2-26D9-4F3E-A71C-A58D5F1B69FB@yahoo.com>
References: 
 <CA+YP9s2bcVCDv-zpGL9-n5tsmp9odXuwMHW4y9S=JJ0o_5nuzQ@mail.gmail.com>
 <A8868BDE-61F9-4C07-BC4C-87A1CC1E70F9@yahoo.com>
 <CA+YP9s37-8yP9ZH7DPfM-Zm2wVnCgRTUNQeQ_N5MLTpMg-QVzQ@mail.gmail.com>
 <CAPR_grrGxuS+p4XL__z8s6jZ0RGzDh8AgVjQGhUKj9qbdGtgHQ@mail.gmail.com>
 <CANjG=50uQjuuODW0Jj1jUwqWmuQBsNKjNgMJXZo2PmKZG_7+Jw@mail.gmail.com>
 <CAPR_grrJrdAHMgL2iyxi3gvfmDhmct6GL2PhBfNfoOtriMWTMw@mail.gmail.com>
 <4E5F901C.9010906@cait.org>
To: dev@geronimo.apache.org

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:

>=20
>=20
> On 08/31/2011 10:18 PM, Jarek Gawor wrote:
>> On Wed, Aug 31, 2011 at 11:07 PM, Shawn Jiang <genspring@gmail.com> =
wrote:
>>>=20
>>>=20
>>>=20
>>> We just turn it off by default,  the user can still open it easily =
if they
>>> want.
>>=20
>> 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.
>=20
> 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.
>=20
> None of these are currently done.
>=20
> 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.
>=20
> 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.
>=20
> Then we add a JIRA to have this issue made into the ideal =
configuration.
>=20
> 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.
>=20
>=20
> 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.
>=20
>=20
>>=20
>>>> 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.
>>>=20
>>> 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.
>>=20
>> I was thinking about using GEP with a remote server.
>>=20
>> Jarek
>=20