Configuring NFSv4 on SUSE Linux Enterprise 10

Transcription

1 Technical White Paper DATA CENTER Configuring NFSv4 on SUSE Linux Enterprise 10 Setup Guide

2 Enhancing Client Performance for Narrow Data-sharing Applications on High-bandwidth Networks This document is intended as a step-by-step guide for administrators setting up the Network File System Version 4 (NFSv4) on SUSE Linux Enterprise 10 from Novell. It discusses NFSv4 server and client configuration. 1. Overview NFSv4 is a new distributed file system, similar to previous versions of NFS in its straightforward design and the independence of transport protocols and operating systems for file access in a heterogeneous network. Unlike earlier versions of NFS, the new protocol integrates file locking, strong security, compound Remote Procedure Calls (RPCs, combining relevant operations) and delegation capabilities to enhance client performance for narrow data-sharing applications on high-bandwidth networks. NFSv4 implementations are backward compatible with NFSv2 and NFSv3. Note: NFSv4 access control lists (ACLs) and Kerberos privacy (krb5p) are currently not supported. 2. Quickstart For the NFSv4 server, please follow these steps: 1. Edit /etc/exports to create an entry similar to the one below: /export <client_ip/hostname/wildcard> (rw,fsid=0,sync,no_root_squash) Note: fsid=0 is a must. Replace /export with the file tree that needs to be nfs-exported, and <client_ip/hostname/wildcard> with your client s IP or hostname or with the wildcard *. (* means any client.) 2. Edit /etc/idmapd.conf, modifying the default Domain to contain your Domain Name System (DNS) domain name. 3. Execute the following commands to start idmapd and nfsserver: #/etc/init.d/nfsserver start For the NFSv4 client, please follow these steps: 1. Edit /etc/idmapd.conf, modifying the default Domain to contain your DNS domain name. 2. Execute the following command to start idmapd: 3. Mount the exported file system using the following command: #mount -t nfs4 <servername>:/ <mntpath> Observe that only / is given here instead of the actual exported path name. 3. idmapd Configuration on Client and Server idmapd.conf is the configuration file for idmapd (or the idmapping daemon), which performs NFSv4<=>name mapping. Here, the DNS domain (Domain) name has to be configured in both the client and the server. Sample configuration file: [General] Verbosity = 0 Pipefs-Directory = /var/lib/nfs/rpc_pipefs Domain = mydomain.com [Mapping] Nobody-User = nobody Nobody-Group = nobody p. 2

3 Configuring NFSv4 on SUSE Linux Enterprise Setting up the NFSv4 Server and Client 4.1 Configuring the Server There are three main configuration files you will need to edit to set up an NFSv4 server: /etc/exports /etc/sysconfig/nfs /etc/idmapd.conf We will describe the first two options here; idmapd.conf is explained in the previous section /etc/exports The /etc/exports file contains a list of entries; each entry indicates a volume that is shared as well as how it is shared. The /etc/exports file format in NFSv4 is slightly different from previous versions. A sample exports entry looks like this. /export *(rw,fsid=0,no_subtree_check,sync, no_root_squash) Note that: The value 0 has a special meaning when used with NFSv4. NFSv4 has a concept of a root of the overall exported file system. The export point exported with fsid=0 will be used as this root. There must be at least one entry with fsid=0. (This will be the pseudo file system s /.) The method used to mount multiple exported trees is different. NFSv4 uses the concept of a pseudo file system to give a single file system view to the client, with a pseudo- / as root of the file system tree. To illustrate, suppose we have /path1/volume1 /path2/volume2 as two file system trees on the server that need to be exported. First, these need to be bound to another name under the /export directory, using the mount command s bind option: mount --bind <old dir> /export/<new dir> In our example, #mount --bind /path1/volume1 /export/volume1 #mount --bind /path2/volume2 /export/volume2 will bind these local file system trees to their local new names. Then these two exported file systems (with their newly bound paths) are entered into /etc/exports with their respective independent options. As an example, /etc/exports would contain: /export/volume1 *(<options_to_be_filled>) /export/volume2 *(<options_to_be_filled>) If both a directory and its subdirectory residing on different file systems need to be exported, then the option nohide must be appropriately used. For example, if /export and /export/subdir reside on different file systems and both need to be exported to same client, then /export <client>(<options>) /export/subdir <client>(<options>,nohide) must be entered so that the client can see the contents of /subdir, too. Although this is not specific to NFSv4, it is included here as a common-use case scenario. For more information, please see man exports. Currently, the YaST2 NFS server module can only be used as a substitute for manually editing the /etc/exports. Fully functional YaST options with other configuration editing (idmapd and so forth) are a work in progress. In case of different kinds of exports for the same exported path, the syntax that must be followed is: /export host1(<options>) host2(<options>) (or) /export host1(<options>) /export host2(<options>) p. 3

