[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[dsdp-tm-dev] RE: SSH tunneling & port forwarding
|
Title: rseserver-2.0-unix.tar
Hi Patrick,
I'm not clear whether you would want to hide the fact from
the
user that a tunnel is used, or you want to make it
explicit.
Consequently, I see two
possibilities:
a) Make it explicit:
* Create new systemType
"SSH-With-Tunnel"
* Register a newConnectionWizard against
it
* Wizard has a single page, allowing
user to select the port
--> E.g. a Listbox
of ports with associated remote host
--> User can pick a
port+host or probably create new one
* Once a port is picked, the wizard
configures the existing
unchanged SSH
Subsystems with the proper port and
instantiates them. See
org.eclipse.rse.discovery for how
to do that
programmatically.
* You'll probably also have to implement
a mountPathMappers
extension in order to
fix remote editing, since all your tunneled
connections will have a host
name "localhost" but with different
ports.
b) Hide tunneling from the user:
* Create new systemType
"SSH-With-Tunnel"
--> User will enter
normal remote hostname
* Create "SSHTunneled" SubSystem, same as
SSHSubSystem,
but with
getConnectorService() returning your own
TunneledSshConnectorService
* TunneledSshConnectorService implementation
takes the
remote hostname, looks up
matching port etc. and returns
proper session to
clients.
In case of (a) you implement your own wizard, similar to
what you
already see in org.eclipse.rse.discovery. In case of (b)
you only
implement your own
TunneledSshConnectorService.
Which option would you like?
Cheers,
Martin
Hello
Martin,
I have
been working in the implementation of the SSH tunnel utility I mentioned.
I
would like to know if you could help my understanding in order to
do the following:
I want
to create a new subsystem which would be used to explore remote systems. I want
it to be indentical to an Sftp subsystem with the little variation that a
port should be chosen when creating the connection using this subsystem. This
port should be retrieved form my ssh tunnel plugin which stores all active
tunnel by their local port number (forwarded port) as they are unique. This
would allow to retrieve the ip adress of the corresponding remote
system to which the port is forwarded to and create a connection with the name
of the target (optional).
In
fact I think reusing the existing Sftp subsystem with a modified
property page would do the trick.
I get in troubles when starting to develop this despite
the many different tutorials are available on the web. I believe some
are out of date because the code used sometimes does not correspond. I have been
through the "Building Tools on the Target Management RSE Framework" as
well.
From
what I understand so far:
-subsystemConfiguration extension point
will be used to register the new subsystem, give it a nice look and make it
available under corresponding systemTypes
-the corresponding
xxxFileSubSystemConfiguration class should describe the subsystem
factory
-Then comes, in the case of Sftp, the two
classes describing the configuration, SftpFileAdapter and
SftpRemoteFile.
I have
succesfully reused the code from the Sftp file subsystem in order to create my
own. It works fine despite the many accessibility warnings.
I am
not sure where the port selection should come into the picture nor how I give
this specific subsystem a property page of its own. Would it be a better
solution to use the newConnectionWizard extension point in order to fully
customize a wizard where the port would be the connection creation basis instead
of the ip adress for the remote system (fixed to localhost in this
case).
Looking back, is creating a subsystem even necessary? Maybe just
accessing the configuration to insert the port value from the connection wizard
would do?
I
believe I lost a little focus while working on this and I got a little confused
on how to approach this problem. I hope, I am not too far off the point, if
so please help get back on track.
Thank
you,
Best Regards,
Patrick Juhl
Hello Patrick,
thanks for your suggestion!
Your contribution would be greatly welcome, and using JSch
is just
fine because we use it ourselves in RSE
already.
I suggest we continue this discussion on the relevant
bug:
As you see there, an Open Source tool for port forwarding
already
exists, but we cannot include it directly since it is under
GPL. So,
if you could make your contribution under the EPL that
would be
just great!
I'd also suggest that we package your tool such that it can
also
run standalone without RSE.
If you need any help on making this happen, please let me
know.
Looks like your first step will be getting permission from
Ericsson
to contribute the code under the EPL.
Thanks!
Martin
Hi
again!
First
of all I would like to mention how usefull and well designed i find the RSE
plugin of which I make extensive use.
I am
writing to you because I would like to make a contribution
regarding an SSH tunnel & port forwarding utility. For the solution I
work on I needed such a tool and ended up developing it myself. I hope I could
contribute in some way by sharing some knowledge.
I
unfortunately did not design my code to work directly with RSE but rather as an
external plugin. Also, the code I wrote contains Ericsson sensitive information
and cannot be shared as such. Let me know if you still need a solution for this
and I will find some time to make a version i can send. However
the implementation is rather simple and uses JSch, a
java implementation of SSH, for the creating the port forwarding. Please
find more info on the following link:
From
this, it is very straightforward to build an Eclipse tool for port
forwarding using the "-L" option of the SSH command. Examples are provided
on how to use it in the downloadable package.
I
didn't go that much into the source of RSE so unfortunately I don't know how
usefull this would be. But in any case, this is a good starting point for
creating such a utility.
Let me
know if you need more information.
Best
regards,
Patrick Juhl
From: Oberhuber, Martin
[mailto:Martin.Oberhuber@xxxxxxxxxxxxx]
Sent: Thursday, October 18,
2007 7:50 PM
To: Patrick Juhl
Subject: RE:
rseserver-2.0-unix.tar
Hello Patrick -
thanks for this patch, this is definitely helpful
!
My only problem is, that for legal reasons I can only
accept community
contributions that are submitted through bugzilla. Could
you go and
attach your contribution on bug 164300
?
Because by doing so, we get your code under the Eclipse
Terms of Use.
We'll also need a comment like the following from you on
the bugzilla item:
Legal Message: I, {name},
declare that I developed attached code from scratch, without referencing any 3rd
party materials except material licensed under the EPL. {I am authorized by my
employer to make this contribution under the EPL.}
See also
You can submit the server.sh script as you have it, but
ideally you'd submit
it as a patch. To do so,
1.) File > Import > Team > Project Set the
TM Project Set from
2.) Edit the file, it's checked in
at
/org.eclipse.rse.services.dstore/serverruntime/scripts/unix/server.sh
3.) Team > Create Patch...
Hi!
I just stumble uppon Bug#: 164300.
I also went through the discussion at http://dev.eclipse.org/newslists/news.eclipse.dsdp.tm/msg00240.html.
A quick fix for the Server.sh file and in order to
allow port selection, change the code to the following:
#!/bin/sh
#*******************************************************************************
# Copyright (c) 2005, 2006 IBM
Corporation, Wind River Systems, Inc. and others.
# All rights reserved. This program and the
accompanying materials
# are made
available under the terms of the Eclipse Public License v1.0
# which accompanies this distribution, and is
available at
# http://www.eclipse.org/legal/epl-v10.html
#
# Contributors:
# IBM
Corporation - initial API and implementation
# Martin Oberhuber (Wind River) - Fix for solaris
(Bourne Shell export statement)
#*******************************************************************************
# Shell script to start an RSE
communications server
# This script
will start the datastore server listening on an available socket
serverpath=.;
CLASSPATH=.:dstore_extra_server.jar:dstore_core.jar:dstore_miners.jar:clientserver.jar:$CLASSPATH;
export serverpath CLASSPATH
if [ $1
]
then java
-DA_PLUGIN_PATH=$serverpath -DDSTORE_TRACING_ON=false -Dclient.username=$1
-DDSTORE_SPIRIT_ON=true org.eclipse.dstore.core.server.Server $1
&
else java -DA_PLUGIN_PATH=$serverpath
-DDSTORE_TRACING_ON=false -DDSTORE_SPIRIT_ON=true
org.eclipse.dstore.core.server.Server 0 60000 &
Fi
By the way, where should I redirect my
questions regarding the use of RSE?
I hope this was helpful!
Best regards,
Patrick Juhl
