Ftp Web Hosting - J2Ee Hosting Sun Java Developing Blog

You can find the node address of a router by making judicious use of the tcpdump command with the -eargument to display link level headers and look for traffic from the router. If the router is a Linux machine, you can more simply use the ifconfig command to display it. You can delete a route using the ipx_route command: # ipx_route del 203a41bc You can list the routes that are active in the kernel by looking at the /proc/net/ipx_route file. Our routing table so far looks like this: # cat ipx_route Network Router_Net Router_Node 203A41BC 31A10103 00002a02b102 31A10103 Directly Connected The route to the 31A10103 network was automatically created when we configured the IPX interface. Each of our local networks will be represented by an /proc/net/ipx_route entry like this one. Naturally, if our machine is to act as a router, it will need at least one other interface. Internal IPX Networks and Routing IPX hosts with more than one IPX interface have a unique network/node address combination for each of their interfaces. To connect to such a host, you may use any of these network/node address combinations. When SAP advertizes services, it supplies the network/node address associated with the service that is offered. On hosts with multiple interfaces, this means that one of the interfaces must be chosen as the one to propagate; this is the function of the primary interface flag we talked about earlier. But this presents a problem: the route to this interface may not always be the optimal one, and if a network failure occurs that isolates that network from the rest of the network, the host will become unreachable even though there are other possible routes to the other interfaces. The other routes are never known to other hosts because they are never propagated, and the kernel has no way of knowing that it should choose another primary interface. To avoid this problem, a device was developed that allows an IPX host to be known by a single route-independent network/node address for the purposes of SAP propagation. This solves our problem because this new network/node address is reachable via all of the host interfaces, and is the one that is advertised by SAP. To illustrate the problem and its solution, Figure 15.1 shows a server attached to two IPX networks. The first network has no internal network, but the second does. The host in diagram Figure 15.1 would choose one of its interfaces as its primary interface, let’s assume 0000001a:0800000010aa, and that is what would be advertised as its service access point. This works well for hosts on the 0000001a network, but means that users on the 0000002c network will route via the network to reach that port, despite the server having a port directly on that network if they’ve discovered this server from the SAP broadcasts.

# ipx_interface check eth0 etherII The ipx_interface command is explained more fully in its manual page. Configuring an IPX Router You will recall from our short discussion of the protocols used in an IPX environment that IPX is a routable protocol and that the Routing Information Protocol (RIP) is used to propagate routing information. The IPX version of RIP is quite similar to the IP version. They operate in essentially the same way; routers periodically broadcast the contents of their routing tables and other routers learn of them by listening and integrating the information they receive. Hosts need only know who their local network is and be sure to send datagrams for all other destinations via their local router. The router is responsible for carrying these datagrams and forwarding them on to the next hop in the route. In an IPX environment, a second class of information must be propagated around the network. The Service Advertisement Protocol (SAP) carries information relating to which services are available at which hosts around the network. It is the SAP protocol, for example, that allows users to obtain lists of file or print servers on the network. The SAP protocol works by having hosts that provide services periodically broadcast the list of services they offer. The IPX network routers collect this information and propagate it throughout the network alongside the network routing information. To be a compliant IPX router, you must propagate both RIP and SAP information. Just like IP, IPX on Linux provides a routing daemon named ipxd to perform the tasks associated with managing routing. Again, just as with IP, it is actually the kernel that manages the forwarding of datagrams between IPX network interfaces, but it performs this according to a set of rules called the IPX routing table. The ipxd daemon keeps that set of rules up to date by listening on each of the active network interfaces and analyzing when a routing change is necessary. The ipxd daemon also answers requests from hosts on a directly connected network that ask for routing information. The ipxd command is available prepackaged in some distributions, and in source form by anonymous FTP from http://metalab.unc.edu/ in the /pub/Linux/system/filesystems/ncpfs/ipxripd-x.xx.tgz file. No configuration is necessary for the ipxd daemon. When it starts, it automatically manages routing among the IPX devices that have been configured. The key is to ensure that you have your IPX devices configured correctly using the ipx_interface command before you start ipxd. While auto-detection may work, when you’re performing a routing function it’s best not to take chances, so manually configure the interfaces and save yourself the pain of nasty routing problems. Every 30 seconds, ipxd rediscovers all of the locally attached IPX networks and automatically manages them. This provides a means of managing networks on interfaces that may not be active all of the time, such as PPP interfaces. The ipxd would normally be started at boot time from an rc boot script like this: # /usr/sbin/ipxd No & character is necessary because ipxd will move itself into the background by default. While the ipxd daemon is most useful on machines acting as IPX routers, it is also useful to hosts on segments where there are multiple routers present. When you specify the -p argument, ipxd will act passively, listening to routing information from the segment and updating the routing tables, but it will not transmit any routing information. This way, a host can keep its routing tables up to date without having to request routes each time it wants to contact a remote host. Static IPX Routing Using the ipx_route Command There are occasions when we might want to hardcode an IPX route. Just as with IP, we can do this with IPX. The ipx_route command writes a route into the IPX routing table without it needing to have been learned by the ipxd routing daemon. The routing syntax is very simple (since IPX does not support subnetworking) and looks like: # ipx_route add 203a41bc 31a10103 00002a02b102 The command shown would add a route to the remote IPX network 203a41bc via the router on our local network 31a10103 with node address 00002a02b102.

