Document Home

A Basic Samba Installation

Determining how file sharing should be implemented is the most important factor in configuring user and security setup for samba. As a simple example, let's say that we have set up a mosix cluster in a grade school, and that the only file sharing use for the cluster is as storage for common projects being undertaken by three classes for fourth graders. In that context, we really only need to create three users for the samba services, i.e., class_a, class_b, and class_c. In a fairly wide range of circumstances, such solutions are very appropriate, because they are low maintenance and minimize the amount of effort required to maintain user credentials in samba. Often, the benefits afforded by strong user management do not justify the effort required to achieve them. In this example, as long as a reasonable backup capability exists to protect against accidental deletion or modification of files, simple userids can be a perfectly acceptable solution. The reason why you shouldn't make your configuration any more complicated than is required is related to the nature of the cluster, but not at all unique to it. We have several environments interacting to create the capabilities we are implementing, and complexity added on any level generally adds to the overall complexity of the environment in a non-linear fashion. This is all well and good if file sharing is one of the primary roles of your cluster, but if your intent in adding samba is just to add a little functionality to a cluster that is primarily used for database operations you can quickly find yourself overwhelmed by the details of administering a function that is not one of the core functions of the cluster. While some might trivialize the relevance of that ("What, you afraid of work?"), you should recognize that this would drain time and effort from the primary focus of your cluster. Further, trying to do a quick and dirty configuration of a service like samba can result in the inadvertent exposure of some element of the cluster that is key to its primary role.


Now that is not to say that you can't implement a sophisticated file sharing system, and that putting one together is not a worthwhile exercise. In fact, that's what we're doing here. The reason I've suggested caution will be apparent as we progress from the simple example that is described here through more sophisticated installations.


(The following account should be supplemented with a review of the samba documentation as you reach the point of implementing samba in a given environment. Any given situation has characteristics that are unique on both organizational and physical levels. A simple configuration, such as this, can be used virtually anywhere, but if you are attempting to more tightly integrate samba and your cluster into the overall environment of an organization there are likely to be wrinkles that the more complex examples below do not address. Keep in mind that samba is a complex tool, that there is much you can do with it, and that I can't tell you everything you might want to do with it in your environment because you are there and I'm not.)


To return to our example, implementation is going to be based on user-level authentication on the cluster controller, ralphzilla. To do that we first have to create the user accounts on the machine. Struck with a blinding flash of inspiration, I named the accounts for the three classes class_a, class_b, and class_c. To actually create the accounts, telnet into the cluster controller, su to the root account, and create the users ("adduser class_a", etc.) providing as much details about the individual class accounts as you wish. After creating the users, the following actions must be taken, though in no particular order.


Assign passwords to the user accounts ("passwd class_a"). From the perspective of this section, the individual accounts do not represent a login account, they are primarily a way of controlling directory and file access permissions. Unless someone is going to act as a group supervisor, with the ability to control file permissions within the directory, you might as well assign a password that is incomprehensible gibberish and tell it to no one, even yourself. You don't need it, and if you even come to need it you can just assign a new one.


Assign ownership of the shared directory to the pertinent user. For example, in our example the directory path to the shared directory for class_a is "/mfs/3/data/class_a". The actual location of this directory is, of course, under the /data mount point on ralphzilla-raider, which is assigned to the three-drive RAID0 stripe set. We are manipulating file and directory permissions on a second machine from the cluster controller through mosix. In this context, the command is

"chown class_a /mfs/d/data/class_a"

After performing this operation myself I was curious as to just what mosix had done behind the scenes, so I telnetted to ralphzilla-raider from ralphzilla and looked at the long directory listing for the /data directory. It indicated that the owner of the class_a subdirectory was "1001", a uid that does not exist on ralphzilla-raider, but which is the uid of the user class_a on ralphzilla. Interesting.


Su to the class_a account (when you are logged in as root "su class_a") and modify permissions for that directory as you deem appropriate. You do this with the chmod command. Let's say that you feel that no one other than the user class_a should be able to see what is in the class_a directory. First you would remove all permissions on the directory, i.e., "chmod a-rwx /mfs/3/data/class_a". Then you have to determine what rights that user class_a should have. Remember that this user represents every member of a group of perhaps twenty individuals. if you want those users to have full rights to the directory and everything in it, a not inappropriate configuration, you would type "chmod u+rwx /mfs/3/data/class_a".

This kind of scenario would be absolutely appropriate in many of the circumstances in which you will be operating. Let's say, however, that you want others to be able to see and read the files readme.txt and project.doc in that directory. In that context, you'd have to give everyone the ability to read the directory ("chmod a+r /mfs/3/data/class_a"), remove their ability to read all of the files in the directory ("chmod a+r /mfs/3/data/class_a/*.*") and then restore their ability to read the two files you do want them to see ("chmod a+r /mfs/3/data/class_a/readme.txt" and "chmod a+r /mfs/3/data/class_a/project.doc").

