X11 over the network
Using X over the network affords accessing remote servers graphically as if you were on the console. So for instance, from your Windows workstation, you can run Windows and Linux side by side, full screen, and switch with function-key combinations such as alt-tab or ctrl-alt-F7 or F8. A very handy feature. X is natively present and fast on Linux. On Windows, it will always be a bit slower, and you need to install an X server. VcXrv is a very competent one.
The software presenting an X window on a terminal is called an X server, which is contrary to what we are used to, as the X server is not on the server but actually on the client ! Over the Internet, you will always encapsulate X11 in SSH (X11 forwarding, to configure in /etc/ssh/sshd_config) as the X protocols are not secure. However, X needs a significant bandwidth so it is not likely that you will use it over an ADSL connection as it would be too slow. Optical fiber could be OK though.
Xdm, Kdm, Gdm
X requires a daemon on the server to handle connections. The base daemon is Xdm, that offers a graphical login directly under X, with no desktop manager. Access can be local on the computer console, or can be from an X terminal or X emulated terminal on the network.
The KDE and Gnome desktop environments Kdm and Gdm come with Xdm variants that have a different look and feel. It is possible to run one or several of the three, provided that they will not compete for management of the same terminals.
However it makes sense to use only one. Kdm is a good choice as it affords choosing the Session Window Manager (Kde, Xfce4, ...) from the connection dialog box.
For KDE to manage X terminals over the network, update /etc/kde/kdm/kdmrc specifying Enable=true for [Xdmcp].
In /etc/kde/kdm/Xaccess, uncomment line #* # any host can get a login window to authorize connection from any incoming IP address (or to restrict usage to your local network).
Another trick using KDM : to be able to connect as root, update /etc/kde/kdm/kdmrc, specifying AllowRootLogin=true for [X-*-Core].
In /etc/X11/xdm/xdm-config, comment out the last line to authorize X terminal access from the network. Else port 177 won't be listened, as can be verified using nmap -sU localhost, that lists the listening UDP ports. If checking with tcpdump, udp port xdmcp unreachable will be seen on the wire.
In /etc/X11/xdm/Xaccess, uncomment line #* # any host can get a login window to authorize connection from any incoming IP address (or to restrict usage to your local network). In /etc/X11/xdm/Xservers, comment out the line with :0 to avoid getting an X login screen on the console.
To automatically launch xdm during Slackware init, add the following lines to /etc/rc.d/rc.local :
# Xdm if [ -x /usr/X11/bin/xdm ]; then /usr/X11/bin/xdm fi
At the firewall level, the X terminal must be able to contact the host using UDP 177 and the host must be able to callback the X terminal using TCP 6000:6063. Open the corresponding ports, but to avoid login information to be sent over the wire, restrict usage to the local network :
# SSH-tunnelled X-Window output appears as input on interface lo iptables -A INPUT -p udp -j ACCEPT --dport 177 -s 192.168.0.0/24 iptables -A INPUT -p tcp -j ACCEPT --dport 6000:6063 -m state --state NEW -s 192.168.0.0/24 iptables -A INPUT -i lo -p tcp -j ACCEPT --dport 6000:6063 -m state --state NEW -s 192.168.0.0/24
For access from the Internet, il will be better to encapsulate X11 within an SSH session, using the X11 forwarding option. Due to encryption, this is however much slower. In this case, instead of KDE, prefer a less network-intensive window manager such as xfce4.
The X terminal can be a Linux computer on which you run the X server to display X from a remote client. For instance typing nohup X -query host :1 & will display X from host host on virtual terminal 8. This way you will be able to keep local X and remote X side by side and switch between them using <ctrl><alt><F7> and <ctrl><alt><F8>.
The X terminal can also be a Windows PC equipped with an X emulator such as VcXrv or other software found from the Internet. At the time of this writing though, such software is frustrating due to unstability or poor licensing conditions, so VcXrv seems to currently be the better choice, although a bit slow. Note : Specify in the configuration that you will be using XDMCP.
On Windows, use the firewall with «Allow exceptions» and create an entry in the firewall for the X11 protocol (port 6000), specifying in the scope the server IP address or the local network (not the Internet).
|X11 configuration||Main Page||Compiling the Kernel|