Bug 1954

Summary: X windows fails if hostname changes
Product: [Retired] Red Hat Linux Reporter: Chris Evans <chris>
Component: XFree86Assignee: David Lawrence <dkl>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 6.0CC: blizzard, chris
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-04-03 04:10:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Chris Evans 1999-04-02 18:18:14 UTC
Hi! Nasty one this, might bite people

When you bring up your dialup connection whilst in X, this
(obviously) changes the hostname. Unfortunately this has
the effect of breaking the new X authorization method.

So I hit the button to bring up my ppp link, and then..
oh dear X won't let me launch any new windows.

n.b. the new X authorization stuff is _great_ for security
so please don't revert that change :-)))

Comment 1 Bill Nottingham 1999-04-03 04:10:59 UTC
*** Bug 1955 has been marked as a duplicate of this bug. ***

Hi! Nasty one this, might bite people

When you bring up your dialup connection whilst in X, this
(obviously) changes the hostname. Unfortunately this has
the effect of breaking the new X authorization method.

So I hit the button to bring up my ppp link, and then..
oh dear X won't let me launch any new windows.

n.b. the new X authorization stuff is _great_ for security
so please don't revert that change :-)))this has been fixed in a later initscripts. ppp/slip interfaces
no longer change the hostname.

Comment 2 Christopher Blizzard 1999-05-09 15:37:59 UTC
This bug is not fixed.  When the hostname is set to
localhost.localdomain after the install, the ifup-post script will
change the hostname after the ppp connection is brought up.  This will
break the Xauthority mechanism because the only entry left in your
.Xauthority file will be an entry for "localhost.localdomain/unix:0".
Clients that are trying to connect will be looking for your new
hostname, something like "dhcp14.foo.com/unix:0" and won't be able to
connect.

The reason that this is the case, according to a brief conversation
with Erik is that people who are sending out mail through the local
sendmail daemon will end up sending mail as "localhost.localdomain" if
they don't know enough to change their hostname.  Hence, on dialup
they set the hostname to the dialup connection so that mail that goes
out will always have the hostname of the dialup connection and the
chance that they will get mail back increases.

The workaround for this bug is to do two things:

o Change your hostname.  You can do this by editing the file
/etc/sysconfig/network and changing the entry HOSTNAME to a simple
name like HOSTNAME=foo.  You can also use Linuxconf to do this

o Add an entry in /etc/hosts for the name that you have assigned as an
alias for the localhost address.  This means that you will have an
entry in /etc/hosts that looks something like this:

127.0.0.1  localhost localhost.localdomain foo

You can also use Linuxconf to do this.

Users that have "real" hostnames that are either assigned to the
machine and are on a network or are assigned a dhcp based address at
bootup aren't affected by this.  Users that may bring up their
interface using dhcp while using X may be affected, depending on their
local configuration.

So, the question is, how do we fix this in the long run?  Is the win
of having mail going out from a box have a "real" hostname ( although
a dialup hostname ) more important than not having X break every time
a user dials up their ISP?

Comment 3 Christopher Blizzard 1999-05-09 15:42:59 UTC
Oh, this doesn't fix the problem of "changing your hostname breaks X"
but it does fix the problem of "dialing up using Red Hat's scripts
breaks X."  If you change your hostname, X doesn't work anymore.
xauth always seems to add the hostname to the .Xauthority entry even
when the DISPLAY env variable is set to :0.