On Tue, Jan 23, 2007 at 08:54:51AM +0000, Brian Candler wrote:
> On Mon, Jan 22, 2007 at 07:34:13PM -0500, stan wrote:
> > > Well, It Works For Me [TM]. Actually, our office network is divided into
> > > several subnets, and the Windows fileserver is on another subnet in a
> > > remote
> > > data centre, several IP hops away, and it all still works.
> > >
> > > Locating a machine by name ("Network Neighbourhood") requires either a
> > > WINS
> > > server or dynamic DNS, but you've realised that. Mount by IP address
> > > should
> > > just work.
> >
> > Can you clarify what you mean by dynamic DNS in this context?
>
> Ah, for that you would need a Windows expert, and that's not me :-)
>
> However my rough understanding is that Windows clients make dynamic DNS
> updates to their 'local' DNS server (that is, Microsoft are assuming that
> your DNS cache is also authoritative for your own domain - which is probably
> true if you use Windows domain controllers which are also configured to be
> DNS servers)
>
> Machines register their hostname in this way, so that when you do a lookup
> on another machine for //foo/subdir then 'foo' can be resolved via DNS.
>
> I don't know how this gives you the 'Network neighborhood' browsing
> capability.
IIRC - but I'm not sure I do - you can configure Windows to do lookups
in any combination of ways: netbios, possibly over TCP/IP, which is the
classical solution; a WINS server, which is like a DNS server but not
entirely[1]; the lmhosts file, which is like /etc/hosts but only for
Windows networking; and DNS lookups.
The first two give you browsing capability, or at least should; the rest
don't, but still allow you to configure shares by name instead of by IP
address.
ISTR that netbios and lmhosts are enabled by default, and that the other
two must be explicitly enabled; also, the option to update dynamic DNS
must be explicitly enabled.
Note that you can always hardcode IP addresses; this isn't the best
possible practice, but it does work.
Joachim
