network terminals (was rtems command line shells)

[Fernando RUIZ CASAS]

> -----Mensaje original-----
> De: Joel Sherrill [mailto:joel.sherrill at OARcorp.com]
> Enviado el: viernes, 07 de septiembre de 2001 21:33
> Para: Chris Caudle
> CC: rtems-users at OARcorp.com
> Asunto: Re: network terminals (was rtems command line shells)
>
>
>
>
> Chris Caudle wrote:
> >
> > On Fri, 7 Sep 2001 19:12:12 +0200 '"Fernando RUIZ CASAS"
> <correo at fernando-ruiz.com>' wrote:
> > > But if you have tcp/ip started you can start
> > > telnetd that gives you 1 (Default) pseusoterminal
> > > ready for remote console
> >
> > Anyone ported the OpenSSH secure shell daemon to RTEMS yet?
> > I haven't seen any announcements on this list, but perhaps
> someone is looking at it already.
> > The openssh.org page mentions that the portable version runs
> into a lot of headaches regarding authentication differences
> between different flavors of Unix-like operating systems, so I
> don't really have a good understanding of how that will work on
> an RTOS that doesn't have a native concept of user authentication.
>
>
> That would be interesting.  Right now, the RTEMS user scheme is based on
> a somewhat fake version of /etc/passwd and /etc/groups.  You can populate
> it however you want.  I suppose you would have to somehow magically
> create a home directory with the files that ssh expects.
>
> I would expect that RTEMS has the infrastructure to support this
> but it would require some magic and care setting up the
> files on the RTEMS target.
>
> > -- Chris Caudle
>
Of course that a better implementation of remote secure conection is very
good but..

What is the goal of this?

At this moment is necessary to build a minimum infrastructure based in imfs
directory.
The first step is define the level of crypt.c: old crypt style, MD5, etc...
Next step is to use passwd, -passwd, shadow password, etc....
Once this is correct a real login will be builded.

Ftpd could use this feature.
telnetd of course.

And after all these steps a real user environment with several tasks owned
by the user
linked must be deleted once the user does the logoff.

Is this necessary in rtems environment?

Too much effort with the only goal of the remote control of the BSP.

Another big question is create a separate file descriptor array for EVERY
"process" started.
it's also necesary rebuild exit() in order to close the user files opened
only.
And exit() close the rtems executive.


We cann't  think in linux around this concern. We need think in rtems.
A executive that it let us to execute several task like threads but not like
process with fork().

A redefinition of rtems kernel to improve this goal would be necessary.

Perhaps too many lines of code in the kernel to link the tasks, users and
process.

Working with an Etrax100 LX EVB running linux 2.4.5 inside this kind of
features are cutted
for the sake of simplicity and to avoid waste the limited memory.
And linux 2.4.5 contains all of this features inside.

The embedded software runs always with the minimum of resources hardware and
the size of code is an important point to bear in mind.


> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel at OARcorp.com                 On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985
>