Re: [SLUG] hostname resolution wackiness

From: Chad Perrin (perrin@apotheon.com)
Date: Sat Jul 10 2004 - 11:12:55 EDT


I'll be responding to several different emails in this one email. Specifically,
I'm responding here to Scott, Kwan Lowe, Eben King, and Larry Brown, in that
order (because that's the time/date stamp order in my inbox).

##### scott wrote:

> What do you have in your /etc/network/interfaces file? Do you request a
> hostname from the router?
>
> See "man interfaces" for some ideas.
>

/etc/network/interfaces:

      # loopback (127.0.0.1) interface
      auto lo
      iface lo inet loopback

      # NIC
      auto eth0
      iface eth0 inet dhcp

Having looked through the interfaces manpage, I found syntax that seems to be
designed to set the machine's hostname and to specify the DHCP client that is
used, but nothing that seems to pertain to requesting name service. Did I
overlook something?

##### Kwan Lowe wrote:

> It sounds like your appliance is acting as some sort of WINS server for
> the Windows machines. WINS clients will register their names on network
> initialization and this will allow you to see them by name.
>
> Or...
> If you're using W2K machines you may be using some form of DynamicDNS
> (not the same as dydns, but the same principle).
>
> For the Linux client you can try:
> Adding a DNS_HOSTNAME option to the network configuration scripts (works
> in RedHat, Fedora). I have used this personally and know that it works.
>
> Doing something with Samba to register on the WINS network. I have not
> used so caveat emptor.

I believe the appliance is running both WINS and DNS name resolution
dynamically, as both "nmblookup foo" and "host foo" will return data for the
specified node. This network contains Win98, Win2k, and WinXP workstations.
I've frittered around in smb.conf to see if I could "fix" the name resolution
problem I'm having there, though I sincerely doubt it has anything to do with
Samba since nmblookup is finding nodes by hostname just fine even while ping
fails to. In any case, no amount of smb.conf tinkering has solved the problem.
  As for the DNS_HOSTNAME option, I'm not sure where I'd do that.

##### Eben King wrote:

> When I decided to use DHCP rather than static addresses, my router didn't
> do fixed assignments, so I ran a DHCP server on one of the clients (a
> Linux box, so it's almost always on). If it's the structure that's
> getting you (as it got me with one of the format changes), I can give you
> a working file.

The network isn't solely mine to define the arhitecture, so I'm not sure this is
really an option -- especially considering the only machine I could use for such
a purpose is a 350MHz machine that's already acting as a file server and fax
server, since it's the only Linux box that's currently connected to a UPS (and
thus protected from having to be shut down during thunderstorms, despite my
almost rabid advocation of ubiquitous UPS use). I'd appreciate any explication
of your suggested solution, though, in case I can find a way to implement it,
either now or at some point in the future.

##### Larry Brown wrote:

> What does your /etc/resolv.conf file reflect? This file will be
> automagically edited by your dhcp client. On the appliance there may be
> a field in the dhcp setup for dns (NOT the field for dns in the ISP or
> WAN settings), what does it show?

/etc/resolv.conf:

      search
      nameserver 192,168.2.1

(where 192.168.2.1 is the IP address of the router appliance)
I went through all the configuration options in the appliance's interface a few
days ago, and found that the only references to DNS configuration involved DNS
client setup on the WAN side.
-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:22:27 EDT