Completely agreed. It is very nice to have a lightweight raw connection glue bundle for shell access. The security weakness can be easily suppressed by allowing only trusted hosts (in a local network or something).
By the other hand, it is very useful to have that full featured implementation. Mainly for applications wanting remote access with authentication and security requirements. That's where telnetd2 has a lot to help felix. Regards, -- Pedro Pedruzzi | V2COM On Thu, Jun 26, 2008 at 3:28 PM, Richard S. Hall <[EMAIL PROTECTED]> wrote: > I think this is very cool and I am sure that other people would agree with > me that such a small bundle would be cool in addition to a more full > featured one. We are greedy, aren't we? ;-) > > -> richard > > 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
