Inside Linux Setting Up an NFS Server You (Web site domain)
Inside Linux Setting Up an NFS Server You might be tasked with NFS server administration at your organization, or you may want to set up an NFS server on your home network. Either way, proper organization and a clear understanding of the maintenance aspects of NFS will allow you to get NFS up and running with a minimum of hassle. NFS offers a number of benefits to users: You can keep administrative data on one central host, relieving you of having to replicate those files to multiple machines. User data can all be stored on one central host, allowing users to be mobile. Users can move about the organization or outside the doors and continue to access their data transparently. If you are using NIS, your users can also log in to any system and gain access to their data. You can store application and system data that consumes large amounts of disk space on a central host. This reduces maintenance chores, and it allows your users to gain access as required. Basically, setting up an NFS server requires some quick file manipulation and ensuring that the required daemons are started. As mentioned previously, NFS sits on top of the RPC mechanism, so you have to be sure that the RPC components are properly set up. Preconditions Our journey to set up NFS will take us through a universal technique. Most all NFS systems follow the same pattern for setup and execution. If you are unfamiliar with what NFS is and its architecture, I recommend that you read the earlier sections of this chapter. NFS is not rocket science, but an understanding of its functionality is beneficial. The NFS Portmapper The RPC server registers with the portmapper daemon on startup. The portmapper obtains the port numbers on which the RPC server will listen for incoming requests. This relieves the portmapper from having to listen on the ports. The portmapper is an RPC service and acts as an intermediary for RPC clients. When an RPC client requires the services of the RPC server, it contacts the portmapper at a well- known IP port (port 111) to ascertain the RPC server’s port number. Optionally, the client may request that the portmapper contact the RPC server on behalf of the client. The portmapper is indeed an important part of the RPC mechanism. If the portmapper ceases to exist (crashes, for example), RPC clients will be unable to contact RPC servers such as NIS and NFS. The portmapper goes beyond the functionality it provides within the NFS terrain. The portmapper is also responsible for RPC broadcasts, which are requests that are transmitted to all RPC servers handling a specific RPC service. In these situations, the portmapper is contacted to transmit the broadcast to the RPC servers on behalf of the requester. This is done because hosts must know the port numbers (of the RPC servers) to deliver the broadcast. The problem is that RPC servers are not always at well-known addresses. On Linux, the portmapper is named portmap or rpc.portmap and is normally found in the /usr/sbin directory. It is rare indeed, but possible, that it is named rpcbind on your distribution. After you have the name of the portmapper, you need to fire it up. For now, you can invoke it by hand at the Linux command line. The following dialog demonstrates the action: stimpy $ portmap stimpy $ Now that is an uneventful dialog, to say the least. To ensure that the portmapper is running, you can do a couple of things. One is to use the trusty ps command to confirm the portmapper’s existence. page 215
We recommend high quality webhost to host and run your jsp application: christian web host services.