Far more complex implementations are also possible, but handling them with this kind of authentication framework quickly becomes clunky and unwieldy. I will discuss them in detail in following sections.


Create the samba passwords for the users. These are the passwords that are actually used by the users to access the share. To follow our example, the command would be "smbpasswd -a class_a", and so on for the other two users. You will then be asked to type the password twice to confirm the spelling.


Modify the samba configuration file (/etc/samba/smb.conf) to reflect your configuration. The smb.conf file is the key to the operation of any given samba implementation, and is split into sections that are headed with a title in square brackets. The [global] section defines parameters that pertain to the entire samba implementation, while the other sections configure individual shares and shared printers. While there are tools to aid in the configuration of the smb.conf file, the most prominent of them being the browser-based swat, for this example we will make the requisite modifications by hand.

First, we'll define the shares for the shared directory for each class. The sample below, for class_a, represents the model used for all three classes.
[class_a]
writable = yes
locking = no
path=/mfs/3/data/class_a
The first line simply says that the share is writable ... that files can be created and changed in the directories in the share (subject to the rights assigned on the local machine itself). The second line, locking, determines whether a file is locked when opened by an application. If the file is locked, then the next client to try to open it may not be able to, and if it can open it has a read-only version in memory and any changes made are not saved unless the user saves it with a different name or to a different location. Whether file locking is appropriate in this context, of course, depends on how the shared file space is to be used. If file locking is off and several users have the same file open, then the changes made by one user can be overwritten by another as they save their changes. At the same time, modifying a file is an exercise in futility unless you can save those modifications. The most prudent course is to turn file locking on, and educate the users to save their customized versions under a personalized name, cooperatively adding those changes to a master file if such is appropriate. If we were really using ralphzilla as a file server for shared projects for fourth grade classes, that would be part of the purpose of the system in the first place. The final line in this sample share definition is the path to the shared directory, relative of course to the root of ralphzilla, the cluster controller. In this example, the path is "/mfs/3/data/class_a".

I've also commented out the [homes] section in the smb.conf file. Home directories are automatically created when you create an ID in linux, and samba is by default configured to export home directories. You probably do not want this, it will likely confuse the users when they try to attach to the share, because this is not the shared directory you are intending to export. Just go to that part of the smb.conf file and put a semi-colon (";") in front of each of the the lines in the [homes] section, including the section title itself.

The second thing we have to do is implement some mechanism to get individual users logged in and able to access the shared directory. While you could have users log into their machines under the username "class_a" or "class_b", or use the "connect as" option from within Windows, a more flexible and manageable solution is to create a username map file. This file maps the netbios name (the user name used by windows networking) to an id maintained on the linux machine. In this fashion you can avoid having to maintain user accounts on the cluster controller simply to enable basic file sharing. This file (in another fit of creativity, I named it user.map) is formatted with the local ID on the left, an equal sign ("="), and the netbios name on the right. A username map file for this example might therefore look something like this:

class_a=fsmith
class_a=bsmith
class_b=lsmith
class_c=gsmith
class_c=rsmith

Once you've created the username map file, put a reference to its location in the [global] section of the /etc/samba/smb.conf file. I placed it in the /etc/samba directory, because that made sense organizationally. Therefore, that line looks like this ...

username map = /etc/samba/user.map

At his point, if you restart samba the modifications you have made should become effective. The easiest way to restart samba is to is to issue the command "/etc/init.d/samba reload".

The shares you've created should now be visible under the machine name in the workgroup designated in the smb.conf file. If you didn't change that line the default name is "workgroup". Make sure that Windows Network is the default logon for the workstation, and log on with one of the IDs you specified in the username map file. If you used the same password as you set when you ran the smbpasswd command for the ID your username maps to the shared directory will be displayed when you double-click on the share. If that isn't the password under which you logged into the workstation you'll be prompted for the share password before the directory is displayed.


CAVEAT

If you have an existing account on the cluster controller, don't map your netbios name to another ID in the username map file. You won't be able to attach to the share. The authentication process seems to get all messed up. Strictly speaking, there is no reason why you'd want to do this, but you might be tempted to try it to simulate membership in a group. This is not the way to do that. There are many ways to address issues in which certain individuals would have wider rights ... the kind of rights you might want to assign to teachers in this example. In line with the model we've been following, you might want to create a username named "teacher", give it rights to the appropriate shared directories, and map the netbios names for teachers and aides to that in the username map file. We'll work through more complex examples like this is coming sections, using different authentication methods.