LMHOSTS as static WINS entry repository?

[John H Terpstra]

On Tue, 29 Apr 2003, Christopher R. Hertel wrote:

> On Tue, Apr 29, 2003 at 10:45:21AM -0500, Gerald (Jerry) Carter wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Mon, 28 Apr 2003, Herb Lewis wrote:
> >
> > > Maybe we could add some of the directive support from the MS lmhosts
> > > file to ours. Only load entries flagged #PRE or #DOM into WINS
> >
> > I would rather see a "wins preload file = <string>" in smb,conf that
> > points to an lmhosts formatted file to be used as static entries in
> > wins.tdb.  Keeping lmhosts and the static entries is better and less
> > confusing I think.
>
> I've been wildly busy, and have not participated in this conversation.
> My book is moving into production, I'm digging out from the time away from
> home and office, and my in-laws are visiting.  Seems you just put down one
> elephant and you get handed two more.
>
> Anywhich...
>
> First question I have is this:
> Should our LMHosts do exactly the same job as Microsoft's LMHosts or
> should we allow it to be different?  We're currently different, but that
> causes trouble for some users.
>
> >From my reading it seems that the MS LMHosts is a kitchen-junk-drawer.
> It can be used in a variety of ways.  For example, you can use it to
> identify DMBs (both the same workgroup and foreign workgroups) for browse
> list syncing.  We *do not* have the same feature, to my knowledge.  We
> have similar features--eg., we can announce to foreign DMBs and Enhanced
> Browsing to discover foreign DMBs--but nothing to specifically/statically
> identify foreign DMBs so that we can query them.  (Please correct me if'n
> I'm wrong.)
>
> I am not sure, however, whether the MS LMHosts file is used to pre-load
> WINS.  Some documentation I've seen suggests that this is optional (and
> must be enabled via a configuration check-box).  In general, the
> documentation suggests that the LMHosts file was designed for client-side
> use.
>
> All that in mind, I like Jerry's suggestion.  The end user can point the
> "wins preload file" to the Samba LMHosts file, just to simplify things.

I do NOT want to see yet MORE FEATURES being added to smb.conf. Please
give the admin a break!

We need a winsadmin tool. Sort of like the pdbedit tool. Metze had started
on this, it is essentially a simple tool to allow all WINS entries to be
manipulated. Today, with WINS in wins.tdb we are hosed if any changes to
dynamic entries are needed. Simple things like a forced expire or a forced
deletion can NOT be done with wins.tdb without such a tool.

Adding another parameter to smb.conf to read in lmhosts is a
fundamentally broken idea! Sorry if I come across so strongly, that
because this is such a crippled proposition. No offense meant!

- John T.
-- 
John H Terpstra
Email: jht at samba.org