Hello everyone,
Well after spending most of my Saturday playing with 0xrfbserver source code I believe
I have added the
"-stealth" option. Here's how:
step 1:
Compile xclass version 0.63. Get it at:
http://sourceforge.net/projects/xclass
(this step is probably optional as older xclasses will most likely work but
just-in-case)
step 2:
Grab & untar x0rfbserver version 0.6.1 get it at:
http://download.hexonet.com/software/rfb
step 3:
Grab my patched files for:
x0rfbserver.cc
OXServiceApplet.cc
which replaces those in the x0rfbserver sub-directory you untarred in step 2. (yes I
know I should
have made them differential patches!). Get those files at:
www.sd73.bc.ca/tux/rfb
step 4:
Compile as per normal as stated in the INSTALL file:
make depend
make
That'll do it. An "x0rfbserver -help" should reveal the stealth option. This patch
also includes the feature of
a GLOBAL .x0rfbserver file. If .x0rfbserver exists in / that will be used over
~/.x0rfbserver. This is useful for those
of us who run local apps and/or want the client to activate the daemon themselves but
not have them enter their own password
or options (like disable keyboard & mouse). This global file needs to be placed in the
root of the client. So in my
case that would be /tftpboot/lts/ltsroot; for other's it would be /opt/... If you
issue a:
x0rfbserver -stealth
and do not have either a /.x0rfbserver file or a ~/.x0rfbserver file the user will be
prompted with the options box so
I would recommend running the daemon first without stealth, entering the wanted
password, then copying the .x0rfbserver
file from that users home directory and use it for your global config.
I would launch the program as described in my previous email with xinit like:
xinit /usr/bin/x0rfbserver -stealth >& /dev/null -- /ltsbin/XF86_SVGA -ac -query <ip
of server>
There has been a very valid concern of running this daemon when not needed and the
overhead. Looking at the
source it appears the client goes to sleep and does nothing until there is a
connection. Tests with 'top' confirm
this. Even with a connection the daemon's cpu usage is typically less than 8%. Again
in my tests running with
xinit showed no speed difference while the daemon was waiting and even with a
connection it was
barely noticeable on the workstation.
:)
On Fri, 7 Jun 2002 [EMAIL PROTECTED] wrote:
> Ok, so the curiosity got the better of me, and I decided
> to take a look at the x0rfbserver program.
>
> I grabbed the source tarball and looked at the code, to see if
> I could understand how it works, and what it would take
> to eliminate the pop-up dialog and to setup the properties
> via commandline args.
>
> What totally surprised me was the COMPLETE lack of comments
> and documentation.
>
> If you guys EVER catch me distributing code like this, then get
> a gun and shoot me!
>
> Maybe they figured that the comments would all be in German
> and, and most people wouldn't understand anyway, but jeez.
> at least give us a clue of how the thing works.
>
> I come from a Cobol world, where the idea was that the
> code would be self-documenting, and even my cobol code
> contains tons of comments.
>
> Ok, enough ranting :)
>
> What i'm trying to figure out, is: Does this thing
> work with any Xserver, or does it have to be an xserver
> that uses vesa ?
>
> Assuming it works with any Xserver, it may be a very lightweight
> program, in terms of its memory consumption, and it may
> very well sit there on a workstation without causing much
> trouble.
>
> Then, when someone wants to view the session, they'd just
> connect up to it.
>
> I can see where I'd like to add a dialog box, giving the
> user a chance to permit/deny the connection.
>
> Anyway, I won't be doing much with this until I get v3.1
> out the door.
>
> Jim.
>
>
>
> On Fri, 7 Jun 2002, John_Cuzzola wrote:
>
> >
> >
> > > 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
> >
>
>
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
_____________________________________________________________________
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
