|
telnetd discussion
Hey everyone,
The following is intended as a summary of the recent discussion on
telnetd (most of this analysis is from an email Felix Meschberger sent me).
The following bundles are necessary for remote shell access to Felix:
1. Felix' standard shell bundle (i.e., shell bundle).
2. Dieter's telnetd bundle (i.e., telnetd bundle).
3. Dieter shell-telnetd glue bundle (i.e., glue bundle).
Dieter also mentioned that the telnetd bundle depended on a commons
bundle, but we could easily package this into the telnetd bundle so that
it is self-contained (we can help make this happen with the maven bundle
plugin).
From Felix' analysis, we could simplify creating remote shell access by
having the glue bundle inject a dummy configuration into telnetd's
ManagedServiceFactory so that the Config Admin dependency could be
optional. This all sounds good. (We could even consider embedding the
telnetd stuff directly into the glue bundle, but that is another
discussion.)
Given this setup, we can ponder where should the telnetd and glue bundle
projects reside? The obvious choices are at the Source Forge telnetd
site or at Felix. I think that any combination can be reasonably argued.
Here is my personal take...
I definitely think it makes sense to create a subproject for the glue
bundle at Felix, I am less certain about the telnetd bundle itself.
While I definitely want to support the telnetd bundle, I am not sure if
it really falls into the scope of the Felix project.
I guess the question is, is telnetd a completely generic telnet
implementation that could easily be used outside of OSGi or not? If so,
then it seems like it should be separate from Felix. On the other hand,
if the implementation is somehow tied to OSGi, then it might make sense
to host it at Felix.
Another possibility is that telnetd is generic, but that it has some
sort of wrapper that integrates it into an OSGi environment, then maybe
it makes sense to host the wrapper at Felix, keeping the generic library
at SF.
I would definitely like to see this functionality available. My mind is
open as to how to achieve it, so what does everyone else think?
-> richard
|
|
Re: telnetd discussion
p.s. A lot of this discussion is based on the assumption that Dieter is
will and interested in closer integration with the Felix community. :-)
Richard S. Hall wrote:
> Hey everyone,
>
> The following is intended as a summary of the recent discussion on
> telnetd (most of this analysis is from an email Felix Meschberger sent
> me).
>
> The following bundles are necessary for remote shell access to Felix:
>
> 1. Felix' standard shell bundle (i.e., shell bundle).
> 2. Dieter's telnetd bundle (i.e., telnetd bundle).
> 3. Dieter shell-telnetd glue bundle (i.e., glue bundle).
>
> Dieter also mentioned that the telnetd bundle depended on a commons
> bundle, but we could easily package this into the telnetd bundle so
> that it is self-contained (we can help make this happen with the maven
> bundle plugin).
>
> From Felix' analysis, we could simplify creating remote shell access
> by having the glue bundle inject a dummy configuration into telnetd's
> ManagedServiceFactory so that the Config Admin dependency could be
> optional. This all sounds good. (We could even consider embedding the
> telnetd stuff directly into the glue bundle, but that is another
> discussion.)
>
> Given this setup, we can ponder where should the telnetd and glue
> bundle projects reside? The obvious choices are at the Source Forge
> telnetd site or at Felix. I think that any combination can be
> reasonably argued. Here is my personal take...
>
> I definitely think it makes sense to create a subproject for the glue
> bundle at Felix, I am less certain about the telnetd bundle itself.
> While I definitely want to support the telnetd bundle, I am not sure
> if it really falls into the scope of the Felix project.
>
> I guess the question is, is telnetd a completely generic telnet
> implementation that could easily be used outside of OSGi or not? If
> so, then it seems like it should be separate from Felix. On the other
> hand, if the implementation is somehow tied to OSGi, then it might
> make sense to host it at Felix.
>
> Another possibility is that telnetd is generic, but that it has some
> sort of wrapper that integrates it into an OSGi environment, then
> maybe it makes sense to host the wrapper at Felix, keeping the generic
> library at SF.
>
> I would definitely like to see this functionality available. My mind
> is open as to how to achieve it, so what does everyone else think?
>
> -> richard
|
|
Re: telnetd discussion
Hi all,
Thanks for summarizing this up here.
I agree to have the shell-telnetd glue at Felix and I am equally open
and share the same concerns with respect to telnetd. I think this may
best be answered by Dieter.
Regards
Felix
Richard S. Hall schrieb:
> Hey everyone,
>
> The following is intended as a summary of the recent discussion on
> telnetd (most of this analysis is from an email Felix Meschberger sent me).
>
> The following bundles are necessary for remote shell access to Felix:
>
> 1. Felix' standard shell bundle (i.e., shell bundle).
> 2. Dieter's telnetd bundle (i.e., telnetd bundle).
> 3. Dieter shell-telnetd glue bundle (i.e., glue bundle).
>
> Dieter also mentioned that the telnetd bundle depended on a commons
> bundle, but we could easily package this into the telnetd bundle so that
> it is self-contained (we can help make this happen with the maven bundle
> plugin).
>
> From Felix' analysis, we could simplify creating remote shell access by
> having the glue bundle inject a dummy configuration into telnetd's
> ManagedServiceFactory so that the Config Admin dependency could be
> optional. This all sounds good. (We could even consider embedding the
> telnetd stuff directly into the glue bundle, but that is another
> discussion.)
>
> Given this setup, we can ponder where should the telnetd and glue bundle
> projects reside? The obvious choices are at the Source Forge telnetd
> site or at Felix. I think that any combination can be reasonably argued.
> Here is my personal take...
>
> I definitely think it makes sense to create a subproject for the glue
> bundle at Felix, I am less certain about the telnetd bundle itself.
> While I definitely want to support the telnetd bundle, I am not sure if
> it really falls into the scope of the Felix project.
>
> I guess the question is, is telnetd a completely generic telnet
> implementation that could easily be used outside of OSGi or not? If so,
> then it seems like it should be separate from Felix. On the other hand,
> if the implementation is somehow tied to OSGi, then it might make sense
> to host it at Felix.
>
> Another possibility is that telnetd is generic, but that it has some
> sort of wrapper that integrates it into an OSGi environment, then maybe
> it makes sense to host the wrapper at Felix, keeping the generic library
> at SF.
>
> I would definitely like to see this functionality available. My mind is
> open as to how to achieve it, so what does everyone else think?
>
> -> richard
>
|
|
Re: telnetd discussion
On Wed, Jun 25, 2008 at 9:08 PM, Felix Meschberger < fmeschbe@...> wrote:
> Hi all,
>
> Thanks for summarizing this up here.
>
> I agree to have the shell-telnetd glue at Felix and I am equally open and
> share the same concerns with respect to telnetd.
Same here.
> I think this may best be answered by Dieter.
I agree.
regards,
Karl
> Regards
> Felix
>
> Richard S. Hall schrieb:
>>
>> Hey everyone,
>>
>> The following is intended as a summary of the recent discussion on telnetd
>> (most of this analysis is from an email Felix Meschberger sent me).
>>
>> The following bundles are necessary for remote shell access to Felix:
>>
>> 1. Felix' standard shell bundle (i.e., shell bundle).
>> 2. Dieter's telnetd bundle (i.e., telnetd bundle).
>> 3. Dieter shell-telnetd glue bundle (i.e., glue bundle).
>>
>> Dieter also mentioned that the telnetd bundle depended on a commons
>> bundle, but we could easily package this into the telnetd bundle so that it
>> is self-contained (we can help make this happen with the maven bundle
>> plugin).
>>
>> From Felix' analysis, we could simplify creating remote shell access by
>> having the glue bundle inject a dummy configuration into telnetd's
>> ManagedServiceFactory so that the Config Admin dependency could be optional.
>> This all sounds good. (We could even consider embedding the telnetd stuff
>> directly into the glue bundle, but that is another discussion.)
>>
>> Given this setup, we can ponder where should the telnetd and glue bundle
>> projects reside? The obvious choices are at the Source Forge telnetd site or
>> at Felix. I think that any combination can be reasonably argued. Here is my
>> personal take...
>>
>> I definitely think it makes sense to create a subproject for the glue
>> bundle at Felix, I am less certain about the telnetd bundle itself. While I
>> definitely want to support the telnetd bundle, I am not sure if it really
>> falls into the scope of the Felix project.
>>
>> I guess the question is, is telnetd a completely generic telnet
>> implementation that could easily be used outside of OSGi or not? If so, then
>> it seems like it should be separate from Felix. On the other hand, if the
>> implementation is somehow tied to OSGi, then it might make sense to host it
>> at Felix.
>>
>> Another possibility is that telnetd is generic, but that it has some sort
>> of wrapper that integrates it into an OSGi environment, then maybe it makes
>> sense to host the wrapper at Felix, keeping the generic library at SF.
>>
>> I would definitely like to see this functionality available. My mind is
>> open as to how to achieve it, so what does everyone else think?
>>
>> -> richard
>>
>
--
Karl Pauls
karlpauls@...
|
|
Re: telnetd discussion
Richard, all:
I'd suggest to first take a step back and ask yourselves a question.
As far as I understood from the discussion, you would be looking for
an occasional, simple telnet based remote access to the felix shell
service.
If this is correct, then I wonder whether it really requires a telnet/
SSH2 compliant server with connection management to achieve this.
Actually, taking equinox as an example, it's nothing more than a
simple single connection without any telnet protocol negotiation
happening at all.
So, this is the question I'd suggest to ask yourselves before we
proceed to find a solution:
Do you need something like the simple equinox "telnet" access, or do
you need a "real" telnet/SSH server?
If the answer is "we need a simple access", then I would actually
suggest to hack a simple listener implementation into the glue bundle,
make it "the telnet" bundle and go with it (from my point of view,
telnetd-osgi would be simply an overkill tool for that job).
Regards,
Dieter
> The following is intended as a summary of the recent discussion on
> telnetd (most of this analysis is from an email Felix Meschberger
> sent me).
Felix, could you please drop me a copy of this analysis? :)
> The following bundles are necessary for remote shell access to Felix:
>
> 1. Felix' standard shell bundle (i.e., shell bundle).
> 2. Dieter's telnetd bundle (i.e., telnetd bundle).
> 3. Dieter shell-telnetd glue bundle (i.e., glue bundle).
> Dieter also mentioned that the telnetd bundle depended on a commons
> bundle, but we could easily package this into the telnetd bundle so
> that it is self-contained (we can help make this happen with the
> maven bundle plugin).
>
> From Felix' analysis, we could simplify creating remote shell access
> by having the glue bundle inject a dummy configuration into
> telnetd's ManagedServiceFactory so that the Config Admin dependency
> could be optional. This all sounds good. (We could even consider
> embedding the telnetd stuff directly into the glue bundle, but that
> is another discussion.)
>
> Given this setup, we can ponder where should the telnetd and glue
> bundle projects reside? The obvious choices are at the Source Forge
> telnetd site or at Felix. I think that any combination can be
> reasonably argued. Here is my personal take...
>
> I definitely think it makes sense to create a subproject for the
> glue bundle at Felix, I am less certain about the telnetd bundle
> itself. While I definitely want to support the telnetd bundle, I am
> not sure if it really falls into the scope of the Felix project.
>
> I guess the question is, is telnetd a completely generic telnet
> implementation that could easily be used outside of OSGi or not? If
> so, then it seems like it should be separate from Felix. On the
> other hand, if the implementation is somehow tied to OSGi, then it
> might make sense to host it at Felix.
>
> Another possibility is that telnetd is generic, but that it has some
> sort of wrapper that integrates it into an OSGi environment, then
> maybe it makes sense to host the wrapper at Felix, keeping the
> generic library at SF.
>
> I would definitely like to see this functionality available. My mind
> is open as to how to achieve it, so what does everyone else think?
>
> -> richard
|
|
Re: telnetd discussion
Dieter Wimberger wrote:
> Richard, all:
>
> I'd suggest to first take a step back and ask yourselves a question.
>
> As far as I understood from the discussion, you would be looking for
> an occasional, simple telnet based remote access to the felix shell
> service.
>
> If this is correct, then I wonder whether it really requires a
> telnet/SSH2 compliant server with connection management to achieve
> this. Actually, taking equinox as an example, it's nothing more than a
> simple single connection without any telnet protocol negotiation
> happening at all.
>
> So, this is the question I'd suggest to ask yourselves before we
> proceed to find a solution:
> Do you need something like the simple equinox "telnet" access, or do
> you need a "real" telnet/SSH server?
>
> If the answer is "we need a simple access", then I would actually
> suggest to hack a simple listener implementation into the glue bundle,
> make it "the telnet" bundle and go with it (from my point of view,
> telnetd-osgi would be simply an overkill tool for that job).
Good question. Most of my use cases would be the simple variety, but I
wouldn't want to be constrained to it either. I think the point, for me,
is to create a useful tool that is flexible enough to be used in simple
cases as well as more sophisticated ones.
-> richard
>
> Regards,
> Dieter
>
>
>> The following is intended as a summary of the recent discussion on
>> telnetd (most of this analysis is from an email Felix Meschberger
>> sent me).
>
> Felix, could you please drop me a copy of this analysis? :)
>
>> The following bundles are necessary for remote shell access to Felix:
>>
>> 1. Felix' standard shell bundle (i.e., shell bundle).
>> 2. Dieter's telnetd bundle (i.e., telnetd bundle).
>> 3. Dieter shell-telnetd glue bundle (i.e., glue bundle).
>> Dieter also mentioned that the telnetd bundle depended on a commons
>> bundle, but we could easily package this into the telnetd bundle so
>> that it is self-contained (we can help make this happen with the
>> maven bundle plugin).
>>
>> From Felix' analysis, we could simplify creating remote shell access
>> by having the glue bundle inject a dummy configuration into telnetd's
>> ManagedServiceFactory so that the Config Admin dependency could be
>> optional. This all sounds good. (We could even consider embedding the
>> telnetd stuff directly into the glue bundle, but that is another
>> discussion.)
>>
>> Given this setup, we can ponder where should the telnetd and glue
>> bundle projects reside? The obvious choices are at the Source Forge
>> telnetd site or at Felix. I think that any combination can be
>> reasonably argued. Here is my personal take...
>>
>> I definitely think it makes sense to create a subproject for the glue
>> bundle at Felix, I am less certain about the telnetd bundle itself.
>> While I definitely want to support the telnetd bundle, I am not sure
>> if it really falls into the scope of the Felix project.
>>
>> I guess the question is, is telnetd a completely generic telnet
>> implementation that could easily be used outside of OSGi or not? If
>> so, then it seems like it should be separate from Felix. On the other
>> hand, if the implementation is somehow tied to OSGi, then it might
>> make sense to host it at Felix.
>>
>> Another possibility is that telnetd is generic, but that it has some
>> sort of wrapper that integrates it into an OSGi environment, then
>> maybe it makes sense to host the wrapper at Felix, keeping the
>> generic library at SF.
>>
>> I would definitely like to see this functionality available. My mind
>> is open as to how to achieve it, so what does everyone else think?
>>
>> -> richard
>
|
|
Re: telnetd discussion
Richard, all:
Thought I put the "simple access alternative" together so you can
decide upon facts not ideas.
http://www.karanet.at/~wimpi/felix/org.apache.felix.telnetconsole.jarSize is close to 15kB, only dependency is the felix shell service
bundle. Port is 6666 by default and may be configured using the system
property "osgi.shell.telnet.port".
(No command history, but BS, DEL and Strg-U work).
Regards,
Dieter
On 25 Jun 2008, at 15:35, Richard S. Hall wrote:
> Dieter Wimberger wrote:
>> Richard, all:
>>
>> I'd suggest to first take a step back and ask yourselves a question.
>>
>> As far as I understood from the discussion, you would be looking
>> for an occasional, simple telnet based remote access to the felix
>> shell service.
>>
>> If this is correct, then I wonder whether it really requires a
>> telnet/SSH2 compliant server with connection management to achieve
>> this. Actually, taking equinox as an example, it's nothing more
>> than a simple single connection without any telnet protocol
>> negotiation happening at all.
>>
>> So, this is the question I'd suggest to ask yourselves before we
>> proceed to find a solution:
>> Do you need something like the simple equinox "telnet" access, or
>> do you need a "real" telnet/SSH server?
>>
>> If the answer is "we need a simple access", then I would actually
>> suggest to hack a simple listener implementation into the glue
>> bundle, make it "the telnet" bundle and go with it (from my point
>> of view, telnetd-osgi would be simply an overkill tool for that job).
>
> Good question. Most of my use cases would be the simple variety, but
> I wouldn't want to be constrained to it either. I think the point,
> for me, is to create a useful tool that is flexible enough to be
> used in simple cases as well as more sophisticated ones.
>
> -> richard
>
>>
>> Regards,
>> Dieter
>>
>>
>>> The following is intended as a summary of the recent discussion on
>>> telnetd (most of this analysis is from an email Felix Meschberger
>>> sent me).
>>
>> Felix, could you please drop me a copy of this analysis? :)
>>
>>> The following bundles are necessary for remote shell access to
>>> Felix:
>>>
>>> 1. Felix' standard shell bundle (i.e., shell bundle).
>>> 2. Dieter's telnetd bundle (i.e., telnetd bundle).
>>> 3. Dieter shell-telnetd glue bundle (i.e., glue bundle).
>>> Dieter also mentioned that the telnetd bundle depended on a
>>> commons bundle, but we could easily package this into the telnetd
>>> bundle so that it is self-contained (we can help make this happen
>>> with the maven bundle plugin).
>>>
>>> From Felix' analysis, we could simplify creating remote shell
>>> access by having the glue bundle inject a dummy configuration into
>>> telnetd's ManagedServiceFactory so that the Config Admin
>>> dependency could be optional. This all sounds good. (We could even
>>> consider embedding the telnetd stuff directly into the glue
>>> bundle, but that is another discussion.)
>>>
>>> Given this setup, we can ponder where should the telnetd and glue
>>> bundle projects reside? The obvious choices are at the Source
>>> Forge telnetd site or at Felix. I think that any combination can
>>> be reasonably argued. Here is my personal take...
>>>
>>> I definitely think it makes sense to create a subproject for the
>>> glue bundle at Felix, I am less certain about the telnetd bundle
>>> itself. While I definitely want to support the telnetd bundle, I
>>> am not sure if it really falls into the scope of the Felix project.
>>>
>>> I guess the question is, is telnetd a completely generic telnet
>>> implementation that could easily be used outside of OSGi or not?
>>> If so, then it seems like it should be separate from Felix. On the
>>> other hand, if the implementation is somehow tied to OSGi, then it
>>> might make sense to host it at Felix.
>>>
>>> Another possibility is that telnetd is generic, but that it has
>>> some sort of wrapper that integrates it into an OSGi environment,
>>> then maybe it makes sense to host the wrapper at Felix, keeping
>>> the generic library at SF.
>>>
>>> I would definitely like to see this functionality available. My
>>> mind is open as to how to achieve it, so what does everyone else
>>> think?
>>>
>>> -> richard
>>
|
|
Re: telnetd discussion
Woah - 15KB!
Nice work Dieter - that should help the embedded folks!
- R
Dieter Wimberger wrote:
> Richard, all:
>
> Thought I put the "simple access alternative" together so you can
> decide upon facts not ideas.
>
> http://www.karanet.at/~wimpi/felix/org.apache.felix.telnetconsole.jar>
> Size is close to 15kB, only dependency is the felix shell service
> bundle. Port is 6666 by default and may be configured using the system
> property "osgi.shell.telnet.port".
> (No command history, but BS, DEL and Strg-U work).
>
> Regards,
> Dieter
>
>
> On 25 Jun 2008, at 15:35, Richard S. Hall wrote:
>
>> Dieter Wimberger wrote:
>>> Richard, all:
>>>
>>> I'd suggest to first take a step back and ask yourselves a question.
>>>
>>> As far as I understood from the discussion, you would be looking for
>>> an occasional, simple telnet based remote access to the felix shell
>>> service.
>>>
>>> If this is correct, then I wonder whether it really requires a
>>> telnet/SSH2 compliant server with connection management to achieve
>>> this. Actually, taking equinox as an example, it's nothing more than
>>> a simple single connection without any telnet protocol negotiation
>>> happening at all.
>>>
>>> So, this is the question I'd suggest to ask yourselves before we
>>> proceed to find a solution:
>>> Do you need something like the simple equinox "telnet" access, or do
>>> you need a "real" telnet/SSH server?
>>>
>>> If the answer is "we need a simple access", then I would actually
>>> suggest to hack a simple listener implementation into the glue
>>> bundle, make it "the telnet" bundle and go with it (from my point of
>>> view, telnetd-osgi would be simply an overkill tool for that job).
>>
>> Good question. Most of my use cases would be the simple variety, but
>> I wouldn't want to be constrained to it either. I think the point,
>> for me, is to create a useful tool that is flexible enough to be used
>> in simple cases as well as more sophisticated ones.
>>
>> -> richard
>>
>>>
>>> Regards,
>>> Dieter
>>>
>>>
>>>> The following is intended as a summary of the recent discussion on
>>>> telnetd (most of this analysis is from an email Felix Meschberger
>>>> sent me).
>>>
>>> Felix, could you please drop me a copy of this analysis? :)
>>>
>>>> The following bundles are necessary for remote shell access to Felix:
>>>>
>>>> 1. Felix' standard shell bundle (i.e., shell bundle).
>>>> 2. Dieter's telnetd bundle (i.e., telnetd bundle).
>>>> 3. Dieter shell-telnetd glue bundle (i.e., glue bundle).
>>>> Dieter also mentioned that the telnetd bundle depended on a commons
>>>> bundle, but we could easily package this into the telnetd bundle so
>>>> that it is self-contained (we can help make this happen with the
>>>> maven bundle plugin).
>>>>
>>>> From Felix' analysis, we could simplify creating remote shell
>>>> access by having the glue bundle inject a dummy configuration into
>>>> telnetd's ManagedServiceFactory so that the Config Admin dependency
>>>> could be optional. This all sounds good. (We could even consider
>>>> embedding the telnetd stuff directly into the glue bundle, but that
>>>> is another discussion.)
>>>>
>>>> Given this setup, we can ponder where should the telnetd and glue
>>>> bundle projects reside? The obvious choices are at the Source Forge
>>>> telnetd site or at Felix. I think that any combination can be
>>>> reasonably argued. Here is my personal take...
>>>>
>>>> I definitely think it makes sense to create a subproject for the
>>>> glue bundle at Felix, I am less certain about the telnetd bundle
>>>> itself. While I definitely want to support the telnetd bundle, I am
>>>> not sure if it really falls into the scope of the Felix project.
>>>>
>>>> I guess the question is, is telnetd a completely generic telnet
>>>> implementation that could easily be used outside of OSGi or not? If
>>>> so, then it seems like it should be separate from Felix. On the
>>>> other hand, if the implementation is somehow tied to OSGi, then it
>>>> might make sense to host it at Felix.
>>>>
>>>> Another possibility is that telnetd is generic, but that it has
>>>> some sort of wrapper that integrates it into an OSGi environment,
>>>> then maybe it makes sense to host the wrapper at Felix, keeping the
>>>> generic library at SF.
>>>>
>>>> I would definitely like to see this functionality available. My
>>>> mind is open as to how to achieve it, so what does everyone else
>>>> think?
>>>>
>>>> -> richard
>>>
>
--
Ascert - Taking systems to the Edge
robw@...
+44 (0)20 7488 3470
www.ascert.com
|
|
Re: telnetd discussion
Hi Dieter,
That _IS_ cool. Thanks alot. While full telnetd functionality is
certainly valid in its own right. For a simple Felix shell it is
probably sufficient to have such a tiny thing.
Are you willing to contribute the source of this to Apache Felix ?
Regards
Felix
Dieter Wimberger schrieb:
> Richard, all:
>
> Thought I put the "simple access alternative" together so you can decide
> upon facts not ideas.
>
> http://www.karanet.at/~wimpi/felix/org.apache.felix.telnetconsole.jar>
> Size is close to 15kB, only dependency is the felix shell service
> bundle. Port is 6666 by default and may be configured using the system
> property "osgi.shell.telnet.port".
> (No command history, but BS, DEL and Strg-U work).
>
> Regards,
> Dieter
>
>
> On 25 Jun 2008, at 15:35, Richard S. Hall wrote:
>
>> Dieter Wimberger wrote:
>>> Richard, all:
>>>
>>> I'd suggest to first take a step back and ask yourselves a question.
>>>
>>> As far as I understood from the discussion, you would be looking for
>>> an occasional, simple telnet based remote access to the felix shell
>>> service.
>>>
>>> If this is correct, then I wonder whether it really requires a
>>> telnet/SSH2 compliant server with connection management to achieve
>>> this. Actually, taking equinox as an example, it's nothing more than
>>> a simple single connection without any telnet protocol negotiation
>>> happening at all.
>>>
>>> So, this is the question I'd suggest to ask yourselves before we
>>> proceed to find a solution:
>>> Do you need something like the simple equinox "telnet" access, or do
>>> you need a "real" telnet/SSH server?
>>>
>>> If the answer is "we need a simple access", then I would actually
>>> suggest to hack a simple listener implementation into the glue
>>> bundle, make it "the telnet" bundle and go with it (from my point of
>>> view, telnetd-osgi would be simply an overkill tool for that job).
>>
>> Good question. Most of my use cases would be the simple variety, but I
>> wouldn't want to be constrained to it either. I think the point, for
>> me, is to create a useful tool that is flexible enough to be used in
>> simple cases as well as more sophisticated ones.
>>
>> -> richard
>>
>>>
>>> Regards,
>>> Dieter
>>>
>>>
>>>> The following is intended as a summary of the recent discussion on
>>>> telnetd (most of this analysis is from an email Felix Meschberger
>>>> sent me).
>>>
>>> Felix, could you please drop me a copy of this analysis? :)
>>>
>>>> The following bundles are necessary for remote shell access to Felix:
>>>>
>>>> 1. Felix' standard shell bundle (i.e., shell bundle).
>>>> 2. Dieter's telnetd bundle (i.e., telnetd bundle).
>>>> 3. Dieter shell-telnetd glue bundle (i.e., glue bundle).
>>>> Dieter also mentioned that the telnetd bundle depended on a commons
>>>> bundle, but we could easily package this into the telnetd bundle so
>>>> that it is self-contained (we can help make this happen with the
>>>> maven bundle plugin).
>>>>
>>>> From Felix' analysis, we could simplify creating remote shell access
>>>> by having the glue bundle inject a dummy configuration into
>>>> telnetd's ManagedServiceFactory so that the Config Admin dependency
>>>> could be optional. This all sounds good. (We could even consider
>>>> embedding the telnetd stuff directly into the glue bundle, but that
>>>> is another discussion.)
>>>>
>>>> Given this setup, we can ponder where should the telnetd and glue
>>>> bundle projects reside? The obvious choices are at the Source Forge
>>>> telnetd site or at Felix. I think that any combination can be
>>>> reasonably argued. Here is my personal take...
>>>>
>>>> I definitely think it makes sense to create a subproject for the
>>>> glue bundle at Felix, I am less certain about the telnetd bundle
>>>> itself. While I definitely want to support the telnetd bundle, I am
>>>> not sure if it really falls into the scope of the Felix project.
>>>>
>>>> I guess the question is, is telnetd a completely generic telnet
>>>> implementation that could easily be used outside of OSGi or not? If
>>>> so, then it seems like it should be separate from Felix. On the
>>>> other hand, if the implementation is somehow tied to OSGi, then it
>>>> might make sense to host it at Felix.
>>>>
>>>> Another possibility is that telnetd is generic, but that it has some
>>>> sort of wrapper that integrates it into an OSGi environment, then
>>>> maybe it makes sense to host the wrapper at Felix, keeping the
>>>> generic library at SF.
>>>>
>>>> I would definitely like to see this functionality available. My mind
>>>> is open as to how to achieve it, so what does everyone else think?
>>>>
>>>> -> richard
>>>
>
|
|
RE: telnetd discussion
Hi,
Just tried it out... super small and super fast... For the tiny solution, this looks perfect...
Any chance I could see the source? I want to learn! :)
BTW - I'm working through the tutorial page on the Felix shell service as I want to do other mediums, such as JMS and JMX...
Kind regards, Craig Phillips
From: Dieter Wimberger
Sent: Wed 6/25/2008 6:10 PM
To: dev@...
Subject: Re: telnetd discussion
Richard, all:
Thought I put the "simple access alternative" together so you can
decide upon facts not ideas.
http://www.karanet.at/~wimpi/felix/org.apache.felix.telnetconsole.jarSize is close to 15kB, only dependency is the felix shell service
bundle. Port is 6666 by default and may be configured using the system
property "osgi.shell.telnet.port".
(No command history, but BS, DEL and Strg-U work).
Regards,
Dieter
On 25 Jun 2008, at 15:35, Richard S. Hall wrote:
> Dieter Wimberger wrote:
>> Richard, all:
>>
>> I'd suggest to first take a step back and ask yourselves a question.
>>
>> As far as I understood from the discussion, you would be looking
>> for an occasional, simple telnet based remote access to the felix
>> shell service.
>>
>> If this is correct, then I wonder whether it really requires a
>> telnet/SSH2 compliant server with connection management to achieve
>> this. Actually, taking equinox as an example, it's nothing more
>> than a simple single connection without any telnet protocol
>> negotiation happening at all.
>>
>> So, this is the question I'd suggest to ask yourselves before we
>> proceed to find a solution:
>> Do you need something like the simple equinox "telnet" access, or
>> do you need a "real" telnet/SSH server?
>>
>> If the answer is "we need a simple access", then I would actually
>> suggest to hack a simple listener implementation into the glue
>> bundle, make it "the telnet" bundle and go with it (from my point
>> of view, telnetd-osgi would be simply an overkill tool for that job).
>
> Good question. Most of my use cases would be the simple variety, but
> I wouldn't want to be constrained to it either. I think the point,
> for me, is to create a useful tool that is flexible enough to be
> used in simple cases as well as more sophisticated ones.
>
> -> richard
>
>>
>> Regards,
>> Dieter
>>
>>
>>> The following is intended as a summary of the recent discussion on
>>> telnetd (most of this analysis is from an email Felix Meschberger
>>> sent me).
>>
>> Felix, could you please drop me a copy of this analysis? :)
>>
>>> The following bundles are necessary for remote shell access to
>>> Felix:
>>>
>>> 1. Felix' standard shell bundle (i.e., shell bundle).
>>> 2. Dieter's telnetd bundle (i.e., telnetd bundle).
>>> 3. Dieter shell-telnetd glue bundle (i.e., glue bundle).
>>> Dieter also mentioned that the telnetd bundle depended on a
>>> commons bundle, but we could easily package this into the telnetd
>>> bundle so that it is self-contained (we can help make this happen
>>> with the maven bundle plugin).
>>>
>>> From Felix' analysis, we could simplify creating remote shell
>>> access by having the glue bundle inject a dummy configuration into
>>> telnetd's ManagedServiceFactory so that the Config Admin
>>> dependency could be optional. This all sounds good. (We could even
>>> consider embedding the telnetd stuff directly into the glue
>>> bundle, but that is another discussion.)
>>>
>>> Given this setup, we can ponder where should the telnetd and glue
>>> bundle projects reside? The obvious choices are at the Source
>>> Forge telnetd site or at Felix. I think that any combination can
>>> be reasonably argued. Here is my personal take...
>>>
>>> I definitely think it makes sense to create a subproject for the
>>> glue bundle at Felix, I am less certain about the telnetd bundle
>>> itself. While I definitely want to support the telnetd bundle, I
>>> am not sure if it really falls into the scope of the Felix project.
>>>
>>> I guess the question is, is telnetd a completely generic telnet
>>> implementation that could easily be used outside of OSGi or not?
>>> If so, then it seems like it should be separate from Felix. On the
>>> other hand, if the implementation is somehow tied to OSGi, then it
>>> might make sense to host it at Felix.
>>>
>>> Another possibility is that telnetd is generic, but that it has
>>> some sort of wrapper that integrates it into an OSGi environment,
>>> then maybe it makes sense to host the wrapper at Felix, keeping
>>> the generic library at SF.
>>>
>>> I would definitely like to see this functionality available. My
>>> mind is open as to how to achieve it, so what does everyone else
>>> think?
>>>
>>> -> richard
>>
|
|
RE: telnetd discussion
Hi,
I'm experiencing something weird in one newly created workspace/project, which is pretty much a replica of others...
If I install any of the various telnet bundles, from the one below to the original telnetd to the one-off I recreated from source, set up a sandbox to run (meaning, bin and bundle and conf and cache directories and all items thereof), and run felix, here's the odd behavior:
- The bundles all seem to load and resolve, from what I can tell from stdout, almost... (note I also use SCR)
- Until I hit a keystroke / enter key (such as 'ps'), the services are not promulgated
- At such time I hit a keystroke / enter key, then the services are propagated and telnetd gets its shell service and SCR gets busy and any play-hello-world bundle I have gets it's pax logger and away we go
- If I remove shell.tui from the mix ('er, auto.start.1), all the above is not necessary... the services load, and telnetd (or telnet.console) and my hello-world bundles are all up and running, services and the like
Now, I don't see this same behavior in other "sandboxes", just a newly created project I just set up.. all I have is a hello world in it...
Obviously, I'm not asking anyone to diagnose my workspace or anything... All I'm asking is whether someone has seen this before and if they remember the circumstances and what was the fix...
I'm posting / replying to this thread because I think it is apropos to the discussion -- there is obviously some sort of shell conflict with the shell.tui bundle, seemingly on the inputStream/outputStream/printStream, but it's beyond my comprehension ATT...
Trying to narrow down the difference between this stock hello world app I just created could take me a while...
For what it's worth, Craig
From: Dieter Wimberger
Sent: Wed 6/25/2008 6:10 PM
To: dev@...
Subject: Re: telnetd discussion
Richard, all:
Thought I put the "simple access alternative" together so you can
decide upon facts not ideas.
http://www.karanet.at/~wimpi/felix/org.apache.felix.telnetconsole.jarSize is close to 15kB, only dependency is the felix shell service
bundle. Port is 6666 by default and may be configured using the system
property "osgi.shell.telnet.port".
(No command history, but BS, DEL and Strg-U work).
Regards,
Dieter
On 25 Jun 2008, at 15:35, Richard S. Hall wrote:
> Dieter Wimberger wrote:
>> Richard, all:
>>
>> I'd suggest to first take a step back and ask yourselves a question.
>>
>> As far as I understood from the discussion, you would be looking
>> for an occasional, simple telnet based remote access to the felix
>> shell service.
>>
>> If this is correct, then I wonder whether it really requires a
>> telnet/SSH2 compliant server with connection management to achieve
>> this. Actually, taking equinox as an example, it's nothing more
>> than a simple single connection without any telnet protocol
>> negotiation happening at all.
>>
>> So, this is the question I'd suggest to ask yourselves before we
>> proceed to find a solution:
>> Do you need something like the simple equinox "telnet" access, or
>> do you need a "real" telnet/SSH server?
>>
>> If the answer is "we need a simple access", then I would actually
>> suggest to hack a simple listener implementation into the glue
>> bundle, make it "the telnet" bundle and go with it (from my point
>> of view, telnetd-osgi would be simply an overkill tool for that job).
>
> Good question. Most of my use cases would be the simple variety, but
> I wouldn't want to be constrained to it either. I think the point,
> for me, is to create a useful tool that is flexible enough to be
> used in simple cases as well as more sophisticated ones.
>
> -> richard
>
>>
>> Regards,
>> Dieter
>>
>>
>>> The following is intended as a summary of the recent discussion on
>>> telnetd (most of this analysis is from an email Felix Meschberger
>>> sent me).
>>
>> Felix, could you please drop me a copy of this analysis? :)
>>
>>> The following bundles are necessary for remote shell access to
>>> Felix:
>>>
>>> 1. Felix' standard shell bundle (i.e., shell bundle).
>>> 2. Dieter's telnetd bundle (i.e., telnetd bundle).
>>> 3. Dieter shell-telnetd glue bundle (i.e., glue bundle).
>>> Dieter also mentioned that the telnetd bundle depended on a
>>> commons bundle, but we could easily package this into the telnetd
>>> bundle so that it is self-contained (we can help make this happen
>>> with the maven bundle plugin).
>>>
>>> From Felix' analysis, we could simplify creating remote shell
>>> access by having the glue bundle inject a dummy configuration into
>>> telnetd's ManagedServiceFactory so that the Config Admin
>>> dependency could be optional. This all sounds good. (We could even
>>> consider embedding the telnetd stuff directly into the glue
>>> bundle, but that is another discussion.)
>>>
>>> Given this setup, we can ponder where should the telnetd and glue
>>> bundle projects reside? The obvious choices are at the Source
>>> Forge telnetd site or at Felix. I think that any combination can
>>> be reasonably argued. Here is my personal take...
>>>
>>> I definitely think it makes sense to create a subproject for the
>>> glue bundle at Felix, I am less certain about the telnetd bundle
>>> itself. While I definitely want to support the telnetd bundle, I
>>> am not sure if it really falls into the scope of the Felix project.
>>>
>>> I guess the question is, is telnetd a completely generic telnet
>>> implementation that could easily be used outside of OSGi or not?
>>> If so, then it seems like it should be separate from Felix. On the
>>> other hand, if the implementation is somehow tied to OSGi, then it
>>> might make sense to host it at Felix.
>>>
>>> Another possibility is that telnetd is generic, but that it has
>>> some sort of wrapper that integrates it into an OSGi environment,
>>> then maybe it makes sense to host the wrapper at Felix, keeping
>>> the generic library at SF.
>>>
>>> I would definitely like to see this functionality available. My
>>> mind is open as to how to achieve it, so what does everyone else
>>> think?
>>>
>>> -> richard
>>
|
|
RE: telnetd discussion (ordering of bundles)
Hi,
Well... it was the order of the bundles within the auto.start.1... The telnetd.jar or telnetconsole.jar bundle has to be the first entry (well, for me), ahead of shell and tui... When I put telnetd.jar / telnetconsole.jar last, well -- then I get a conflict...
For what it's worth, Craig
From: Craig Phillips
Sent: Thu 6/26/2008 1:10 PM
To: dev@...
Subject: RE: telnetd discussion
Hi,
I'm experiencing something weird in one newly created workspace/project, which is pretty much a replica of others...
If I install any of the various telnet bundles, from the one below to the original telnetd to the one-off I recreated from source, set up a sandbox to run (meaning, bin and bundle and conf and cache directories and all items thereof), and run felix, here's the odd behavior:
- The bundles all seem to load and resolve, from what I can tell from stdout, almost... (note I also use SCR)
- Until I hit a keystroke / enter key (such as 'ps'), the services are not promulgated
- At such time I hit a keystroke / enter key, then the services are propagated and telnetd gets its shell service and SCR gets busy and any play-hello-world bundle I have gets it's pax logger and away we go
- If I remove shell.tui from the mix ('er, auto.start.1), all the above is not necessary... the services load, and telnetd (or telnet.console) and my hello-world bundles are all up and running, services and the like
Now, I don't see this same behavior in other "sandboxes", just a newly created project I just set up.. all I have is a hello world in it...
Obviously, I'm not asking anyone to diagnose my workspace or anything... All I'm asking is whether someone has seen this before and if they remember the circumstances and what was the fix...
I'm posting / replying to this thread because I think it is apropos to the discussion -- there is obviously some sort of shell conflict with the shell.tui bundle, seemingly on the inputStream/outputStream/printStream, but it's beyond my comprehension ATT...
Trying to narrow down the difference between this stock hello world app I just created could take me a while...
For what it's worth, Craig
From: Dieter Wimberger
Sent: Wed 6/25/2008 6:10 PM
To: dev@...
Subject: Re: telnetd discussion
Richard, all:
Thought I put the "simple access alternative" together so you can
decide upon facts not ideas.
http://www.karanet.at/~wimpi/felix/org.apache.felix.telnetconsole.jarSize is close to 15kB, only dependency is the felix shell service
bundle. Port is 6666 by default and may be configured using the system
property "osgi.shell.telnet.port".
(No command history, but BS, DEL and Strg-U work).
Regards,
Dieter
On 25 Jun 2008, at 15:35, Richard S. Hall wrote:
> Dieter Wimberger wrote:
>> Richard, all:
>>
>> I'd suggest to first take a step back and ask yourselves a question.
>>
>> As far as I understood from the discussion, you would be looking
>> for an occasional, simple telnet based remote access to the felix
>> shell service.
>>
>> If this is correct, then I wonder whether it really requires a
>> telnet/SSH2 compliant server with connection management to achieve
>> this. Actually, taking equinox as an example, it's nothing more
>> than a simple single connection without any telnet protocol
>> negotiation happening at all.
>>
>> So, this is the question I'd suggest to ask yourselves before we
>> proceed to find a solution:
>> Do you need something like the simple equinox "telnet" access, or
>> do you need a "real" telnet/SSH server?
>>
>> If the answer is "we need a simple access", then I would actually
>> suggest to hack a simple listener implementation into the glue
>> bundle, make it "the telnet" bundle and go with it (from my point
>> of view, telnetd-osgi would be simply an overkill tool for that job).
>
> Good question. Most of my use cases would be the simple variety, but
> I wouldn't want to be constrained to it either. I think the point,
> for me, is to create a useful tool that is flexible enough to be
> used in simple cases as well as more sophisticated ones.
>
> -> richard
>
>>
>> Regards,
>> Dieter
>>
>>
>>> The following is intended as a summary of the recent discussion on
>>> telnetd (most of this analysis is from an email Felix Meschberger
>>> sent me).
>>
>> Felix, could you please drop me a copy of this analysis? :)
>>
>>> The following bundles are necessary for remote shell access to
>>> Felix:
>>>
>>> 1. Felix' standard shell bundle (i.e., shell bundle).
>>> 2. Dieter's telnetd bundle (i.e., telnetd bundle).
>>> 3. Dieter shell-telnetd glue bundle (i.e., glue bundle).
>>> Dieter also mentioned that the telnetd bundle depended on a
>>> commons bundle, but we could easily package this into the telnetd
>>> bundle so that it is self-contained (we can help make this happen
>>> with the maven bundle plugin).
>>>
>>> From Felix' analysis, we could simplify creating remote shell
>>> access by having the glue bundle inject a dummy configuration into
>>> telnetd's ManagedServiceFactory so that the Config Admin
>>> dependency could be optional. This all sounds good. (We could even
>>> consider embedding the telnetd stuff directly into the glue
>>> bundle, but that is another discussion.)
>>>
>>> Given this setup, we can ponder where should the telnetd and glue
>>> bundle projects reside? The obvious choices are at the Source
>>> Forge telnetd site or at Felix. I think that any combination can
>>> be reasonably argued. Here is my personal take...
>>>
>>> I definitely think it makes sense to create a subproject for the
>>> glue bundle at Felix, I am less certain about the telnetd bundle
>>> itself. While I definitely want to support the telnetd bundle, I
>>> am not sure if it really falls into the scope of the Felix project.
>>>
>>> I guess the question is, is telnetd a completely generic telnet
>>> implementation that could easily be used outside of OSGi or not?
>>> If so, then it seems like it should be separate from Felix. On the
>>> other hand, if the implementation is somehow tied to OSGi, then it
>>> might make sense to host it at Felix.
>>>
>>> Another p
|
smime.p7s (3K)