With no arguments, the ipx_configure command displays the current setting of the automatic configuration flags: # ipx_configure Auto Primary Select is OFF Auto Interface Create is OFF Both the Auto Primary and Auto Interface flags are off by default. To set them and enable automatic configuration, you simply supply arguments like these: # ipx_configure –auto_interface=on –auto_primary=on When the –auto_primary argument is set to on, the kernel will automatically ensure that at least one active interface operates as the primary interface for the host. When the –auto_interface argument is set to on, the kernel IPX driver will listen to all of the frames received on the active network interfaces and attempt to determine the IPX network address and frame type used. The auto-detection mechanism works well on properly managed networks. Sometimes network administrators take shortcuts and break rules, and this can cause problems for the Linux auto-detection code. The most common example of this is when one IPX network is configured to run over the same Ethernet with multiple frame types. This is technically an invalid configuration, as an 802.2 host cannot directly communicate with an Ethernet-II host and therefore they cannot be on the same IPX network. The Linux IPX network software listens on the segment to IPX datagrams transmitted on it. From these, it attempts to identify which network addresses are in use and which frame type is associated with each. If the same network address is in use with multiple frame types or on multiple interfaces, the Linux code detects this as a network address collision and is unable to determine which is the correct frame type. You will know this is occurring if you see messages in your system log that look like: IPX: Network number collision 0×3901ab00 eth0 etherII and eth0 802.3 If you see this problem, disable the auto-detection feature and configure the interfaces manually using the ipx_interface command described in the next section. The ipx_interface Command The ipx_interface command is used to manually add, modify, and delete IPX capability from an existing network device. You should use ipx_interface when the automatic configuration method just described does not work for you, or if you don’t want to leave your interface configuration to chance. ipx_interface allows you to specify the IPX network address, primary interface status, and IPX frame type that a network device will use. If you are creating multiple IPX interfaces, you need one ipx_interface for each. The command syntax to add IPX to an existing device is straightforward and best explained with an example. Let’s add IPX to an existing Ethernet device: # ipx_interface add -p eth0 etherII 0×32a10103 The parameters in turn mean: -p This parameter specifies that this interface should be a primary interface. This parameter is optional. eth0 This is the name of the network device to which we are adding IPX support. etherII This parameter is the frame type, in this case Ethernet-II. This value may also be coded as 802.2, 802.3, or SNAP. 0×32a10103 This is the IPX network address to which this interface belongs. The following command removes IPX from an interface: # ipx_interface del eth0 etherII Lastly, to display the current IPX configuration of a network device, use:

