View Source: XFree86Notes - Waikato Linux Users Group

Edit PageHistory Diff Info LikePages
!!! 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|inittab(5)] 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.

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

!! Using X11 Remotely
See the Security section above.

! Using SSH
You can use X11 apps remotely with:
<pre>
 ssh -Y ''machinename'' xterm
<pre>
will login to ''machinename'' and run the program "xterm" which will display locally.  For this to work you need the <tt>xauth</tt> program installed on the server.  SSH will encrypt the X11 session and setup <tt>$DISPLAY</tt> properly.

! Using $DISPLAY
You can run a program as:
<pre>
 export DISPLAY=''displaymachinename'':0
 xterm
</pre>

This will make "xterm" run on the local machine but to display it's output on ''displaymachine'' (display 0).  You may need to run:
<pre>
 xhost +''appmachine''
</pre>
to allow appmachine permission to use your display.

! Using XDMCP
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)''

----
[CategoryXFree86Notes]
2 pages link to XFree86Notes:
Last edited on Saturday, April 29, 2006 1:58:56 pm by PerryLorier
Edit PageHistory Diff Info LikePages