WINS replication
Gerald Carter
Has anyone every looked int o the protocol used for
WINS replication between two NT Servers? Just curious
how diffucult it would be.
jerry
________________________________________________________________________
Gerald ( Jerry ) Carter
Engineering Network Services Auburn University
je...@eng.auburn.edu http://www.eng.auburn.edu/users/cartegw
"...a hundred billion castaways looking for a home."
- Sting "Message in a Bottle" ( 1979 )
Jean Francois Micouleau
> Has anyone every looked int o the protocol used for
> WINS replication between two NT Servers? Just curious
> how diffucult it would be.
undocumented, undecoded my netmon (or at least what I'd looked)
One part is on the MS-RPC/DCE wins pipe and an other on tcp/135 port, IIRC
If the frames are obfuscated that's just a bit longer to decode :-)
J.F.
Dan Kaminsky
JF--any idea how difficult it would be to patch the NetBIOS broadcast
detection code into the WINS code, so that machines not able to hear the
broadcasts could still connect to those computers via the WINS server? Just
curious how much revamping would be necessary.
Richard Sharpe
At 05:32 AM 1/31/99 +1100, you wrote:
>On Sun, 31 Jan 1999, Gerald Carter wrote:
>
>> Has anyone every looked int o the protocol used for
>> WINS replication between two NT Servers? Just curious
>> how diffucult it would be.
>
>undocumented, undecoded my netmon (or at least what I'd looked)
>One part is on the MS-RPC/DCE wins pipe and an other on tcp/135 port, IIRC
>If the frames are obfuscated that's just a bit longer to decode :-)
Hmmm, I wonder if WINS replication uses the same techniques as SAM and
logon service replication for a PDC to BDC?
> J.F.
>
>
Regards
-------
Richard Sharpe, sha...@ns.aus.com, NIC-Handle:RJS96
NS Computer Software and Services P/L,
Ph: +61-8-8281-0063, FAX: +61-8-8250-2080,
Samba (Team member), Linux, Apache, Digital UNIX, AIX, C, ...
Luke Kenneth Casson Leighton
of the fields then, could probably do it pretty easily now.
On Sun, 31 Jan 1999, Gerald Carter wrote:
> Hey everyone! :)
Luke Kenneth Casson Leighton
> detection code into the WINS code, so that machines not able to hear the
> broadcasts could still connect to those computers via the WINS server? Just
> curious how much revamping would be necessary.
do you mean UDP 138 "netbios datagram distribution" (see rfc1001/1002 -
NBDD)? this is not enabled in samba. someone three or so years ago did
say that they were patching samba to do this, they went silent when i
mentioned "GPL".
if you mean just UDP 137 (NetBIOS name resolution) then samba does the job
already, samba will allow the resolution of NetBIOS names for
point-to-point NetBIOS clients already and has been able to do so since
the introduction of nmbd WINS server capabilities in 1.9.15 (or
thereabouts).
luke
Dan Kaminsky
----- Original Message -----
From: Luke Kenneth Casson Leighton <lk...@switchboard.net>
To: Multiple recipients of list <samba-t...@samba.org>
Sent: Monday, February 01, 1999 7:37 AM
Subject: Re: WINS replication
Luke--
What I'd like is for /var/lock/samba.d/browse.dat to automatically
convert and enter itself into /var/lock/samba.d/wins.dat . That way,
clients not within the broadcast zone could still "pick up" on the IP's via
WINS.
This is of specific concern for me since I had to sacrifice my NetBIOS
access in order to directly connect my Linux machine to the network. My
windows machine exists Proxy ARP'ed through a 100mbit hub, but since it's on
a different broadcast address and there's no way to bridge broadcasts in
Linux, it gets everything but NetBIOS.
Any ideas?
Luke Kenneth Casson Leighton
> convert and enter itself into /var/lock/samba.d/wins.dat . That way,
> clients not within the broadcast zone could still "pick up" on the IP's via
> WINS.
all you do is specify that the windows client should use x.x.x.x as the
WINS server, that's all you need to do.
Christopher R. Hertel
Worth taking a look.
Chris -)-----
--
Christopher R. Hertel -)----- University of Minnesota
c...@nts.umn.edu Networking and Telecommunications Services
Jeremy Allison
> What I'd like is for /var/lock/samba.d/browse.dat to automatically
> convert and enter itself into /var/lock/samba.d/wins.dat . That way,
> clients not within the broadcast zone could still "pick up" on the IP's via
> WINS.
>
> This is of specific concern for me since I had to sacrifice my NetBIOS
> access in order to directly connect my Linux machine to the network. My
> windows machine exists Proxy ARP'ed through a 100mbit hub, but since it's on
> a different broadcast address and there's no way to bridge broadcasts in
> Linux, it gets everything but NetBIOS.
For Samba to Samba WINS replication, here's what I have in mind.
Firstly - convert nmbd to a gdbm database. Chris was interested
in doing this originally but is now doing java stuff.
Secondly - as entries are added/deleted write them out into
a "pending transactions" file.
Every few minutes, use some file transfer protocols (maybe
a new IPC$ rap call ?) to transfer them to replicating Samba
nmbd's.
Then the nmbd's read and apply the changes to their local
databases.
Every 6 hours or so, replicate out any transactions, close
down the database, and then use rsync to transfer the whole
gdbm files from a designated WINS master to all WINS slaves
and re-open the database.
This ensures no database "drift" with replication error.
Comments ?
Jeremy.
--
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------
Luke Kenneth Casson Leighton
> a new IPC$ rap call ?) to transfer them to replicating Samba
> nmbd's.
recommend dce/rpc in preference to rap, it's far superior (i know you
prefer onc/rpc jeremy :).
Christopher R. Hertel
>
> Firstly - convert nmbd to a gdbm database. Chris was interested
> in doing this originally but is now doing java stuff.
No, no, no!
I am doing Java stuff *in addition to*--not to the exclusion of--Samba
work. I can't really do the Java stuff without digging into Samba anyway.
First, I don't see that you need gdbm or any other disk-based database to
implement replication. In fact, I've had to ask the question "Why do we
need a disk-based database at all?", and I no longer have a good answer.
My original reasons were:
- Use less RAM when handling large lists.
We could save a lot more ram (63 bytes per entry +/-) by not storing
empty scope bytes.
- Recovery.
We're more likely to lose a gdbm database in a crash than we are to
lose the wins.dat file, and the latter is manually editable. It
might be better to write transaction records (added this, removed
that, updated the other) to the wins.dat and rewrite it less
frequently.
- Accessibility.
One idea was to enable the use of multi-user databases so that a sys
admin could view & modify the contents of a running NBNS. I would
rather see a command-line tool that talks to the WINS server (via a
named pipe, perhaps) and lets the server handle the database
exclusively.
The problem with the back-end database is that it requires more in-depth
work on nmbd. All of the nmbd name lists (there are several) are handled
in basically the same way, and the assumption is made that all records are
in memory. Changes are done by updating the record directly (no
read-modify-write sequence).
So, to provide a back-end database for the Samba NBNS, one of two things
would have to happen:
1) Split out the NBNS (WINS) code so that handling of WINS entries is
not tied to the handling of other name lists. Once that's done, you
can replace the code with more database-oriented calls. It's no
problem, then, to use gdbm or mSQL, or Postgress, or...
2) Change all calls to the namelists to use indirect access to the
records. The shorter lists could still be handled in memory and
longer lists could be kept in (cached) databases.
I really have a lot of this thought out. I'd be happy to work with
anyone who wants to play with it.
> Secondly - as entries are added/deleted write them out into
> a "pending transactions" file.
..or just tag them in the WINS database itself. Again, we could write
transactions to the wins.dat so, in the event of a crash, we'd know which
transactions had not been propogated. We'd re-write the wins.dat after
each redistribution.
> Every few minutes, use some file transfer protocols (maybe
> a new IPC$ rap call ?) to transfer them to replicating Samba
> nmbd's.
Yep.
> Then the nmbd's read and apply the changes to their local
> databases.
Yep.
> Every 6 hours or so, replicate out any transactions, close
> down the database, and then use rsync to transfer the whole
> gdbm files from a designated WINS master to all WINS slaves
> and re-open the database.
Master-slave? There certainly are issues of authority. If two machines
claim the name "FOO" against two different NBNS servers we do need to
have a means of resolving the conflict. My thought was to allow a Sys
Admin to configure a given NBNS as authoritative for a Workgroup, or set
of subnets, or some-such. This is an extension of the master-slave
you've suggested.
Anyway, if anyone wants to work on this stuff let me know. I've got lots
history with the issues.
David Collier-Brown
> - Recovery.
> It
> might be better to write transaction records (added this, removed
> that, updated the other) to the wins.dat and rewrite it less
> frequently.
From a former life, journals are A Good Thing: my smarter
colleagues synchronized multiple copies of my horrible kludgy
database with each other by making them read each other's
journals. Timestamps gave us a weak ordering after
some clock-skew estimation, and we never actually saw the
expected race conditions when we suffered network partition.
Turned out the changes had a natural locality of reference.
I was **impressed**.
--dave c-b
--
David Collier-Brown, | Always do right. This will gratify some people
185 Ellerslie Ave., | and astonish the rest. -- Mark Twain
Willowdale, Ontario | http://java.science.yorku.ca/~davecb
Work: (905) 477-0437 Home: (416) 223-8968 Email: dav...@canada.sun.com