multiple nmbds domains workgroups...

[Kenny Stoltz]

No, my intention is, as Arnaldo said, to have an IP alias for the
interface, so each one has a different IP alias, different workgroup,
different network, and different subnet. This limits the usefulness in
common situations (because you can't make separate workgroups on the same
subnet) but it does allow a single machine to serve lots workgroups as
long as the rules are followed. I was pretty sure when I started out that
there must have been a protocol limitation because I would have expected
samba to support it if it were that easy.

My approach would basically be for nmbd to respect the includes, and alias
lines, provided a switch was set, and each alias had a different interface
and network. Are there problems with this?

Andrew Tridgell wrote:

> > IIRC from talks with Andrew, there are some protocol limitation
> > to implementing this.  I'll let him or Chris (or Jeremy)
> > comment on this specifics as they are escaping my mind right now.
>
> yes, there are protocol limitations. The problem is that there are
> parts of the protocol where the client asks a question that has a
> workgroup specific answer but the client gives no indication as to
> what workgroup they are interested in. The NetServerEnum RAP call
> comes to mind. In that call client may choose whether to supply a
> workgroup, and if it isn't supplied then the server is supposed to use
> its workgroup. So which workgroup would you use?
>
> That's why when Luke implemented multiple workgroup support in Samba
> several years ago we didn't integrate it - we didn't have a solution
> to this problem and the consequences were that machines leaked between
> workgroups (so you could eventually end up with all machines showing
> up in all workgroups). This happens because NetServerEnum is used for
> browse synchronisation within workgroups.
>
> I don't think this is the only part of the protocol where you have
> this type of problem. It's pretty much an inevitable result of having
> a complex protocol combined with Microsoft not implementing
> multiple-workgroup support. Programmers get lazy and don't bother
> adding a workgroup field to a call then you are stuck with that
> decison.
>
> Cheers, Tridge