One thing we could try is to use the ServerSocket.setFactoryImpl() to have a way to manage socket creation, but I fear this kinda mean we have to reimplement all the socket layer afaik :-(
On Tue, Jul 3, 2012 at 3:05 PM, Jean-Baptiste Onofré <[email protected]>wrote: > The problem is that it will "couple other projects" (for instance Pax Web) > with Karaf, as Karaf will "exposes" the API. > > So it's not so easy, even if I would like to see a netstat command > internally to Karaf ;) > > Regards > JB > > > On 07/03/2012 02:47 PM, Christian Schneider wrote: > >> I agree. Removing the command is probably the easiest solution. By >> changing the config you can start/stop the ssh server instantly. >> >> About the netstat like command. I am also not sure how to implement such >> a thing. One idea is to have each module that offers and external >> service also offer a osgi service that reports the metadata of this >> service. We could either have a Java interface for that or use service >> properties. >> >> In any case the metadata about each network service could be: >> >> Ipaddress / Name >> Port >> Description >> (Config PID) >> (Security Infos) >> >> So for example netstat may give: >> >> Name/Port Service Name Description >> localhost:8101 ssh Secure Shell >> localhost:8181 http Jetty >> localhost:6161 ActiveMQ ActiveMQ Messaging >> >> Optionally we could also show the config pid so people know where to >> configure port and other settings. >> We could also show some details about the security. >> >> For example if the default ssh private key may login we can show a >> warning about that. >> >> A central config file where you can set ports and if services should >> start may make sense. We should then make sure though that this >> mechanism is well a bit hidden from the modules so they do not have to >> each implement reading this file. >> >> Perhaps we could have a central service that can be asked for the port >> of a named service and if it should start. A config for a such a service >> could look like this: >> >> ssh:8101,start >> activemq:6161,stop >> http:8181,start >> >> Not sure if this is a good idea though. >> >> Christian >> >> Am 03.07.2012 14:18, schrieb Guillaume Nodet: >> >>> I'm not really sure how we could do such a netstat command if we don't >>> manage all the ports ourselves ... >>> >>> Anyway, for sshd, i guess we could get rid of the command if it isn't >>> used >>> (and I agree I've never seen anyone using it so far). I don't think we >>> should add management layers for each port though: all the >>> configuration is >>> already centralized in configadmin, and I fear that adding lots of >>> commands >>> for managing things that we already have common management for, may just >>> confuse users. I guess what we're missing for common ports is a simpler >>> way (more centralized) configuration file, so maybe using >>> etc/config.properties for common port configuration and using >>> placeholders >>> referring to those would be easier for users, so that they would only >>> have >>> a single file to modify... >>> Removing this sshd command will have a nice effect of removing your >>> concern >>> about mixing blueprint calls in the code btw ;-) >>> >>> On Mon, Jul 2, 2012 at 2:57 PM, Christian Schneider >>> <[email protected] >>> >>>> wrote: >>>> You hit a good sport there. I think we could need an information on all >>>> kind of services with external connectivity that are running. >>>> >>>> So tpyically I would like to see: >>>> - http >>>> - ssh >>>> - jmx >>>> ... >>>> >>>> As bit like netstat -l just for karaf but with some additional >>>> informations. I think such a command would also be a nice security >>>> tool to >>>> check you do not have ports open that should be closed. >>>> >>>> Christian >>>> >>>> >>>> Am 02.07.2012 14:48, schrieb Claus Ibsen: >>>> >>>> Hi >>>> >>>>> I miss a command to list the current running sshd servers. >>>>> >>>>> So for example if people start Karaf using bin/karaf, then there is no >>>>> easy way to find out what the SSH port is if you want to remote >>>>> connect to your Karaf. >>>>> >>>>> In that light for starters a list option on sshd would be nice >>>>> ssdh list >>>>> >>>>> >>>>> >>>>> PS: Likewise for JMX etc. >>>>> It would be nice with some way to see in the logs / from karaf:info >>>>> etc. to see all the running management services and the urls they >>>>> expose for remote management. Today you gotta know the defaults, and >>>>> "cross fingers" that this is the options you use. If not you gotta go >>>>> hunt in the zillion config files in etc to figure out this. >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Jul 2, 2012 at 11:50 AM, Christian Schneider >>>>> <[email protected]> wrote: >>>>> >>>>> Hi all, >>>>>> >>>>>> while working on the ssh part of karaf I wondered if the sshd >>>>>> command is >>>>>> really implemented in the way people need it. >>>>>> Currently each call to sshd creates a new ssh server. I personally >>>>>> never >>>>>> had >>>>>> the need to have more than one ssh server running for one instance of >>>>>> karaf. >>>>>> >>>>>> So I wonder if it would make sense to change the command to manage a >>>>>> single >>>>>> ssh server instance. Like: >>>>>> >>>>>> ssh:sshd start -p 8102 >>>>>> or ssh:sshd start -p 8102 >>>>>> ssh:sshd stop >>>>>> >>>>>> JB told me that ssh is used in Fabric and there it might be >>>>>> necessary to >>>>>> have more than one instance. >>>>>> @Guillaume can you give us some insight how it is used there? >>>>>> >>>>>> If we decide we need the capability to run more than one instance >>>>>> of ssh >>>>>> server then I think we should at least provide full management of >>>>>> these >>>>>> instances. >>>>>> Currently the sshd command can start any number of ssh servers but >>>>>> it can >>>>>> not stop them. I think the servers started in this way would not even >>>>>> stop >>>>>> when the ssh bundle is stopped. >>>>>> >>>>>> I also wonder if it would make sense to separate the ssh server >>>>>> part from >>>>>> the ssh client. So you can start a ssh server by installing a >>>>>> org.apache.karaf.sshd bundle or similar. >>>>>> >>>>>> Christian >>>>>> >>>>>> -- >>>>>> Christian Schneider >>>>>> http://www.liquid-reality.de >>>>>> >>>>>> Open Source Architect >>>>>> Talend Application Integration Division http://www.talend.com >>>>>> >>>>>> >>>>>> >>>>> -- >>>> Christian Schneider >>>> http://www.liquid-reality.de >>>> >>>> Open Source Architect >>>> Talend Application Integration Division http://www.talend.com >>>> >>>> >>>> >>> >> >> > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com > > > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
