Christopher R. Hertel
crh at nts.umn.edu
Mon Feb 1 21:39:38 GMT 1999
> 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.
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
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
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
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
> Every few minutes, use some file transfer protocols (maybe
> a new IPC$ rap call ?) to transfer them to replicating Samba
> Then the nmbd's read and apply the changes to their local
> 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
Anyway, if anyone wants to work on this stuff let me know. I've got lots
history with the issues.
Christopher R. Hertel -)----- University of Minnesota
crh at nts.umn.edu Networking and Telecommunications Services
More information about the samba-technical