General setup —> [*] Networking support Networking options —> <*> The IPX protocol Network device support —> [*] Ethernet (10 or 100Mbit) … and appropriate Ethernet device drivers If you want Linux to support the NCP filesystem so it can mount remote NetWare volumes, you must additionally select these options: Filesystems —> [*] /proc filesystem support <*> NCP filesystem support (to mount NetWare volumes) When you’ve compiled and installed your new kernel, you’re ready to run IPX. Configuring IPX Interfaces Just as with TCP/IP, you must configure your IPX interfaces before you can use them. The IPX protocol has some unique requirements; consequently, a special set of configuration tools was developed. We will use these tools to configure our IPX interfaces and routes. Network Devices Supporting IPX The IPX protocol assumes that any collection of hosts that can transmit datagrams to each other without routing belong to the same IPX network. All hosts belonging to a single Ethernet segment would all belong to the same IPX network. Similarly (but less intuitively), both hosts supporting a PPP-based serial link must belong to the IPX network that is the serial link itself. In an Ethernet environment, there are a number of different frame types that may be used to carry IPX datagrams. The frame types represent different Ethernet protocols and describe differing ways of carrying multiple protocols on the same Ethernet network. The most common frame types you will encounter are 802.2 and ethernet_II. We’ll talk more about frame types in the next section. The Linux network devices that currently support the IPX protocol are the Ethernet and PPP drivers. The Ethernet or PPP interface must be active before it can be configured for IPX use. Typically, you configure an Ethernet device with both IP and IPX, so the device already exists, but if your network is IPX only, you need to use the ifconfig to change the Ethernet device status to the following: # ifconfig eth0 up IPX Interface Configuration Tools Greg Page developed a set of configuration tools for IPX interfaces, which is a precompiled package in modern distributions and may also be obtained in source form by anonymous FTP from http://metalab.unc.edu/ in the /pub/Linux/system/filesystems/ncpfs/ipx.tgz file. An rc script file usually runs the IPX tools at boot time. Your distribution may already do this for you if you have installed the prepackaged software. The ipx_configure Command Each IPX interface must know which IPX network it belongs to and which frame type to use for IPX. Each host supporting IPX has at least one interface that the rest of the network will use to refer to it, known as the primary interface. The Linux kernel IPX support provides a means of automatically configuring these parameters; the ipx_configure command enables or disables this automatic configuration feature.

IPX and Linux Alan Cox first developed IPX support for the Linux kernel in 1985.83 Initially it was useful for little more than routing IPX datagrams. Since then, other people, notably Greg Page, have provided additional support.84 Greg developed the IPX configuration utilities that we’ll use in this chapter to configure our interfaces. Volker Lendecke developed support for the NCP filesystem to allow Linux to mount volumes on network-connected Net- Ware fileservers.85 He also created tools that allow printing to and from Linux. Ales Dryak and Martin Stover each independently developed NCP fileserver daemons for Linux that allow network-connected NetWare clients to mount Linux directories exported as NCP volumes, just as the NFS daemon allows Linux to serve filesystems to clients using the NFS protocol.86 Caldera Systems, Inc. offers a commercial and fully licensed NetWare client and server that supports the latest Novell standards, including support for the NetWare Directory Service (NDS).87 Today, therefore, Linux supports a wide range of services that allow systems to be integrated with existing Novell-based networks. Caldera Support Although we don’t detail the Caldera NetWare support in this chapter, it is important that we talk about it. Caldera was founded by Ray Noorda, the former CEO of Novell. The Caldera NetWare support is a commercial product and fully supported by Caldera. Caldera provides the NetWare support as a component of their own Linux distribution called Caldera OpenLinux. The Caldera solution is an ideal way of introducing Linux into environments that demand both commercial support and the ability to integrate into existing or new Novell networks. The Caldera NetWare support is fully licensed by Novell, providing a high degree of certainty that the two companies’ products will be interoperable. The two exceptions to this certainty are “pure IP” operation for the client, and NDS server, though neither of these were available at the time of writing. NetWare client and NetWare server are both available. A suite of management tools is also provided that can simplify management of not only your Linux-based NetWare machines, but your Novell NetWare machines, too, by bringing the power of Unix scripting languages to the task. More information on Caldera can be found at their web site. More on NDS Support Along with Version 4 of NetWare, Novell introduced a feature called the NetWare Directory Service (NDS). The NDS specifications are not available without a nondisclosure agreement, a restriction that hampers development of free support. Only Version 2.2.0 or later of the ncpfs package, which we’ll discuss later, has any support for NDS. This support was developed by reverse engineering the NDS protocol. The support seems to work, but is still officially considered experimental. You can use the non-NDS tools with NetWare 4 servers, provided they have “bindery emulation mode” enabled. The Caldera software has full support for NDS because their implementation is licensed from Novell. This implementation is not free, however. So you will not have access to the source code and will not be able to freely copy and distribute the software. Configuring the Kernel for IPX and NCPFS Configuring the kernel for IPX and the NCP filesystem is simply a matter of selecting the appropriate kernel options at kernel build time. As with many other parts of the kernel, IPX and NCPFS kernel components can be built into the kernel, or compiled as modules and loaded using the insmod command when you need them. The following options must be selected if you want to have Linux support and route the IPX protocol: 83 Alan can be reached at alan@lxorguk.ukuu.org.uk. 84 Greg can be reached at gpage@sovereign.org. 85 Volker can be reached at lendecke@namu01.gwdg.de. 86 Ales can be reached at A.Dryak@sh.cvut.cz. Martin can be reached at mstover@freeway.de. 87 Information on Caldera can be found at http://www.caldera.com/.

Chapter 15 - IPX and the NCP Filesystem Long before Microsoft learned about networking, and even before the Internet was known outside academic circles, corporate environments shared files and printers using file and print servers based on the Novell Net- Ware operating system and associated protocols.82 Many of these corporate users still have legacy networks using these protocols and want to integrate this support with their new TCP/IP support. Linux supports not only the TCP/IP protocols, but also the suite of protocols used by the Novell Corporation’s NetWare operating system. These protocols are distant cousins of TCP/IP, and while they perform similar sorts of functions, they differ in a number of ways and are unfortunately incompatible. Linux has both free and commercial software offerings to provide support for integration with the Novell products. We’ll provide a brief description of the protocols themselves in this chapter, but we focus on how to configure and use free software to allow Linux to interoperate with Novell products. Xerox, Novell, and History First, let’s look at where the protocols came from and what they look like. In the late 1970s, the Xerox Corporation developed and published an open standard called the Xerox Network Specification (XNS). The Xerox Network Specification described a series of protocols designed for general purpose internetworking, with a strong emphasis on the use of local area networks. There were two primary networking protocols involved: the Internet Datagram Protocol (IDP), which provided a connectionless and unreliable transport of datagrams from one host to another, and the Sequenced Packet Protocol (SPP), which was a modified form of IDP that was connection- based and reliable. The datagrams of an XNS network were individually addressed. The addressing scheme used a combination of a 4-byte IDP network address (which was uniquely assigned to each Ethernet LAN segment), and the 6-byte node address (the address of the NIC card). Routers were devices that switched datagrams between two or more separate IDP networks. IDP has no notion of subnetworks; any new collection of hosts requires another network address to be assigned. Network addresses are chosen such that they are unique on the internetwork in question. Sometimes administrators develop conventions by having each byte encode some other information, such as geographic location, so that network addresses are allocated in a systemic way; it isn’t a protocol requirement, however. The Novell Corporation chose to base their own networking suite on the XNS suite. Novell made small enhancements to IDP and SPP and renamed them IPX (Internet Packet eXchange) and SPX (Sequenced Packet eXchange). Novell added new protocols, such as the NetWare Core Protocol (NCP), which provided file and printer sharing features that ran over IPX, and the Service Advertisement Protocol (SAP), which enabled hosts on a Novell network to know which hosts provided which services. Table 15.1 maps the relationship between the XNS, Novell, and TCP/IP suites in terms of function. The relationships are an approximation only, but should help you understand what is happening when we refer to these protocols later on. Table 15.1: XNS, Novell, and TCP/IP Protocol Relationships XNS Novell TCP/IP Features IDP IPX UDP/IP Connectionless, unreliable transport SPP SPX TCP Connection-based, reliable transport NCP NFS File services RIP RIP Routing information exchange SAP Service availability information exchange Novell and NetWare are trademarks of the Novell Corporation.

The 2.2.0 kernel supports an experimental kernel-based NFS server developed by Olaf Kirch and further developed by H.J. Lu, G. Allan Morris, and Trond Myklebust. The kernel-based NFS support provides a significant boost in server performance. In current release distributions, you may find the server tools available in prepackaged form. If not, you can locate them at http://csua.berkeley.edu/~gam3/knfsd/. You need to build a 2.2.0 kernel with the kernel-based NFS daemon included in order to make use of the tools. You can check if your kernel has the NFS daemon included by looking to see if the /proc/sys/sunrpc/nfsd_debug file exists. If it’s not there, you may have to load the rpc.nfsd module using the modprobe utility. The kernel-based NFS daemon uses a standard /etc/exports configuration file. The package supplies replacement versions of the rpc.mountd and rpc.nfsd daemons that you start much the same way as their userspace daemon counterparts. Kernel-Based NFSv3 Server Support The version of NFS that has been most commonly used is NFS Version 2. Technology has rolled on ahead and it has begun to show weaknesses that only a revision of the protocol could overcome. Version 3 of the Network File System supports larger files and filesystems, adds significantly enhanced security, and offers a number of performance improvements that most users will find useful. Olaf Kirch and Trond Myklebust are developing an experimental NFSv3 server. It is featured in the developer Version 2.3 kernels and a patch is available against the 2.2 kernel source. It builds on the Version 2 kernel-based NFS daemon. The patches are available from the Linux Kernel based NFS server home page at http://csua.berkeley.edu/~gam3/knfsd/.

