If you want something done right you have to do it yourself. | ||
| --Well-known axiom | ||
Sit back and think about it for a minute... There are a lot of ways to fiddle with the Browse Service. That could be good, or it could be bad. (Now would be a good time to check your firewall configuration.)
Samba takes advantage of the fiddlability of the Browse Protocol to improve the workings of the Network Neighborhood. It may break a few rules, but it gets the job done... sort of like Chicago.[1]
Samba’s Browse Service enhancements are worth a bit of study, because knowing how to gracefully break the rules can provide a better insight on the proper workings of the system.
There may still be systems out there that run the old LAN Manager style browsing. Things like that don’t die, they fade away... but, just when you think they’ve finally faded entirely they reach a skeletal hand up through the damp earth and grab your ankle. It’s best to be prepared for such events, and Samba offers a very simple clove of garlic.
Samba’s smb.conf configuration file provides the LM ANNOUNCE parameter, which is used to enable or disable the transmission of LAN Manager Browse Service announcements. This parameter has three possible values: TRUE, FALSE, or AUTO. The third option is the interesting one.
In LM ANNOUNCE = AUTO mode, Samba will not send any LAN Manager-style announcements until (and unless) it hears a LAN Manager Browse Service message from another system. If it hears such a message, it knows that LAN Manager style browsing is being used on the local wire and will start participating. This mode is the default for Samba, and it means that System Administrators don’t ever need to think about configuring LAN Manager style browsing. It’s automagical!
The BROWSABLE parameter can be used to completely hide a share. Share names ending with a dollar sign (’$’) are supposed to be hidden, but it is up to the client to decide whether or not to display these names. They are included in the reply to the NetShareEnum RAP call, so the client can do as it pleases with them.
Samba can be told not to include a share in the NetShareEnum reply message simply by setting BROWSABLE = NO in the share declaration. This moves control to the server side and allows a System Administrator to really truly hide a share.
Samba’s implementation of the NBNS supports a non-standard wildcard Domain Master Browser query. You can send a query for the name “*<1B>” (that’s an asterisk, followed by 14 bytes of either space or nul padding, with a suffix byte value of 0x1B), and Samba’s NBNS will return a list of all of the IP addresses of all Domain Master Browsers that have registered with it. In other words, all of the IP addresses for all of the <1B> names in its database.
If the ENHANCED BROWSING parameter is set to TRUE (the default), a Samba DMB will periodically send a query for “*<1B>” to the NBNS to get the list of DMB IPs. The Samba DMB will then go through the list of IPs and send a NODE STATUS REQUEST message to any IP address that it doesn’t already recognize. The reply will contain the registered workgroup<1B> name of the “foreign” DMB.
This trick is used by Samba to short-cut the building of the workgroup list. The normal mechanism relies on Local Master Browsers to discover foreign workgroups on their own subnet and report them back to the DMB. That process is slow and, as shown in Figure 24.1, workgroups can be isolated on separate subnets where they will never see or be seen by foreigners. By querying the NBNS for the list of DMBs, Samba does a better job of ensuring that all of the workgroups within the NBT namespace know about one another.
The ARTHROPODS and MAMMALS workgroups are isolated because there is no subnet on which they both have a Local or Domain Master Browser. Workgroups normally find one another by broadcasting DomainAnnouncement messages on the local LAN. Samba can query the NBNS to find Domain Master Browsers on remote subnets, and synchronize with them to merge isolated Browse Lists.
Figure 24.1. Hidden workgroups
...but it’s not perfect. There might be workgroups out there that don’t have a DMB, in which case querying the NBNS for DMB names won’t help much. With Enhanced Browsing enabled, a Samba DMB will try to find lost workgroups by periodically querying other DMBs to see if they know about them. The Samba DMB then adds any missing workgroups to its internal list.
There is a downside to this second trick, which is that bogus or expired workgroup names, once added to the Browse List, may never disappear. Samba DMBs may wind up sending the bogus names back and forth like an urban legend. This is known as the “Dead Workgroup” problem. The comments under ENHANCED BROWSING in the smb.conf manual page suggest disabling this feature if empty workgroups won’t go away.
Note that Windows also has a work-around for this problem. You can specify foreign DMBs in the LMHOSTS file on a known DMB, and the DMB will include the foreign names in its Browse List and try to synchronize with them.
The Remote Announce feature allows a Samba server to announce itself to Local and Domain Master Browsers anywhere across the internetwork. The format of the REMOTE ANNOUNCE parameter is:
remote announce = [IP[/workgroup]{" "IP[/workgroup]}]
That is, a list of zero or more entries, separated by spaces, in which each entry consists of an IP address and an optional workgroup name. The IP and workgroup are separated by a slash. The Samba server will send HostAnnouncement Browser Frames to the specified IP address (which could be either a host or a broadcast address). If the workgroup name is specified, the Samba server will announce itself as a member of that workgroup, otherwise it will use the name specified by the smb.conf WORKGROUP parameter.
As a result of using this feature...
An isolated server can send a directed broadcast to a subnet, where an LMB might pick it up.
An isolated server can announce itself directly to the DMB.
A single server can show up as a member of many workgroups.
Be careful, though, a misconfiguration can really mess things up.
Samba servers running as Local Master Browsers can be configured to synchronize with one another directly, without the need for a DMB. The notes in the smb.conf manual page explain that this is done in a Samba-specific way. The trick is fairly simple, though. Samba unicasts a MasterAnnouncement Browser Frame to the remote IP address.
You may recall that MasterAnnouncement messages are supposed to be sent to DMBs. An LMB sends them to let the DMB know that the LMB exists. The DMB then sends a NetServerEnum2 request to the LMB to collect the Browse List and merge it with the master list... but you knew that.
Samba’s extension is that a Samba LMB will also respond to a MasterAnnouncement message and synchronize with the sender.
It is suggested, in the smb.conf docs, that the destination addresses be specified as subnet broadcast addresses. Current network best practices recommend against allowing directed broadcasts, however, so on most networks you won’t be able to send a broadcast message to a remote subnet. To really make this feature work, you will need to know the IP address of the Local Master Browser on the remote subnet. One way to do this is to ensure that a specific Samba server on that remote LAN always wins the LMB election.
You can fiddle the PREFERRED MASTER and OS LEVEL parameters in such a way that Samba will always win the election.