WINS replication

[Christopher R. Hertel]

> 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.

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.

Chris -)-----

-- 
Christopher R. Hertel -)-----                   University of Minnesota
crh at nts.umn.edu              Networking and Telecommunications Services