|Contents||Bulletin||Scripting in shell and Perl||Network troubleshooting||History||Humor|
|News||Troubleshooting X11||Recommended Links||Architecture||X display manager||Reinstallation of X11 and Gnome Desktop in RHEL||"init: Id "x" respawning too fast: disabled for 5 minutes."|
|Configuration||Fonts in X||Exporting_display||Xdefaults||Using xauth||Too high refresh rate ot too high resolution||XDMCP|
The X Window uses a client/server-architecture (and the server is your workstation to which you are exporting the session).
It can use a number of transport protocols, including Unix sockets and TCP/IP sockets. Which mechanism is used, is determined by the format of the DISPLAY environment variable.
X has an authentication mechanism, which decides whether a client is allowed to connect to a server. As the Internet has become an increasingly hostile environment, it has become good practice to only open up services to the Internet when they are really needed. Recently in some Linux distributions, X is by default configured to listen only to localhost.
That means that default X settings become more and more defensive and thus without tuning there are more and more reasons why remote communications attempts using X initially will fail.
That's why the first time you try to run a remote X application on modern Linux distributions, it usually does not work. The most common error message by far is
"Can't open display".In this case an X client application, for example xterm, reports an error Can't open display on startup, for instance
xterm Xt error: Can't open display: localhost:0.0
The first thing to try is to ensure that you used a correct sequence of commands. One typical mistake is you use like xhost + on the client instead of the server (your workstation).
If you have problems the first thing to do is to see the value of the variable DISPLAY on the client. If it is not set at all or set incorrectly you need to fix that, for example
The second step to check is whether X11 server itself is accessible from the client. If firewall on the server is enables it can block X11 session. You better exclude filewall and You can see this by using nmap. If port 177 (UDP) or port 6000 (TCP) are blocked you need to fix this first.
The next step is to check /var/log/messages on the server. Often if you can't connect from the client /var/log/messages contain helpful messages
In RHEL by default X11 is enabled only for localhost.
To be able to connections from the external box you need to edit the file /etc/gdm/custom.conf. The default setting for RHEL is
[security] DisallowTCP=yeswhich should be changed to false
To enable XDMCP that some users need you need to enable it.
After that you need to restart X11 using the command
init 3 && init 5
If in addition you want to provide ability to log as root you need security section as following
[security] DisallowTCP=false AllowRemoteRoot=true
But please do it only on temp basis.
# GDM configuration storage [daemon] [security] DisallowTCP=false AllowRemoteRoot=true [xdmcp] Enable=true [greeter] [chooser] [debug]
|Bulletin||Latest||Past week||Past month||
Jan 5, 2011 | RHEL Tech
# vi /etc/gdm/custom.conf
Note: Here “AllowRemoteRoot=true” used to allow root access.
3) Restart the gdm service
4) Check weather xdmcp port is opened or not, using netstat command
# netstat –an | grep 177
udp 0 0 0.0.0.0:177 0.0.0.0:*
by Jeff Hunter, Sr. Database Administrator
- Configure Linux to use GUI Logins
- Granting Remote Access to the Login Manager
- Remote X Server Access from a Linux Client
- About the Author
Most users installing Linux today choose to install and configure the X Windows System. This allows those users to access their Linux environment using a graphic (GUI) console connected to the workstation or server. An X Windows environment provides users to run X programs like xterm, OpenOffice, Mozilla Firefox and a host of other useful graphical software packages.
There are times, however, when users need to log in to a Linux machine using the graphical X Windows System from a remote computer, like a Windows PC for example. The remote Windows PC would first need to have an X Windows Server installed like Xming, Exceed Hummingbird, or my personal favorite X-Win 32.
When installing Red Hat Enterprise Linux, the system defaults to a secure configuration which does not allow remote graphical logins or remote desktop access. This article explains the configuration changes required to allow remote access to a Red Hat Enterprise Linux system (RHEL) using the X Display Manager Control Protocol (XDMCP) or GDM (GUI login).
Configure Linux to use GUI Logins
One of the first steps is to make certain the Red Hat Linux environment is configured to use a graphical (GUI) login. A Linux environment allows for either a text login or a graphical (GUI) login. This option is specified in the init script configuration file /etc/inittab. In order to allow remote graphical (GUI) logins, the environment itself must be configured for a X11 GUI login. Make certain the system is configured with the correct X11 runlevel (which in this case is runlevel 5):
..... <SNIP> .....
# Default runlevel. The runlevels used by RHS are:
# 0 - halt (Do NOT set initdefault to this)
# 1 - Single user mode
# 2 - Multiuser, without NFS (The same as 3, if you do not have networking)
# 3 - Full multiuser mode
# 4 - unused
# 5 - X11
# 6 - reboot (Do NOT set initdefault to this)
..... <SNIP> .....
Granting Remote Access to the Login Manager
The next step is to grant MS Windows users remote GUI access to the Red Hat Linux system. More specifically, we need to grant access to the RHEL Login Manager. Use the GDM Login Manager for RHEL 5 or higher while using the XDM Login Manager for RHEL 3 and RHEL 4.
GDM Login Manager
Users running Red Hat Enterprise Linux 5, CentOS 5, or Oracle Linux Release 5 will need to use the GDM login manager as XDM is no longer supported.
First, edit the file /etc/gdm/custom.conf and add the following two entries:
Next, restart X Windows:
[root@racnode1 ~]# init 3
[root@racnode1 ~]# init 5
The final step is to configure the GDM login manager using the gdmsetup utility:
[root@racnode1 ~]# gdmsetup
After starting the gdmsetup utility, click the Remote tab. Under the Remote tab, change the Style pull-down menu selection from 'Remote login disabled' to 'Same as Local':
Aug 3, 2011 | Ask Ubuntu(Here follows an almost verbatim copy of a self-answer from an identical question on serverfault which I'd forgotten about; askubuntu wasn't yet created).
Based on information found in this page about enabling XDCMP and the file /etc/gdm/gdm.schemas, I managed to create a /etc/gdm/custom.conf file:# /etc/gdm/custom.conf [xdmcp] [chooser] [security] DisallowTCP=false [debug]
Take care with letter case: it won't work, if you write "disallowTCP=false"... I also changed the /etc/X11/xinit/xserverrc file to:exec /usr/bin/X11/X
i.e. I removed the -nolisten tcp options to the X executable. I don't know if I needed to. You might want to try avoiding this edit.
If you only change the xserverrc file, X will nevertheless start with "-nolisten TCP".
After that, all that is needed is a restart of the gdm process:sudo service gdm restart
You can verify the success as:tzot@tzot-laptop:/etc/X11 $ netstat -an | grep -F 6000 tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN tcp6 0 0 :::6000 :::* LISTEN
So, in 10.10 this still works: create /etc/gdm/custom.conf with contents as specified above and restart gdm.
April 10, 2006 | FedoraForum.org
Remove -nolisten tcp argument for Xorg
I'd like to have Xorg started without the "-nolisten tcp" argument. Upon logging into KDE and did 'ps -ef | grep Xorg' , I found "-nolisten tcp" arg. was used. I found the config. file /etc/X11/xdm/kdmrc and changed ServerArgsLocal=-nolisten tcp into ServerArgsLocal=
restart computer and still have above argument loaded.
Does anyone know how to remove above argument ?
Try running /usr/bin/gdmsetup. Select the "Remote" tab and in the "Style" window select one of the options other than "Remote login disabled." If that doesn't do it for you, try the next suggestion.
AFAIK, gdm.conf is gone from FC5. You use /etc/gdm/custom.conf instead. The correct parameter is DisallowTCP. Add DisallowTCP=false in /etc/gdm/custom.conf to make gdm listen.
Quote:On your xserver, you have to allow incoming connections. Do a "ps -ef | grep listen", and see if it returns your Xserver daemon. If it returns a line with "-nolisten" in it (the default for lots of distros), you'll have to change your X configuration to remove the -nolisten option. I've never done it on ubuntu, so I can't be of much help there, but I'm sure there are lots of docs on the net.
I seem to have a configuration issue that is preventing me from displaying an X application using an X server on a different machine.
I would like to run an X application like this:
# export DISPLAY=10.1.60.59:0
Error: Can't open display: 10.1.60.59:0
Error: Can't open display: 10.1.60.59:0
After you get that going (and don't just log out...you have to either reboot or do a CTRL-ALT-BACKSPACE to restart your X server), you have to allow the connections to take place.
As root, you can either do "xhost +" (unsafe, allows ANYONE to start remote windows on your machine), or "xhost <ip address of remote machine>" (allows just that machine to fire up an X session.
The first time you try to run a remote X application, it usually does not work. Here are a few common error messages, their probable causes, and solutions to help you on your way.xterm Xt error: Can't open display:
There is no DISPLAY variable in the environment, and you didn't tell the application with the -display flag either. The application assumes the empty string, but that is syntactically invalid. To solve this, be sure that you set the DISPLAY variable correctly in the environment (with setenv or export depending on your shell._X11TransSocketINETConnect: Can't connect: errno = 101 xterm Xt error: Can't open display: love.dial.xs4all.nl:0
Errno 101 is ``Network is unreachable''. The application could not make a network connection to the server. Check that you have the correct DISPLAY set, and that the server machine is reachable from your client (it should be, after all you're probably logged in to the server and telnetting to the client)._X11TransSocketINETConnect: Can't connect: errno = 111 xterm Xt error: Can't open display: love.dial.xs4all.nl:0
Errno 111 is ``Connection refused''. The server machine you're trying to connect to is reachable, but the indicated server does not exist there. Check that you are using the right host name and the right display number.
Alternatively, it is possible that the X server was configured not to listen to the usual TCP port. To find out if this is the case, see if the X server is started with the -nolisten tcp argument, and if so, remove it.Xlib: connection to ":0.0" refused by server Xlib: Client is not authorized to connect to Server xterm Xt error: Can't open display: love.dial.xs4all.nl:0.0
The client could make a connection to the server, but the server does not allow the client to use it (not authorized). Make sure that you have transported the correct magic cookie to the client, and that it has not expired (the server uses a new cookie when a new session starts).
Possible cause #1: no valid X authentication credentials
With the default X authentication mechanism, an X client needs to have access to a valid X session cookie (which is, essentially, a shared secret between the X server and its clients).
When a user switches to a different user using the su command, X session cookies are not transferred and thus the user cannot start X applications under the user id to which he or she switched.
Solution to the authentication credentials problem: sux
Instead of su, use sux to switch user id. Like su, sux switches to a different user id. Unlike su, it ensures that the id being assumed is given access to the X session cookie so that X applications can be started.
Possible cause #2: the X server isn't listening
A DISPLAY setting is used which causes the X client application to attempt to use TCP/IP sockets rather than Unix sockets. This attempt fails because in recent releases of SUSE Linux the X server does not listen to TCP/IP sockets by default, for security reasons.
Solution for local connections
When, as is mostly the case, the X server and the X client application are running on the same system, do not use a hostname in the DISPLAY settings. Use DISPLAY=:0.0; export DISPLAY.
Preferred solution for non-local X connections: ssh
When the X server and the X client application are to run on different systems, there are two ways to enable the connection.
The first is to connect to the remote system using ssh -X. SSH (secure shell) is a de facto standard remote access mechanism that uses cryptographic techniques to secure connections against wiretapping and session hijacking. The -X option to ssh tells it to try to set up a tunnel through which X11 connections can be forwarded.
Alternative solution for non-local X connections: enable TCP/IP socket connections
Another solution is to enable TCP/IP sockets for X11 as follows:
- Set DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN="yes" in the /etc/sysconfig/displaymanager file
- Running /sbin/SuSEconfig to propagate that setting
- Restart your display manager through /usr/sbin/rcxdm restart
Enabling a network service on a port increases the ways a system may be attacked by a cracker. As a good security practice, when a network service (like X connections via TCP port 6000) is enabled, access to it should be restricted to authorized systems only, e.g. via iptables rules.
As this solution is more cumbersome than using ssh -X, in particular from a security management point of view, it should only be used when ssh -X isn't an option (e.g. due to interoperability issues with legacy systems).
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least
|You can use PayPal to make a contribution, supporting hosting of this site with different providers to distribute and speed up access. Currently there are two functional mirrors: softpanorama.info (the fastest) and softpanorama.net.|
The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: February 19, 2014