Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

just a reminder, please take a look at the script I attach (the scripts aren't
mine but from an user)

Created an attachment (id=24230) [details]
conf.d

Created an attachment (id=24231) [details]
init.d

http://forums.gentoo.org/viewtopic.php?t=72893

vncd hacks are an annoying thing.  I just wrote my own actually, it takes a
conf.d file that's just a bunch of lines of user,display,geometry and su's to
the user, then runs vncserver $display -geometry $geometry.

What we REALLY need is an actual vncd coded for tightvnc.  It should require a
username/password entry, and then track that, on connect.  Here's how this
would be done securely:

 - vncd service running, listening on port 5999 (vnc uses 5900 + display, this
would equivalate to :99)
 - User connects with vncviewer to vnchost:99
 - A new vncserver is spawned, on a new display, on a new port, and the
connection is directed at it.  This is the same as what apache does; the client
port will be 5999 and the server port will be something else.
 - There is *no* password, screen immediately comes up with no authorisation.
 - vncd starts up vncdauth, an X program that demands that the user enter a
username and password (just like xdm/gdm does).
 - vncd checks to see that the username/password is valid AND the user is in
group vncusers, if not, kills the Xvnc that was started.
 - If the user is still connected (authorization approved), then it starts up
gdm/kdm/xdm/xsession/etc.  Optionally, the user may chose from a list of
already running VNCs and connect to those without entering his password, but
this will still cause the chosen VNC to request authorization for reconnect
 - VNC session operates as normal from then on
 - When other connections come directly in to a user's vnc, the vnc requests
authorization as a normal vncserver would, from the vncpasswords in ~/.vnc
 - When the WM is exited, the Xvnc dies, connection is closed.

This is the only real way to make something like this actually majorly useful
for generalized remote logins; running a hundred VNCs for each of your users is
impractical.

Hey, the scripts look better than mine (attached after this; basically ported
from what FC1 uses to the gentoo init architecture). The one problem I have
with these scripts is that I changed:

su ${user%%:*} -c "PATH=$PATH:/usr/X11R6/bin vncserver :${user##*:} $VNC_OPTS"
&>/dev/null

and the ilk to 

su ${user%%:*} -c "vncserver :${user##*:} $VNC_OPTS" &>/dev/null

See, when root's shell has been changed to TCSH, changing the path doesn't work
correctly. So, either check and see what root's shell is, or don't set it at
all.

Created an attachment (id=34227) [details]
redhat vncservers init script ported to gentoo init architecture

Created an attachment (id=34228) [details]
redhat vncservers config script ported to gentoo init architecture

Add - the init script needs modified depend section as follows:

depend() {
        need net
        after netmount nfsmount
}

Because if you're NFS mounting home, it can only start after those are done...

Add - the init script needs to cd into the user's homedir when starting the
server (the redhat one does this already). Otherwise, the default path that
xterm gets when it starts is wrong (among other things).

Something like:

su ${user%%:*} -c "cd ~${USER} && vncserver :${user##*:} $VNC_OPTS" &>/dev/null

works.

Are these scripts in any of the tightvnc ebuilds yet?

go for it

Added the scripts to both tightvnc and vnc, thanks to the one who made them,
and thanks Matthew for the info :)