Difference between pages "X11 configuration" and "X11 over the network"

From Wikislax
(Difference between pages)
Jump to: navigation, search
(Created page with "{{RightTOC}} '''X11R7''' and later eliminate the need for manual configuration of '''X11''' during Linux installation. The correct graphic card, screen, keyboard and mouse ar...")
 
(Created page with "{{RightTOC}} 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...")
 
Line 1: Line 1:
 
{{RightTOC}}
 
{{RightTOC}}
  
'''X11R7''' and later eliminate the need for manual configuration of '''X11''' during Linux installation. The correct graphic card, screen, keyboard and mouse are recognized automatically and stored in '''/etc/X11/xorg.conf''' (that you can still edit manually).
+
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. [https://sourceforge.net/projects/vcxsrv/ VcXrv] is a very competent one.
  
== Local language ==
+
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.
  
The Language at Slackware level is chosen as part of system installation. '''pkgtool''' affords re-running startup scripts later. Also, files '''/etc/profile.d/lang.csh''' and '''/etc/profile.d/lang.sh''' can be edited manually to update the shell environment with the correct language settings.
+
For more information on using remote X applications, check this [http://www.xs4all.nl/~zweije/xauth.html mini-HOWTO] or this excellent [http://shop.oreilly.com/product/9780596101954.do O'Reilly book].
  
Choosing the language in X requires additional steps. From within KDE, choose the '''Settings''', '''System Settings''' application. Choose the display languages using '''Common apparence and behaviour''', '''Locale''', then choose the keyboard layout using '''Hardware''', '''Input devices''', '''Layout'''.
+
== Xdm, Kdm, Gdm ==
  
Last but not least, in Slackware '''14''', the logon screen requires copying '''/usr/share/X11/xorg.conf.d/90-keyboard-layout.conf''' to '''/etc/X11/xorg.conf.d''' then manual editing, replacing '''us''' by your locale.
+
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.
  
cp /usr/share/X11/xorg.conf.d/90-keyboard-layout.conf /etc/X11/xorg.conf.d
+
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.
vi /etc/X11/xorg.conf.d/90-keyboard-layout.conf
 
  
For other Slackware versions, please refer to this [http://docs.slackware.com/howtos:window_managers:keyboard_layout page].
+
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.
  
== X11 legacy configuration ==
+
== Kdm ==
  
As the title suggests, it is normally no longer needed to effect these settings that are left here for reference. So please proceed to the next paragraph.
+
For KDE to manage X terminals over the network, update '''/etc/kde/kdm/kdmrc''' specifying '''Enable=true''' for '''[Xdmcp]'''.
  
'''X11R6''' makes you run '''Xorg -configure''' to generate the '''/etc/X11/xorg.conf''' file based on the results of autoconfigurationor let  '''/usr/X11R6/bin/xorgconfig''' produce a base '''/etc/X11/xorg.conf''' file for your configuration and fine-tune it.
+
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).
  
If using the latter, a key point is the graphical board. If it is not in the list of compatible hardware then it is not managed. <u>A solution is to use the '''Vesa''' driver (number 0)</u> but the maximal resolution is 1280 x 1024, which will probably be under the possibilities of your screen. <u>A workaround is to use an X terminal</u> on another machine. See «using Xdm» on the next page.
+
Another trick using KDM : to be able to connect as root, update '''/etc/kde/kdm/kdmrc''', specifying '''AllowRootLogin=true''' for '''[X-*-Core]'''.
  
For the mouse, try to use '''auto [Auto detect]''' and the '''/dev/input/mice''' default device.
+
== Xdm ==
  
Also important are the horizontal and vertical frequencies. This information is probably located in the documentation of your screen. If not, word goes that a program named '''SuperProbe''' would be able to determine the values, but I have no additional information about this. Beware, a configuration mistake can definitely damage your screen! Otherwise the resolution can be edited manually in  '''/etc/X11/xorg.conf'''.
+
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.
  
== X11 usage ==
+
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 start X, use the '''startx command'''. To stop X, use '''ctrl+alt+backspace'''. It’s good to know as if your screen freezes this avoids rebooting. On '''i386''', you can switch among consoles using '''ctrl+alt+Fn''', but if you have a screen under X, you need to go back using '''ctrl+alt+F7''' (or another Fn function key depending on the number of virtual consoles configured in your kernel).
+
To automatically launch '''xdm''' during Slackware init, add the following lines to '''/etc/rc.d/rc.local''' :
  
By defaut, Slackware configures a single console on '''ctrl+alt+F6''' to use in addition to the X console on '''ctrl+alt+F7'''. It's possible to configure more by choosing the run level 4 for consoles c1 to c6 in '''/etc/inittab''' :
+
# Xdm
 +
if [ -x /usr/X11/bin/xdm ]; then
 +
        /usr/X11/bin/xdm
 +
fi
  
# These are the standard console login getties in multiuser mode:
+
== X11 firewalling ==
c1:12345:respawn:/sbin/agetty 38400 tty1 linux
 
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
 
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
 
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
 
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
 
c6:12345:respawn:/sbin/agetty 38400 tty6 linux
 
  
Console mode is run level 3 and graphical mode is run level 4. To switch from console mode to graphical mode and vice versa, use '''telinit 4''' and '''telinit 3'''.
+
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 :
  
== X11 drivers ==
+
# 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
  
Default drivers are available for the most common boards but might be slow. To speed up, you might go to your chipset provider website and get a recent driver. Of course, it will be a good idea to check beforehand that your chipset provider supports Linux and provides Linux drivers (but this is generally true for all of your hardware). nVidia are Linux-oriented and provide Linux drivers for all their boards. However, at the time of this writing (July 2012), nVidia has not fully taken the virtualization road, and the nVidia drivers are not compatible with Xen (4.1.2). The '''Nouveau driver''' - available in kernel 3.4.2 upstream - is. Although Nouveau is not a very popular driver, due to performances usually deemed insufficient.
+
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.
  
OK now download and run the install script. Execution requires the presence of development tools and Linux headers, but «taints the kernel» : in case of crash,  the kernel debug information could be unreliable, meaning that if you have an issue with something, you could be denied support until you provide debug information obtained with an untainted kernel.
+
== X11 server ==
 +
 
 +
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 <i>host</i> :1 &''' will display X from host <i>host</i> 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 [https://sourceforge.net/projects/vcxsrv/ 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. <u>'''Note'''</u> : Specify in the configuration that you will be using XDMCP.
 +
 
 +
== Windows firewall ==
 +
 
 +
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).
  
 
<br/>
 
<br/>
  
{{pFoot|[[IPTables]]|[[Main Page]]|[[X11 over the network]]}}
+
{{pFoot|[[X11 configuration]]|[[Main Page]]|[[Compiling the Kernel]]}}

Latest revision as of 22:24, 6 December 2017

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.

For more information on using remote X applications, check this mini-HOWTO or this excellent O'Reilly book.

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.

Kdm

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].

Xdm

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

X11 firewalling

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.

X11 server

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.

Windows firewall

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