4 4.1.2 Co-existing NFSv3 and NFSv3 Exports for the Same File Systems The current Linux* implementation of NFSv4 caters to NFSv2 and NFSv3 clients, too. The /etc/exports can contain both types of export entries even for the same file system trees being exported /etc/sysconfig/nfs /etc/sysconfig/nfs is another NFS server configuration file. Here, you can configure the number of kernel threads, NFSv4 support and Kerberos Generic Security Service (GSS). (The Kerberos setup is explained in Section 5.) 4.2 Starting Services on the Server and Client Now you need to start idmapd and nfsserver on the NFSv4 server. #/etc/init.d/nfsserver start Then, start idmapd alone on the client. If the machines being used as client and server are just meant for that, the daemons can be enabled during bootup, as shown below. Use insserv #insserv -d idmapd #insserv -d nfsserver and start idmapd alone on the client. 4.3 Mounting Remote Exported Directories One of the main differences between previous versions of NFS and NFSv4 is the way in which mount is invoked. With regard to the pseudo file system concept sketched above, mount is invoked as follows: #mount -t nfs4 <servername>:/ <mntpath> Observe that only / is given after the server name. 5. Setting up the Kerberized NFSv4 Server and Client 5.1 Prerequisites The Key Distribution Center (KDC) must already be set up on the network. krb5-1.4.x must be installed on both the NFS server and NFS client. krb5-client-1.4.x must be installed on both the NFS server and NFS client. The NFS server and client and the KDC server must have their time synchronized. NFS_SECURITY_GSS has to be set to yes in /etc/sysconfig/nfs in both the server and client. 5.2 Configuring a Kerberized NFSv4 Server and Client The following configuration steps except those detailed in chapter are to be followed for both the NFSv4 client and server. p. 4

5 Configuring NFSv4 on SUSE Linux Enterprise Configure Kerberos Edit krb5.conf. Sample configuration: Note: Replace MYDOMAIN.COM with your REALM, kdcserver.mydomain.com with your KDC server, adminserver.mydomain.com with your Admin server and mydomain.com with your DNS domain name Create Machine Credentials Creating machine credentials means creating a Kerberos V5 principal/instance name of the form nfs/<hostname>@realm and either adding a key for this principal to an existing /etc/krb5.keytab or creating an /etc/krb5.keytab. Note: Only the encryption type of des-cbc-crc is functional so far in the kernel, so add only this type of key. kadmin: addprinc -e des-cbc-crc:normal nfs/ <hostname>@realm kadmin: ktadd -e des-cbc-crc:normal -k /etc/krb5.keytab nfs/<hostname>@realm p. 5

6 5.2.3 Configure /etc/gssapi_mech.conf This configuration file determines which GSS-API (application programming interface) mechanisms the gssd code should use. There is usually no need to modify this file in 32-bit machines because the libraries are installed in /usr/lib. Note: In the case of 64-bit machines, this has to be modified to /usr/lib64. This is a workaround and will be fixed later. Sample configuration: /etc/exports Entries for a Kerberized Server Typical entries for Kerberos security mode look like these: /export gss/krb5(rw,fsid=0,insecure,no_subtree _check,sync,no_root_squash) /export gss/krb5i(rw,fsid=0,insecure,no_subtree _check,sync,no_root_squash) Note: krb5p is currently not supported. The insecure option in this entry also allows clients with NFS implementations that don t use a reserved port for NFS. So it is advisable *NOT* to use this option unless you have a Kerberized setup or you know what you are doing. 5.3 Starting the Services on Server and Client On the NFSv4 server, svcgssd needs to be started. Follow these steps: #/etc/init.d/svcgssd start #/etc/init.d/nfsserver start On the NFSv4 client, gssd needs to be started, too. Follow these steps: #/etc/init.d/gssd start To avoid starting manually, another option is to enable service during bootup, using insserv as mentioned in section 4.2 p. 6

