X Server configuration

The XServer configuration file on Linux distributions is normally one of

• /etc/X11/XF86Config-4
• /etc/X11/XF86Config

(searched for in that order) if using the XFree86 XServer, or

• /etc/X11/xorg.conf

if your distribution uses the X.org XServer.

Default bitmap depth (number of colours)

Instead of starting the XServer with "-depth 16" for 16 bits per pixel (which requires editing your gdm/xdm/kdm startup scripts), you can add

DefaultDepth? 16

into the "Screen" section of your XServer's configuration file.

"xRandR" Extension

The X Resize and Rotate extension allows you to change your screen's resolution (and notifies your window manager/applications without restarting X) in a way that Ctrl+Alt+keypad+/- don't.

To make use of the xrandr(1)? program (or the GNOME or KDE front ends), it appears you need to have

Load "xtrap"

in the "Module" Section and

Option "RandR" "on"

in the "!ServerFlags?" Section of your X configuration file.

It doesn't seem to work if Xinerama is loaded though.

Not starting on boot

If you want to get X to not start automatically when your system boots:

RedHat, FedoraCore and related distros

edit /etc/inittab and set the default runlevel to 3, instead of 5.

Debian

run update-rc.d to remove xdm(8)?/gdm(8)/kdm(8)? from the rc2.d directory.

Security

X Auth

xauth(1) is the new way to allow access to your X display. xauth(1) uses tokens (called cookies) to determine if a connection to the X server (eg XFree86) is allowed. These cookies are stored in the /.Xauthority file.

The old xhost(1) way of doing things is deprecated due to lack of security. xhost works on your X server (your local machine) and allows connections based on machine name/IP address, which can be insecure due to spoofing and other things. These days, most distributions start the X server with "-nolisten tcp" which means the x server won't accept connections from other machines.

You need xauth(1) installed if you want to run graphical programs of a machine to a remote display (for example via X11 over ssh - see SSHNotes). Under DebianLinux (if you don't already have an X server installed) you need to

$ apt-get install xbase-clients

The remote machine will also need xauth, so needs xbase-clients installed.

To view the individual cookies, you can do

$ xauth list

but you probably don't care about the data.

To run remote X clients, extract your xauth key from the local system, ssh into remote-host and merge it with the xauth information there.

$ xauth extract - $DISPLAY | ssh <remote-host> /usr/X11R6/bin/xauth merge -

Then you can ssh to the remote machine and run, say, an xterm to connect to my local display with a command like

ssh <remote-host> DISPLAY=$DISPLAY /usr/X11R6/bin/xterm &

Of course, you should do ssh-based X forwarding (see ssh(1) and/or SSHNotes for info), but that doesn't always work. xauth also works in other situations where ssh may not.

If your .Xauthority file gets wiped out (for example, your home directory's partition becomes full) then you won't be able to open any new X windows. Even xhost(1) won't help as it needs to authenticate to the Xserver before changing permissions

$ xhost + Xlib: connection to ":0.0" refused by server Xlib: Client is not authorized to connect to Server xhost: unable to open display ":0.0"

The only solution (I've found) is to log out and re-start your X session. However, if you are cunning, you might be able to get the cookie from one of your currently running processes, especially an ssh connection with X forwarding (do xauth list on the remote machine). After getting some free disk space again, use the xauth merge command as above.

Preventing the server from listening for TCP connections

The stock XFree86 startx(1) script assumes that you want X listening on port 6000. On the common standalone desktop machines, this is an unnecessary potential security risk. To disable this behaviour, edit /usr/X11R6/bin/startx, changing the line

serverargs=""

to say

serverargs="-nolisten tcp"

Now when X is started with startx(1), the server will not be listening on any ports.

IPv6 Support needed

If you have IPv6 enabled X, but your machine doesn't have IPv6 enabled, you might see something like the following error

_X11TransSocketOpen: socket() failed for tcp _X11TransSocketOpenCOTSClient: Unable to open socket for tcp _X11TransOpen: transport open failed for tcp/localhost:10 xterm Xt error: Can't open display: localhost:10.0

In this particular case I'm doing X11Forwarding from another machine (via ssh -X hostname). Strace confirms this as an IPv6 related bug

strace xterm ... socket(PF_INET6, SOCK_STREAM, 0) = -1 EAFNOSUPPORT (Address

family not supported by protocol)

loading IPv6 support on the remote machine fixes this.

See XFree86KeyboardMouseNotes for information on Keyboards and Mice under XFree86

CategoryXFree86Notes