Chapter 8

Configuring File Servers

THE FOLLOWING LINUX PROFESSIONAL INSTITUTE OBJECTIVES ARE COVERED IN THIS CHAPTER:

• 209.1 SAMBA Server Configuration (weight: 4)
• 209.2 NFS Server Configuration (weight: 4)
• 212.2 Securing FTP Servers (weight: 2)

In many offices, one of Linux's major roles is as a file server—a computer that holds files that are read, modified, and written by client computers. A file server can help centralize data storage for administrative and backup purposes, and it can facilitate collaboration by enabling users to share or exchange documents.

Linux is well suited to the role of a file server because it has excellent server programs for the most common protocols: The Samba Suite (http://www.samba.org) is a powerful and highly configurable package that manages the Server Message Block/Common Internet File System (SMB/CIFS) protocol used on many Windows-dominated networks; the Network File System (NFS) protocol, which is Unix's dominant file sharing protocol, is handled by a server of the same name; and several Linux server programs exist to handle the File Transfer Protocol (FTP), which is a popular means of cross-platform file sharing, particularly on the Internet.

Understanding the Role of a File Server

In some sense, many servers are file servers; for instance, email messages and Web pages can be thought of as files and indeed are stored as such on disks. A file server as typically defined, though, gives users access to files as such. Some file server protocols, including SMB/CIFS and NFS, are designed to provide common filesystem features to clients. This enables clients to treat the file server as if it were a hard disk, mounting it and giving users access to files on the server as if they were local files. (In SMB/CIFS, the directories shared in this way are referred to as shares; in NFS, they're referred to as exports.) This model for a file server is extremely powerful, since it simplifies the user experience; users can double-click network share icons on their desktops and then double-click file icons to launch applications associated with the file types, such as a word processor or a graphics editor.

SMB/CIFS was designed with DOS, Windows, and OS/2 in mind, and so it supports the filesystem features that are common to these OSs. This fact presents certain challenges for Samba, since Samba must map the Microsoft-style filesystem features onto the nearest Linux equivalents. Much of Samba's complexity derives from the need to make these mappings. In most cases, this works well, and users can be blissfully unaware that their files are stored on a Linux computer. Samba also supports extensions, implemented in the CIFS portion of the SMB/CIFS protocols, that enable it to store Unix-style filesystem metadata so that Samba can act as a server for Unix and Linux clients while retaining their native filesystem metadata. Since it originated in the Unix world, NFS is even better suited to act as a server for Unix and Linux clients; NFS more directly maps Unix-style filesystem metadata onto the underlying filesystem.

FTP is typically used in a different way; this protocol doesn't support all the filesystem features normally needed to mount a filesystem. Instead, FTP servers are typically accessed via FTP client programs, such as the text-mode ftp or ncftp or the GUI gFTP. Linux provides FTP clients, as part of the Filesystems in Userspace (FUSE; http://fuse.sourceforge.net) project, that enable FTP sites to be mounted like filesystems, but for the most part, FTP involves dedicated user-mode clients rather than the filesystem mounts that are common with SMB/CIFS and NFS.

Configuring a Samba Server

The Samba server suite, which is usually installed via a package called samba or samba-server, handles the SMB/CIFS protocol that's common on Windows networks. To configure Samba, you must first set some critical global options. You may also need to adjust the mapping of Windows to Linux usernames and passwords. You can then define file and printer shares, which enable sharing of files and printers. You can also configure Linux as an SMB/CIFS client, using Samba, Windows, or even more exotic SMB/CIFS servers.

Setting Global Samba Options

Samba's main configuration file is called smb.conf, and it's stored in the /etc/samba directory on all major Linux distributions. Some older or obscure distributions may store this file in another directory, such as /etc/samba.d or /etc/smb. The smb.conf file is broken down into sections, each of which is led by a name in square brackets, such as [global] or [home]. Subsequent lines, up until the next section name, belong to the specified section.

Understanding Samba Configuration File Sections

Three types of sections exist:

The Global Section The first section in most smb.conf files is the [global] section. This section defines global defaults and sets options that affect the overall performance of the server, such as its NetBIOS name.

File Shares File shares enable Samba to deliver files to clients and to accept files from clients.

Printer Shares Printer shares are very similar to file shares in many respects, but Samba sends the files that a printer share accepts into Linux's local print queue, so they end up being printed.

Within each section, options are assigned using lines of the following form:

option = value

Options and most values are case-insensitive. (Some values are Linux pathnames or other inherently case-sensitive strings, though.) Boolean values of 1, True, and Yes are equivalent, as are 0, False, and No. Hash marks (#) and semicolons (;) are both comment characters; lines beginning with these characters are ignored.

Setting Basic Global Options

The [global] section is particularly important to Samba's functioning. In fact, your Samba server probably won't be useable by your Windows clients until you've made one or two changes to this section. Table 8.1 summarizes some of the features you might want to change in this section. As with similar tables throughout this chapter, Table 8.1 is far from complete. You may need to consult the Samba documentation or a book on the server to learn about additional options if you have problems. The man page for smb.conf is unusually complete—but for this very reason, it can take a while to read it or even to search it for relevant information.

TABLE 8.1 Common global Samba options

Setting Password Options

Two of the options in Table 8.1 are very important for most systems. The first of these options is encrypt passwords. All versions of Windows since Windows 95 OEM Service Release 2 (OSR2) and Windows NT 4.0 Service Pack 3 use encrypted passwords by default. If encrypt passwords is set to No, Samba uses the Linux username and password database. In this case, recent Windows clients won't connect to Samba unless the Samba or Windows client configuration is changed. When encrypt passwords is set to Yes, Samba requires its own password database, which is independent of the standard Linux password database. In this case, recent Windows clients will connect to the Samba server. In practice, it's usually easiest and safest to use encrypted passwords. To do so, follow these steps:

1. If necessary, set encrypt passwords to Yes.
2. As root, type smbpasswd -a username at a command prompt, where username is a username for a user who should have access to the Samba server. The program will prompt for a new password, and then it will prompt you to type it again. The first time you issue this command, it will complain that the passdb database doesn't exist. You can ignore this complaint.
3. Repeat step 2 for all the users who should have Samba access.

If you have many users, the process of adding them all to Samba's encrypted password database can be tedious, but it's necessary. Many distributions include a script called mksmbpasswd or mksmbpasswd.sh that can create a Samba password file from a Linux /etc/passwd file. Unfortunately, Linux and Samba use different methods of encrypting passwords, so it's not possible to convert actual passwords. The resulting Samba password file includes usernames but no passwords. As a result, mksmbpasswd saves little or no effort. If you can run with unencrypted passwords for a time, though, you could use this script and use the update encrypted = Yes option. Samba will then add passwords to its encrypted database as users log on using unencrypted passwords. (You must run with encrypt passwords = No for this process to work.) This practice might be useful if you were migrating a network from unencrypted to encrypted passwords, but for most existing installations, it's not an option.

As just described, local Samba passwords rely on a setting of the security option to User. This option causes Samba to maintain its own list of users and passwords or to rely on the regular Linux account database, as just described. Another approach, described shortly, employs a domain controller for account maintenance. A third approach, exemplified by security = Share, attempts to mimic the way that old Windows 9x/Me servers authenticated users: No username is used, and instead a unique password is used with each share. When set to use this method, Samba runs through a series of accounts for authentication, including any username that the client might send even though it's not required to do so, the name of the share, the client's NetBIOS name, and any usernames explicitly provided by the username parameter (if present) in the share. This is an awkward system of checks, so in most cases, user-level security or one of the options that relies on a domain controller is used.

Setting Workgroup or Domain Options

The second option you'll most likely have to adjust from Table 8.1 is workgroup. SMB/CIFS networks are built atop NetBIOS workgroups or domains. If your Samba server's workgroup name isn't set correctly, your Windows clients won't be able to find it—at least, not easily. If you don't know what your workgroup name is, try typing the following command (note the trailing dash in the command):

$ nmblookup -MS -
querying __MSBROWSE__ on 192.168.1.255
192.168.1.1 __MSBROWSE__<01>
Looking up status of 192.168.1.1
        SPEAKER         <00> -        M <ACTIVE>
        SPEAKER         <03> -        M <ACTIVE>
        SPEAKER         <20> -        M <ACTIVE>
        ..__MSBROWSE__. <01> - <GROUP> M <ACTIVE>
        RINGWORLD       <00> - <GROUP> M <ACTIVE>
        RINGWORLD       <1b> -        M <ACTIVE>
        RINGWORLD       <1c> - <GROUP> M <ACTIVE>
        RINGWORLD       <1d> -        M <ACTIVE>
        RINGWORLD       <1e> - <GROUP> M <ACTIVE>

The output includes information on both the master browser computer (which manages lists of computers for browsing with GUI server-locating tools) and on the workgroup. In this case, SPEAKER is the master browser for the RINGWORLD workgroup.

Many Windows networks today use a domain configuration rather than a workgroup configuration. Domains may be either NT domains or Active Directory (AD) domains. A domain is basically a workgroup with some additional features, most of which relate to user authentication. You specify the domain name using the same workgroup option used to specify the workgroup; however, to use a domain controller for authentication, you must also set three additional options:

• You must set the name of the domain controller with the password server option.
• You must set encrypt passwords to Yes.
• You must set the security option to Server, Domain, or ADS.

Using security = Server is the simplest method to use, but in this configuration, the Samba server isn't a full member of the domain. Setting security = Domain causes Samba to fully join a domain using the older NT protocols, and using security = ADS causes Samba to fully join the domain using the newer AD protocols.

If you use either domain- or AD-level security, you must explicitly join the domain using the following command:

$ net join member -U adminuser

In this command, adminuser is the domain's administrative user, as defined on the domain controller. The domain controller may need to be configured to permit the Samba server to join the domain. If all goes well, you'll be prompted for a password, and Samba will store the necessary information locally so that you won't need to join the domain again; this command need be typed only once. In practice, using domain- or AD-level security can be tricky; a number of finicky details can cause the net join command to fail. The Samba developers encourage use of full domain membership over server-level security, though.

Any of these approaches to security (server, domain, or ADS) have the advantage that you needn't maintain a full Samba account database on the server computer. You must, however, maintain a conventional Linux account database for the computer's users. On a network with few users, you can probably do this manually. On a larger network, though, you might want to use tools to help automate this task. Some possibilities include:

Use a Local Script The add user script option in Samba can run a script when a user is authenticated. If you write a simple script to add a local account, you can ensure that you'll have local accounts for all your users. This approach will not, however, automatically remove accounts when they're removed from the domain controller.

Use LDAP A Lightweight Directory Access Protocol (LDAP) server, as described briefly in Chapter 7, “Advanced Network Configuration,” can manage accounts. If you're using an AD server for Windows, you can extend it to fill this role.

Use Winbind Samba includes an ancillary package called Winbind, which enables Linux to use a domain controller much like it can use an LDAP server. Using Winbind can be convenient on a Windows-dominated network, but it requires generating and storing some Linux-specific information locally, since a Windows server knows nothing about features like Linux user ID (UID) numbers and home directories.

Full descriptions of these options are beyond the scope of this book; I mention them here only so that you can explore them yourself should the need arise.

Mapping Linux and Windows Usernames

Linux usernames are generally short single words, such as tgilliam or samlowry. Windows networks often favor using fuller mixed-case names with spaces, such as T Gilliam or Sam Lowry. You can use either type of name in either OS (although some Linux utilities, such as useradd, impose more stringent rules); however, it's sometimes necessary to create a way to “translate” usernames between the two systems. This is done via the file specified via the username map option in smb.conf (the filename username.map is often used for this purpose, but you can use any filename you like). Each line in this file begins with a single Linux username and continues with an equal sign (=) and a space-delimited list of usernames that will be accepted in its place. Listing 8.1 provides an example.

!tgilliam = “T Gilliam” Terry
!samlowry = slowry “Sam Lowry” Sam
!jlayton = Jill
!tuttle = @heating
nobody = *

Listing 8.1 illustrates several features of the username map file:

• Because spaces are used to separate usernames on the right side of each entry, quotes (“) must be used to specify a username that includes a space.
• Usernames on the right side may be unusual by typical Linux standards, as in Sam Lowry; or they can be ordinary by Linux standards, as in slowry.
• An ampersand (@) leading a right-side name means to decode the name into all the members of that local or Network Information System (NIS) group. Thus, Listing 8.1 converts all members of the heating group into the local username tuttle.
• An asterisk (*) is a wildcard that matches any name, which may be used to map unknown names to a known local user.
• Ordinarily, processing continues after a match has been made. An exclamation mark (!) at the start of an entry means to stop processing at that point if it matches a name. This is particularly important on the lines before using wildcards, lest all usernames be converted to the default name (nobody in Listing 8.1). Protecting groups specified via an ampersand can be important, too.

When using share- or user-level security, the username map is applied before authentication, so Windows-style usernames are mapped to Linux-style usernames before the password is authenticated. When using server-, domain-, or ADS-level security, though, the username map file is applied after authentication. This enables the domain controller to store the Windows-style username, while the Samba server can rely on its local Linux username internally.

Configuring File Shares

File shares begin with the share name in square brackets and continue until the next share definition or until the end of the file. Typically, lines after the share name line are indented, although this isn't required. A fairly basic file share looks like this:

[test]
    comment = Test share on %L
    path = /exports/shared
    writeable = Yes

This share delivers the contents of /exports/shared under the share name test. Most of these options aren't actually required; they provide extra information to clients (the comment option) or set features of the share (the writeable option). Even the path option can be omitted—the default value is /tmp, except in one special case, described shortly. Table 8.2 summarizes some of the most common file share options.

TABLE 8.2 Common file share Samba options

Many Samba file share options affect how Samba handles the translation between Linux ownership, permissions, filenames, and other filesystem details and features that DOS and Windows expect on their filesystems. DOS and Windows 9x/Me don't support Linux ownership and permissions, so Samba uses create mask and directory mask to set default permissions. Samba uses the username of the individual who mounted the share to set the owner of new files, unless force user overrides that setting. Modern versions of Windows support ownership and access control lists (ACLs). When such a client connects to Samba, the server maps Linux ownership and permissions onto limited ACLs. If you use an ACL-enabled filesystem with a recent Samba package, you get better ACL support for your clients.

One special Samba file share comes predefined in many distributions' smb.conf files: [homes]. This share is unusual because it maps to the user's home directory. For instance, if the user jill has a home directory of /home/jill and if this user opens a browser onto the server from a Windows machine, a [homes] share will appear under the name jill. If this user opens this share, she'll find files from her home directory available in the share.

The [homes] share is unusual in a couple of configuration details. First, it normally includes a browseable = No option, which would ordinarily make the share disappear from browse lists. In the case of [homes], this option makes the share name homes disappear from browse lists, but a share named after the user remains in the browse list. Second, [homes] shares usually lack a path option. Samba knows to map this share to the users' home directories rather than to a fixed location.

Configuring Printer Shares

Samba printer shares are similar to file shares. The primary distinguishing characteristic is the printable = Yes option, which tells Samba to treat the share as a printer share. If this option is set, Samba tries to send files destined for the printer to a local print queue of the same name as the Samba printer share. (If you want to use another print queue name, you can set it with the printer option.)

Rather than define printers one by one, many Samba configurations rely on a special printer share name that's akin to the [homes] share for file shares: [printers]. This share might look something like this:

[printers]
   comment = All Printers
   browseable = no
   path = /tmp
   printable = yes
   create mode = 0700

If this share is present and if the [global] section does not include a load printers = No option, Samba scans your available printers and creates a printer share for every print queue on the system. This feature can be a convenient way to share all of your printers at once.

Samba delivers the print job via the local printing system—BSD LPD, LPRng, CUPS, or something more exotic if that's what you use. The global printing option defines how Samba submits print jobs, so be sure this option is set correctly. In all cases, the format of the job Samba submits must be something that the print queue can handle. Because Samba simply passes a file it receives from the client on to the server's printing system, this means the client must have a print driver that generates output the Linux print queue can process. In most cases, Linux print queues are designed to handle PostScript input, so using a generic PostScript driver on the client is in order. As a general rule, drivers for Apple LaserWriter models work well for monochrome printers, and QMS magicolor PostScript drivers work well for color printers. If your printer is a PostScript model, you can try using the driver provided by the manufacturer. On occasion, though, these drivers create output that includes mode-switching codes that confuse Linux print queues, so you may need to use another driver. Alternatively, you can include the postscript = Yes option; this tells Samba to tack a PostScript identifier onto the start of the file, causing the Linux print queue to correctly identify the output as PostScript.

If your printer is a non-PostScript model, you can try using its native driver. This practice will work only if the Linux print queue recognizes the format and passes print jobs unmodified to the printer, though. If necessary, you can create a “raw” print queue to pass data through without changes.

In practice, it's hard to say which is better—to use Windows PostScript drivers with a Linux print queue that interprets PostScript using Ghostscript, or the printer's native drivers in Windows and a raw queue. The PostScript approach is likely to reduce network traffic when printing text, but it imposes a greater CPU load on the print server. The native driver approach is likely to increase network traffic when printing text and shifts the CPU load onto the clients. The PostScript approach may be desirable if you use applications that work best with PostScript printers, such as some desktop publishing and graphics tools. Native drivers often give more convenient access to printer features such as resolution adjustments. Either approach could produce superior output; the best approach depends on the drivers in question and the type of printing. I recommend you try both approaches. You may want to create two queues, one for each method. (If your Linux queue is smart enough to recognize the file type, you'll need only one Samba printer share; you can create multiple queues on the clients that print to the same Samba share.)

Checking Your Configuration and Running Samba

Once you've made changes to your smb.conf file, you can restart or reload the Samba server by using your SysV or Upstart startup script. Before you do this, though, you might want to use the testparm utility, which scans your smb.conf file and flags any errors it finds:

# testparm Load smb config files from /etc/samba/smb.conf WARNING: The “printer admin” option is deprecated Processing section “[homes]” Processing section “[netlogon]” Processing section “[profiles]” Processing section “[smbpdf]” Processing section “[printers]” Processing section “[print$]” Loaded services file OK. Warning: Service smbpdf defines a print command, but rameter is ignored when using CUPS libraries. Server role: ROLE_DOMAIN_PDC Press enter to see a dump of your service definitions

Most of these example output lines are simply informative, such as the Processing lines and the Server role line. This example produced two warnings, though. The first identified a deprecated option (printer admin), which is still honored but is flagged for removal in the future. The second identifies a problem with a parameter that's ignored in the smbpdf share. (This chapter doesn't present the smb.conf file that produced this testparm output, so I don't describe correcting these specific errors. You should research any warnings or errors that crop up on your own system, since they're likely to be highly idiosyncratic to your configuration.)

Once Samba is running, it consists of two main server programs: smbd and nmbd. The smbd daemon handles the bulk of the file-sharing duties; it responds to connection attempts related to file and printer sharing. The nmbd daemon handles the behind-the-scenes NetBIOS “glue” functions, such as name resolution. (NetBIOS over TCP/IP implements its own name resolution system independent of TCP/IP hostnames, and it implements features such as file browsing. These duties are handled by nmbd.)

You can use the nmblookup utility to query servers about their names and related NetBIOS features. The preceding section “Setting Workgroup or Domain Options” showed an example of using this utility to locate your local workgroup or domain name. It's more often used much like the host utility, as a means of locating the IP address associated with a NetBIOS name:

$ nmblookup nessus
querying nessus on 192.168.1.255
192.168.1.2 nessus<00>

This output reveals that the IP address of the nessus computer is 192.168.1.2. You can pass additional options to nmblookup to perform more advanced queries. Consult the program's man page for details.

The smbstatus utility tells you about the current status of your Samba server, including the clients that are connected to it and the files that are currently open:

$ smbstatus Processing section “[homes]” Processing section “[netlogon]” Processing section “[smbpdf]” Processing section “[printers]” Processing section “[print$]” Samba version 3.4.9 PID Username Group Machine -------------------------------------------------------------------- 20225 samlowry users 172.24.21.5 (172.24.21.5) 20209 jill users helpman (172.24.21.9) Service pid machine Connected at -------------------------------------------------------- jill 20209 helpman Sat Nov 13 13:24:22 2010 samlowry 20225 172.24.21.5 Sat Nov 13 13:26:30 2010 Locked files: Pid Uid DenyMode Access R/W Oplock SharePath Name Time --------------------------------------------------------------------- 20209 500 DENY_NONE 0x100081 RDONLY NONE /home/jill . Sat Nov 13 13:24:23 2010

This example shows connections from two computers (172.24.21.5 and helpman), which have opened the jill and samlowry shares (two user home shares on the server). One client has opened the /home/jill directory on the server, but no files are currently open.

The smbstatus utility supports many options that can fine-tune the output it produces. Consult the program's man page for details.

Checking Samba Log Files

The /var/log/samba directory holds Samba's log files. Several such files exist. Most commonly, the nmbd and smbd servers create the log.nmbd and log.smbd files, respectively. These files hold information on these servers generally. In addition, files named after the names or IP addresses associated with specific clients, such as log.central or log.10.27.107.24, hold information on connection attempts for these clients.

Log files can be a treasure trove of information if you run into problems with Samba. If a client can't connect, you can examine the log.nmbd and log.smbd files, along with any files for that particular client. (Check using both its name and its IP address.) Look for obvious error messages soon after you attempt to connect. You may also want to compare what happens with the problem client to equivalent log entries from a client that has no problems—assuming of course that a problem is isolated to just one or a few clients!

You can also check log files on the client side; however, such logs are unlikely to appear in /var/log/samba. Instead, check /var/log/messages, /var/log/syslog, or other log files for problems related to mounting an SMB/CIFS share.

Using Linux as an SMB/CIFS Client

Linux includes tools that provide the ability to interact with Windows systems or Samba servers as an SMB/CIFS client, rather than a server. Samba includes a major client program called smbclient. In addition, you can use the smbfs or cifs filesystem type code with the regular Linux mount command.

Using a Dedicated Client Program

The smbclient program provides an FTP-like access to remote shares. Specifically, smbclient mimics the behavior of the standard text-mode ftp program, so if you're familiar with ftp, you should feel at home with smbclient. Even though SMB/CIFS is generally used by an OS client that mounts the shares locally, using smbclient can be a useful tool because it can provide convenient access to a server that you don't use on a regular basis with minimal setup configuration. You may also find that smbclient can provide useful debugging information that can be harder to obtain when you use a more conventional share-mounting approach to using the server.

The basic syntax for smbclient is:

smbclient [//SERVER/SHARE] [password] [options]

Table 8.3 summarizes the most common and useful options, but you should consult the program's man page for additional options and operational details. Most of your interactions with smbclient will take place at its own internal smb: > prompt, at which you can type commands such as help, ls, cd, rename, get, put, and exit. Many of these commands function just like their ftp equivalents, many of which are in turn similar to regular Linux shell commands. Type help command or consult the man page for smbclient to learn more about these commands.

TABLE 8.3 Common smbclient options

As an example, consider the following interactions:

$ smbclient //SERVICES/jill -U jill Enter jill's password: Domain=[CENTRAL] OS=[Unix] Server=[Samba 3.4.9] smb: > ls . D 0 Sat Nov 13 17:07:04 2010 .. D 0 Sun Nov 29 00:34:30 2009 EFI D 0 Fri Oct 16 16:00:55 2009 linux-2.6.36.tar.bz2 70277083 Tue Nov 9 09:34:47 2010 Form27b-6.pdf 79081 Sun Oct 31 23:25:38 2010 smb: > get Form26b-6.pdf getting file Form26b-6.pdf of size 79081 as Form26b-6.pdf (4542.8 KiloBytes/sec) (average 4542.8 KiloBytes/sec) smb: > exit

This sequence logs into the SERVICES server as jill, obtains a file listing, and retrieves one file (Form27b-6.pdf).

The -A option enables you to store your authentication credentials in a file, which is often useful for scripts. If you use this option, ensure that the file you create has the minimum necessary permissions (generally 0600 or even 0400). It contains three lines:

username = user
password = pass
domain = dom

Mounting SMB/CIFS Shares

The usual way to mount SMB/CIFS shares is via the standard Linux mount command. This requires you to pass a filesystem type of either smbfs or cifs with the -t parameter, along with the server and share name rather than a local Linux device filename:

# mount -t cifs //services/jill /mnt/services

Typing this command will ordinarily result in a password prompt. The program uses the value of the USER environment variable as the username unless you use the user=username option to set another username. This and other options may be specified via the -o option to mount, as in mount -t cifs -o user=jill //services/jill /mnt/services. Table 8.4 summarizes some of the more useful mount options. Consult the man pages for mount.cifs and mount.smbfs for more details. The credentials option is particularly important, since it enables you to automatically mount a share without placing the sensitive password information in /etc/fstab. The format of the credentials file is similar to that described earlier, with reference to smbclient; however, if you include a workgroup/domain name, it should be identified by the workgroup keyword rather than domain.

TABLE 8.4 Important smbfs and cifs mount options

You can mount a share automatically when the computer boots, or enable ordinary users to mount shares, by including entries in /etc/fstab, such as this one:

//SERVICES/jill /mnt/jill-serv cifs credentials=/etc/samba/jill 0 0

This example mounts the jill share on the SERVICES server to the /mnt/jill-serv mount point using credentials in /etc/samba/jill whenever the computer boots. You can of course change the mount options, many of which are the same as the options for local filesystems described in Chapter 3, “Basic Filesystem Management.”

Once an SMB/CIFS share is mounted, you can access it much as you would an ordinary filesystem. You should be aware, however, that you may have to deal with strange or limiting ownership and permissions rules, since Windows SMB/CIFS servers don't support the Unix-style ownership and permissions that Linux uses. If the server is a Unix or Linux system running Samba, matters may improve, but supporting two sets of conflicting rules sometimes creates a tangled mess of rules that can be hard to overcome. In such cases, you may prefer to simplify by implementing NFS for file sharing between these similar OSs.

Configuring an NFS Server

If your network hosts more than a handful of Linux or Unix file-sharing clients, you may want to use NFS instead of or in addition to Samba. Because NFS was designed with Unix ownership and permissions in mind, it's a more natural fit between a Linux server and Linux or Unix clients than is SMB/CIFS, which was designed with DOS, Windows, and OS/2 clients in mind. (NFS clients for Windows and other non-Linux/Unix OSs are available, but it's generally better to use Samba when serving such clients.)

To configure NFS, you should first look at NFS prerequisites, such as kernel and package options. You can then move on to setting up the NFS exports by editing the /etc/fstab file. (Recall that an export is the NFS equivalent of an SMB/CIFS share.) You should also know how to make temporary changes to the NFS configuration and adjust options that affect NFS security. Finally, you should know how to mount NFS exports on a client system.

Setting NFS Prerequisites

Every major Linux distribution ships with an NFS server called rpc.nfsd. In most distributions, this server is part of the nfs-utils package, but Debian, Ubuntu, and related distributions place it in the nfs-kernel-server package. These standard servers rely on NFS server support that's built into the kernel, as described shortly. Older NFS servers did not rely on this support, and such servers are still available on some distributions. For instance, Debian's nfs-user-server runs entirely in user space without taking advantage of the kernel NFS server support.

Many distributions present options to activate the NFS server at system installation or when you install the NFS server package. For others, you may need to create or activate a SysV, Upstart, or local startup script, as described in Chapter 1, “System Startup and Advanced System Management.” The startup script is called nfs-kernel-server (or nfs-user-server for the user-mode server) in Debian and Ubuntu, nfs in Mandriva and Red Hat, and nfsserver in OpenSUSE.

To use a kernel-based server, your kernel must include the appropriate options to support NFS features. Other kernel features are required to mount another computer's NFS exports. Both sets of options are accessible from the File Systems Network File Systems kernel configuration menu, as shown in Figure 8.1 for a 2.6.37 kernel. (Chapter 2, “Linux Kernel Configuration,” describes configuring a kernel in more detail.) The NFS Client Support option enables support for NFS client functionality, and the NFS Server Support option activates NFS server functionality.

FIGURE 8.1 The Linux kernel provides NFS support options in its configuration tool

NFS has undergone several revisions over the years. These NFS version numbers are often appended to the NFS acronym, as in NFSv2 for NFS version 2. This level is the default in the Linux kernel options; to use NFSv3 or NFSv4, you must activate extra features, which are visible in Figure 8.1's menu. As of the 2.6.x kernels, NFS support through NFSv3 is reasonably stable and complete. NFSv4 server support is still considered experimental as of the 2.6.37 kernel (the latest as I write). I recommend avoiding the use of an experimental NFS driver; it may result in poor performance, lost files, or other problems.

All Linux distributions' default kernels support NFS, although it's sometimes compiled as separate modules—nfs.o for the NFS client and nfsd.o for the NFS server. The appropriate module should load automatically when you try to mount a remote export or start the NFS server. Although the NFS support modules aren't hardware drivers, loading them is done using the same tools you use to load hardware driver modules. Some distributions ship with this support compiled into the main kernel file rather than as a module.

Linux's NFS implementation relies on several additional programs. These programs should be installed automatically with the NFS server. For the most part, these programs operate behind the scenes and require no special configuration, but you should be aware of their existence. Table 8.5 summarizes these programs. These programs relate to the Remote Procedure Call (RPC) mechanism, which is a method of enabling one computer to trigger the activation of a function on another computer. NFS relies on RPC, and so requires various RPC helper programs to be running.

TABLE 8.5 NFS's RPC support programs

Setting Basic Export Options

Linux uses the /etc/exports file to describe the directories that an NFS server exports. Lines in this file may be comments, which begin with hash marks (#), or they may be export definitions. Each export definition takes the following form:

/directory client(options) [client(options)[…]]

The /directory is the directory that's to be made available, such as /home or /opt/OpenOffice.org. Following the directory are one or more client specifications. You can list clients in any of several ways:

Hostnames You can provide a computer's hostname, such as services.luna.edu or services. If you omit the domain name, the server assumes you're referring to a computer in its own domain.

Wildcards If you want to export a directory to all the computers in a domain or to certain subsets of them, you might be able to use the asterisk (*) and question mark (?) wildcards. These features work much like their equivalents in shells when used to specify filenames. They don't match dots in hostnames, though. For instance, *.luna.edu matches central.luna.edu and services.luna.edu but not helpman.info.luna.edu.

IP Addresses You can specify a computer by IP address, as in 172.24.202.7. This method is harder for humans to interpret than hostnames, but it has a security advantage because it doesn't rely on a Domain Name System (DNS) server to convert the hostname to an IP address. If you use hostnames, an attacker could conceivably gain access to your NFS server by first taking over a DNS server.

Network Addresses You can specify a network by IP address range by providing the IP address, a slash, and a netmask. The netmask can be specified either in dotted-decimal form or as the number of bits in the network portion of the address. For instance, 172.24.0.0/255.255.0.0 and 172.24.0.0/16 are equivalent.

NIS Netgroups Although it's seldom used today, the Network Information System (NIS) enables you to specify an NIS netgroup by preceding its name with an at sign, as in @tranquility.

Following each client specification is a comma-separated list of options. Table 8.6 summarizes the most common of these options. You can find additional options in the exports man page.

TABLE 8.6 Common NFS export options

As an example of an NFS /etc/exports file, consider Listing 8.2. This file defines three exports—for /home, /opt, and /exports. The /home export is fairly straightforward. The clients of this export (helpman, kurtzmann, and ida) are defined using hostnames without domain names. All of these clients have read/write access to the share. All except kurtzmann must connect from a secure port, but kurtzmann is granted an exception to this rule. Perhaps kurtzmann is running a non-Unix OS that uses a high-numbered port for NFS access. The /opt export is made available to two clients, helpmann.luna.edu and ida.luna.edu. The first of these clients has full read/write access to the share, and root access from this client is not squashed. You might use this configuration if the client's administrator needs to be able to add software to the /opt export, but this configuration is risky—a security problem could allow a miscreant to change files in this potentially sensitive directory. Finally, the /exports directory is exported to all computers in the info.luna.edu domain (but not its subdomains) and to all computers in the 172.24.0.0/16 network. In the case of the info.luna.edu domain, all user accesses are squashed. In both cases, no client can write to the export.

/home helpman(rw) kurtzmann(rw,insecure) ida(rw)
/opt helpmann.luna.edu(rw,no_root_squash) ida.luna.edu(ro,nohide)
/exports *.info.luna.edu(ro,all_squash) 172.24.0.0/16(ro)

If you make changes to your /etc/exports file, you can tell the NFS server about those changes with the exportfs program. Specifically, type exportfs -r as root to update the server's list of available exports to match the exports file. You can also use this utility's -u option to make a specific export unavailable or use various other options to have other effects. The upcoming section “Adjusting a Running NFS Server” describes additional exportfs options.

Managing Exports on the Fly

It's frequently necessary to monitor the operation of an NFS server and to implement changes in the configuration without bringing the server down. Several tools exist for this purpose: exportfs, showmount, and nfsstat. The /proc/mounts file, described in Chapter 3, can also be useful in this regard.

Adjusting a Running NFS Server

In addition to /etc/exports, NFS enables nonpermanent changes to its exports via the exportfs command. Used without any options, exportfs displays a list of active NFS exports, similar to the contents of /etc/exports, but with one line per export (so if you list a directory as being exported to three systems or networks, three lines will appear in the exportfs output for that directory). Adding options enables you to modify your system's NFS exports. Table 8.7 summarizes the most important of these options. The man page for exportfs provides details on more obscure options.

TABLE 8.7 Common exportfs options

When using exportfs to add or delete exports, you specify a client and directory in the form client:/export/directory. You don't need to specify any of the options from Table 8.7 when exporting a new directory, but you must use the -u option to unexport a directory. For instance, suppose your NFS server is currently exporting /var/www to 192.168.23.0/24 as a means to enable local users to edit a Web server's files. You want to move this directory to /var/apache/webfiles. You could implement these changes by typing the following commands:

# exportfs -u 192.168.23.0/24:/var/www
# exportfs 192.168.23.0/24:/var/apache/webfiles

This change will be temporary, however; you should also edit /etc/exports. In fact, you might prefer to edit /etc/exports first and then type exportfs -r, thus implementing your changes.

Identifying Mounted Exports

A second tool for managing NFS is showmount, which displays information on current NFS activity. Used without options, this tool reveals the IP addresses of the computers that are currently using the server. Table 8.8 summarizes showmount's most common options.

TABLE 8.8 common showmount option

You can use showmount to display information on the server running on any computer, network firewall and other security options permitting. By default, the program displays information on the local computer's NFS server, but if you add a computer hostname, the result is information on that computer:

$ showmount -a central
All mount points on central:
172.24.21.5:/home
172.24.21.5:/home/jill/photos
192.168.1.4:/home
192.168.1.4:/home/tuttle

In this example, 172.24.21.5 is accessing /home/jill/photos (part of the /home export), and 192.168.1.4 is accessing /home/tuttle (also part of the /home export).

Measuring NFS Activity

The nfsstat utility provides statistics related to NFS and RPC client and server activity. Table 8.9 summarizes some important nfsstat options. It should be emphasized that nfsstat provides both client and server information, so you can use it from either side of an NFS connection, although of course the information provided on each side won't be identical.

TABLE 8.9 common nfsstat option

Much of nfsstat's output is cryptic, but you can glean some useful information from the entries you understand. For instance, columns labeled read, write, create, and mkdir specify bytes read and written and the number of files and directories created, respectively. The output of the -m (--mounts) option can be particularly useful on an NFS client, since you can learn how an export is mounted. This information can provide clues to problems, such as if a user can't create new files. (For instance, is the share mounted read-only?)

Checking on RPC Activity

The rpcinfo utility provides access to RPC data. This program can be useful for identifying what RPC-enabled servers are running on a computer or network. The most useful option is probably -p, which should include lines such as the following, which denote NFS versions 2 and 3 running on both TCP and UDP:

$ rpcinfo -p
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs

Additional output has been removed from this example output for brevity. Table 8.10 summarizes other rpcinfo options. Some of these are fairly obscure.

TABLE 8.10 Common rpcinfo options

Improving NFS Security

Most servers use passwords or some other authentication tool to control access to files. NFS works differently; an NFS server trusts the client system to control access to files. Once a directory is exported via NFS, any client computer that's authorized to access the directory in /etc/exports may do so in any way the /etc/exports definition permits. The idea is that the client computer will have a user base that's compatible with the user base on the server and that the client computer is trustworthy.

These assumptions weren't unreasonable when NFS was created, but in today's computing environment, they're a bit risky. Somebody with a notebook computer and wireless networking hardware may be able to access your server and masquerade as another computer if you use a wireless network. Even with a wired network, a compromised system or physical access can enable an attacker to pretend to be a trusted system. An attacker can control the user database on the attacking computer or use a custom NFS client program that doesn't play by the usual security rules, thus bypassing the intent of the NFS security scheme. Therefore, you should be cautious about NFS security. Don't add a computer to /etc/exports unless it's really necessary, and don't give clients read/write access unless they really need it. The no_root_squash option is particularly risky. You might also want to use IP addresses rather than hostnames to specify computers in /etc/exports; this practice makes masquerading as a trusted system a little more difficult.

An additional security precaution is to protect the port mapper or NFS server ports using firewall rules (as described in Chapter 7) or TCP Wrappers (as described in Chapter 10, “Security”). Either approach will prevent unauthorized computers from accessing the NFS server. (The same can and should be done with Samba and other servers, of course.)

Using Linux as an NFS Client

Linux's NFS client is, essentially, the Linux kernel itself. The kernel treats another computer's NFS export as a filesystem that can be mounted via the mount command or an entry in /etc/fstab. Chapter 3 describes these tools in detail. The rules for using NFS exports are similar to those for using regular filesystems on partitions, although some details differ. To mount an NFS export, you specify the nfs filesystem type. (Use nfs4 to force use of NFSv4, if both client and server support it.) In some cases, Linux can determine from context that you mean nfs, so you can sometimes omit this option. Instead of specifying a Linux device filename, you specify the host and export name. (For protection against a DNS server compromise or as a matter of preference, you can use an IP address rather than a hostname.) For instance, to mount /home from central.luna.edu at /mnt/morehome, you might type the following command:

# mount -t nfs central.luna.edu:/home /mnt/morehome

In the case of the preceding example, you can omit the -t nfs specification, and if your client is in luna.edu or is configured to search that domain via a search line in /etc/resolv.conf, you can specify the export as central:/home rather than central.luna.edu:/home. If you want to mount an export whenever the computer boots or give ordinary users the power to mount an export, you can do so by adding an entry to /etc/fstab. For instance, the following line mounts this export at boot time:

central.luna.edu:/home /mnt/morehome nfs defaults 0 0

You can add many standard mount options, as well; for instance, specifying an option of ro causes a read-only mount, even if the server has granted your system read/write access. (You cannot use rw to gain read/write access if the server gives you only read-only access, though.) There are also a few NFS-specific mount options. The most important of these may be hard and soft. Ordinarily or if you eplicitly specify hard, a program trying to access an NFS server will block (become unresponsive while waiting for input) if the server doesn't respond. When the server becomes available, the program will continue where it left off. If you specify soft, though, the kernel's NFS client will eventually time out and deliver an error message to the client. If your network or NFS server is flaky, you may prefer soft, because you'll be better able to kill processes that hang because of an inability to access NFS exports. If your network is functioning normally, though, hard is the preferred behavior, because specifying soft can cause occasional problems on a well-behaved network.

Another NFS-specific mount option you may want to use is proto=transport, where transport is either tcp or udp. (Alternatively, you may use tcp or udp as options, without the proto= part.) NFS was originally a UDP-based protocol, which works well on reliable local networks. Using TCP adds features that can improve reliability if the network is unreliable, but these features also add overhead you might prefer to avoid. You may want to experiment with both settings to see which works best on your network.

Once an export is mounted, all ordinary users can access that export, within limits imposed by file ownership and permissions. One potential caveat is that NFS uses user ID (UID) and group ID (GID) numbers in handling ownership and permissions. If users have accounts on both the client and the server computer, the users' UIDs and GIDs on those two systems must match, or the users won't be able to access their own files. A similar problem can arise if users have accounts on two or more clients that access the same server. Various workarounds have been deployed to fix this problem, some of which aren't current. Three approaches are best today:

Manually Synchronize Usernames On a small network with few users, you can manually maintain your accounts so that the same user has the same UID on all systems, and likewise for GID values. This approach becomes quite tedious on larger networks with many users, though.

Use an ID Mapper You can use the rpc.idmap server, described previously, which can automatically map usernames and UID values. This server must be run on both the NFS server and the NFS client.

Use a Central Login Server If you use LDAP or some other centralized login server, the problem can go away, since users managed by the login server will have the same UID values on all the network's computers.

Note that UID synchronization isn't required for fundamentally public read-only exports, such as exports of directories holding software or shared read-only templates, unless some users should be restricted from accessing these files. Also, if an NFS server holds home directories but users don't need to log into that computer directly, you don't need to synchronize UIDs and GIDs because the users don't need accounts on the server. (You do still need to synchronize UIDs and GIDs across multiple clients in this case, though.) If the server doesn't have accounts for its NFS users, be sure any directory to which users should be able to write has permissions to enable world writing, or at least writing by the appropriate group, which in this case must be mapped appropriately.

Configuring an FTP Server

FTP has long been a popular server. The protocol has some peculiarities, but every OS that has a serious TCP/IP stack has an FTP client. FTP is typically used in one or both of two ways:

• Users must authenticate themselves to the server by providing a username and password. They can then read, and often write, files to their home directory or to common areas on the computer.
• Users provide a username of anonymous and any password (conventionally their email addresses). They can then read, but usually not write, data stored in public directories. This anonymous FTP access is a popular means of delivering public files such as software upgrades, multimedia files, and so on.

Both configurations share many features, but certain details differ. How you set up an FTP server to use either system depends on the server you choose. Several such servers exist for Linux. The next section describes your choices and then covers two popular FTP servers, Pure-FTPd and vsftpd, in more detail.

Although anonymous access is often necessary on public FTP servers, it should be avoided if only authenticated users should have access to the server. Also, anonymous access is best restricted to downloads only; if a site enables anonymous uploads, then anybody on the Internet can upload files to your server, including illegal content. If others can anonymously retrieve those files, then your site can quickly become an unwitting hosting site for piracy.

If you really do need to enable anonymous uploads (say, to permit customers to submit files in support of bug reports), you can minimize the risks by giving the anonymous upload directory permissions of 733 (rwx-wx-wx) or 773 (rwxrwx-wx) and ownership by root. If you use 773 permissions, give group ownership to a group that contains users who should be able to read the directory, but ensure that the account used for anonymous access by the FTP server is not in this group! This configuration will enable anonymous users to upload files to this directory but not download files from it. If you use an existing directory, type chmod -R u-r /path/to/incoming/dir to ensure that no files within it can be read by random users before you put this configuration in place.

Selecting an FTP Server

FTP is an old protocol, and numerous implementations of it have sprung up over the years. These servers vary in many details; however, they all serve the same protocol, and they all look very much alike to their users. FTP server options for Linux include the following:

Pure-FTPd This server, headquartered at http://www.pureftpd.org, is an FTP server that emphasizes security. Many distributions ship with it, typically under the package name pure-ftpd.

vsftpd This server aims to excel at security, stability, and speed. In doing so, its developers have chosen to eschew some of the more advanced features of servers such as ProFTPd. If you don't need those features, this trade-off may be more than acceptable. You can learn more from its Web site, http://vsftpd.beasts.org. It's available with a growing number of Linux distributions, usually with the package name vsftpd.

ProFTPd This server, headquartered at http://proftpd.org, is one of the more popular of the very complex FTP servers. It ships with most major Linux distributions. Its configuration file is modeled after that of Apache, and the server supports many advanced features. It is accordingly much harder to configure.

Because FTP can potentially provide users with substantial access to the system—the ability to read or write any file, within limits imposed by Linux file ownership and permissions—FTP servers are unusually sensitive from a security point of view. As a result, the Web pages for many FTP servers emphasize their developers' attention to security. Most FTP servers provide explicit support for locking themselves in chroot jails, as described with reference to DNS servers in Chapter 6, “DNS Server Configuration.”

For a small FTP site, chances are any of the servers in the preceding list will work well. Because they both ship with multiple Linux distributions, the next two sections focus on Pure-FTPd and vsftpd.

Understanding FTP Basics

FTP is an old and quirky protocol, and it presents a couple of pitfalls that are unique to FTP. These are largely client-side problems, so users should be aware of them; however, if you configure a firewall, as described in Chapter 7, you may need to take the first of these issues into account.

The first FTP quirk is in the way it manages ports. Two ports (TCP ports 20 and 21) are registered to FTP. Port 20 is the data port, which is used for data transfers; and port 21 is the command port, which is used for issuing commands. The big problem with this configuration is that in the conventional FTP active mode, the client initiates the connection to the command port, and then the server initiates a reverse connection to the client from the server's command port. This server-to-client connection is blocked by some firewalls, so FTP often fails on firewalls that aren't explicitly configured to permit this connection. A client-side workaround to this problem is to use FTP passive mode (by typing passive in the ftp program or by selecting equivalent options in GUI or other FTP clients). In passive mode, the FTP client initiates both connections, which overcomes the problem of firewalls that block all incoming connections. Passive mode uses an unprivileged port on the server for its data transfers, though, which can sometimes run afoul of firewalls. Thus, you may need to try both active and passive modes to determine which one works best. You should check your FTP client's documentation to learn which mode it uses by default.

The second FTP quirk relates to transfer mode. FTP clients often default to ASCII (plain-text) transfer mode, in which the files are transferred in such a way as to dynamically alter the character encoding to account for the different ways that different OSs store plain-text files. (Linux/Unix, Windows, and the original Mac OS all used different line-ending conventions, and some even more exotic systems use non-ASCII encoding methods.) Using ASCII mode works well for plain-text files, but this mode will almost always corrupt binary files, such as tarballs, graphics files, word processing documents, and so on. You can use the ascii and binary options in ftp, or similar options in other FTP clients, to set the transfer mode. If in doubt, use binary mode; most text editors today can handle any of the common line-ending types, so retrieving a text file in the wrong format will cause minimal or no problems. Some Linux configuration files must use Unix-style line endings, though, so you may need to pay attention to this detail if you transfer such files.

You should also be aware of the way in which the FTP server launches. Some FTP servers favor being launched via SysV, Upstart, or local startup scripts; but others work better when launched via a super server, such as inetd or xinetd. Chances are your distribution's package includes the necessary startup scripts and configuration files, but you may need to reconfigure your system to launch the server in your runlevel. (Sometimes the default configuration is to not launch the server, as a safety measure in case it's installed accidentally.)

Configuring Pure-FTPd

The Pure-FTPd server is designed to be controlled mostly through command-line arguments rather than a configuration file. Thus, if you want to adjust its main options, you must track down the distribution-specific file in which these options are stored and modify it. For instance, in Ubuntu you can edit /etc/default/pure-ftpd-common and files in /etc/pure-ftpd/conf, in Fedora you can edit /etc/pure-ftpd/pure-ftpd.conf, and in Gentoo you can edit /etc/conf.d/pure-ftpd. Table 8.11 summarizes the most important Pure-FTPd options; however, many more are available—consult the server's man page for details.

TABLE 8.11 Common pure-ftpd options

When used for anonymous access, Pure-FTPd requires that the computer have an account called ftp, and it enables anonymous users to download from and (if so configured via command-line options) upload to the anonymous directory. Scripts included with the pure-ftpd package might or might not set up the necessary account and home directory, so you should check for their presence. Also, some distributions' Pure-FTPd packages disallow anonymous access by default; thus, you may need to track down your distribution-specific configuration files and modify them appropriately. Because Pure-FTPd has no standard configuration file, the details of this task will vary greatly from one distribution to another.

Configuring vsftpd

A second FTP server that's popular on modern Linux systems is vsftpd. Ordinarily, vsftpd is run from a super server; however, it can be run from a SysV or local startup script if you prefer. The vsftpd configuration file is /etc/vsftpd.conf or /etc/vsftpd/vsftpd.conf. This file contains comment lines, which begin with hash marks (#), and directive lines that take this form:

option=value

There must be no stray spaces surrounding the equal sign in vsftpd directives. Table 8.12 summarizes some of the most important vsftpd directives. This table doesn't cover all of the available directives; check the man page for vsftpd.conf for information on additional directives.

TABLE 8.12 important vsftpd.conf directives

The default vsftpd configuration file often supports both authenticated local user logins and anonymous logins. Typically, vsftpd performs a chroot for anonymous users, but it does not do so for authenticated local users. If you want to verify or change these features, check the configuration file for the following lines, and change them as necessary:

anonymous_enable=YES
local_enable=YES

You can also change additional options related to these, such as the location of the anonymous root directory (anon_root) and whether to chroot into authenticated users' home directories when they log in (chroot_local_user).

Summary

File servers are a critical component of many networks, and Linux supports a wide variety of software to handle this task. This chapter describes servers used to handle three specific protocols. The Samba server handles the SMB/CIFS protocol, which is the dominant file-sharing protocol on Windows networks. Samba has to “translate” certain features to make Windows clients happy, and it does this job very well. To satisfy Linux and Unix clients, Samba adds more features, but for these clients, the NFS protocol is generally a better choice. Unlike Samba, NFS can present a more truthful view of the underlying filesystem to its clients, which streamlines and simplifies the file-sharing process. The final protocol described in this chapter is FTP, which is intended for use by dedicated client programs, rather than OSs that treat the server as if it were a filesystem to be mounted. Quite a few FTP servers are available for Linux, but this chapter covers just two of the most popular ones, Pure-FTPd and vsftpd. Both servers provide a variety of options to enable logins by username and password or for anonymous users. Because FTP is often used to deliver files on the Internet at large (as opposed to the local use that's more common for SMB/CIFS and NFS), FTP security is particularly important, and you should be sure to configure your FTP server in as secure a manner as possible.

Exam Essentials

Explain the difference between user- and share-level security in Samba. Share-level security emulates the old Windows 9x/Me security model, in which passwords are associated with shares rather than accounts. User-level security employs a security model similar to that of Linux, in which accounts have passwords and clients must send a username to the server, along with the password.

Describe the two major Samba daemons. The nmbd daemon handles name resolution and similar background and support tasks for a Samba server. The smbd daemon handles the bulk of the Samba file- and printer-sharing work. Both daemons are necessary for a fully functional Samba installation.

Summarize two methods of using a Linux computer as an SMB/CIFS client. The smbclient program connects to an SMB/CIFS server and presents a user interface similar to that of the text-mode ftp program. Users can transfer files, delete files, rename files, and so on. The Linux mount command, in conjunction with suitable kernel filesystem support and helper programs, enables the system administrator (or users, if appropriate /etc/fstab entries exist) to mount SMB/CIFS shares as if they were local filesystems. Users can then do anything they could do with files stored on a local filesystem, using normal file-maintenance tools (cp, mv, and so on) or applications.

Describe the smb.conf file's structure. Samba's configuration file, smb.conf, is broken into sections, each of which begins with a name in square brackets. The [global] section sets global options, and most subsequent sections set options for a single file or printer share. (The [homes] and [printers] share definitions both create multiple shares based on all users and all printers, respectively.) Within each section, options take the form option=Value, where option is an option name and Value is its value. All options and most values are case-insensitive.

Describe the /etc/exports file structure. The NFS server's main configuration file, /etc/exports, consists of a series of lines, one per export. Each line begins with the directory that's to be exported and begins with a series of space-delimited server or server group definitions. Each of these definitions consists of a hostname, network name, IP address, or IP address range followed by a series of options in parentheses. These options are comma-separated.

Explain why proper access restrictions are so important for NFS. Unlike many servers, NFS requires no password to gain entry. Thus, an NFS server that does not restrict access based on IP addresses can be easily invaded by anybody with physical access to the local network (or by anybody on the Internet, if the server is exposed to it). For this reason, specifying clients in a limited way in /etc/exports is very important for NFS.

Summarize how NFS exports may be modified without restarting the server. The exportfs command can modify an NFS server's exports on the fly, enabling changes without modifying /etc/exports or restarting the server. The -o option enables you to set new options using the same format as the entries in /etc/exports; -u unexports a single directory; -r re-implements the /etc/exports file; and so on.

Describe how NFS exports may be mounted on a client. NFS clients use the mount command or /etc/fstab entries much as they would for local filesystems. You should use the filesystem type code of nfs (or nfs4 for NFSv4 servers), and instead of a device filename, you specify the server and export in the form server:/export.

Explain the difference between active and passive FTP. FTP traditionally employs active mode, in which the client initiates a connection with the server and the server then implements a reverse connection with the client. This unusual connection approach causes problems with some firewalls. In FTP passive mode, the client initiates two separate connections with the server, which works better with some firewalls. (Some clients now use passive mode by default.)

Name some of the popular FTP servers for Linux. The Pure-FTPd and vsftpd servers both provide full-featured FTP server features but are configured in very different ways from one another. The ProFTPd server is another popular FTP server for Linux. It provides extra functionality but is much harder to configure.

Review Questions

1. A Samba server (dance) includes a [homes] share definition but no [sammy] share definition. Assuming the relevant account exists, what will then happen when the user sammy on a client attempts to access \dancesammy?

   A. An error message will appear because the [sammy] share doesn't exist.

   B. If the user enters the correct password, he'll be given access to the /home directory on the server.

   C. The user will be given access to the /tmp directory whether or not a correct password is entered.

   D. If the user enters the correct password, he'll be given access to his home directory's files on the server.

2. You're configuring a Samba server to participate in an existing Windows domain that's managed by a Windows 7 domain controller. You want users to be able to authenticate using the Windows controller's account database. How would you set the security option in smb.conf to achieve this result? (Choose all that apply.)

   A. security = User

   B. security = Server

   C. security = Domain

   D. security = ADS

3. What does the following line in an smb.conf file mean?

   name resolve order = lmhosts

   A. Samba uses the lmhosts file preferentially for name resolution but will use other methods if necessary.

   B. Samba uses the lmhosts file exclusively for name resolution and does not fall back on other methods.

   C. Samba uses the lmhosts file as source material when it functions as a NetBIOS name server.

   D. Samba uses the lmhosts file's contents to determine the priority given to different clients' name-resolution requests.

4. What is wrong with the following Samba share definition?

   [themes]
   comment: Themes for all users
   writable: 0
   path: /usr/share/themes
   public: 1

   A. Lines within a share definition require an equal sign (=), not a colon (:), to separate the option from the value.

   B. Lines following the share definition line must be indented at least one space.

   C. The Boolean options (writable and public) require No or Yes values, not 0 or 1 values.

   D. Nothing is wrong with it.

5. Which of the following things can you do when you access a file on an SMB/CIFS share using mount that you can't do when accessing it via smbclient?

   A. Delete the file from the server.

   B. Use Emacs to edit the file while it's on the server.

   C. Copy the file from the server to the client.

   D. Rename the file while it's on the server.

6. You want to add a Samba server to an existing Windows network, on which users are used to using their full names, including spaces, as usernames. What file would you edit to enable users to continue using those usernames, while converting them to more conventional and shorter Linux usernames?

   A. The file pointed to by the username map option in smb.conf

   B. The /etc/samba/username.map file

   C. The file pointed to by the smb passwd file option in smb.conf

   D. The /etc/samba/smbpasswd file

7. How can you verify that your smb.conf file contains no serious syntax errors before launching a Samba server?

   A. Type check-samba.

   B. Type smbchkconfig.

   C. Type smbd --check smb.conf.

   D. Type testparm.

8. What does it mean when a Samba server's security option is set to Share?

   A. Samba attempts to emulate Windows 9x/Me-style authentication.

   B. Samba enables access to files and printers, rather than being offline.

   C. Samba uses SMB/CIFS style file-sharing rather than the Export style used by NFS.

   D. Samba functions as both a client and a server on the network.

9. How does an NFS server determine who may access files it's exporting?

   A. It uses the local file ownership and permission in conjunction with the client's user authentication and a list of trusted client computers.

   B. It uses a password that's sent in unencrypted form across the network.

   C. It uses a password that's sent in encrypted form across the network.

   D. It uses the contents of individual users' .rlogin files to determine which client computers may access a share.

10. You want to export the /home directory to two computers via NFS: remington should have full read/write access, while gentle should have read-only access. How would you configure this in /etc/exports?

    A. remington(/home,rw) gentle(/home,ro)

    B. [homes] remington(readwrite) gentle(readonly)

    C. /home remington(rw) gentle(ro)

    D. remington(/home,readwrite) gentle(/home,readonly)

11. You want to temporarily export the /mnt/cdrom directory using NFS so that reader.example.org may read but not write the export. Assuming an NFS server is already running, what would you type at a shell prompt to accomplish this goal?

    A. exports -o ro reader.example.org:/mnt/cdrom

    B. showmount -o ro reader.example.org:/mnt/cdrom

    C. exportfs -o ro reader.example.org:/mnt/cdrom

    D. mount -o ro reader.example.org:/mnt/cdrom

12. In what way is Linux's most popular NFS server unusual, compared to most other Linux servers?

    A. The Linux NFS server requires execute permissions to be present on all served files.

    B. The Linux NFS server cannot serve Windows or Mac OS X clients.

    C. The Linux NFS server includes a kernel-based component.

    D. The Linux NFS server must be run from a super server such as inetd or xinetd.

13. What is the function of the portmapper with respect to NFS?

    A. It listens to the NFS port and hands off connections to the NFS server.

    B. It creates a map of NFS clients to help the server optimize its speed.

    C. It tells clients on which port the NFS server is running.

    D. It maintains information on local filesystems and their relationship to NFS exports.

14. What is wrong with the following /etc/fstab entry to mount an NFS export?

    //central/jill /mnt/jill nfs users 0 0

    A. It uses an SMB/CIFS-style, not NFS-style, server/export description.

    B. The users option is not valid with an NFS entry in /etc/fstab.

    C. An NFS server should not be exporting /jill, but /home/jill.

    D. The dump code for an NFS mount should be 1, not 0.

15. Why should you use the no_root_squash option with caution on NFS exports?

    A. This option gives root on client systems root privileges within exported directories on the server, which is dangerous if the client is compromised.

    B. This option causes the NFS server to run outside of its chroot jail, which gives it access to user and system files it should not be able to access.

    C. This option gives root full shell login privileges on the server without going through a regular account, thus making it easier for an intruder who lacks a user password.

    D. This option enables ordinary users to log into the NFS server as root, which can quickly lead to security compromises if your users are untrustworthy.

16. You know that the computer hereville has an NFS export you want to use, but you can't recall its name. How can you discover this information?

    A. smbclient //hereville

    B. showmount -e hereville

    C. nfsclient --show hereville

    D. nfsstat --server hereville

17. What configuration file should you edit to enable anonymous access to a Pure-FTPd server?

    A. /etc/pure-ftpd/conf/NoAnonymous

    B. /etc/pure-ftpd/pure-ftpd.conf

    C. /etc/conf.d/pure-ftpd

    D. More information is required to answer this question.

18. What vsftpd.conf option would you set to allow anonymous users to access the FTP server?

    A. anon=YES

    B. anonymous_enable=YES

    C. anonymous=YES

    D. noanonymous=NO

19. Which is the best way to launch an FTP server?

    A. From a SysV startup script.

    B. From a super server.

    C. From a local startup script.

    D. It's impossible to say without more information.

20. A small network is protected by a very strict firewall. This firewall prevents all outside systems from initiating connections to any computer inside the firewall; only connections initiated from within the local network are permitted. How will this firewall impact users on the local network who need to download files from external FTP sites?

    A. The users will have to use ASCII FTP transfers.

    B. The users will have to use binary FTP transfers.

    C. The users will have to use passive FTP transfers.

    D. The users will have to use active FTP transfers.

Answers to Review Questions

1. D. The [homes] share in Samba is special; it gives access to users' home directories, with each user being given access to his or her own home directory, as option D describes. Option A is incorrect because the point of the [homes] share is to enable access to home directories without having to explicitly define a new share for each user. Option B is incorrect because the [homes] share gives access to users' individual home directories, not to the Linux /home directory, which is typically the directory in which all users' home directories reside. Option C is incorrect because a correct password is still normally required to access [homes] and because this share doesn't give access to /tmp unless options are set strangely. (The default directory for most Samba shares is /tmp, but this isn't true of [homes].)
2. B, C, D. The Server setting tells Samba to authenticate against the domain controller without fully joining the domain. The Domain setting tells Samba to fully join the domain using Windows NT 4 protocols. The ADS setting tells Samba to fully join the domain using Active Directory (AD) protocols. Any of these options will work, if properly configured. The User setting tells Samba to use its local account database, so this setting won't do as the question specifies.
3. B. The name resolve order option in Samba determines what tools Samba uses to resolve hostnames into IP addresses. Since only one option (lmhosts) appears in this example, this is the only tool that's used, as stated by option B. Option A is incorrect because no other methods will be used. Options C and D are incorrect because the name resolve order option controls Samba's own name resolution, not how it functions as a NetBIOS name server or how it delivers names to clients.
4. A. As specified in option A, Samba's smb.conf file separates options from values with an equal sign (=), not a colon (:). Option B is incorrect because, although the lines containing a share's option/value pairs are often indented, this is not a requirement. Option C is incorrect because 0, No, and False are all synonymous in Boolean options, as are 1, Yes, and True.
5. B. The single most important ability that mounting an SMB/CIFS share gives you, compared to accessing it with the ftp-like smbclient, is that mounting the share enables ordinary programs to treat the file as if it were a local file. Emacs, being an ordinary program, can therefore edit the file on the SMB/CIFS server, as option B describes. Options A, C, and D are all things that can be done using both smbclient and normal file-manipulation tools on a mounted file share.
6. A. The username map option in smb.conf specifies where a mapping of Windows to Linux usernames can be found, so option A is correct. Although /etc/samba/username.map is a common filename to specify via the username map option, it's not the only possibility, so option B is incorrect. The smb passwd file option tells Samba where to find its user password file, but this file doesn't include mapping of Windows to Linux usernames, so option C is incorrect. A common name for the Samba password file is /etc/samba/smbpasswd, but this filename does not conventionally hold mappings of Windows to Linux usernames, so option D is incorrect.
7. D. The testparm program checks your smb.conf file for various simple types of errors. (It cannot check for all errors, though.) Thus, option D is correct. The check-samba and smbchkconfig programs are fictitious, so options A and B are incorrect. The smbd program is one of the major Samba server programs, but it has no --check option, so option C is incorrect.
8. A. Share-level security refers to the authentication method used: Samba emulates, as best it can, Windows 9x/Me-style authentication, in which passwords are associated with shares rather than users. Thus, option A is correct. Although various Samba options can temporarily disable file and printer access, that is not true of security = Share, so option B is incorrect. The terms share and export have similar meanings but are used in reference to SMB/CIFS and NFS, respectively; but Export is not a valid value for Samba's security parameter, so option C is incorrect. Samba is fundamentally a server, although the Linux kernel and some ancillary Samba programs (such as smbclient) can function as clients. The security option in smb.conf doesn't directly affect the status of the computer as an SMB/CIFS client, though, so option D is incorrect.
9. A. NFS uses a “trusted host” policy to let clients police their own users, including access to the NFS server's files, which is what option A describes. NFS does not use a password, so options B and C are incorrect; nor does it use the .rlogin file in users' home directories, so option D is incorrect.
10. C. Option C presents the correct syntax for achieving the specified goal in /etc/exports. Options A and D incorrectly place the exported directory name in the option list for each client. Option B uses [homes] (a Samba name for users' home directories) rather than /homes. Options B and D incorrectly expand the ro and rw codes into readonly and readwrite.
11. C. The exportfs program controls the NFS server; it adds or removes directories and clients from the list the server maintains, thus temporarily extending or restricting the list that's normally maintained in /etc/exports. Option C presents the correct syntax for this program to achieve the stated goal. There is no standard exports command, so option A is incorrect. Option B's showmount command displays information on the clients that are using the server, but it doesn't change the export list. The mount command mounts a remote export; it doesn't affect what's exported, so option D is incorrect.
12. C. Linux's kernel-based NFS server features help improve its performance. Most other servers do not include such kernel-based help, so option C is correct. Option A describes a fictitious requirement of the NFS server. Although few Windows computers have NFS clients, NFS clients for Windows are available; and OS X includes an NFS client. Thus, option B is incorrect. Contrary to option D, Linux's NFS server is run directly, not from a super server.
13. C. Option C correctly summarizes the role of the portmapper. Option A describes the function of a super server, such as inetd or xinetd, except that super servers aren't commonly used with NFS servers. Options B and D are made-up descriptions of solutions to nonexistent problems.
14. A. The correct form for an NFS export definition in /etc/fstab is server:/share, so this entry should probably begin central:/jill or central:/home/jill. The entry instead uses the SMB/CIFS-style share definition, as option A states. Contrary to option B, the users option is perfectly valid for NFS entries in /etc/fstab. Although exporting a directory called /jill is indeed unusual, it is not illegal, and because a more serious problem is correct in the form of option A, option C is incorrect. The dump utility is used for backing up local ext2, ext3, and ext4 filesystems, not NFS exports, so the dump code should be 0 on NFS entries in /etc/fstab, contrary to option D.
15. A. The no_root_squash option does as option A specifies, which is useful if a client needs access to restricted files on the server, but it also poses the risk specified in option A. The no_root_squash option has nothing to do with chroot jails, so option B is incorrect. Option C describes a Secure Shell (SSH) login option and its risks, but because NFS does not provide login shell access or use passwords, it is an incorrect answer to this question. NFS doesn't allow users to “log into” a server in the sense suggested by option D, making that option incorrect.
16. B. The showmount utility displays information about the server you specify. Details vary with the options you pass it, but -e produces a list of the server's exports, making option B correct. The smbclient program is used for accessing SMB/CIFS servers, not NFS servers, and option A's syntax is incorrect even for discovering SMB/CIFS shares. The nfsclient program is fictitious. The nfsstat program displays statistics related to NFS use, and although option D is a valid command for producing such information, it won't display information on available exports on the server, as the question requires.
17. D. Pure-FTPd has no standard configuration file; instead, it relies on command-line arguments to change its behavior. Unfortunately, different distributions handle passing these arguments to the server in different ways, so you need to know the distribution to answer the question, making option D correct. Options A, B, and C are each correct, but only for specific distributions: Ubuntu, Fedora, and Gentoo.
18. B. Option B is correct. Options A and C are fictitious; neither anon nor anonymous is a valid vsftpd.conf option. Option D is also not a valid vsftpd.conf option, but passing --noanonymous to the pure-ftpd server is one way to disable anonymous access with that server.
19. D. FTP server programs vary in design; some are intended to be run from a local or SysV startup script, others are intended to be run from super servers, and others can be launched in either way. The needs of the site must also be considered; for instance, a lightly used FTP server might best be launched from a super server, whereas an FTP server that's in constant use might better be launched from a startup script. Thus, option D is correct. Because there is no single best way, options A, B, and C are all incorrect answers.
20. C. Passive FTP transfers involve the FTP client initiating two connections to the FTP server, which should not run afoul of the firewall configuration described in the question, so option C is correct. The alternative to passive FTP transfers is active FTP transfers, in which the client initiates one connection to the server and the server then initiates a return connection to the client. Since the firewall blocks incoming connections, an active FTP transfer will be blocked by the described firewall, making option D incorrect. The issue of ASCII vs. binary transfers is independent of the issue of passive vs. active transfers and is irrelevant to firewall configuration, so options A and B are both incorrect.