Child pages
  • 4.7 Remote Graphical Login: Using Xvnc and gdm for One-Shot sessions
Skip to end of metadata
Go to start of metadata

GDM (GNOME)

I think this is now in a fit state for consumption. Please try it out, even if you're not sure you could use it. Inquiring minds want to know.

Basic premises

A reasonably clean installation of OI-151.1.7 (any version OI should do just fine), with Xvnc and gdm installed. Gnome and a window manager of your choice seems a good idea, if this exercise is to be at all meaningful. Or some other combination to provide you with a graphical user environment.

The first thing is to start xvnc-inetd under SMF in the default form. You also need to enable gdm to accept XDMCP login connections, and relax the security settings for gdm slightly.

If you've (ever???) installed SunRay Server software on the login host, you must also correct the permissions on three directories, as detailed below. Other corrections might be needed in other circumstances.

So what is it, then?

This is a login facility, i.e. you run vncviewer <host>, or use some other VNC client, and a gdm login session will appear in a window on your client machine. You log in roughly as if you were on the console of <host>.  Multiple users can log in in parallell, limited only by the speed and other resources of <host>.

This provides some of the advantages of using thin clients, like SunRays, in that you can have a remote GUI, with all the comforts of a GUI prompting you in admin tasks you don't perform very often, without ssh-ing across, starting a server manually, noting down the display number and starting a viewer on that display number.

It is also NOT a facility for letting others view your login screen: you can do that as well with Xvnc, but you need to set that up separately, using different TCP ports.

The session started by this scheme is a one-shot session. If your vncviewer dies on the displaying host, your Xvnc session dies, too. The scheme presented here does NOT replace persistent sessions.

How to set up Xvnc as a remote login facility

On the host you want to make available for graphical login sessions, install the required packages: x11/server/xvnc and system/display-manager/gdm, if they're not already there. Make sure the box you're using as a physical display has vncviewer or some other VNC client installed.

Configure xvnc-inetd, using:

:; pfexec svccfg -s xvnc–inetd editprop

Make sure the lines for the inetd_start/exec method definition and the inetd/wait property look like this:

# setprop inetd/wait = boolean: false
...
# setprop inetd_start/exec = astring: "/usr/bin/Xvnc -inetd -query localhost -once securitytypes=none"

Check in /etc/services that vncserver is defined to use a free port, 5900 by default.

Edit /etc/gdm/custom.conf to contain these lines:

[security] 
DisallowTCP=false
[xdmcp]
Enable=true
DisplaysPerHost=16

This will enable gdm to manage remote login sessions, and also allow more than one remote login session from a single computer. Note that "16" may be a bit excessive for you...

Start xvnc-inetd and restart/refresh gdm:

:; pfexec svcadm refresh gdm
:; pfexec svcadm restart gdm
:; pfexec svcadm enable xvnc-inetd

And how does it work?

When you connect to the xvnc-inetd service, i.e. to <serverhost>:5900 by default, xvnc-inetd starts up a VNC server for you that's also a local X server for X clients on <serverhost>, the host on which it runs. That go-between X+Vnc server is connected to your VNC client session through its stdin and stdout. The X server that you have now started uses no TCP port.

The xvnc-inetd service is run in nowait and with the arg -once, so the callee dies once the actual X+Vnc server has started, and it all starts again when a new caller connects.

Since login security is handled in gdm, which runs as a child of the Xvnc process, no other security measures are strictly necessary, I hope.

Problems one may encounter, and solutions

If nothing seems to work, try and get a log.

  • In one terminal on the display client, do:

    clienthost-prompt> ssh user@<serverhost>
    serverhost-prompt> vncserver :N -Log '*:stderr:100'  
  • In another window on the display client, do:

    clienthost-prompt> vncviewer <serverhost> :N

The log spewed out in the terminal logged on to the Xvnc server host should contain enough clues. If things seem shaky, check if you have failed to install some obscure part of GNOME.

Known issues with SRSS

If you are on a Sun Ray server using SunRay software SRS 5.2 or SRSS of an older ilk, check for the permissions of certain directories:

Directory          Permissions required

/tmp/.X11-unix, /tmp/.X11-pipe

  0777 (both)
/var/run/xkb  0775

The SRS installation sets these dirs' permissions too restrictively (note that by default these paths are on tmpfs, recreated upon every reboot of the server).

There might be more secure solutions, please add a comment if you know of any.

 

LIGHTDM (MATE)

This was tested on /hipster, since it supports MATE desktop. How to install and use mate desktop you might find on https://wiki.openindiana.org/oi/MATE+1.14+Desktop page. To me it was logical to describe use of (only) Xvnc on this page - and if I am mistaken, then please re-organize...

  • This actually requires change on only one file: /etc/lightdm/lightdm.conf (scroll to the bottom of file - you can also experiment with size of display):
/etc/lightdm/lightdm.conf
[VNCServer]
enabled=true
command=Xvnc securitytypes=none
port=5900
  • After that, service has to be refreshed and restarted (this might you log out - I did not tested it that way, since that refresh/restart came after OS upgrade):
Shell
$ pfexec svcadm refresh svc:/application/graphical-login/lightdm:default
$ pfexec svcadm restart svc:/application/graphical-login/lightdm:default
  • Go to another PC and try to connect using vncviewer program
  • That is it!
  • No labels