insecure This flag reverses the effect of the secure flag. ro This flag causes the NFS mount to be read-only. This flag is enabled by default. rw This option mounts file hierarchy read-write. root_squash This security feature denies the superusers on the specified hosts any special access rights by mapping requests from uid 0 on the client to the uid 65534 (that is, -2) on the server. This uid should be associated with the user nobody. no_root_squash Don’t map requests from uid 0. This option is on by default, so superusers have superuser access to your system’s exported directories. link_relative This option converts absolute symbolic links (where the link contents start with a slash) into relative links. This option makes sense only when a host’s entire filesystem is mounted; otherwise, some of the links might point to nowhere, or even worse, to files they were never meant to point to. This option is on by default. link_absolute This option leaves all symbolic links as they are (the normal behavior for Sun-supplied NFS servers). map_identity This option tells the server to assume that the client uses the same uids and gids as the server. This option is on by default. map_daemon This option tells the NFS server to assume that client and server do not share the same uid/gid space. rpc.nfsd then builds a list that maps IDs between client and server by querying the client’s rpc.ugidd daemon. map_static This option allows you to specify the name of a file that contains a static map of uids and gids. For example, map_static=/etc/nfs/vlight.map would specify the /etc/nfs/vlight.map file as a uid/gid map. The syntax of the map file is described in the exports(5) manual page. map_nis This option causes the NIS server to do the uid and gid mapping. anonuid and anongid These options allow you to specify the uid and gid of the anonymous account. This is useful if you have a volume exported for public mounts. Any error in parsing the exports file is reported to syslogd’s daemon facility at level notice whenever rpc.nfsdor rpc.mountd is started up. Note that hostnames are obtained from the client’s IP address by reverse mapping, so the resolver must be configured properly. If you use BIND and are very security conscious, you should enable spoof checking in your host.conf file. We discuss these topics in Chapter 6, Name Service and Resolver Configuration. Kernel-Based NFSv2 Server Support The user-space NFS server traditionally used in Linux works reliably but suffers performance problems when overworked. This is primarily because of the overhead the system call interface adds to its operation, and because it must compete for time with other, potentially less important, user-space processes.

if [ -x /usr/sbin/rpc.mountd ]; then /usr/sbin/rpc.mountd; echo -n ” mountd” fi if [ -x /usr/sbin/rpc.nfsd ]; then /usr/sbin/rpc.nfsd; echo -n ” nfsd” fi The ownership information of the files an NFS daemon provides to its clients usually contains only numerical user and group IDs. If both client and server associate the same user and group names with these numerical IDs, they are said to their share uid/gid space. For example, this is the case when you use NIS to distribute the passwd information to all hosts on your LAN. On some occasions, however, the IDs on different hosts do not match. Rather than updating the uids and gids of the client to match those of the server, you can use the rpc.ugidd mapping daemon to work around the disparity. Using the map_daemon option explained a little later, you can tell rpc.nfsd to map the server’s uid/gid space to the client’s uid/gid space with the aid of the rpc.ugidd on the client. Unfortunately, the rpc.ugidd daemon isn’t supplied on all modern Linux distributions, so if you need it and yours doesn’t have it, you will need to compile it from source. rpc.ugidd is an RPC-based server that is started from your network boot scripts, just like rpc.nfsd and rpc.mountd: if [ -x /usr/sbin/rpc.ugidd ]; then /usr/sbin/rpc.ugidd; echo -n ” ugidd” fi The exports File Now we’ll look at how we configure the NFS server. Specifically, we’ll look at how we tell the NFS server what filesystems it should make available for mounting, and the various parameters that control the access clients will have to the filesystem. The server determines the type of access that is allowed to the server’s files. The /etc/exports file lists the filesystems that the server will make available for clients to mount and use. By default, rpc.mountd disallows all directory mounts, which is a rather sensible attitude. If you wish to permit one or more hosts to NFS-mount a directory, you must export it, that is, specify it in the exports file. A sample file may look like this: # exports file for vlager /home vale(rw) vstout(rw) vlight(rw) /usr/X11R6 vale(ro) vstout(ro) vlight(ro) /usr/TeX vale(ro) vstout(ro) vlight(ro) / vale(rw,no_root_squash) /home/ftp (ro) Each line defines a directory and the hosts that are allowed to mount it. A hostname is usually a fully qualified domain name but may additionally contain the * and ? wildcards, which act the way they do with the Bourne shell. For instance, lab*.foo.com matches lab01.foo.com as well as laboratory.foo.com. The host may also be specified using an IP address range in the form address/netmask. If no hostname is given, as with the /home/ftp directory in the previous example, any host matches and is allowed to mount the directory. When checking a client host against the exports file, rpx.mountd looks up the client’s hostname using the gethostbyaddr call. With DNS, this call returns the client’s canonical hostname, so you must make sure not to use aliases in exports. In an NIS environment the returned name is the first match from the hosts database, and with neither DNS or NIS, the returned name is the first hostname found in the hosts file that matches the client’s address. The hostname is followed by an optional comma-separated list of flags, enclosed in parentheses. Some of the values these flags may take are: secure This flag insists that requests be made from a reserved source port, i.e., one that is less than 1,024. This flag is set by default.

