|
|
Running Dual Samba Servers on on ComputerI have a Samba server as a PDC for an NT Domain in a small office network. All the client computers were Win95/NT and Win2000. I recently added one Windows XP Pro system and it broke the Samba configuration. While all the other computers could see the shares on a Samba aliases, the WinXP couldn't. The shares were specified with an include file using the %L variable. This document describes one method to fix the problem. The solution is to use dual Samba servers on one computer rather than NetBIOS aliases. There are some information about running dual Samba servers on the web but it's not complete. This document hopes to fill in some of the gaps. The BackgroundThe network where Samba is running has a couple of servers with specific purposes. It started out with one WinNT Workstation (Central-One) with a tape drive and a plotter attached to serve a few workstations. That was before my time. When I took over, I added a small computer with Linux and Samba and converted the network to a NT domain model so we could better handle the user accounts. This created a Single Sign-On (SSO) for all the resources in the workgroup. The Samba computer was the Primary Domain Controller (PDC) for the NT Domain and was appropriately named Checkin. The Linux server also added an email server (Sendmail), DHCP and DNS services. Later, we added a larger hard drive to the WinNT system and made it a file server for a central Project Store. As the demand increased I upgraded the hardware for both servers, moving the Project Store to the Linux box. Linux has RAID capability which added some redundancy to file sharing. In keeping with the system naming, I just created an alias called Central-Two on Samba. The name Checkin wasn't something that the users were familiar with. It existed for one purpose, logging on. That was transparent to the users. The Central-two name was a compliment to the Central-One name which they understood. The shares were added with an include statement: include = /etc/samba/smb.conf.%L So the shares only showed up under the Central-Two alias in the network neighborhood. That is what Windows XP broke. The ProblemThe %L variable is a great way to add multiple personalities to a Samba server and is well documented in the Official Samba documentation. However, WinXP no longer uses NetBIOS over TCP/IP. It has the SMB protocol directly on TCP/IP and uses port 445 rather then the 137-139 ports. Some of the information, including the service name (%L) is no longer available. The result was, the WinXP system couldn't see the Central-Two shares. The SolutionWhen I searched for a solution, I came up with a few options. I could abandon the separation of services and just go with one NetBIOS name for the server. I also could keep the aliases but remove the include statement. The shares would then show up under both server names in the network neighborhood. Another solution was to run two Samba's on the same computer. Since a smbd daemon was initiated every time a connection was made, what harm could a few more instances do. I decided that the separation of services had some merits. Should I need to expand to more servers in the future, I could do that without disrupting what the users had come to expect. I already had some protests when I moved the file sharing services to Central-Two so I know change is not an easy thing to accept. As it was the services were separated as shown: Central-One (Windows 2000 Server):
Checkin (Samba PDC):
Central-Two (alias for Checkin):
The MechanicsSamba is made up of two daemons. nmbd handles the name resolution and browser lists. The browser list is the list of computers and shares that are displayed in the Network Neighborhood on Windows computers. When a Windows computer is turned on, it broadcasts for the local master browser and registers it's name and services with the local master browser. Samba has only one nmbd daemon running. It is associated with the NetBIOS name and aliases. The smbd daemon handles the services (shares) when another computer connects and requests a service. A new smbd daemon is started to handle the connection and shuts down when it is no longer required. There can be a number of smbd daemons running depending on the number of connections. The Primary Domain Controller (PDC) is just another service for centrally handling authentication. When a user connects to a share, the serving computer checks the credentials of the connecting request with a PDC. This is called SSO or Single Sign-On. There are lots of HOWTO's about making Samba a PDC for NT Domains so I won't repeat that here. However, I did need to run a separate Samba with the NetBIOS name Checkin for this purpose on my system. The CaveatI looked at what was needed to run the two Samba processes. Each needs separate smb.conf and log files. I also needed a new script to start the separate instances. I expected the support programs to work as they were. The log files location could be specified in the config file and the config file could be specified on the command line when Samba was started. From the Internet, I discovered that the two nmbd daemons would have to be run on separate IP addresses. This made sense because as servers they would be listening on ports. Only one program can listen on a port at a time. What I didn't realize was that they needed to be recompiled to work together. I discover that the moment I tried to run the second instance. It died with the error: ERROR: nmbd is already running. File /var/run/nmbd.pid exists and process id 7149 is running. In addition, they both need their own secrets.tdb file, even if one is a PDC and the other is a member server. More on that later in this document. I also found out with some experiment that some of the support binaries are bound to the Samba they were compiled with. More on that later also. What's RequiredNearly everything that needs to be configured can be specified in the smb.conf file. The smb.conf file can be specified from the command line so the personality of the server can be changed at run time. The pid file is the method to control the number of instances running and it has to be changed at compile time. I compiled a list of changes required to get dual Samba servers running: IP address: Each instance of nmbd requires a separate IP address. It can be specified in the smb.conf file: bind interfaces only = true interfaces = 192.168.0.5/24 127.0.0.1 You can use a virtual interface eth0:1 for the second IP address. You have to specify bind interfaces only = true or Samba will listen to all the interfaces. You also will have to specify the local host address: 127.0.0.1 in one instance of Samba (but not both). Some utilities such as swat and smbpasswd require it. In fact any secure communication with the Samba servers is done on the local host IP address 127.0.0.1. PID File Location The pid directory is the only thing that needs to be compiled into the program. However, you could compiled the config and log file locations in. I compiled it with new pid and config file locations. Since this instance of Samba was going to be the PDC, I used that theme for the directories. From the source location, use the following command to compile: #./configure --with-fhs=yes --with-piddir=/var/run/pdc --with-configdir=/etc/samba/pdc --- lots of output --- #make --- lots of output --- #make install The --with-fhs=yes switch tells the compiler to use a standard location for the files which is different then the normal Samba directories. You might want to see what directory structure your distro uses and go with that. The final binary files are placed in /usr/local/samba/sbin and /usr/local/samba/bin. I renamed nmbd to nmbdpdc and smbd to smbdpdc and copied them to /usr/sbin, where the original files were. Binary Files You might want to have a look at the rest of the binary files created. If you use the special compile for your PDC, then all the command that pertain to user accounts will look in the new file location for the configuration files. For instance, with the build shown above the new smbpasswd and pdbedit both look for the password files in /etc/samba/pdc/secret/ while the old binaries (on Fedora C1) look for the files in /etc/samba/ Some of the binaries work fine with both versions. testparm can be pointed at the smb.conf file you want to check so it works fine with both. smbstatus however only seems to work with the Samba files it was compiled with despite the fact that you can can specify the smb.conf file. The smb.conf Files I made up two smb.conf files. One for the PDC: [global] server string = Samba PDC Server %v workgroup = MYPLACE netbios name = CHECKIN bind interfaces only = true interfaces = 192.168.0.5/24 127.0.0.1 security = user domain master = Yes domain logons = Yes logon path = logon home = os level = 65 encrypt passwords = Yes username map = /etc/samba/smbusers log file = /var/log/samba/pdc/%m.log max log size = 200 load printers = No [netlogon] comment = Samba Network Logon Share path = /var/Samba/netlogon browseable = No And one for the member server: [global] server string = Samba Server %v workgroup = MYPLACE netbios name = CENTRAL-TWO bind interfaces only = true interfaces = 192.168.0.4/24 security = domain password server = * encrypt passwords = Yes username map = /etc/samba/smbusers log file = /var/log/samba/%m.log max log size = 200 load printers = No [Temporary] comment = Temporary File Storage path = /var/Samba/Temporary read only = No create mask = 0760 directory mask = 0770 guest ok = Yes and many more shares Start Script I created a new script to start the samba pdc daemons. I just copied the /etc/init.d/smb script to a new name (smbpdc) and changed the references to the binaries (nmbdpdc and smbdpdc). Smbpasswd and Secrets.tdb Each instance needs a secrets.tdb. The member computers use it to store their SID or System ID. Since my system was a PDC, I copied the existing passdb.tdb and secrets.tdb to the new /etc/samba/pdc directory. I started the PDC instance first with the new smbpdc script. It appeared in the network neighborhood as checkin. I then started the second instance with the original smb script. Central-two showed up in the network neighborhood, but it wasn't accessible. Although it was an alias before, I figured it didn't have a machine account. I created an account and joined it to the domain: [root@amos-rh etc]# adduser -d /dev/null -s /bin/false central-two$ [root@amos-rh source]# net rpc join -n central-two -U root root's password: Joined domain PSGEOMAT. This created a secrets.tdb in the /etc/samba directory. The net command must be from the newly compiled binaries or it will look for the password database in the wrong place. The -n central-two switch is required to specify which computer account you are trying to join. It worked for me without this switch, but I'm thinking it could get mixed up. I was now able to access the Central-two server from the network neighborhood and the Windows XP system could see all the shares. Final Thoughts It seems to work. Both servers show up in the network neighborhood. Renaming the binaries turned out to be a good thing. You can check the processes separately. [root@amos-rh etc]# ps -A | grep mbd 7497 ? 00:00:00 smbdpdc 7498 ? 00:00:00 smbdpdc 7502 ? 00:00:00 nmbdpdc 7514 ? 00:00:00 smbdpdc 7713 ? 00:00:00 smbd 7714 ? 00:00:00 smbd 7718 ? 00:00:00 nmbd 7721 ? 00:00:00 smbd Here is the status of the domain on the dual Samba system: [root@amos-rh mm]# nmblookup -S checkin
querying checkin on 192.168.0.255
192.168.0.5 checkin<00>
Looking up status of 192.168.0.5
CHECKIN <00> - B <ACTIVE>
CHECKIN <03> - B <ACTIVE>
CHECKIN <20> - B <ACTIVE>
..__MSBROWSE__. <01> - <GROUP> B <ACTIVE>
PSGEOMAT <00> - <GROUP> B <ACTIVE>
PSGEOMAT <1b> - B <ACTIVE>
PSGEOMAT <1c> - B <ACTIVE>
PSGEOMAT <1d> - B <ACTIVE>
PSGEOMAT <1e> - <GROUP> B <ACTIVE>
As compared to an alias: [root@bigbertha mm]# nmblookup -S checkin
querying checkin on 90.0.0.255
90.0.0.11 checkin<00>
Looking up status of 90.0.0.11
CHECKIN <00> - H <ACTIVE>
CHECKIN <03> - H <ACTIVE>
CHECKIN <20> - H <ACTIVE>
..__MSBROWSE__. <01> - <GROUP> H <ACTIVE>
CENTRAL-TWO <00> - H <ACTIVE>
CENTRAL-TWO <03> - H <ACTIVE>
CENTRAL-TWO <20> - H <ACTIVE>
PSGEOMAT <00> - <GROUP> H <ACTIVE>
PSGEOMAT <1b> - H <ACTIVE>
PSGEOMAT <1c> - <GROUP> H <ACTIVE>
PSGEOMAT <1d> - H <ACTIVE>
PSGEOMAT <1e> - <GROUP> H <ACTIVE>
The dual Samba system seems to work. I have yet to try it on a production server. Another instance where this may work is when you want to serve up two domains from the same server. The question then would be if the same computer can be a PDC for two different domains. One problem of course is putting too many services on one computer. Spreading the services around several computers probably causes less disruptions. If one goes down, there are still other services to uses. Something that needs work is the file naming convention. I renamed the binaries for the Samba PDC installation. However. There will probably only be one PDC instance. It you have several aliases, you may want to leave the PDC installation as the default and compile a new installation for every alias. The file structure would reflect that with a subdirectory for every alias instance. update mar.03.2005: Problems with the secrets file. I finally got around to adding this to a production system, but had lots of trouble with the member server. The office decided to update the server so I was working with a complete new system. I did a fresh install of Fedora Core 3 and copied the passwd/shadow and passdb.tdb/secrets.tdb file over from the original server. I didn't copy the secrets.tdb to the member server directory, just to the pdc/private directory. The member server denied access to it's shares, so I joined it to the domain again. It joined but still wouldn't allow access. After a lot of fiddling, I found that both Samba servers need access to the same secrets file. This makes sense as that is were the trust passwords are kept. The PDC maintains the file. So for any member server running as another instance on the same system, add this to the smb.conf file: private dir = /etc/samba/pdc/private so that the member servers have access to the PDC secrets.tdb file. I created a new /etc/rc.d/init.d/smb1 file to start the second instance and made up a standard /etc/samba/samba1/smb.conf file and added these lines: private dir = /etc/samba ; same secrets file as the PDC username map = /etc/samba/smbusers ; same user map file as PDC log file = /var/log/samba/samba1/%m.log ; separate log file location This version still needs a /etc/samba/samba1/private/smbpasswd file and kept failing to start until I created an empty file. It now seems to work just fine.
|
|
