[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [dsdp-tm-dev] RLogin Shell Service
|
Hi Florian,
we cannot accept any inbound contributions via E-Mail
anyways. I think it is time for you to file a bug on bugzilla, which will
eventually hold your contribution as an attachment.
Feel free to create / upload your contribution when you
think it is good enough. The better it is, the better for us here since, as you
guess, we are indeed busy with releasing Galileo at the
moment.
Some checks for you before you attach your
code:
-
Do all the files that you copied & modified from EPL'd code (such
as telnet) include the *original* EPL'd copyright header plus a line of yours
indicating that you copied & modified?
-
Do all your new files have an EPL copyright
header?
-
Do all your new plugins contain an about.html file for
EPL?
Even if we review your code, we'll likely not be able to
fix your bugs so it would help if you attack those yourself. We may help
answering any questions you have ("how should I...", "why..."). Try to be as
specific as possible.
For externalizing your strings, this is not a must-do
for the initial contribution, a wizard can do this easily later (Source >
Externalize Strings..."
Thanks,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
Hi,
I have a first version of the RLogin service. I've been
testing it on my debian (localhost) and it seems to work, in spite of several
annoying bugs :
- You have to re-enter your password in the shell, after pressing some
keys (io bug i guess)
- The prompt is diplayed twice on the line
- You will find i'm not quite familiar with the NLS Strings
I've
been re-using the Telnet Service code, so I think there's place for code
optimization.
I haven't been able to test the Commons RLoginClient part
since I don't have any Windows installed.
Do you want me to send you
the jar files for a quick review ? I'd understand if you don't have time, due
to the 3.1 release.
Florian
2009/6/5 Florian Guillochon
<florian.guillochon@xxxxxxxxx>
Hello,
Forget
what you've read on my previous mail, the redirections work very well, I was
missing the fact that the EOL character was a '\r'. At this point, I can run
the rlogin command, authenticate myself and run commands in the remote shell
(localhost for the moment).
I will now try to incorporate it in the RSE
architecture.
Florian
PS : I hope
I'm not getting too annoying with the mails, but if it can provide some
informations about my avancement, I guess this is not completely useless
;)
2009/6/4 Florian Guillochon
<florian.guillochon@xxxxxxxxx>
Hi,
After
two days of testing the exec() method, I don't think it's possible to
communicate with the rlogind server, though the redirection of the
standard input and output work well (I can run a bash and get all the
commands output). The problem is, from what i've read on the internet, the
entrance of the rlogin password does not use the standard input (for
security reason), but a sort of pseudo-terminal.
Florian
2009/6/2 Oberhuber, Martin
<Martin.Oberhuber@xxxxxxxxxxxxx>
Hi,
this
comment has more links to related bugs.
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff,
Wind River
Target Management
Project Lead, DSDP PMC Member
Sent: Montag, 01. Juni 2009
15:05
To: Target Management developer
discussions
Subject: Re: [dsdp-tm-dev] RLogin Shell
Service
Hello,
Thank you for answering that fast, that's
more than appreciable.
I'm sorry to say I didn't find the bugzilla
entry, but I've decided to investigate the "Runtime.exec()" way. From
what I could read, it allows the programmer to launch any external
application, and to redirect the input,output and error streams to the
Java application.
As I'm not sure to be on the right path, don't
hesitate if you think that's not the right mechanism to use. What
intrigues me is that many sites related to Runtime.exec() mentions the
fact that this can't be used as a shell, therefore user interaction
doesn't seem to be possible. To be more precise, I haven't been able
to test it yet, but using exec("rlogin") and redirecting the streams
shouldn't be sufficient enough to make it work properly. Maybe running
exec("/usr/bin/bash -c rlogin") could do it... I'm far from being a
Java expert, so I'd just like to hear your advices and ideas on this
solution.
Thanks for the attention,
Florian
2009/5/30 Oberhuber, Martin
<Martin.Oberhuber@xxxxxxxxxxxxx>
Ah, yes... now I remember :)
rlogin works from java only if the super-user (root) runs the
Java program.
For normal users, all you can do is launch the operating
system's rlogin executable.
That executable is built with setuid bit so it will run with
root privileges.
We've been doing this commercially, so I know it's doable and
I don't think there is any other way around it.
On Windows, I'm not quite sure ... the privileged ports below
1024 may be accessible on Windows, you'd need to try it out or
google the web if there is a chance for this to work. Otherwise, you
need an rlogin.exe on Windows.
BTW, if you write your program to launch the external rlogin
exe and communicate through it, this has more advantages: your
solution becomes very flexible, since users can replace rlogin.exe
by any other exe they like. We've had existing requests to do this
for ssh (i.e. use external ssh.exe) because such external ssh
programs support more configuration options than internal Java ssh
client. There should be a related bug in bugzilla (something about
ssh config, I'm sure you find it when running bugzilla
search).
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target
Management Project Lead, DSDP PMC Member
Hi everybody,
I'm currently working on an RLogin
shell service, adapting the work done for telnet.
I'm facing a
major problem : for security reasons, when a user wants to access
a remote system, the "source port" for the rlogin command must be
in the range 0-1023. As i'm accessing it through Eclipse, this
condition is not respected and the authentification failed
miserably ("java.net.BindException: All ports in use or
insufficient permssion").
Do I have to modify the Apache
Commons Net sources to bypass this restriction (dirty) or is there
a another solution ?
Thank you for your
attention
Florian
_______________________________________________
dsdp-tm-dev
mailing list
dsdp-tm-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
_______________________________________________
dsdp-tm-dev
mailing list
dsdp-tm-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev