Fedora 6 & 7

some problem in Fedora 6 and 7 all I get is a grey screen and standard X cursor

Using VNC to access an LTSP server

This mechanism allows a VNC client to access the LTSP server as an LTSP client. This is not strictly an LTSP feature as it allows other devices that support the VNC protocol to access LTSP server resources.

Rationale

It is a rare site that is all LTSP/Linux. Many times the site can support a connection from a Windows or Macintosh computer without the computer requiring a full blown Xserver. This allows the use of some Linux programs for all users, Windows and LTSP.

Here are some usage scenarios:

• Normal login
  • Accessing terminal server from on-site or off-site via a stand-alone VNC application
  • Accessing terminal server from off-site via a browser-based VNC application
• Monitoring a user already logged in to a terminal (see VncModule)
• Providing remote support to a user already logged in to a terminal
• Using a VNC viewer on the terminal to log into some other system

Unless otherwise noted, this page is about access the terminal server.

Disadvantages

• Increases the loading on the server as the Xserver for each connection resides on the server. This consumes CPU and, in particular, memory resources.
• Many VNC flavors don't support encryption (generally just an issue with remote access).
• For off-site access, VNC doesn't support remote printing or remote sound (compare to NoMachine/NX).

Providing access to terminal server using Xvnc + inetd

How does it work

The server is configured to allow inetd (xinetd) to manage connections to a particular TSP port from a VNC client. When a connection occurs, inetd starts the Xvnc program which uses XDMCP to access the server login program such as XDM/GDM/KDM. The user is therefore presented with a login box as though they were using a LTSP thin client. This process uses the same port for any number of simultaneous connections.

Several different configurations can be enabled to have different Xserver properties as needed. The VNC server is started with a fixed resolution or colour depth but inetd can be configured to have several ports listening for connections to Xservers with different properties. The display should not open to the full resolution of the client to allow access to the menu etc.

Setup

Services

Add the following to the end of /etc/services. The services file provides the mapping between the name of the port and the port number. Add as many ports as required for different Xserver properties

xvnc1024         5950/tcp                # VNC Service with 1000x700 resolution
xvnc800          5951/tcp                # VNC Service with 780x550 resolution

Add more as required (5952,5953,...) the names must be unique.

Inetd configuration

Xinetd

The following is suitable for RedHat/Fedora

Add this file to /etc/xinetd.d/xvnc1024

service xvnc1024
{
        disable = no
        protocol = tcp
        socket_type = stream
        wait = no
        user = nobody
        server = /usr/bin/Xvnc
        server_args = -inetd -query localhost -geometry 1000x700 -depth 16 -cc 3 -once securitytypes=none -fp unix/:7100
}

Add this file to /etc/xinetd.d/xvnc800

service xvnc800
{
        disable = no
        protocol = tcp
        socket_type = stream
        wait = no
        user = nobody
        server = /usr/bin/Xvnc
        server_args = -inetd -query localhost -geometry 780x550 -depth 16 -cc 3 -once securitytypes=none -fp unix/:7100
}

Add more as required. The file names and services names must reflect the name in /etc/services.

Restart xinetd

# service xinetd restart

Inetd

Testing

Test the configuration by connecting from another client by connecting to the

• < server name or IP >:50 for a 1000x700 display or
• < server name or IP >:51 for a 780x550 display

You should be presented with a login box as normal

Tweaking

The Xvnc has arguments to change properties such as resolution and colour depth. It should be obvious in the server_args line as to which arguments need to be changed.

The Xnc server also does not have to make XDMCP requests to the localhost. Any server that accepts XDMCP can provide a login box. This allows a different server to provide the VNC server than the LTSP server if loading becomes an issue.

Some applications will only run on 8 bit (256 colour) displays. A special VNC server just for 8 bit connections can be configured and accessed from the LTSP clients.

-- DarrylBond - 17 Dec 2004

x11vnc

.. cliebow@ltsp.org

Included with LTSP 4.1 is an executable called x11vnc. This program allows you to take control of an existing display on a client or server. Like many of you, I have servers spread across the county and can often save a trip by taking over a display across the internet.

x11vnc runs as a local app on the client, polls the existing x display of the terminal and makes it available to VNC. Normally one appends a display number when running vnc (like mybigserver:1) Using x11vnc one connects without specifying a display number. Briefly,you ssh into the client as root, execute the command x11vnc -display:0, then use vncviewer to see the desktop.

We have incorporated these commands into the Teachertool.py script, such that one highlights a particular machine/username combination,clicks run and then chooses either a view-only or take-over session.

One important fact is that the -via feature used to make Teach2.py work seems only available in tightvnc.This is NOT the default vnc program used in redhat, for instance.It is easy enough to rpm -qa|grep vnc and remove vnc and vncserver with rpm -e (assuming rpm is happy today) and install instead tightvnc-1.2.9.

1.Enable local apps

To generate the private/public key pair for the workstations, run the 
following commands: 
    ssh-keygen  -q  -t rsa1  -f /opt/ltsp/i386/etc/ssh/ssh_host_key      -C ''  -N ''
    ssh-keygen  -q  -t rsa   -f /opt/ltsp/i386/etc/ssh/ssh_host_rsa_key  -C ''  -N ''
    ssh-keygen  -q  -t dsa   -f /opt/ltsp/i386/etc/ssh/ssh_host_dsa_key  -C ''  -N ''

You will then take the contents of the /opt/ltsp/i386/etc/ssh/ssh_host_rsa_key.pub and add
 a line in /etc/ssh/ssh_known_hosts for each workstation. Make sure you put the workstation 
name in front of each record.
Below is an example of how the /etc/ssh/ssh_known_hosts file should look: 
    ws001  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxFCM2eZU7P3HvEOMYhAFUiwE...
    ws002  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxFCM2eZU7P3HvEOMYhAFUiwE...

2.Enable root access to clients

Allow root Access-Probably there is a better way but...I simply edited /opt/ltsp/i386/etc/passwd
 and changed /bin/false to /bin/sh.Then I created a /opt/ltsp/i386/etc/shadow file and pasted a non
 priviledged users line from my server's /etc/shadow. Then i changed the name at the beginning to 
 root. Now the root account is available on the client using that non-privileged password.

3.Plop the new x11vnc executable into /opt/ltsp/i386/usr/bin (or symlink the existing)

This is Karl Runge's newest x11vnc compiled for ltsp 4.1. Very cool! http://169.244.61.66/x11vncnew.gz

3.5 Did i forget to say that in ts.conf you can DISABLE_ACCESS_CONTROL=Y? This eliminates xauth probs......MORE importantly: Setting this up on rhel 4 it was necessary to overide the DISABLE_ACCESS_CONTROL=Y item in lts.conf and hard-code it into screen.d/startx. After the if statements regulating access control i add the one line ACC_CTRL="-ac" so I KNOW it is disabled ..Chuck

4. Execute python Teach2.py

Here is a link to my Teach2.py http://169.244.61.66/Teach2.tar.gz

In Dapper there is a tweak to line 303.See the Ubuntu section to allow showing of ser@computer..Also my experiences with runspy.

cliebow@ltsp.org

We have reports of ssh failing using the 2.6 kernel. Apparently devpts needs to be mounted with the following: added to rc.sysinit.

if [ `grep "Linux version 2.6." /proc/version`" != "" ] then 
  echo "Mounting devpts filesysytem"
  mount -t devpts devpts /dev/pts/
fi

Some additional information on running x11vnc

1. To enable login in on the workstation without a password we did this:

 first generate as root a DSA key
    > ssh-keygen -q -t dsa -f /root/.ssh/id_dsa
 Create a directory .ssh in /opt/ltsp/i386/root/
    > mkdir /opt/ltsp/i386/root/.ssh
    > chmod 700 /opt/ltsp/i386/root/.ssh
 Copy the public dsa file
    > cp /root/.ssh/id_dsa.pub /opt/ltsp/i386/root/.ssh/authorized_keys
    > chmod 600 /opt/ltsp/i386/root/.ssh/authorized_keys
 Now it's time to test if login without a password is permitted.

2. GDM caused some trouble, no authority to connect to the workstations X server. We solved that:

 the directory /var/gdm/ on the server contains the authority files, (for instance: cerberus_b1.cerberus:0.Xauth). Copy
 the appropriate file to the workstation.
    > scp /var/gdm/${WORKSTATION_NAME}*.Xauth ${WORKSTATION_NAME}:/tmp/Xauthority
 
 after that it's possible to start x11vnc and vncviewer:

    > ssh -L 5900:localhost:5900 ${WORKSTATION_NAME} 'export XAUTHORITY=/tmp/Xauthority; x11vnc -display :0' &
    > vncviewer -encodings "tight hextile zlib" localhost:0

I think the appropriate way to use x11vnc depends heavily on your LTSP configuration. We needed some tweaks to get it working with GDM. I think it will be different for XDM and others.
-- MarkLeeuw - 03 Jan 2005

Comparison of Java applets

Use a VNC Java applet to allow access to your terminal server from any virtually computer anywhere without installing a viewer (think Internet Cafe, for example).

Some or all of these applets have common sources, so it'd be good to figure out their "genealogy."

Name	License	Full Session Encryption	Limitations	Comments
UltraVNC JavaViewer? 1.0.2	GPL	http://forum.ultravnc.info/viewtopic.php?t=5318Yes with SSL-Explorer bundle]]	?	?
SSHTools sshvnc 0.1.3	GPL	SSH	Some bugs	Last updated 2003
TightVNC Java Viewer	GPL	No?	?	?
RealVNC Java VNC Viewer	Multiple	Yes in Ent. Ed.?	?	?

If your favorite Java VNC applet doesn't support encryption but you want encryption, maybe you can combine it with a encrypted port forwarding Java applet such as (FIXME: research this list): MindTerm^?, JCTerm, SSL-Explorer, ...? (I don't list all VPN options since we're just talking about what can be used through a browser.)

-- AndrewZ - 15 May 2007

sshvnc: Secure remote desktop via web browser

The main benefit of sshvnc is that the remote user only needs a Java-enabled browser to connect. In other words, you can walk up to almost any computer in the world and get a terminal session without installing any software or doing any configuration. This is contrasted to solutions like NX where the user must install and configure local software in order to connect. NX on the other hand provides better performance with higher resolutions and better overall usability in my opinion. I use them both in different situations.

Here's a link to my notes on setting up sshvnc. -- DerekDresser - 22 Dec 2004

http://network.gouldacademy.org/modules.php?name=News&file=article&sid=21

• The above link is dead (9/30/2005), so here are its snapshots from archive.org:

http://web.archive.org/web/*/http://network.gouldacademy.org/modules.php?name=News&file=article&sid=21

sshvnc tweaks at Ellsworth.

Our experience..without Derek to help us we had problems with the server_args line, and so split server_args to another file to start vnc as an xinetd service

#/etc/xinetd.d/vnc 
 service vnc
{
   disable   = no
         wait            = no
         protocol        = tcp
         user            = nobody
        server          = /usr/local/bin/lts_vnc
         server_args     = 800x600 16
         socket_type   = stream
   }
service vnchttp10
{
   disable   = no
   socket_type = stream
   protocol = tcp
   wait = no
   user = nobody
   server = /usr/X11R6/bin/vnc_inetd_httpd
   server_args=800 600 5910
   type=UNLISTED
   port = 5801
}

#/usr/local/bin/lts_vnc
#!/bin/bash
#echo "$0 $*" >> /tmp/vnc.log
/usr/bin/Xvnc -inetd -once -query localhost -geometry $1 -depth $2 #-fp tcp/localhost:7100 securitytypes=none

Using VNC.SO to control terminals

from "shore" as submitted via pastebot on #ltsp

HOWTO using vnc.so to control terminals

This HOWTO is made for K12LTSP 4.2.0, but it should also work on other systems with minor changes. Log as a root to the LTSP server (avoid using a terminal if possible).

First we must edit lts.conf (usually in /opt/ltsp/i386/etc/lts.conf)

nano /opt/ltsp/i386/etc/lts.conf

and add this line

X4_MODULE_02 = vnc

Note! You can later disable the vnc by editing lts.conf and commenting X4_MODULE_02 = vnc if needed.

Then we must edit build_x4_cfg file.

nano /opt/ltsp/i386/etc/build_x4_cfg

and add these lines

        Option     "httpdir"  "/usr/share/vnc/classes"
        Option     "PasswordFile"       "/root/.vnc/passwd"
        Option     "rfbport"    "5900"
        Option     "usevnc"

In Screen section Example after a Modes ${MODE[*]}

Now we make a password that is asked when connecting to terminals using VNC. To create the password run /usr/bin/vncpasswd to make a /root/.vnc/passwd password file. Now copy the /root/.vnc directory to /opt/ltsp/i386/root/ using

cp -R -p /root/.vnc /opt/ltsp/i386/root/

Note: Do not give this password to anyone you don't trust! This password is like a root password and should be keep secret. The person that knows this password can spy and control any terminal, but knowing this password does not allow him to log in to the terminal.

DANGEROUS EXAMPLE: If some user logs in to terminal and someone is spying the terminal using this password. The spy may be able to get the user's password example when the person at the terminal goes to get a coffee on other side of a closed room and thinks it is not important to log off because no one can enter this room. But If someone was spying the terminal and got this key he can then secretly change anything on the users terminal or steal/change passwords and the user may not see or even notice it.

Now we need to copy the vnc.so X module from the main system to the terminals system. (NOTE! You may need to build/rebuild the vnc.so module and if you rebuild it. It may help in a way that you dont have to copy some lib files that we do in the next section)

cp /usr/X11R6/lib/modules/extensions/vnc.so /opt/ltsp/i386/usr/X11R6/lib/modules/extensions/

Now we copy few lib files from the servers to the terminals. We need to copy libstdc++.so.6 and libgcc_s.so.1 files to the terminals that is required by vnc.so.

cp /usr/lib/libstdc++.so.6 /opt/ltsp/i386/usr/lib/

WARNING the next file is likely going to overwrite an existing lib file. Because of that I recommend to copy (actually move)of the original libgcc_s.so.1 file using:

mv /opt/ltsp/i386/libgcc_s.so.1 /opt/ltsp/i386/libgcc_s.so.1_backup

Now we can safely copy the newer libgcc_s.so.1 that vnc.so requires to the terminals:

cp /lib/libgcc_s.so.1 /opt/ltsp/i386/lib/

Because I don't know if the newer file causes any errors, there is a one little thing to do to minimize it. (OR MAKE IT WORSE and NOTE! This is not needed to make vnc.so to work)

ln -s /lib/libgcc_s.so.1_backup /opt/ltsp/i386/lib/libgcc_s.so -f

Now reboot the terminal(s).

If everything went well, you should now be able to login to terminal using VNC and see the terminal's login screen or whatever is shown at the moment.

Example:

vncviewer hostname.ltsp (replace hostname.ltsp with the real terminal hostname) or using graphic VNC Viewer and write ws040.ltsp:0 and click OK

Note: You can get a list of terminal hosts/ip using arp -a -i eth0 (If eth0 is not the interface to the lan of terminals then change it) in console, but entriess starting at ? are more likely buggy/ghost ones and ones having word in the same line are terminals that are disconnected or rebooting.

# arp -i eth0 -a
ws040.ltsp (192.168.0.40) at  on eth0              DISCONNECTED TERMINAL
ws041.ltsp (192.168.0.41) at 00:10:5A:E7:63:EC [ether] on eth0

Providing remote support to a user already logged in

There are several ways to remotely provide support to a user already logged in. One way is Vino, a standard part of GNOME, but see Vino note under NotLTSPFriendlySoftware.

VNC viewer as a local app

See LocalApps.

Alternative protocols to VNC

• X11: the standard LTSP protocol
• NoMachine (aka NX): see WorkInProgress

Related pages

• VncViewer
• VncModule: a way to monitor users already logged in
• TeacherTool: monitor/control terminals, etc.