> Ooh! What about this... What about starting a program
> with xinit as was recently suggested, but instead of
> starting x0rfbserver it starts a monitoring app?
*** I've written a similiar program (God it's a hacked up mess, but I get
by) that listens on the client machine (tcp port) for an incoming
connection. It is specifically written for local apps use (it
assumes it has certain NFS mounts available but the idea could work
the same for purely remote). There's two parts the daemon (runs on the
server) and the
client (issued by user root on the server). The client connects and tells
the daemon the full path of the program to run then runs
it. Authentication of course is a concern and I've implemented a very
simple method. It may be flawed but simple and I think it does the job in
terms of safety:
1. Client program connects to the workstation's daemon via tcp on a
specified port. The daemon returns back a random 50 character filename to
the client.
2. The client writes the file to a directory
'/tftpboot/lts/ltsroot/remote-auth' (or
whatever. ie: /opt/..) and sends back the full path of the program to run
with arguments and optionally the uid/gid it would like to have the daemon
launch it as.
3. The daemon server checks to see if the 50 character file in
remote-auth directory exists, sends back a confirmation to the
client, forks and drops it's permissions (if
requested) and launches the program.
4. The client deletes the no longer needed remote-auth/filename.
the remote-auth directory permissions would be 600 with user/group as
root. So only root can read/write to that directory (daemon runs as root
which it needs to anyway to change to an arbitrary uid/gid not to
mention that the LTSP root is mounted read-only anyhows).
Aaaannyways there's a simple method which doesn't require
username/passwords.
>
>
> > The problem with running an rsh daemon on the
> > workstations is that it needs to know WHO is sending
> > the request to run something, and whether they are
> > allowed to or not.
> >
> > By turning on local apps, you enable NIS. That is how
> > the rsh daemon will validate that the "WHO" is a correct
> > user.
> >
> > An alternative to NIS might be LDAP, but we haven't
> gotten
> > that to work for local apps yet.
> >
> > In the past, some people have suggested just copying the
> > servers /etc/passwd file to /opt/ltsp/i386/etc, but I can
> > tell you very clearly that will NEVER be part of a
> > standard LTSP package.
> >
> > Creating a special-purpose daemon to handle this, in my
> > opinion, is just reinventing the wheel. Use what is
> already
> > there, and spend your time solving other more important
> > problems.
> >
> > But, I also invite you to challenge me on this. Maybe
> you've
> > got a better way.
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _____________________________________________________________________
> Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
> https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
> For additional LTSP help, try #ltsp channel on irc.openprojects.net
>
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.openprojects.net