7 Configuring NFSv4 on SUSE Linux Enterprise Mounting Exported Directories with Kerberos To mount a file system using krb5, provide the -osec=krb5 option to mount: #mount -tnfs4 -osec=<secmode> nfsserver:/ /mntpoint <secmode> can be krb5 (for Authentication) or krb5i (for Integrity). 5.5 A Known Issue Using NFSv4 with Kerberos Even if the no_root_squash option is used while exporting a file system at the server, root on the client gets a Permission denied error when creating files on the mount point. This happens due to the fact that there is no proper mapping between root and the GSSAuthName. Note: Don t try to set 777 (read/write/execute permission for all users): it is not secure. Also, any file created on the mount point will have nobody as owner. There is a workaround for this if both the NFS server and client use ldap_umich methods to authenticate. If idmapd on both the server and client is configured to use ldap_umich modules, then having the GSSAuthName (<nfs/hostname@realm>) parameter map to root user on the Lightweight Directory Access Protocol (LDAP) server will solve this problem. A proper fix for this issue is being developed. 6. Troubleshooting 6.1 Checklist to Ensure NFSv4 Is Up and Running Check if the server-side daemons are up and running: ps -ef grep nfsd ps -ef grep idmapd ps -ef grep svcgssd Check if the client-side daemons are up and running: ps -ef grep idmapd ps -ef grep gssd Check all registered RPC programs (nfs, portmapper, mountd) and versions: rpcinfo -p Check if the firewall is enabled on the server/client from YaST: Yast -> Security and Users -> Firewall. Make sure the NFS service is enabled. Check mount information on the NFS server: showmount -e <server name> Make sure that one and only one path is exported with fsid=0 Refer to the pseudo file systems discussion in section for more information. If users are not mapped properly, check whether idmapd is running in both the server and client AND that the DNS domain name is properly configured. If you are unable to mount, check for the correctness of the exports file entry. 6.2 Check List to Ensure That Kerberos Is Working Properly There are different reasons why Kerberos could be failing, some of which are listed below: Verify that rpc.gssd is running on the client and rpc.svcgssd is running on the server. Verify that your hostnames are correct. The hostname command should return a fully qualified hostname that has a correct DNS reverse mapping (either through DNS or the /etc/hosts file). Verify that there is a keytab entry for nfs/<hostname>@realm in your keytab file (/etc/krb5.keytab). p. 7

8 Verify that the [domain_realm] section of your Kerberos configuration file (/etc/krb5.conf) has the proper mapping from the DNS domain to the correct REALM. As an example, if your NFS server s hostname is foo.abc.org and your Kerberos realm name is ALPHABET.ORG, then you need an entry like the following in /etc/krb5.conf on the NFS client machine: [domain_realm].abc.org = ALPHABET.ORG Verify whether your ticket is expired or not on the client, using klist. If your ticket is expired, renew it using kinit. This must be checked when you find I/O Error or Permission denied while doing file operations. 7. For More Information As well as the man pages of exports, nfs, and mount, information about configuring an NFS server and client is available in /usr/share/doc/packages/nfs-tils/readme and the following Web documents: Find the detailed technical documentation online at: For instructions for setting up kerberized NFS, refer to NFS Version 4 Open Source Reference Implementation: projects/nfsv4/linux/krb5-setup.html If you have any question on NFSv4, refer to the Linux NFSv4 Frequently Asked Questions FAQ at: projects/nfsv4/linux/faq/ Contact your local Novell Solutions Provider, or call Novell at: U.S./Canada Worldwide Facsimile Novell, Inc. 404 Wyman Street Waltham, MA USA / Novell, Inc. All rights reserved. Novell, the Novell logo, the N logo and SUSE are registered trademarks of Novell, Inc. in the United States and other countries. *Linux is a registered trademark of Linus Torvalds. All other third-party trademarks are the property of their respective owners.