The use of multiple server hosting involves running multiple separate instances of Samba, each with it's own configuration file. This method is complicated by the fact that each instance of nmbd, smbd and winbindd must have write access to entirely separate TDB files. The ability to keep separate the TDB files used by nmbd, smbd and winbindd can be enabled either by recompiling Samba for each server hosted so each has its own default TDB directories, or by configuring these in the smb.conf file, in which case each instance of nmbd, smbd and winbindd must be told to start up with its own smb.conf configuration file.

Each instance should operate on its own IP address (that independent IP address can be an IP Alias). Each instance of nmbd, smbd and winbindd should listen only on its own IP socket. This can be secured using the socket address parameter. Each instance of the Samba server will have its own SID also, this means that the servers are discrete and independent of each other.

The user of multiple server hosting is non-trivial, and requires careful configuration of each aspect of process management and start up. The smb.conf parameters that must be carefully configured includes: private dir, pid directory,lock directory, interfaces, bind interfaces only, netbios name, workgroup, socket address.

Those who elect to create multiple Samba servers should have the ability to read and follow the Samba source code, and to modify it as needed. This mode of deployment is considered beyond the scope of this book. However, if someone will contribute more comprehensive documentation we will gladly review it, and if it is suitable extend this section of this chapter. Until such documentation becomes available the hosting of multiple samba servers on a single host is considered not supported for Samba-3 by the Samba Team.

Samba has the ability to host multiple virtual servers, each of which have their own personality. This is achieved by configuring an smb.conf file that is common to all personalities hosted. Each server personality is hosted using its own netbios alias name, and each has its own distinct [global] section. Each server may have its own stanzas for services and meta-services.

When hosting multiple virtual servers, each with their own personality, each can be in a different workgroup. Only the primary server can be a domain member or a domain controller. The personality is defined by the combination of the security mode it is operating in, the netbios aliases it has, and the workgroup that is defined for it.

This configuration style can be used either with NetBIOS names, or using NetBIOS-less SMB over TCP services. If run using NetBIOS mode (the most common method) it is important that the parameter smb ports = 139 should be specified in the primary smb.conf file. Failure to do this will result in Samba operating over TCP port 445 and problematic operation at best, and at worst only being able to obtain the functionality that is specified in the primary smb.conf file. The use of NetBIOS over TCP/IP using only TCP port 139 means that the use of the %L macro is fully enabled. If the smb ports = 139 is not specified (the default is 445 139, or if the value of this parameter is set at 139 445 then the %L macro is not serviceable.

It is possible to host multiple servers, each with their own personality, using port 445 (the NetBIOS-less SMB port), in which case the %i macro can be used to provide separate server identities (by IP Address). Each can have its own security mode. It will be necessary to use the interfaces, bind interfaces only and IP aliases in addition to the netbios name parameters to create the virtual servers. This method is considerably more complex than that using NetBIOS names only using TCP port 139.

Consider an example environment that consists of a standalone, user-mode security Samba server and a read-only Windows 95 file server that has to be replaced. Instead of replacing the Windows 95 machine with a new PC, it is possible to add this server as a read-only anonymous file server that is hosted on the Samba server. Here are some parameters:

The Samba server is called ELASTIC, its workgroup name is ROBINSNEST. The CDROM server is called CDSERVER and its workgroup is ARTSDEPT. A possible implementation is shown here:

The smb.conf file for the master server is shown in Elastic smb.conf File. This file is placed in the /etc/samba directory. Only the nmbd and the smbd daemons are needed. When started the server will appear in Windows Network Neighborhood as the machine ELASTIC under the workgroup ROBINSNEST. It is helpful if the Windows clients that must access this server are also in the workgroup ROBINSNEST as this will make browsing much more reliable.

The configuration file for the CDROM server is listed in CDROM Server smb-cdserver.conf file. This file is called smb-cdserver.conf and it should be located in the /etc/samba directory. Machines that are in the workgroup ARTSDEPT will be able to browse this server freely.

The two servers have different resources and are in separate workgroups. The server ELASTIC can only be accessed by uses who have an appropriate account on the host server. All users will be able to access the CDROM data that is stored in the /export/cddata directory. File system permissions should set so that the others user has read-only access to the directory and its contents. The files can be owned by root (any user other than the nobody account).

In this example, the requirement is for a primary domain controller for the domain called MIDEARTH. The PDC will be called MERLIN. An extra machine called SAURON is required. Each machine will have only its own shares. Both machines belong to the same domain/workgroup.

The master smb.conf file is shown in the Master smb.conf File Global Section. The two files that specify the share information for each server are shown in the smb-merlin.conf File Share Section, and the smb-sauron.conf File Share Section. All three files are locate in the /etc/samba directory.