Network File-Sharing Services


Besides making files available to users logged in locally, often you also need to make files and directories transparently available to other servers or to remote workstations. And these other servers and workstations may or may not be running Linux. To make this file sharing possible, SLES supports both the Network File System (NFS) and Samba network file-sharing protocols.

NFS is a protocol originally developed by Sun Microsystems in 1984 and defined in RFC 3530, as a Unix-based file system that allows a computer to access files over an IP network as easily as if they were on its local disks. NFS is available for a wide range of computer hardware running different operating systems to share files and disk storage. At around the same time, the Server Message Block (SMB) protocol was created by Dr. Barry Feigenbaum at IBM Corporation. It was later extended and used by IBM, 3Com, Intel, and Microsoft as the communications protocol for network file sharing between DOS, Windows, and OS/2 operating systems. Today, Microsoft Windows uses SMB, better known as the Common Internet File System (CIFS), which utilizes NetBEUI (NetBIOS Enhanced User Interface) over TCP, as the standard network file sharing mechanism. Like NFS, a number of CIFS implementations are available for a wide variety of operating systems, including NetWare. Samba is an open source implementation of CIFS that runs on Unix/Linux platforms but speaks to Windows clients like a native. It allows a Unix/Linux system to move into a Windows "Network Neighborhood" without causing a stir. Windows users can happily access file and print services without knowing or caring that a Unix/Linux host instead of a Windows server is offering those services. In short, NFS and Samba are two different methods in which you can share your server's disk storage with other systems over the network. The choice of which package to use depends on your network environment. If you have Windows workstations and servers, Samba would be a good choice. Or if you mostly have Unix/Linux-based systems, NFS would be a good option.

As mentioned at the beginning of this chapter, because of the complexity of NFS and Samba, rather than delving into the details, we simply supply the bare essentials you need to quickly set up a simple NFS server and Samba server. You can learn more about each of these protocols from other published documents, such as

  • RFC 3530: Network File System (NFS) version 4 Protocol

  • RFC 2624: NFS Version 4 Design Considerations

  • RFC 2224: NFS URL Scheme

  • NFS Illustrated (ISBN 0201325705)

  • The Definitive Guide to Samba 3 (ISBN 1590592778)

  • The Official Samba-3 HOWTO and Reference Guide (ISBN 0131453556)

Setting Up an NFS Server

A computer can be both an NFS server and an NFS client. Here, we concentrate on the NFS server aspect where your SLES server will make available (export) its files and directories over the network (via port 2049) to NFS clients.

The NFS daemon is integrated into the SLES kernel, so no installation is required; all you need to do is configure and then activate it. The main functionality is handled by the nfsd.o kernel module, and /usr/sbin/rpc.nfsd is the user-space application that is treated as a "filesystem" and initiates the NFS server process; the /usr/sbin/rpc.mountd application is used for NFS client operations.

TIP

There are two quick ways to check whether the NFS server is active. First, you can use the ps command:

 Athena:/home/Admin # ps aux |grep nfsd root   7680  0.0  0.0     0    0 ?      S   10:48  0:00 [nfsd] root   7681  0.0  0.0     0    0 ?      S   10:48  0:00 [nfsd] root   7682  0.0  0.0     0    0 ?      S   10:48  0:00 [nfsd] root   7683  0.0  0.0     0    0 ?      S   10:48  0:00 [nfsd] root   7684  0.0  0.0     0    0 ?      S   10:48  0:00 [nfsd] root   7706  0.0  0.1  2588  692 pts/3  R+  10:49  0:00 grep nfs 

If the NFS server is running, you will see a number of [nfsd] processes. Another method is to use the lsmod command, which shows what kernel modules are currently loaded in a user-friendly format:

 Athena:/home/Admin # lsmod | grep nfsd nfsd                  106184  5 exportfs               10368  1 nfsd 

The first column shows the name of the modules, followed by the size of the module (in bytes), followed by a number that indicates how many instances of that module are currently active; if the number is zero, that means the service is not active.


NOTE

Under the NFS protocol, only one user at a time has write access to a file, and this access is controlled by the NFS file-locking daemon (/usr/sbin/rpc.lockd).


All NFS server configuration information is stored in /etc/exports. This file contains an entry for every directory that you intend to share with NFS client machines. Each entry defines how the directory is shared.

