Problem with DHCP, /etc/hosts and GNOME

Rick Stevens rstevens at vitalstream.com
Thu Apr 8 23:47:06 UTC 2004


Satish Balay wrote:
> 
> On Thu, 8 Apr 2004, Keven Ring wrote:
> 
> 
>>>Exactly whats required for laptops :) - with one more step
>>>
>>>DHCP Client: I'll make my own DNS entry in /etc/hosts for mmm.nnn.ooo
>>>
>>>Satish
> 
> 
>>Wow.  In a nutshell, you have reduced this whole thread to:  In some 
>>way, shape, or form, get the hostname that you want your machine to be 
>>in either DNS or /etc/hosts.  As others have pointed out [myself 
>>included], this is not even needed if you set your hostname to something 
>>other than "localhost", "localhost.localdomain", or "(none)".  There are 
>>GUIs for doing this, and there are the files that the GUIs edit.
>>
>>As I indicated earlier, if your ip address is really changing and you 
>>want your hostname to remain the same, then you should consider having a 
>>dynamic DNS.  If your ip address and hostname changes, then all you need 
>>is DNS [assuming there is a one-to-one between ip and hostname].  
>>/etc/hosts is fine for static stuff.  Keep dynamic stuff out of it.
>>
>>I was merely highlighting the intriguing [and somewhat useless] 
>>conversation that could occur between the DHCP client and server.  Now, 
>>having said that, I'd say it's a great design - there are 50 ways of 
>>doing the same thing, each of them with their own uses and benefits.  It 
>>just means that it appears silly to ask the DHCP server for a hostname 
>>when you know you are going to ignore it...
> 
> 
> I must say I was just adding to the 'intriguing' protocol you had -
> another important step - which is also required for the non-localhost
> approach :) - but I do use the non-localhost approach - and the
> suggestion is well taken.
> 
> And I must admit the problem I'm solving is slightly different than
> the one that initated this thread.
> 
> Problem specification: x/xauth is screwed up. When hostname changes -
> the current authentication is broken (and you can no longer open
> xterms etc..)
> 
> As a simple demonstation for this problem - do (as root):
>  hostname
>  xterm
>  hostname foobar
>  xterm
> 
>  - solution 1: don't let DHCP-client change the hostname [which is
>    where most of the discussions of this thread is dealing with]
>     a: (recommended) use non-localhost hostname - and have an entry
>       for it in /etc/hosts for DNS
>     b: if the hostname gets changed by dhcp-client - change it back
>       using 'hostname' command.  This gets annoying with
>       short-lease-dhcp servers.
>     c: the alternate intriguing protocol - just for fun :)
> 
>  - solution 2: fix 'xauth/some-other-script' some-other-way so that
>    'if the hostname changes' then the appropriate xauth for this new
>    'hostname' is added automatically. I managed to this manually once,
>    but don't remember the command anymore. But this approach has a
>    potential to preserve ip addresses/names.

The problem is that xdm creates the initial cookie based on the
hostname.  All additional auth sessions base off that cookie.  If you
change the hostname, then the initial cookie is no longer valid.

I think the command you used was "xauth generate :0 ."

This issue will continue to be a problem as long as DHCP servers don't
heed the client's requested host name as many don't.  Even if they don't
do DDNS, they can still return the requested host name to the client.
Sure, the host won't be visible to the internet under its FQDN, but the
vast majority of DHCP environments do NATing anyway, so it's kind of a
moot point.
----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer     rstevens at vitalstream.com -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
-               Duct Tape + Magic Marker = Label Maker!              -
----------------------------------------------------------------------





More information about the fedora-list mailing list