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.
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.
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.
If you want to get X to not start automatically when your system boots:
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.
The remote machine will also need xauth, so needs xbase-clients installed.
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 -
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.
You should now be able to run X applications as other_user even though you are logged in as my_self.
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.
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.
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.
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
See the Security section above.
You can use X11 apps remotely with:
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 xauth program installed on the server. SSH will encrypt the X11 session and setup $DISPLAY properly. ! Using $DISPLAY You can run a program as: <pre> export DISPLAY=displaymachinename:0 xterm
This will make "xterm" run on the local machine but to display it's output on displaymachine (display 0). You may need to run:
xhost +appmachine
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)
2 pages link to XFree86Notes:
