Configuring the NFS Server on SLES
Before I explain how to implement NFS on Suse Linux Enterprise Server, I need to explain a few things about NFS to let you decide if it is the correct solution for your network deployment.
First, you need to understand that NFS is simply a "Network File System", which means that you can "mount" remote filesystems from your local GNU/Linux - Unix machines and have them act as if the filesystem(s) were physically connected to your machine (more or less). However, in this discussion, what NFS is NOT may seem to be more important, especially for those that may be coming from a Microsoft Windows background.
Unlike Microsoft's Windows "one size fits all" Networking approach, NFS is not an authentication mechanism, you must provide another mechanism to ensure that User's are authenticated from a central server (if you wish them to be). This means that you will probably need to use an LDAP Server, NIS Server or a Windows/Samba server for User Authentication.
NFS is also not a way to ensure that the remote user is who they say they are (meaning "ensuring the computer being logged in from is a part of a 'Domain' or something similar"). For networks that put network security a top priority, you must also implement another service, such as Kerberos, within your network to ensure users are only logging into certain machines.
Let me explain a little more about security: Let's say I implement an NFS server without implementing Kerberos, and I restrict the access to the filesystem to certain network addresses. Then let's say I have a User, "Ron Paul" within my LDAP server with username "rpaul" and user ID number 1105. Then let's say someone decides to bring a GNU/Linux notebook into your network, they just happen to create the a new user with username "rpaul" and user ID 1105 locally (on their notebook) and logs in as this new user. As long as that notebook has an address within the range allowed by the NFS server, that notebook user can then mount an NFS filesystem from your server and have all the permissions that the "rpaul" user has on your server (read/write to the same files/directories that the rpaul user is allowed to).
Although this may sound like a huge security hole, keep in mind that 75% of all Windows Server installations are deployed with shares that are world readable/writable.
Since most networks do not (yet) have GNU/Linux or Unix workstations, and since the next version of Samba will probably have a Kerberos implementation "rolled into it", I have decided not to explain how to implement Kerberos within Suse Linux Enterprise (yet) as the implementation will likely soon change in the next year or two. Until then, if you have any financial or other secure information on your network, it is your responsibility to configure Kerberos within your network or simply do not put secure information within an NFS share.
Setting Up the NFS Server
The first steps to configure an NFS Server is to get a handle on file/directory permissions and setup the directories you wish to export. I know I already have an entire chapter on Unix permissions, but it is important to give a good example of how I usually setup exported directories.
For instance, normally I usually only export 2 directories out of most servers, the /home directory and a directory that I keep most of the network files in, which is usually /srv/exports. For this example I am going to focus on configuring a /srv/exports directory as a good foundation for all the network files/directories.
So, what you want to do is decide what directories you wish to create within the /srv/exports folder, then set appropriate permissions on these directories. Also for each directory I create, I usually create a similar Samba Share that points to that directory. This allows your users to access these files from either GNU/Linux workstations or Microsoft Windows workstations. For this example, I am going to create 3 directories: office, teachers and schoolwide to give you an idea of how I usually set permissions - also note that I will use the groups "office", "teachers" and "students" to control access to these directories.
mkdir /srv/exports mkdir /srv/exports/office mkdir /srv/exports/teachers mkdir /srv/exports/schoolwide chmod 3770 /srv/exports/* chgrp office /srv/exports/office chgrp teachers /srv/exports/teachers chgrp students /srv/exports/schoolwide
The important command is the "chmod 3770" command, this ensures that any file or directory written within that directory is "Group Owned" by the owner of the parent directory. This allows any user that is a member of that group the ability to read/write any file within that directory regardless of the users "Default Group". This command also ensures that only the owner of the file can actually delete the file (even though any member of the group can read/write to the file).
So, in the above example, access to these directories are limited to only the users that are members of the respective group. For instance, only users that are members of the "teachers" group can access the "teachers". This provides an easy way to share files while still maintaining some type of control to who can access which files.
Once you configure your directories, you can now "export" these directories so that other workstations can mount them. To do this open the Yast NFS Server module.
The Yast NFS Server module is seperated into two pages, the first page allows you to configure how the server handles the NFS requests. Here you can enable NFSv4 support and GSS Security if needed. Again, this document does not show you how to utilize Kerberos (as this subject is well beyond the scope of this document), so if you are simply following this guide do not enable these options. The second page allows you to configure the directories you wish to export and what options these exports have.
To include a directory to export, simply click on the "Add Directory" button and enter the location of the directory. In this case you add "/srv/exports". Then you are presented with a dialog asking for the "Host Wild Card" and "Options" for that specific Host Wild Card. Each export can have multiple "Host Wild Card" entries.
Host Wild Card - This is where you specify which hosts are able to mount your exported directory. This is usually listed as IP Addresses, Domain Names, NIS Groups or simple "*" for all access is allowed. For example:
192.168.1.0/24 *.private.lan @groupname
Options - Here is where you specify various options to use for each of the Hosts listed. For instance, you can specify "rw" for Read/Write or "ro" for Read Only. Normal defaults for most shares should be similar to "rw,sync,root_squash". Other options are listed in the Man Page for exports (man exports).
Occasionally, you do want to configure some exports differently to accomplish different tasks. For instance, you may want to provide NFS access to a FTP or HTTP directory on your server. There might even be times that you may want anyone that accesses certain exports to have the same User ID or Group ID to allow for extremely easy file sharing without having to maintain the same UID or GIDs on every client. Here are a few examples showing this.
Directory Host WC Options /srv/ftp * ro,insecure,all_squash /srv/worldwritable * rw,all_squash,anonuid=1001,anongid=1002
Configuring NFS Clients
To configure NFS Clients you first have to ensure that the User IDs and Group IDs on the server are the same ones that the clients will use. The easiest way to do this with Suse Linux Enterprise Server is to simply utilize the LDAP Server on your server for your workstation's authentication procedure.
Configuring LDAP Clients on Suse Linux Enterprise
The process of configuring your Clients to utilize an LDAP database for authentication will vary depending upon the GNU/Linux Distribution you are using for your workstations. Unfortunately, not only do you have to ensure that you change configuration files on your clients, but you must also insure that all the required software libraries are installed and that programs are configured to make use of these libraries.
Since not all Distributions are the same, I am simply going to cover how to configure Suse Linux clients to utilize an LDAP server for authentication. If you are using another Distribution for your clients, please reference their documentation on how to do this.
The Suse Linux Distributions (Suse Linux Enterprise & OpenSuse) include a Yast Module to help you in configuring LDAP Authentication called "LDAP Client". When you launch this module, it will automatically ensure that all the required software and software libraries are installed on your client, as well as allow you to easily configure how LDAP Authentication will operate. These options include:
- User Authentication - This section allows you to set whether or not your Client will utilize an LDAP Server for User/Group information. You can also specify whether or not you will allow LDAP Users to login to the machine.
- LDAP Client Information - This section is where you specify the Address of your LDAP Server, as well as the database that the information is located in. You can also specify whether or not to use encrypted network traffic or even to drop to an older LDAP protocol if your server requires it.
- Start Automounter - This checkbox allows you to start the Automounter Daemon when the computer boots up. This is not recommended for high traffic exports, but can be useful in some circumstances.
- Create Home Directory on Login - This specifies whether or not the machine will automatically create the User's home folder on login. If you are not using an NFS mount for your User's home directory, they you will probably wish to enable this. However, if you wish to utilize an NFS /home directory (think of it as the ultimate "Roaming Profile") then you should not enable this.
The LDAP Client Yast Module also allows you to adjust "Advanced" options, including how passwords are handled, using different LDAP records, etc. when you click on the "Advanced" button.
Mounting NFS Exports on Suse Linux
Mounting NFS shares is relatively strait-forward on GNU/Linux machines provided that you have all of the software libraries installed and you have the necessary services running. To test whether or not you are able to mount NFS shares, simply try to mount a share with something similar to:
mount -t nfs sles-test.private.lan:/srv/exports /mnt/test
If the mount succeeds then you can start editing the "/etc/fstab" file on your clients to create all the necessary network mounts that your environment needs. If you are utilizing Suse Linux clients, you can easily do this by launching the Yast "NFS Client" module.
This module allows you to easily ensure that all of the software is readily present on your system, all the required services are running and it allows you to specify any NFS mount that you may need for your environment.
To add additional NFS mounts, simply click on the "Add" button and fill in the required information including; the NFS Server, the Remote Directory, the local Mount Point and any options you may need. These options allow you to adjust how your NFS Client communicates with NFS Servers. For instance, the most popular ones include:
- hard - This specifies that if the NFS Server goes offline for any reason, the applications accessing the share will "hang" or be unresponsive until the NFS Server goes back online. This should always be included in the options for any NFS Mountpoint.
- intr - This specifies whether or not the User can "Kill" an application that is "frozen" since the NFS Server is offline. Most administrators do include this option for their NFS Mountpoints.
- nolock - This option will allow you to not utilize NFS locking for the NFS Mountpoint. Some applications may require this option to be set on User's NFS Home mounts.
- rsize & wsize - These allow you to adjust the performance of your NFS network communications. The value of these options will vary depending upon your network hardware and software. A good start point for these is "8192", but definitely refer to the NFS documentation to optimize your network.