soft Soft-mount (as opposed to hard-mount) the driver. This option causes an I/O error to be reported to the process attempting a file operation when a major timeout occurs. intr Allow signals to interrupt an NFS call. Useful for aborting when the server doesn’t respond. Except for rsize and wsize, all of these options apply to the client’s behavior if the server should become temporarily inaccessible. They work together in the following way: Whenever the client sends a request to the NFS server, it expects the operation to have finished after a given interval (specified in the timeout option). If no confirmation is received within this time, a so-called minor timeout occurs, and the operation is retried with the timeout interval doubled. After reaching a maximum timeout of 60 seconds, a major timeout occurs. By default, a major timeout causes the client to print a message to the console and start all over again, this time with an initial timeout interval twice that of the previous cascade. Potentially, this may go on forever. Volumes that stubbornly retry an operation until the server becomes available again are called hard-mounted. The opposite variety, called soft-mounted, generate an I/O error for the calling process whenever a major timeout occurs. Because of the write-behind introduced by the buffer cache, this error condition is not propagated to the process itself before it calls the write function the next time, so a program can never be sure that a write operation to a soft-mounted volume has succeeded at all. Whether you hard- or soft-mount a volume depends partly on taste but also on the type of information you want to access from a volume. For example, if you mount your X programs by NFS, you certainly would not want your X session to go berserk just because someone brought the network to a grinding halt by firing up seven copies of Doom at the same time or by pulling the Ethernet plug for a moment. By hard-mounting the directory containing these programs, you make sure that your computer waits until it is able to re-establish contact with your NFS server. On the other hand, non-critical data such as NFS-mounted news partitions or FTP archives may also be soft-mounted, so if the remote machine is temporarily unreachable or down, it doesn’t hang your session. If your network connection to the server is flaky or goes through a loaded router, you may either increase the initial timeout using the timeo option or hard-mount the volumes. NFS volumes are hard-mounted by default. Hard mounts present a problem because, by default, the file operations are not interruptible. Thus, if a process attempts, for example, a write to a remote server and that server is unreachable, the user’s application hangs and the user can’t do anything to abort the operation. If you use the intr option in conjuction with a hard mount, any signals received by the process interrupt the NFS call so that users can still abort hanging file accesses and resume work (although without saving the file). Usually, the rpc.mountd daemon in some way or other keeps track of which directories have been mounted by what hosts. This information can be displayed using the showmount program, which is also included in the NFS server package: # showmount -e moonshot Export list for localhost: /home # showmount -d moonshot Directories on localhost: /home # showmount -a moonshot All mount points on localhost: localhost:/home The NFS Daemons If you want to provide NFS service to other hosts, you have to run the rpc.nfsd and rpc.mountd daemons on your machine. As RPC-based programs, they are not managed by inetd, but are started up at boot time and register themselves with the portmapper; therefore, you have to make sure to start them only after rpc.portmap is running. Usually, you’d use something like the following example in one of your network boot scripts: