X Server configuration
The XServer configuration file on Linux distributions is normally one of
(searched for in that order) if using the XFree86 XServer, or
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
into the "Screen" section of your XServer's configuration file.
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
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.
- run update-rc.d to remove xdm(8)?/gdm(8)/kdm(8)? from the rc2.d directory.
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.
- To let other local users connect to your display, do the following. E.g: You are logged in as my_self and after doing "su - other_user" you get "Can't open display" whenever you try to start an X application. First, as my_self, export your magic cookie
- xauth extract - $DISPLAY > xauth.key
- Make the file xauth.key readable by other_user, and then as other_user do
- export DISPLAY=:0.0
xauth merge /home/my_self/xauth.key
You should now be able to run X applications as other_user even though you are logged in as my_self.
- 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.
It just might be X11 is not forwarded properly
Don't forget to check that your remote login has the DISPLAY environmental variable set correctly. With recent versions of OpenSSH, this will default to localhost:10.0.
The point is that if DISPLAY is not getting set at all, then you probably don't have X11 forwarding set up properly. One way to do this is in the global ssh_config file. A second way is in your personal config file. Or you can set it on the command line with the -X option to ssh.
Lastly, if DISPLAY is set but it still doesn't work, don't forget to check your target sshd_config file to make sure that the option in sshd is turned on. It won't work if the server doesn't support it.
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
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
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
Using X11 Remotely
See the Security section above.
You can use X11 apps remotely with:
ssh -Y machinename xterm
will login to machinename and run the program "xterm" which will display locally. For this to work you need the xauth program installed on the server. SSH will encrypt the X11 session and setup $DISPLAY properly.
! Using $DISPLAY
You can run a program as:
This will make "xterm" run on the local machine but to display it's output on displaymachine (display 0). You may need to run:
to allow appmachine permission to use your display.
You can configure gdm(8) to announce itself onto the local network, and when you run X run it with "-query" to make it query the local network. (This section needs to be filled out)