Introduction to Samba, Part 21. Compiling, installing, and configuring Samba for your environment OK, it's time to download Samba 2.0.7 or greater from the Samba.org Web site (see Resources later in this article).
After you've downloaded Samba 2.0.7 or greater, it's time to decompress it to a directory location of your choice. From the command prompt, type:
A samba-2.0.7 directory will be created. cd into it, and we'll take a look around. First, notice the docs directory. Inside it you'll see another directory called textdocs. texdocs contains a whole bunch of Samba documentation. One of the most important files in the textdocs directory is called DIAGNOSIS.txt. It walks you through a step-by-step process of diagnosing problems you may have with proper Samba operation. We'll be covering some, but not all, of the diagnosis procedures mentioned in this file. Compiling and installing Samba You'll also notice the sources directory in the main samba-2.0.7 directory. Inside sources you'll find a well designed configure script designed to set up all the makefiles properly. As with any other configure script, to get a list of the configuration options, type:
You will probably want to pipe the output to more so that you can view all the options:
Note the directory and file name options. Notice where everything gets installed, and that the default install path is /usr/local/samba. You will probably want to change this to /usr/local by passing the --prefix=/usr/local option when you configure Samba. For this example, I'm going to use the following path settings:
The above configuration options will cause Samba's default tree to be in /usr/local, with the exception of the configuration files. Samba will expect to find these in /etc and log files, which will end up in /var/log. If you omit those configure options, you'll find everything in the /usr/local/samba directory tree (/usr/local/samba/var, /usr/local/samba/etc, etc.). It's now time to start the compilation. After running configure, type:
After compilation completes, type the following as root to install the software:
For the most part, configuring Samba begins and ends with the smb.conf file. This is Samba's main configuration file. It has many different configuration options. To avoid confusion, we're going to start only with those options essential to the proper operation of Samba. First, you'll need to find out where smb.conf should be. If you used the configuration options I specified above, you should place smb.conf in /etc. If you used the default paths, Samba will look for it in /usr/local/samba/etc. To get started, cd to the appropriate directory, fire up your favorite text editor, and type in the following lines. I'll intersperse commentary along the way to provide you with a good understanding of what each option does. Add these lines to your smb.conf file:
The first line tells Samba that we are placing options in the "global" section. There are many options that are intended to be defined only in this section. These options control the global behavior of Samba. The second line tells Samba the name of the Windows workgroup that Samba will create. Replace YOURWORKGROUP with an appropriate name for your workgroup. On the third line, we tell Samba to run in user-level security mode. This option will cause Samba to tell all connecting Windows clients that they need to provide a valid username/password combination to gain access to any network resource. This is definitely a good thing. User-level security is Samba's most often used security level because it's an excellent match for the majority of file sharing situations. However, there are other security levels available. One handy mode tells Samba to authenticate all users against the security database of an existing Windows NT or 2000 Server. We won't be covering that particular mode in this article. If you want more information about it, take a look at the "security" option in the smb.conf main page. Now, on to the fourth line. Here we tell Samba to exchange passwords with Samba in encrypted mode. You will always want to run Samba in encrypted mode, unless all your client machines are extremely ancient (like Windows for Workgroups-era machines). Enabling encrypted passwords does cause Samba to need its own password file, in addition to the standard Unix password database. If you are thinking that it may be nice to turn encrypted passwords off, so that you can avoid having to maintain two password files, don't do it! Turning encrypted passwords off will cause sharing problems with even moderately old versions of Windows NT 4.0 in addition to Windows 2000. If you really want to avoid maintaining two separate databases, Samba provides several ways to synchronize both databases, which is a better approach. The next line specifies a valid Unix user account that will be used for guest access. While people often use "guest account=nobody", it's recommended that you add a literal "guest" user to your system if one doesn't exist already. The new "guest" account does not need a password set and does not need to be able to log in interactively. (It's fine if you do choose to configure guest with a password and a valid default shell.) Now we're ready to add WINS support options to smb.conf. You'll want to add one of the following two lines to the global section:
OR
If you already have a WINS server on your current subnet (a Windows NT Server running WINS, for example), you'll want to use the second option and specify the name of the WINS server on the right side of the equals sign. Samba's internal WINS services will then be disabled, and it will use the WINS server you specify. If you don't have a WINS server running on your subnet, or you're setting Samba up at home and you don't know exactly what a WINS server is, you'll want to use the first option. This will tell Samba to become a WINS server for your LAN. You may be wondering what WINS does. Basically, you can think of WINS as a local dynamic DNS database. When Samba is running as a WINS server, every Windows-compatible machine on the same subnet will register its IP address and NetBIOS name (a.k.a. "computer name") with Samba. This enables Windows machines to use Samba's WINS database to request an IP address for a particular NetBIOS name. WINS is a key component of network browsing, which is what you are doing when you poke around inside the Network Neighborhood on a Windows machine. Now we're ready to add several more options to the global section:
Now for an explanation. All these options are related to network browsing. I've already mentioned that WINS is a key component of network browsing, but there's another element required for browsing to work properly. A local master browser must exist. Sound strange? Some further explanation is required. For browsing to work properly, there must be some central location that keeps track of what machines and workgroups exist on the local subnet. This particular list is called the browse list. The browse list is used to construct the list of workgroups, domains, and machines you see when you first click on the Network Neighborhood. Any modern Windows machine can become the local master browser. Ideally, we'd like Samba to be the local master browser on the network. How is this accomplished? Basically, several beefy Windows-compatible machines on your subnet will regularly duke it out by flinging packets back and forth across your LAN in an attempt to determine who will become the local master browser. This process is called a "browser election."
In the end the "winner" of this broadcast packet war gets to become the local master browser. We can cause Samba to win the battle by using the os level = 99 option, which causes it to beat every other machine on the LAN. This happens because every version of Windows (from Windows 95 to NT to 2000) has a hard-coded OS level that was intended to cause the most advanced version of Windows to become the local master browser (later versions of Windows have a bigger number). Setting Samba to 99 will cause it to beat all Microsoft products, allowing it to become the local master browser every time. Before we leave the global section, here are a few security options that you may be interested in. The host's allow option lets you limit the IP addresses that can connect to Samba:
This option allows only machines in the 192.168.1 network to connect to Samba, in addition to 127, the localhost. Always make sure there is a 127. at the end of your hosts allow line. The interfaces option is very useful if your machine happens to have multiple network interfaces. It allows you to specify the network interfaces on which Samba is available. It is used as follows:
This is an easy way to limit Samba to the necessary interfaces. And limiting the interfaces prevents possible hacking attempts from unwanted users. Now that we've configured Samba's global options, it's time to create a test share that will allow us to access the /tmp directory. Add the following lines:
When Samba is started, these settings will make a share available called tmp. This share will contain the contents of your /tmp directory on your Samba server. Also, if a particular user has write permission in /tmp, as almost all do, that user will be able to create and modify files in that directory. Now that we've added all these entries to smb.conf, it's time to verify that our configuration is correct. To do this, we'll use the testparm utility:
A list of all your configuration options will be listed to the screen after you hit Enter. Any errors in smb.conf will also be noted and commented upon at this point. If there are any errors, follow the instructions on-screen to fix them. Now we're ready to configure Samba users and fire up Samba for the test run. In order for the "myuser" user with the "mypass" password to be able to use Samba, the following things must exist:
These steps must be repeated for every new Samba user. If you are Samba-enabling an existing Unix account, remember to add the username and password to the smbpasswd file. If you're adding a Windows-only user, remember that in addition to adding the user to the smbpasswd file you'll also need to create a valid Unix account with an identical username. In fact, you'll need to create the Unix account first since smbpasswd won't add a user unless the Unix account already exists. Both accounts are needed because Samba uses the Unix account to set the proper permissions on disk, while the smbpasswd file is used for authentication purposes. If you are going to connect from Windows NT, you'll want to create a Samba "administrator" user. We're almost ready to start Samba and configure the client machines. But you must first make sure that your Samba box can ping every Windows client machine on your network, by name. If this doesn't work, you'll need to add some entries to /etc/hosts or update your DNS so that your Samba box can properly find your Windows machines. It is also helpful to note that Samba works best when /etc/hosts is set up so that only the "localhost" name maps to 127.0.0.1. The FQDN of your machine should map to the primary IP address used on your LAN. For example:
Samba is now configured and ready to go. We'll start Samba and then focus on configuring the Windows machines properly. To start Samba, type the following as root:
This will start Samba's two main server processes, smbd and nmbd. They will log any informational and error messages to /var/log/log.smb and /var/log/log.nmb, respectively. Now that the Unix side is up and running, it's time to turn to the client machines and get them set up properly. To configure a Windows machine so that it can participate in your Samba Workgroup, you'll need to make sure the TCP/IP protocol is properly configured. You must also make sure that:
Now is the moment of truth. After your Windows machines have finished rebooting, you'll need to log on to Windows using a username/password that will be accepted by Samba. If you're using Windows 95/98, this username/password combo will be simply stored in a file and used later when you try to connect to any network resource. If you are using Windows NT Workstation, this username/password combo must also be in the NT's local security database (otherwise you won't be able to initially log in to NT). To do this, log on to NT as administrator and create the account using User Manager. Afterwards, log out and log in as the new user. After you've properly logged in, double-click on the Network Neighborhood and take a look at the YOURWORKGROUP workgroup. Look inside. See if your Samba server is listed. Double-click on it and see if the /tmp share is listed. If so, congratulations! Samba is working! If not, here are some things to check:
If all these things check out and Samba is still not working, carefully follow each step in the DIAGNOSIS.txt file found in the docs/textdocs directory. You should be able to pinpoint and fix your configuration or network problem within minutes. If you change smb.conf in any way, you'll need to send smbd and nmbd a HUP signal to force them to reread smb.conf. This is done as follows:
Alternately, you can simply kill smbd and nmbd and restart them again. In my next Samba article I'll familiarize you with Samba's more advanced options. Then you'll be able to set up shares that function exactly the way you want them to. We'll also look at several advanced features of Samba, like Samba printing. I'll see you then!
|
|