The general form of an exports entry is

 directory_name [host_1[(option_list)]] [host_2[(option_list)]] ... 

where directory_name is the directory that you want to export, host_x indicates a machine (using IP address, DNS name, or network name, such as *.UniversalExport.ca) that can mount the exported directory, and option_list is a comma-separated list of option keywords.

WARNING

If no options are given, the default export is read-write to all hosts. If no hostname is provided, it means any machine can mount this exported directory. Consequently, you should never export a directory without specifying at least one option in the option_list.


The following is an example of an /etc/exports file:

 # A sample /etc/exports file /          hermes(ro,root_squash) castor(ro,root_squash) /home      *.UniversalExport.ca(rw,no_root_squash) /var/ftp   (ro,all_squash) #end of /etc/exports file 

In this example, the first entry exports the entire filesystem to servers Hermes and Castor, where it will be read-only, and the root users on Hermes and Castor do not have root privileges on this exported filesystem. The second line exports /home to all hosts in the UniversalExport.ca domain where users have read-write access to their home directories, and the root users on these hosts have root privileges on this exported path. The last entry exports /var/ftp (the default anonymous FTP directory used by vsftpd) as read-only to the world and executes all requests under the nobody account.

After you have modified the /etc/exports file, you can start or restart the NFS server by using the /etc/init.d/nfsserver start or /etc/init.d/nfsserver restart command. You can also use /usr/sbin/rcnfsserver instead of /etc/init.d/nfsserver. To configure the NFS server to start automatically on server boot, you need to enable two system init scripts for it to work:

 Athena:/home/admin # /sbin/insserv /etc/init.d/nfsserver Athena:/home/admin # /sbin/insserv /etc/init.d/portmap 

The portmapper, which uses TCP/UDP port 111, is an essential component of Remote Procedure Call (RPC) services, and NFS makes use of RPC. This is why you need to ensure the portmapper process is also started when the server boots. However, you do not have to create a link for /etc/init.d/nfslock (for the NFS file-locking daemon) because it is started automatically by nfsserver.

NOTE

The nfsserver start script looks in /etc/sysconfig/nfs for a variable called USE_KERNEL_NFSD_NUMBER, which is used to determine how many server threads should be started for rpc.nfsd. The default value is 4.


You can also configure the NFS server using YaST. From the YaST Control Center, select Network Services, NFS Server; or from a terminal prompt, use yast2 nfs-server (or yast nfs-server). When using YaST, you don't need to use insserv to set up the startup scripts. You can simply select Start NFS Server from the Configuration of the NFS Server dialog box, and use the Directories to Export to the Others dialog box (see Figure 8.7) to set up the /etc/exports file.

Figure 8.7. Setting up directory exports.


TIP

Sometimes you may need to temporarily export a directory. You can easily do so using /usr/sbin/exportfs without having to modify /etc/exports. The syntax for exportfs is

 exportfs -o option_list host:/directory_name 

where option_list is a list of export options and host is the remote system. Both are specified in the same manner as /etc/exports. To restore the original export state, use exportfs -r. See man exportfs for more details.


You can easily check to see whether rpc.nfsd and its associated modules are running by using the rpcinfo -p command. The NFS server registers with the portmapper as nfs while the NFS client shows up as mountd; there may be multiple nfs entries corresponding to the number of NFS server threads. In addition, you can also check to see which NFS client systems have mounted your exported directories by using the showmount -a command.

Setting Up a Samba Server

Samba is software package that allows a host to interact with a Microsoft Windows client or server as if it were a Windows file and print server. The Samba package runs on a wide range of operating systemsfor example, Linux/Unix, IBM System 390, and OpenVMS. Samba implements Microsoft's Server Message Block (SMB), which is now referred to as Common Internet File System (CIFS), networking protocol. Among the features offered by SMB/CIFS is network file sharing, in much the same way as NFS discussed previously, by means of SMB shares, which are covered here. Other Samba features such as Samba authentication services are discussed later in this chapter; a discussion of Samba print services can be found in Chapter 9, "Printing Services."

NOTE

At the time of this writing, Samba 4 is in the development stages and hasn't yet had an initial release. SLES 9 ships with Samba 3, the current stable version. Samba 2.2 was declared end-of-life as of October 1, 2004.

You can find the latest version of Samba at http://www.samba.org/samba/download.


A Samba server uses the SMB protocol to share its files and directories with clients using TCP/UPD ports 137 through 139 inclusive. The exported directory is called a share and is identified by a share name, and Samba clients use this name to access the resource. The share name doesn't have to be the same as the directory name; this allows you to use more descriptive names for the exported directories, which makes it easier for users to find them. To access a share from a Samba client, simply use the Unique Naming Convention (UNC) notation: //server_name/share_name.

To set up a basic Samba file server, ensure the samba and yast2-samba-server packages are installed on your server. You need to install yast2-samba-server only if you want to manage your Samba server via YaST. However, you should install samba-doc for online documentation. Other Samba-related packages, such as samba-client and libsmbclient, are available, but they are not required to run a Samba server.

The Samba server consists of three daemons: nmbd, which handles all NetBIOS-related tasks; smbd, which provides file and print services; and winbindd, which resolves user and group information from NT/ADS domains. All of Samba's configuration data is stored in the /etc/samba/smb.conf file. You can either edit this file yourself or do it using YaST or one of the many graphical tools available, such as the web-based interface SWAT (Samba Web Administration Tool) that is included with Samba.

The smb.conf file uses the same syntax as the Windows .INI files. This file consists of sections, which begin with the section name within brackets ([]) on a new line. Each section contains zero or more key/value pairs separated by an equal sign (=).

Although each section in smb.conf represents a user-defined share on the Samba server, you should be aware of three special sections that are predefined:

  • [global] This section contains settings that apply to the whole Samba server, and not to one share in particular.

  • [homes] If this optional section is included in the configuration file, services connecting clients to their home directories can be created on the fly by the server.

  • [printers] This section works like [homes], but for printers. If a [printers] section exists in the configuration file, users are able to connect to any printer specified in the local host's printcap file.

Shown in Listing 8.3 is a minimal smb.conf example.

Listing 8.3. A Minimal Sample smb.conf File
 [global] workgroup = TUX-NET netbios name = MySambaServer ;The following is the default security setting #security = user [junk] path = /tmp [docs] path = /usr/share/doc #read only defaults to yes so no real need to set it read only = yes comment = on-line documentation 

In Listing 8.3, the default security setting in [global] tells Samba to use /etc/passwd and /etc/samba/smbpasswd when validating user passwords. If you have a Windows domain controller or a Windows Active Directory realm set up, you can use them to validate usernames and passwords instead by setting security = domain or security = ads. If you set security = share, no password is required when a client initially connects to the Samba server; however, a password may be necessary when the client tries to access a share.

THE /ETC/SAMBA/SMBPASSWD FILE

/etc/samba/smbpasswd is the Samba password file. It contains the username, Unix/Linux user ID, and the hashed passwords of the user, as well as account flag information and the time the password was last changed.

The format of the smbpasswd file used by Samba 2.2 and 3 is similar to the /etc/passwd file. It is an ASCII file containing one line for each user. Each field within each line is separated from the next by a colon. Any entry beginning with # is ignored. The following is a sample smbpasswd record:

[View full width]

testuser:6002:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: [DU ]:LCT-00000000:

The first field contains the username; this name must already exist in the /etc/passwd file. The second field holds the UID of the user, which must match the UID for the same user entry in /etc/passwd. The third field is the LAN Manager (LANMAN) hash of the user's password, encoded as 32 hexadecimal digits. This is the same password used by Windows 9x systems. If this field's value is equal to 32 X characters, then the user's account is considered disabled and will not be able to log in to the Samba server. The fourth field is also a password field. It contains the Windows NT/2000/XP hash of the user's password. Similar to the LANMAN password hash, if the NT hash value is equal to 32 X characters, then the user's account is considered disabled and will not be able to log in to the Samba server.

The second-to-last field contains account information. The field is bracketed by [ and ] characters and is always 13 characters in length, including the open and close bracket characters. The contents of this field may be one or more of the following characters:

  • U means this is a "User" account, that is, an ordinary user. Only User and Workstation Trust accounts are currently supported in the smbpasswd file.

  • N means the account has no password (the passwords in the fields LANMAN Password Hash and NT Password Hash are ignored). Note that this will allow users to log on with no password only if null passwords = yes is set in the smb.conf file.

  • D means the account is disabled and no SMB/CIFS logins will be allowed for this user.

  • W means this account is a "Workstation Trust" account. This kind of account allows Windows workstations and servers to join a domain hosted by a Samba PDC.

