WebNFS Administration Tasks

This section provides instructions for administering the WebNFS system. This is a list of some related tasks.

Table 15-4 WebNFS Administration Task Map

Planning for WebNFS Access

To use the WebNFS functionality, you first need an application capable of running and loading an NFS URL (for example, nfs://server/path). The next step is to choose the file system that will be exported for WebNFS access. If the application is web browsing, often the document root for the web server is used. You need to consider several factors when choosing a file system to export for WebNFS access.

1. Each server has one public file handle that by default is associated with the server's root file system. The path in an NFS URL is evaluated relative to the directory with which the public file handle is associated. If the path leads to a file or directory within an exported file system, the server provides access. You can use the public option of the share command to associate the public file handle with a specific exported directory. Using this option allows URLs to be relative to the shared file system rather than to the servers' root file system. The root file system does not allow web access unless the root file system is shared.

2. The WebNFS environment enables users who already have mount privileges to access files through a browser regardless of whether the file system is exported by using the public option. Because users already have access to these files through the NFS setup, this access should not create any additional security risk. You only need to share a file system by using the public option if users who cannot mount the file system need to use WebNFS access.

3. File systems that are already open to the public make good candidates for using the public option. Some examples are top directory in an ftp archive or the main URL directory for a web site.

4. You can use the index option with the share command to force the loading of an HTML file instead of listing the directory when an NFS URL is accessed.

   After a file system is chosen, review the files and set access permissions to restrict viewing of files or directories, as needed. Establish the permissions, as appropriate, for any NFS file system that is being shared. For many sites, 755 permissions for directories and 644 permissions for files provides the correct level of access.

   You need to consider additional factors if both NFS and HTTP URLs are to be used to access one web site. These factors are described in "WebNFS Limitations With Web Browser Use".

How to Browse Using an NFS URL

Browsers capable of supporting the WebNFS service should provide access to an NFS URL that resembles the following:

nfs://server<:port>/path

Note - In most browsers, the URL service type (for example, nfs or http) is remembered from one transaction to the next. The exception occurs when a URL that includes a different service type is loaded. After you use an NFS URL, a reference to an HTTP URL might be loaded. If so, subsequent pages are loaded by using the HTTP protocol instead of the NFS protocol.

How to Enable WebNFS Access Through a Firewall

You can enable WebNFS access for clients that are not part of the local subnet by configuring the firewall to allow a TCP connection on port 2049. Just allowing access for httpd does not allow NFS URLs to be used.

Autofs Administration Task Overview

This section describes some of the most common tasks you might encounter in your own environment. Recommended procedures are included for each scenario to help you configure autofs to best meet your clients' needs.

Note - Use the Solstice System Management Tools or see the System Administration Guide: Naming and Directory Services (FNS and NIS+) to perform the tasks that are discussed in this section.

Autofs Administration Task Map

The following table provides a description and a pointer to many of the tasks that are related to autofs.

Table 15-5 Autofs Administration Task Map

Administrative Tasks Involving Maps

The following tables describe several of the factors you need to be aware of when administering autofs maps. Which type of map and which name service you choose change the mechanism that you need to use to make changes to the autofs maps.

The following table describes the types of maps and their uses.

Table 15-6 Types of autofs Maps and Their Uses

The following table describes how to make changes to your autofs environment, based on your name service.

Table 15-7 Map Maintenance

The next table tells you when to run the automount command, depending on the modification you have made to the type of map. For example, if you have made an addition or a deletion to a direct map, you need to run the automount command on the local system to allow the change to become effective. However, if you've modified an existing entry, you do not need to run the automount command for the change to become effective.

Table 15-8 When to Run the automount Command

Modifying the Maps

The following procedures require that you use NIS+ as your name service.

How to Modify the Master Map

1. Login as a user who has permissions to change the maps.

2. Using the nistbladm command, make your changes to the master map.

   See the System Administration Guide: Naming and Directory Services (FNS and NIS+).

3. For each client, become superuser or assume an equivalent role.

   For information about roles, see "Using Privileged Applications" in System Administration Guide: Security Services.

4. For each client, run the automount command to ensure your changes become effective.

5. Notify your users of the changes.

   Notification is required so that the users can also run the automount command as superuser on their own computers.

The automount command gathers information from the master map whenever it is run.