Proposal: Good Neighbor Policy

[John E. Malmberg]

Jeremy Allison <jeremy at valinux.com> wrote:


>Well, we work on the protocol we see on the wire, not in the
>docs :-).

Well that is one of the reasons I am studying SAMBA.  It has taught me how a
lot of things really work.

>Seriously, we are not incompatible with the MS
>browsing protocol, you just have to know how browsing works
>in order to set up a working network. But that's the same
>even in an MS-only environment.
>
>"John E. Malmberg" wrote:
>> Based on these experiences, I always recommend that anyone adding SAMBA
to
>> an NT domain, not allow the SAMBA box to take part in browser elections.
>
>I think that's an overgeneralization. Samba can have
>its place as a tool in browsing (and can do some things
>NT can't, and vica-versa of course). SGI use Samba in
>browsing successfully on a very large network.
>


Please understand that most of the people that ask me questions about this
are also confused about simple things as subnet masks and default gateways.
:-)


I only brought this up as an example of something that did go wrong.  It may
very well have been a defective setup, and not a real "BUG".

To return to the basis that started this thread, was the question if
something can or should be done to prevent a configuration error with SAMBA
from causing a global networking problem, as that could damage Samba's
reputation.

In this case if there was someway that SAMBA could have detect the
deadlocked election, and drop out with the appropriate log message, no
noticable problem would have been seen by the rest of the network.


As I wrote, I do not know the setting used for that SAMBA installation on
that network.  I do know that one of the security policies in place
absolutely forbids any "guest" type accounts.  This was mentioned in another
thread as needed for stable cross platform browsing.


Unfortunately sometimes, you learn the most from repairing problems.

It seems that I have been more fortunate in this than others in not having
much problems with browsing, and I have learned some more from the replies
to this thread, and the other one about browsing.


One of the things that has been discovered where I am at, that having a
large number of non-hidden shares can cause browser failures.  The same
thing also causes replication with "My Briefcase" to fail.  (I do not
understand the connection either)  For that reason, we now have to mark all
home shares as hidden.

Most of the other browsing problems besides "Pathworks" issue, that I have
encountered have been due to network hardware problems that have cause
Windows systems to believe that they have lost communications with the
master browser, but still have some communications.


I have also had to deal with problems where someone has tampered with a WINS
server and added in static mapped entries for a subnet that they were not
authorative for.  This was in a failed attempt to repair a browsing problem.

To aid those fortunate not to have experienced this, if you have a static
mapped entry and a WINS aware client maps it's entry in later for the same
name and address, when the expiration time comes, sometimes WINS will not
ask the client to reregister.  Why should it, it is static.  It does however
let all the other WINS server know that the address is no longer good.

If the entry is needed for cross domain browsing or trusts over a WAN, spot
outages will start occuring.  And basically after the WINS database is
cleaned up. (not as simple as it should be), The victimized node needs to be
rebooted to get it re-registered.

>Sorry for the late reply, still catching up on
>email whilst I was in Japan.


Hope it was a fun trip :-)

-John
WB8TYW at QSL.NET