The last field holds the time the account was last modified. It consists of the characters LCT- (Last Change Time), followed by a numeric encoding of the Unix time in seconds since the epoch (1970) that the last change was made. Any additional colon-separated fields after this LCT field are ignored.


NOTE

All share names that end with a dollar sign ($) are hidden; they do not normally appear when a user displays server resources (such as using the NET VIEW \\SambaServername command from a Windows workstation). This also applies to such shares hosted on an SLES Samba server.


You can specify several options for each of the [share] sections. The most commonly used ones are as follows:

  • read only = yes/no specifies whether the client can create, delete, or modify any files on the share. The default is read only = yes. (You can use writeable = yes instead of read only = no.)

  • guest ok = yes/no indicates whether a password is required to access this share. The default is guest ok = no, which means that a password is required. With guest ok = yes, it means that no password is required. (You can also use public = yes, an older and more vague form of guest ok = yes, and public = no, which is synonymous with guest ok = no.)

  • guest account = username is the username that will be used to access services specified as guest ok = yes. The user must exist in the password file (of whatever service is used to authenticate the users). The default is nobody.

  • comment = description provides a description of the nature of the share, which helps users to select the correct resource to access.

  • hosts allow = host1, host2, ... specifies one or more machines that are allowed to access the share. The default is all hosts are granted access.

  • hosts deny = host1, host2, ... specifies one or more machines that are not permitted to access the share. Localhost (127.0.0.1) is always granted access, but you can use hosts deny = localhost to block it.

Refer to man smb.conf or the documents found in /usr/share/doc/packages/samba for a list of all supported options and the use of macros in the configuration file.

AN ANONYMOUS READ-ONLY SERVER CONFIGURATION

You can very easily and quickly set up a document server using Samba so that anyone within your organization can have access to the shared information. The following configuration file illustrates the minimal settings required:

 [global] workgroup = TUX-NET netbios name = DocumentServer security = share [docs] path = /usr/share/doc read only = yes guest ok = yes # limit access to your internal network hosts allow = *.universalexport.ca, 10.0.0.0 comment = on-line documentation 

If you set the security level to share and allow guest to the docs share, your users can access this share without using a password. For instance, from a Windows 2000 workstation, all a user needs to do is enter the following:

 net use i: \\documentserver\docs 


After you have created the configuration file but before you start the Samba daemons, run /usr/bin/testparm to validate the contents of your smb.conf file. If testparm runs correctly, it will list the loaded services. If not, it will give an error message. Make sure it runs correctly and that the services look reasonable before proceeding. The command syntax is

 /usr/bin/testparm config_file 

TIP

If you leave out the name of the configuration file, it defaults to /etc/samba/smb.conf. You can, therefore, make a copy of your current smb.conf file, modify it, run testparm against the edited file, and overwrite only the current one if the modified version contains no errors as reported by testparm.


testparm parses your configuration file and reports any unknown parameters or incorrect syntax. The following is the testparm output from checking the minimal smb.conf file shown in Listing 8.3:

 Athena:/home/admin # /usr/bin/testparm smb.conf.new Load smb config files from smb.conf.new Processing section "[junk]" Processing section "[docs]" Loaded services file OK. Server role: ROLE_STANDALONE Press enter to see a dump of your service definitions # Global parameters [global]         workgroup = TUX-NET         netbios name = MYSAMBASERVER [junk]         path = /tmp [docs]         comment = on-line documentation         path = /usr/share/doc 

