![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Traditionally, UNIX® systems have been used as central servers, storing shared files and doling them out to client workstations. UNIX's powerful networking capabilities and generally rapid response to security exploits make it great for this purpose, but the plethora of tools, server applications, and client options make it a daunting task to set up and configure a system that plays nice with the sometimes random mix of client systems present on even a small Local Area Network (LAN).
The most popular desktop workstations and laptops, running Microsoft® Windows® and Apple's Mac OS X, can easily communicate with Windows servers without any additional software or configuration. Their support for Server Message Block (SMB) or Common Internet Filesystem (CIFS) networking, often referred to as Windows network, make this a natural choice. Luckily, there's a free UNIX implementation of SMB or CIFS, called Samba.
Samba implements many useful file (and print) sharing abilities, such as public shares and per-user shares, and it can even act as a Windows primary domain controller (PDC) on small networks. To provide another means of sharing public files, you'll augment this with a simple Apache Web server setup.
If you want to follow along with this article, you'll need to pick up a few things. Everything used here is open source and freely available.
Samba is an open source implementation of the SMB or CIFS file and print sharing and network authentication, systems used by Microsoft's Windows and various other operating systems (including OS/2® and Mac OS X). This is common on Linux® systems, but less likely to be installed on other UNIX systems. If you don't have it, hit up the Samba Web site (see Resources) to get the code and install it.
Apache is the world's most popular Web server, and you've probably already got it installed and running if you're using a popular Linux distribution. If you don't have Apache up and running, head to the Apache Software Foundation Web site (see Resources), grab it, and get it going. You'll be using Apache to provide anonymous access to the public file storage areas that will be set up later.
The simplest small network would be one server and one client workstation, connected through a router or switch (most home network routers have at least four ports of switch included in the device). This grows over time, usually by adding more clients and additional storage on the server. You can see this sort of network in Figure 1 below.
Figure 1. A simple, small network
In this setup, the server acts as a centralized location for file sharing, backups, and probably printer sharing. The clients communicate with the server and talk amongst themselves, as appropriate.
For this to all run together smoothly, you should have a single method of authenticating with the server, a way to share public file areas and private per-user file areas with the clients after they've authenticated, and maybe even an anonymous way of accessing public files for clients that haven't authenticated. This last feature is great if friends visit with their computers and want access to your network without requiring an account on the server.
The following sections illustrate one way of setting all of this up on a UNIX system using Samba and Apache.
To let your client workstations authenticate with the UNIX server, you're going to set up Samba as the PDC. This gives them a central location for authentication and works out-of-the-box with Windows XP Professional and Mac OS X clients. Windows XP Home doesn't support domains; if you're using XP Home on your LAN, you'll have to use a different authentication technique. See the Samba documentation (available in Resources) for more information.
Configuring Samba as a domain controller
After logging in as root, find and edit the smb.conf file (usually located in /etc/samba) using your favorite text editor. Note that you can also use sudo to edit the file as root if you'd prefer (for the rest of the article, I'm going to assume that you're logged in as root; if you're not, type sudo before any command listed here to run it as root instead of yourself).
Locate the [global] section of your smb.conf file and add the following options; if they're already present, change them to match what you see here in Listing 1.
Listing 1. Additions to Samba's [global] section
[global]
workgroup = WORKS
domain logons = yes
security = user
local master = yes
os level = 65
preferred master = yes
domain master = yes
encrypt = yes
smb passwd file = /etc/samba/passwd
domain logons = yes
logon path = \\%n\profiles\%u
logon drive = S:
|
This sets the domain name to WORKS (you'll probably want to change that to something else) and tells Samba to require domain logons with user-level security. That's right, user corresponds to the standard domain authentication system. It's called user because, in addition to your regular domain login name, the computers in the domain also have user accounts. The machines need to authenticate with the domain controller, before they're considered trusted systems and allowed to interact with the rest of the domain.
You also need to set up domain logons and automatic mapping of the S: drive (on Windows machines, obviously) to \\SERVERNAME\%u (replace SERVERNAME with your Samba server's name). The %u is replaced with the user's name, so it'll automatically expand to a unique share name for each user. The logon path setting is used for roaming profiles, which are used by mobile workstations (like laptops, for example).
Next you need to add a [netlogon] section for the network logon service, as seen in Listing 2.
Listing 2. The [netlogon] section
[netlogon]
command = The domain logon service.
path = /home/netlogon
guest ok = yes
public = no
writable = no
share modes = no
|
If it doesn't already exist, you'll have to create the path indicated in the [netlogon] section, and it should be empty. This share is required during authentication.
After you've made these changes, you need to add machine accounts (so the workstations are known to the domain controller, and trusted) and user accounts.
To a domain controller, a machine is just another kind of user, and it needs to have its own account (but with a "$" at the end). You should also create a new group for the Samba users, in case you need to segregate them further. Listing 3 shows you how to do this on Fedora Core 4 Linux using the groupadd command; other UNIX systems have similar utilities or detailed instructions for adding new groups and users.
Listing 3. Adding a group and machine accounts for Samba
/usr/sbin/groupadd smbusers
for system in machine1 machine2 ; do \
/usr/sbin/useradd -g smbusers -d /dev/null -s /dev/null $machine\$ ; \
smbpasswd -m -a $machine ; \
done
|
This creates the smbusers group and then adds machine accounts for machine1 and machine2. After each user is added, its account details are added to the Samba password file.
Now you can add accounts for regular users.
A note about Windows XP machine accounts
When you first log in to the Samba server from a newly added Windows machine, you need to log in as root with the Samba server's root password. This authenticates the machine's account on the server (domain administrators adding machines to regular Windows server domains do the same thing, but with the domain Administrator account). You won't need to do this again; the user can log in to the Samba server using any valid account after the machine has been authenticated.
Adding user accounts is similar to adding the machine accounts; you need to create a user, if they don't already exist on the Samba server, and then add that user to the Samba password file using the smbpasswd command. The following code shows you how to do this on Fedora Core 4 Linux using the useradd command; other UNIX systems have similar utilities or detailed instructions for adding new users.
/usr/sbin/useradd -g smbusers username smbpasswd -a username |
This adds username to the system and to the Samba password file. You'll be prompted to set the username's password. Remember to tell them what you've set it to!
Because you've changed Samba's configuration, you need to restart the two Samba daemons, smbd and nmbd, so they'll reload their configuration files. On Fedora Core 4, you'd use the following command:
/etc/rc.d/init.d/smb restart |
This uses the smb init.d script (which also launches Samba when you boot) to restart the servers, as seen in Figure 2.
Figure 2. Samba restarting
If your UNIX isn't Fedora Core 4, you can always use the smbcontrol command to tell the daemons to reload their configuration files:
smbcontrol nmbd reload-config smbcontrol smbd reload-config |
Now that you've configured Samba to work as a domain controller and told it about the machines and users on your network, you should set up some useful file shares.
At the very least, it's nice to have a personal directory on the server and a public share where authenticated users can store files for anyone to access. You'll also set up a completely open shared area where anyone can store and retrieve files.
Adding the [homes] section from Listing 4 to your smb.conf file creates the user's home directory when they log in to the Samba server. This share is invisible (not browseable) to other users, even if they've been authenticated with the server. To a client workstation, their home share is available as \\SERVER\user, where SERVER is the name of the Samba server and user is their user ID. The %S macro used as the list of valid users means the current session name, which will be the name of the currently logged in user.
Listing 4. Making users home directories available
[homes]
comment = Home Directories
valid users = %S
read only = no
browseable = no
|
Next up, you'll add the [public] and [shared] sections, which create the \\SERVER\public and \\SERVER\shared shared directories, respectively (where, as usual, SERVER is the name of your Samba server). These shares have nearly the same settings, but with one difference. With the [public] share, only members of the Samba users group (represented by the %G macro) are allowed to write into the share. Anyone can write into the [shared] share (see Listing 5).
Listing 5. Two public shares
[public]
comment = Public files
public = yes
browseable = yes
write list = %G
path = /data/public
[shared]
comment = Totally open shared area
public = yes
browseable = yes
read only = no
path = /data/shared
|
You should only create a completely open share like the one here if you trust the people who have access to your Samba server; open FTP servers, for example, have been compromised in the past and abused as drop boxes for pirated software.
After you've added these shares to your smb.conf configuration file, remember to either restart Samba or tell it to reload its configuration files (see the Restart Samba section).
Now things should be working well for systems and users that want to log on to the Samba server; however, you also want to provide access through Web browsers so anyone can download files from your public shares. You'll do this by adding the shares to the Apache Web server that you have running on your Samba server.
Locate your httpd.conf file (mine is in /etc/httpd/conf) and add the code from Listing 6. These two declarations, <Alias> and <Directory>, create http://server/public/ and http://server/shared/ on the server, turn on fancy directory listings, and allow access from any Web browser.
Listing 6. Web access to the public shares
Alias /public/ "/data/public/" <Directory "/data/public"> Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all </Directory*> Alias /shared/ "/data/shared/" <Directory "/data/shared"> Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all </Directory> |
Save the file and use the apachectl command to tell Apache to reload its configuration file and activate the new URLs.
/usr/sbin/apachectl restart |
In addition to having convenient Samba access to these shared directories, they're accessible to anyone with a Web browser.
By using powerful and well-supported free software, such as Samba and Apache, you can help integrate a UNIX server with Windows and Mac OS X client workstations. Samba provides authentication services by acting as a PDC. It can serve up shared directories that clients can easily mount by using standard techniques. By adding Apache to the mix, you can also easily provide unauthenticated, read-only access to public shared directories. Sharing resources is part of the point of having a LAN environment and being able to share things reduces the work associated with installing and configuring your network.
Learn
-
For a developerWorks tutorial about setting up Samba as a primary domain controller, see "Using Samba as primary domain controller" (developerWorks, April 2002).
-
Learn how to install and configure Samba as a primary domain controller with a secure LDAP-based authentication mechanism in the developerWorks tutorial
"LDAP-based authentication for Samba" (developerWorks, January 2006).
-
The Samba "How to" collection is an extensive set of Samba documentation.
-
For an article that shows you how to configure and use the new net command in SAMBA 3.0, be sure to read "IBM Rational® ClearCase MultiSite® and SAMBA 3.0" (developerWorks, August 2005).
-
Read an "Interview: Taking Samba beyond POSIX" (developerWorks, April 2003) on the latest Samba rewrite.
-
You'll want to look at the Samba-3 by Example online manual for exercises in successful Samba deployment.
-
Robbins has another article entitled "Common threads: Inside Samba 2.2" (developerWorks, April 2001) that explores some of the functionality incorporated into that release.
-
For a whitepaper supplying technical architects with the methods that the IBM Linux Scalability Center used to implement a Samba file serving consolidation solution using z/VM® and Linux for zSeries® on the IBM eServer™ zSeries hardware platform, see
Samba Fileserving on IBM zSeries servers with z/VM.
-
Stay current with
developerWorks
technical events and webcasts.
- Want more? The developerWorks AIX and UNIX zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on AIX and UNIX.
Get products and technologies
-
Visit the Samba Web site.
-
Visit the main Apache Web site.
Discuss
-
Participate in developerWorks
blogs and get involved in the developerWorks community.
Chris Herborth is an award-winning Senior Technical Writer with more than 10 years of experience writing about operating systems and programming. When he's not playing with his son Alex or hanging out with his wife Lynette, Chris spends his spare time designing, writing, and researching (that is, playing) video games.
