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)
Message-ID: <4E5D4C7B.5060709@cait.org>
Date: Tue, 30 Aug 2011 15:47:55 -0500
From: Russell E Glaue <rglaue@cait.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: PortOffset for o.a.karaf.shell.ssh
References: 
 <CA+YP9s2bcVCDv-zpGL9-n5tsmp9odXuwMHW4y9S=JJ0o_5nuzQ@mail.gmail.com>
 <A8868BDE-61F9-4C07-BC4C-87A1CC1E70F9@yahoo.com>
In-Reply-To: <A8868BDE-61F9-4C07-BC4C-87A1CC1E70F9@yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

How about this idea.
Have the ability to turn the karaf SSH service on and off. And have it off by 
default. Then we do not have to worry about telling novice users what to do, and 
more expert users will figure it out only when they want that extra service.


In the configuration file: /etc/org.apache.karaf.shell.cfg
Keep the "sshPort" attribute as it is.
Add another attribute (e.g. "serviceStart") that has a true/false value.

By default the "serviceStart" would be false.
If a user wanted the SSH service, they would have to set the attribute to true. 
And if they wanted more than one instance, they would have to set the sshPort 
for each instance - as you discussed.

Then, put in a JIRA issue to have the karaf "sshPort" attribute integrated into 
the "var/config-substitutions.properties". Which can happen way down the road.


And with this, this extra service can be used by more expert users who do not 
mind editing the configuration in multiple places. Novice users don't have to 
worry about it - so it won't be in the way to cause extra confusion.

Also, having the SSH service off (false) should decrease the memory footprint 
(as opposed to when true) as that service should not start up.
Having the SSH service on means the admin user additionally needs to secure that 
port on the server. So having that turned off by default also makes Geronimo 
more secure out of the box.


-RG


On 08/30/2011 11:28 AM, David Jencks wrote:
> 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 <http://apache.org/>
>