|Summary:||X windows fails if hostname changes|
|Product:||[Retired] Red Hat Linux||Reporter:||Chris Evans <chris>|
|Component:||XFree86||Assignee:||David Lawrence <dkl>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||1999-04-03 04:10:09 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
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.