Penguin
Recent Changes
Blame: XFree86Notes
EditPageHistoryDiffInfoLikePages
Annotated edit history of XFree86Notes version 17, including all changes. View license author blame.
Rev Author # Line
10 JohnMcPherson 1 !!! X Server configuration
12 JohnMcPherson 2
3 The [XServer] configuration file on Linux distributions is normally one of
4 * /etc/X11/XF86Config-4
5 * /etc/X11/XF86Config
6 (searched for in that order) if using the XFree86 XServer, or
7 * /etc/X11/xorg.conf
8 if your distribution uses the X.org XServer.
9
10 JohnMcPherson 10 !! Default bitmap depth (number of colours)
11 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
12 !DefaultDepth 16
12 JohnMcPherson 13 into the "Screen" section of your XServer's configuration file.
11 CraigBox 14
12 JohnMcPherson 15 !!"xRandR" Extension
16 The X Resize and Rotate extension allows you to change your
17 screen's resolution (and notifies your window manager/applications without restarting X) in a way that Ctrl+Alt+keypad+/- don't.
18
19 To make use of the xrandr(1) program (or the [GNOME] or [KDE]
20 front ends), it appears you need to have
21 Load "xtrap"
13 BasGrolleman 22 in the "Module" Section and
23 Option "RandR" "on"
14 AristotlePagaltzis 24 in the "!ServerFlags" Section of your X configuration file.
13 BasGrolleman 25
14 AristotlePagaltzis 26 It doesn't seem to work if Xinerama is loaded though.
12 JohnMcPherson 27
28
29 !! Not starting on boot
11 CraigBox 30 If you want to get X to not start automatically when your system boots:
31
32 ;__RedHat, FedoraCore and related distros__ : edit [/etc/inittab|inittab(5)] and set the default runlevel to 3, instead of 5.
33 ;__[Debian]__:run update-rc.d to remove xdm(8)/gdm(8)/kdm(8) from the rc2.d directory.
10 JohnMcPherson 34
35 !!! Security
36
37 !! X Auth
38
39 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.
40
41 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.
42
43 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:
44 $ apt-get install xbase-clients
45
46 The remote machine will also need xauth, so needs xbase-clients installed.
47
48 To view the individual cookies, you can do:
49 $ xauth list
50 but you probably don't care about the data.
51
52 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.
53 $ xauth extract - $DISPLAY | ssh <remote-host> /usr/X11R6/bin/xauth merge -
54 Then you can ssh to the remote machine and run, say, an xterm to connect to my local display with a command like:
55 ssh <remote-host> DISPLAY=$DISPLAY /usr/X11R6/bin/xterm &
56
57 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.
15 JanHolstJensen 58
59 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:
60
61 xauth extract - $DISPLAY > xauth.key
62
63 Make the file xauth.key readable by other_user, and then as other_user do:
64
65 export DISPLAY=:0.0
66 xauth merge /home/my_self/xauth.key
67
68 You should now be able to run X applications as other_user even though you are logged in as my_self.
10 JohnMcPherson 69
70 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:
71 $ xhost +
72 Xlib: connection to ":0.0" refused by server
73 Xlib: Client is not authorized to connect to Server
74 xhost: unable to open display ":0.0"
75 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.
16 FelineGrace 76
77 !! It just might be X11 is not forwarded properly
78
79 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.
80
81 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.
82
83 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.
10 JohnMcPherson 84
85 !! Preventing the server from listening for TCP connections
86
87 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
88 serverargs=""
89 to say
90 serverargs="-nolisten tcp"
91
92 Now when X is started with startx(1), the server will not be listening on any ports.
93
94 !! [IPv6] Support needed
95
96 If you have [IPv6] enabled X, but your machine doesn't have IPv6 enabled, you might see something like the following error:
97 _X11TransSocketOpen: socket() failed for tcp
98 _X11TransSocketOpenCOTSClient: Unable to open socket for tcp
99 _X11TransOpen: transport open failed for tcp/localhost:10
100 xterm Xt error: Can't open display: localhost:10.0
101
102 In this particular case I'm doing X11Forwarding from another machine (via ssh -X hostname). Strace confirms this as an [IPv6] related bug:
103
104 strace xterm
105 ...
106 socket(PF_INET6, SOCK_STREAM, 0) = -1 [EAFNOSUPPORT] (Address
107 family not supported by protocol)
108
109 loading [IPv6] support on the remote machine fixes this.
110
111
112 See [XFree86KeyboardMouseNotes] for information on Keyboards and Mice under [XFree86]
17 PerryLorier 113
114 !! Using X11 Remotely
115 See the Security section above.
116
117 ! Using SSH
118 You can use X11 apps remotely with:
119 <pre>
120 ssh -Y ''machinename'' xterm
121 <pre>
122 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.
123
124 ! Using $DISPLAY
125 You can run a program as:
126 <pre>
127 export DISPLAY=''displaymachinename'':0
128 xterm
129 </pre>
130
131 This will make "xterm" run on the local machine but to display it's output on ''displaymachine'' (display 0). You may need to run:
132 <pre>
133 xhost +''appmachine''
134 </pre>
135 to allow appmachine permission to use your display.
136
137 ! Using XDMCP
138 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)''
139
10 JohnMcPherson 140 ----
141 [CategoryXFree86Notes]