Notice that for [docs], testparm did not display the directive read only = yes even though it is specified in the smb.conf.new file. The reason is that it is the default setting, thus is not shown. Any comment lines (those starting with # or ;) are also not displayed.

TIP

Always run testparm after the smb.conf file has been modified.


After you have verified that smb.conf contains no errors, you can start the SMB server by using the following commands:

 Athena:/home/admin # /etc/init.d/nmb start Athena:/home/admin # /etc/init.d/smb start Athena:/home/admin # /etc/init.d/winbind start 

You can also use /usr/sbin/rcnmb, /usr/sbin/rcsmb, and /usr/sbin/rcwinbind instead.

NOTE

The nmbd daemon should be the first command started as part of the Samba startup process, followed by smbd. Note that winbindd is not necessary to run a Samba server. You need to start winbinddd only when using NT/ADS domains for user authentication. Without winbindd, smbd will use only /etc/passwd and /etc/group to resolve user information.


To start the Samba server automatically on server bootup, create the necessary startup scripts using insserv as follows:

 Athena:/home/admin # /sbin/insserv /etc/init.d/nmb Athena:/home/admin # /sbin/insserv /etc/init.d/smb Athena:/home/admin # /sbin/insserv /etc/init.d/winbind 

If you have installed the yast2-samba-server package, you can use YaST to manage your Samba server configuration. From the YaST Control Center, select Network Services, Samba Server; or from a terminal session, use yast samba-server or yast2 samba-server. The first time you configure the Samba Server, you will be asked to select a workgroup or domain to which your server belongs and the role of the server within this domain/workgroup (that is, whether it's a primary domain controller).

Once initialized, YaST displays the Shares tab of the Samba Configuration dialog box as the default. Figure 8.8 shows the Shares dialog box when the sample minimal configuration file is used. From this screen, you can add, delete, or modify shares. Using the Toggle Status button, you can make a share inaccessible while leaving its definition in the configuration file so that you can easily reinstate it later.

Figure 8.8. The Shares tab of the Samba Configuration dialog box.


On the Start Up tab, you indicate whether the Samba server should be active. If you have SuSEfirewall2 installed, this screen also gives you the option to open the necessary ports for Samba: Enable the Open Ports in Firewall check box and then click on Firewall Details to open TCP/UDP ports 137 through 139 inclusive, and TCP/UDP port 445 if you have Windows servers, on all external and internal interfaces. The Identity tab allows you to select the domain/workgroup as well as the role of the Samba server within that domain/workgroup. On the Trusted Domains tab, you can set up NT-style trusts so your server can provide access to the listed domains.

With the Samba server up and running, you can verify whether all your shares are available using the smbclient utility. You should see a list of the defined shares similar to the following:

 Athena:/home/admin #  /usr/bin/smbclient -NL localhost Anonymous login successful Domain=[TUX-NET] OS=[Unix] Server=[Samba 3.0.4-SUSE]    Sharename       Type      Comment    ---------       ----      -------    junk            Disk    docs            Disk      on-line documentation    IPC$            IPC       IPC Service (Samba 3.0.4-SUSE)    ADMIN$          IPC       IPC Service (Samba 3.0.4-SUSE) Anonymous login successful Domain=[TUX-NET] OS=[Unix] Server=[Samba 3.0.4-SUSE]    Server               Comment    ---------            -------    MYSAMBASERVER        Samba 3.0.4-SUSE    Workgroup            Master    ---------            -------    TUX-NET 

The defined shares are listed first, followed by two additional shares called IPC$ and ADMIN$. The IPC$ (Interprocess Communication) share is used by Windows NT and later systems to provide a number of remote system administration services to other networked users. The ADMIN$ share provides remote administration capabilities.

WARNING

In the Windows environment, the IPC$ share is a common target for NetBIOS-based hacking attempts. To protect your SLES Samba server from such attacks, you should at least use hosts allow and host deny directives to limit which machines can have access to your shares. You can put them in the [global] section, making the settings applicable to all shares. If that's not feasible, you can create an [IPC$] section in your smb.conf and put the restrictions there.


Lastly, any servers providing file services should run antivirus software to protect its files from being tampered with. At the time of this writing, SLES 9 includes samba-vscan, a proof-of-concept module for Samba, which uses the virtual file system (VFS) features of Samba 2.2.x/3.0 to provide an on-access Samba antivirus solution. Visit http://www.openantivirus.org/projects.php for more information. If you are looking for a commercial solution, in addition to the ones mentioned earlier in this chapter, BitDefender for Samba (http://www.bitdefender.com) provides on-access virus checking on Samba shared folders.



    SUSE LINUX Enterprise Server 9 Administrator's Handbook
    SUSE LINUX Enterprise Server 9 Administrators Handbook
    ISBN: 067232735X
    EAN: 2147483647
    Year: 2003
    Pages: 134

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net