Remote Multilevel Desktop Sessions
By Glenn Faden-Oracle on Aug 16, 2007
Remote X11 client access is generally disabled, and only Trusted Path processes can modify the X11 server access control policy. For remote CDE access, we provide a script, dtappsession(1), which brings up a remote Tooltalk session and Application Manager. But this is a pretty limited solution. We are working on a secure solution based on XDMCP.
Meanwhile, I have developed a workaround which uses VNC. I am currently using this on a headless T2000 system, storms.sfbay, running Solaris 10 update 4. Since it has no graphics display, I considered using Xvnc, which is a combined X11 and VNC server. But that server doesn't support the xtsol extension, so it wasn't viable. Instead, I am using a shell script called Xvfb(1), which is a wrapper around Xsun(1), that uses a virtual framebuffer, and requires no mouse or keyboard. I am using a VNC server called x0vncserver, which is downloadable from the RealVNC web site. It is included in the VNC Free Edition for Solaris 7 (SPARC). Yes, it's that old!
There is a better VNC server that is included in Solaris Expresss Developer Edition, in /usr/bin/vino-session, that works on x86/x64. I haven't found a pre-compiled version of vino-session or x0vncserver (x86) for Solaris 10, but the sources are available, so we could build one.
The RealVNC bundle includes a vncviewer that you can use on your local system. In my case, I run it in my internal zone. This doesn't require CIPSO, but your local system must be assigned the admin_low network template in the tnrhdb(4) file of the headless system.
On the headless system, I copied following two files:
- cp /usr/dt/config/Xservers /etc/dt/config
- cp /usr/dt/config/Xsetup /etc/dt/config
# :0 Local local_uid@console root /usr/X11/bin/Xserver :0 -nobannerand added the following to /etc/dt/config/Xsetup
:0 Local local_uid@none root /usr/openwin/bin/Xvfb :0 -nobanner -dev vfb screen 0 1024x768x24
# VNCThe password for VNC access is set by the utility vncpasswd. Since I ran it as root on the server, it is stored under /.vnc
/usr/local/bin/x0vncserver display=:0 PasswordFile=/.vnc/passwd >/dev/null 2>&1 &
I ran the same program on my local system so that I don't need to enter the password each time.
After modifying these files, you need to restart the dtlogin process:
svcadm restart cde-loginOn the client side I just run this:
vncviewer PasswordFile=/home/gfaden/.vnc/passwd storms.sfbay
You can also use the Java-based vino viewer in SXDE, by running /usr/share/gnome/vino/vino-client.jar .
The dtgreet(1) window (Welcome to storms) comes up and you can choose trusted CDE or JDS. They should both work fairly well. When you logout, the VNC session ends, too.
There are a few minor problems, such as the cursor not being updated correctly, and there is an issue with changing Trusted JDS workspace labels. In my previous blog, I mentioned a workaround for this bug which disabled the MIT Shared Pixmap extension, MIT-SHM. However, the VNC server requires this extension, so it must be enabled.
VNC supports encryption between the client and server if you need it. In my case, I didn't bother; I'm on a protected network (SWAN), or using IPsec when working from home.