Diff for /wikisrc/tutorials/how_to_set_up_nfs_and_nis.mdwn between versions 1.1 and 1.2

version 1.1, 2011/11/20 20:55:21 version 1.2, 2012/02/05 07:14:36
Line 1 Line 1
 **Contents**  **Contents**
   
 [[!toc]]  [[!toc]]
   
 #  Introduction  #  Introduction 
   
 This little article will try to make sense of the jungle that is NFS and NIS. For our example we will use NFS for keeping /home on a server, allowing us to work on the same files in our homedir from any computer in the network.  This little article will try to make sense of the jungle that is NFS and NIS. For our example we will use NFS for keeping /home on a server, allowing us to work on the same files in our homedir from any computer in the network. 
   
      
   
   
 #  NIS  #  NIS 
   
 NIS (Network Information Service) is a directory system which is used to centralise configuration files like /etc/hosts and /etc/passwd. By using NIS for passwd, you can have the same users on each host in the network without the hassle of keeping the passwd file of all hosts synchronised.  NIS (Network Information Service) is a directory system which is used to centralise configuration files like /etc/hosts and /etc/passwd. By using NIS for passwd, you can have the same users on each host in the network without the hassle of keeping the passwd file of all hosts synchronised. 
   
 We will need NIS (or another directory service) to make sure the NFS user ids/group ids are the same on the server as on all clients. Otherwise, bad things will happen, as you can probably imagine (especially in our example of mounting /home over NFS). Note that using NIS with NFS is not mandatory, you can also keep the server and client's passwd in synch.  We will need NIS (or another directory service) to make sure the NFS user ids/group ids are the same on the server as on all clients. Otherwise, bad things will happen, as you can probably imagine (especially in our example of mounting /home over NFS). Note that using NIS with NFS is not mandatory, you can also keep the server and client's passwd in synch. 
   
 NIS used to be called the `Yellow Pages', or YP for short. Because of trademarks it had to be renamed, but the programs are all still prefixed with `yp'.  NIS used to be called the `Yellow Pages', or YP for short. Because of trademarks it had to be renamed, but the programs are all still prefixed with `yp'. 
   
      
   
   
 #  Kernel options  #  Kernel options 
   
 Before doing anything with NFS, ensure that your kernel has support for NFS sharing. This means your clients and servers must have NFS kernel support enabled. This is the case for GENERIC Kernels. For custom Kernels, the following lines must be in the kernel file:  Before doing anything with NFS, ensure that your kernel has support for NFS sharing. This means your clients and servers must have NFS kernel support enabled. This is the case for GENERIC Kernels. For custom Kernels, the following lines must be in the kernel file: 
          
      file-system     NFS             # Network File System client       file-system     NFS             # Network File System client
          
   
 Your server also must have the following option:  Your server also must have the following option: 
          
      options         NFSSERVER       # Network File System server       options         NFSSERVER       # Network File System server
          
   
 If you want to get funky and boot from NFS (not discussed in this article), your clients need these options as well:  If you want to get funky and boot from NFS (not discussed in this article), your clients need these options as well: 
          
      options         NFS_BOOT_DHCP,NFS_BOOT_BOOTPARAM       options         NFS_BOOT_DHCP,NFS_BOOT_BOOTPARAM
          
   
 #  Creating a NIS setup  #  Creating a NIS setup 
   
 The first thing we should do is decide on a NIS domain name. This has nothing to do with your machine's Internet domain name. It is just a unique name that is used to identify machines in the same NIS block.  The first thing we should do is decide on a NIS domain name. This has nothing to do with your machine's Internet domain name. It is just a unique name that is used to identify machines in the same NIS block. 
   
 The domainname is set (as root) using the [domainname(1)](http://netbsd.gw.com/cgi-bin/man-cgi?domainname+1+NetBSD-current) program, or can be set in the /etc/mydomain file.    The domainname is set (as root) using the [domainname(1)](http://netbsd.gw.com/cgi-bin/man-cgi?domainname+1+NetBSD-current) program, or can be set in the /etc/mydomain file.   
 Alternatively, in most BSD systems, it can be set in /etc/rc.conf under the variable `domainname'.  Alternatively, in most BSD systems, it can be set in /etc/rc.conf under the variable `domainname'. 
          
   
  root@earth# domainname planets   root@earth# domainname planets
          
   
      
 After this, we must initialise all files needed for the server to do its work. For this, we use the ypinit utility.  After this, we must initialise all files needed for the server to do its work. For this, we use the ypinit utility. 
          
      root@earth# ypinit -m       root@earth# ypinit -m
          
   
 The -m means we are creating a master server. On more complex networks, you can even want slave servers. The tool will ask you for a list of YP servers to bind to.    The -m means we are creating a master server. On more complex networks, you can even want slave servers. The tool will ask you for a list of YP servers to bind to.   
 Since we're only using one server, just press RETURN (make sure your own server's internal address is in the list).  Since we're only using one server, just press RETURN (make sure your own server's internal address is in the list). 
   
 Before we run `make' in /var/yp, as the tool says, we must enable the NIS deamons: rpcbind, ypserv and ypbind (in that order). After that, we can run `make' in /var/yp.  Before we run `make' in /var/yp, as the tool says, we must enable the NIS deamons: rpcbind, ypserv and ypbind (in that order). After that, we can run `make' in /var/yp. 
   
 To test if your setup is working, try yptest. It should spew out the passwd file among others, so don't panic ;)  To test if your setup is working, try yptest. It should spew out the passwd file among others, so don't panic ;) 
   
 To get stuff working on your client, you need to enable the yppasswdd, rpcbind and ypbind daemons as well. In order to do that, edit the /etc/rc.conf file and add there following:  To get stuff working on your client, you need to enable the yppasswdd, rpcbind and ypbind daemons as well. In order to do that, edit the /etc/rc.conf file and add there following: 
          
     #NIS server      #NIS server
     ypserv="YES"      ypserv="YES"
     ypbind="YES"      ypbind="YES"
     yppasswdd="YES"      yppasswdd="YES"
     rpcbind="YES"      rpcbind="YES"
          
   
 Then just run  Then just run 
          
     # /etc/rc.d/rpcbind start      # /etc/rc.d/rpcbind start
     # /etc/rc.d/ypserv start      # /etc/rc.d/ypserv start
     # /etc/rc.d/ypbind start      # /etc/rc.d/ypbind start
     # /etc/rc.d/yppasswdd start      # /etc/rc.d/yppasswdd start
          
   
 [rpc.yppasswdd(8)](http://netbsd.gw.com/cgi-bin/man-cgi?rpc.yppasswdd+8+NetBSD-current) must be running on the NIS master server to allow users to change information in the password file.    [rpc.yppasswdd(8)](http://netbsd.gw.com/cgi-bin/man-cgi?rpc.yppasswdd+8+NetBSD-current) must be running on the NIS master server to allow users to change information in the password file.   
 [ypserv(8)](http://netbsd.gw.com/cgi-bin/man-cgi?ypserv+8+NetBSD-current) provides information from NIS maps to the NIS clients on the network.    [ypserv(8)](http://netbsd.gw.com/cgi-bin/man-cgi?ypserv+8+NetBSD-current) provides information from NIS maps to the NIS clients on the network.   
 [ypbind(8)](http://netbsd.gw.com/cgi-bin/man-cgi?ypbind+8+NetBSD-current) finds the server for a particular NIS domain and stores information about it in a ``binding file_._  [ypbind(8)](http://netbsd.gw.com/cgi-bin/man-cgi?ypbind+8+NetBSD-current) finds the server for a particular NIS domain and stores information about it in a ``binding file_._
   
 After that, you can use ypinit:  After that, you can use ypinit: 
          
      root@mars# ypinit -c       root@mars# ypinit -c
          
   
 Then, add your NIS server's address to the list. To test if everything is working, use yptest on the client as well. **Note that ypbind will HANG if it can't find the server!**  Then, add your NIS server's address to the list. To test if everything is working, use yptest on the client as well. **Note that ypbind will HANG if it can't find the server!**
   
 If everything is working, you are ready to go! Just edit /etc/nsswitch.conf and put in some `nis' keywords. For example:  If everything is working, you are ready to go! Just edit /etc/nsswitch.conf and put in some `nis' keywords. For example: 
          
      passwd:            files nis       passwd:            files nis
          
   
 would first look up usernames/passwords/uids in /etc/passwd, and if it can't find it, it would look it up using NIS. Right after changing this file, you should be able to log in on your system using a username which is only in /etc/passwd on the server. That's all there is to it.  would first look up usernames/passwords/uids in /etc/passwd, and if it can't find it, it would look it up using NIS. Right after changing this file, you should be able to log in on your system using a username which is only in /etc/passwd on the server. That's all there is to it. 
   
 #  The deamons  #  The deamons 
   
 What are all those daemons for? Well, here's a quick rundown:  What are all those daemons for? Well, here's a quick rundown: 
   
 Portmap/rpcbind is the program which maps RPC (Remote Procedure Call) program numbers to port numbers (hence, portmapper). Any program which wishes to know on what port a certain RPC program is listening can ask this from the portmapper daemon (rpcbind). Each RPC service has its own number, which can be looked up in /etc/rpc. These numbers are how rpcbind can match the running RPC services to the ports. In short: If rpcbind is not running, not a single RPC program will work.  Portmap/rpcbind is the program which maps RPC (Remote Procedure Call) program numbers to port numbers (hence, portmapper). Any program which wishes to know on what port a certain RPC program is listening can ask this from the portmapper daemon (rpcbind). Each RPC service has its own number, which can be looked up in /etc/rpc. These numbers are how rpcbind can match the running RPC services to the ports. In short: If rpcbind is not running, not a single RPC program will work. 
   
 Ypserv is an authentication daemon for the RPC services, I believe. Ypbind is the daemon which can find the YP server for the specified domain.  Ypserv is an authentication daemon for the RPC services, I believe. Ypbind is the daemon which can find the YP server for the specified domain. 
   
      
   
   
 #  NFS  #  NFS 
   
 Setting up NFS is a piece of cake. Just enter all directories you wish to export in /etc/exports and start the NFS daemon. In our example we would have:  Setting up NFS is a piece of cake. Just enter all directories you wish to export in /etc/exports and start the NFS daemon. In our example we would have: 
          
      /home              -network 192.168.0.0 -mask 255.255.0.0 -maproot=root       /home              -network 192.168.0.0 -mask 255.255.0.0 -maproot=root
          
   
 This exports /home only on the LAN 192.168.x.x. The maproot line is needed, because otherwise the client's root will not have superuser access. Now, start the mount daemon and the NFS deamons (mountd and nfsd) as root on your server, in that order. For that type:  This exports /home only on the LAN 192.168.x.x. The maproot line is needed, because otherwise the client's root will not have superuser access. Now, start the mount daemon and the NFS deamons (mountd and nfsd) as root on your server, in that order. For that type: 
          
      root@mars# /etc/rc.d/rpcbind start       root@mars# /etc/rc.d/rpcbind start
      root@mars# /etc/rc.d/mountd start       root@mars# /etc/rc.d/mountd start
      root@mars# /etc/rc.d/nfsd start       root@mars# /etc/rc.d/nfsd start
      root@mars# /etc/rc.d/nfslocking start       root@mars# /etc/rc.d/nfslocking start
          
   
 If you wish to start the NFS server on boot, add following lines to your /etc/rc.conf  If you wish to start the NFS server on boot, add following lines to your /etc/rc.conf 
          
     nfs_server=yes      nfs_server=yes
     rpcbind=yes      rpcbind=yes
     mountd=${nfs_server}      mountd=${nfs_server}
     lockd=${nfs_server}      lockd=${nfs_server}
     statd=${nfs_server}      statd=${nfs_server}
          
   
 Now, try to mount from the client and type:  Now, try to mount from the client and type: 
          
      root@mars # mount -t nfs earth:/home /home       root@mars # mount -t nfs earth:/home /home
          
   
 Voila, you're done. Just add all NFS volumes you want to mount to your /etc/fstab like this  Voila, you're done. Just add all NFS volumes you want to mount to your /etc/fstab like this 
          
      earth:/home   /home    nfs   rw       earth:/home   /home    nfs   rw
          
   
 and have them mounted at system startup.  and have them mounted at system startup. 
   
 NOTE: I had much trouble with NFS which was caused by UDP packet fragmentation. This made all writes extremely slow (and other outgoing network traffic as well!) while reads were at an acceptable speed. To solve this, I added the (undocumented?) `tcp' option to fstab to mount NFS over TCP. You'll probably also need to add  NOTE: I had much trouble with NFS which was caused by UDP packet fragmentation. This made all writes extremely slow (and other outgoing network traffic as well!) while reads were at an acceptable speed. To solve this, I added the (undocumented?) `tcp' option to fstab to mount NFS over TCP. You'll probably also need to add 
          
     nfsd_flags='-t'      nfsd_flags='-t'
          
   
 to rc.conf so the NFS server serves up TCP exports.  to rc.conf so the NFS server serves up TCP exports. 
   
 If you just want to run NFS, you need to run the following daemons on your server: rpcbind, mountd, nfsd (in that order)  If you just want to run NFS, you need to run the following daemons on your server: rpcbind, mountd, nfsd (in that order) 
   
 #  Notes  #  Notes 
   
 #  Concerning NFS  #  Concerning NFS 
   
 If you find NFS is not suitable for you, you could try Coda. The Coda filesystem tries to overcome some of the drawbacks of NFS:  If you find NFS is not suitable for you, you could try Coda. The Coda filesystem tries to overcome some of the drawbacks of NFS: 
   
   * Handling of (sudden) disconnections    * Handling of (sudden) disconnections 
   * Its own authentication system    * Its own authentication system 
   
 And some others. The latest NFS versions are of course trying to integrate some of Coda's features as well.  And some others. The latest NFS versions are of course trying to integrate some of Coda's features as well. 
   
      
   
   
 #  Concerning NIS  #  Concerning NIS 
   
 A disadvantage of NIS is that it is not very secure. If security is a big concern, have a look at LDAP and NIS+, which are more complex directory services. For networks where security isn't that important (like most home networks), NIS will do. It is also much easier to set up than NIS+ or LDAP.  A disadvantage of NIS is that it is not very secure. If security is a big concern, have a look at LDAP and NIS+, which are more complex directory services. For networks where security isn't that important (like most home networks), NIS will do. It is also much easier to set up than NIS+ or LDAP. 
   
 On NetBSD (probably on other systems as well), the NIS server consults /etc/hosts.allow and /etc/hosts.deny (from Wietse Venema's tcpwrappers package) to determine if the requesting host is allowed to access the NIS directory. This can help you in securing NIS a little.  On NetBSD (probably on other systems as well), the NIS server consults /etc/hosts.allow and /etc/hosts.deny (from Wietse Venema's tcpwrappers package) to determine if the requesting host is allowed to access the NIS directory. This can help you in securing NIS a little. 
   
 My /etc/hosts.deny looks like this:  My /etc/hosts.deny looks like this: 
          
      ypserv: ALL       ypserv: ALL
      rpcbind: ALL       rpcbind: ALL
      ypbind: ALL       ypbind: ALL
      nfsd: ALL       nfsd: ALL
          
   
 In my /etc/hosts.allow I have my LAN hosts.  In my /etc/hosts.allow I have my LAN hosts. 
   
      
   
   
 #  References  #  References 
   
   * O'Reilly's Managing NFS and NIS, 2nd Edition    * O'Reilly's Managing NFS and NIS, 2nd Edition 
   * [Linux NFS howto](http://nfs.sourceforge.net/nfs-howto)    * [Linux NFS howto](http://nfs.sourceforge.net/nfs-howto)
   * [The CODA project](http://www.coda.cs.cmu.edu/)    * [The CODA project](http://www.coda.cs.cmu.edu/)
   * [The good old NetBSD Guide](http://www.netbsd.org/Documentation/#Guide)    * [The good old NetBSD Guide](http://www.netbsd.org/Documentation/#Guide)
   * [Replacing NIS with Kerberos and LDAP howto](http://www.ofb.net/~jheiss/krbldap/howto.html)    * [Replacing NIS with Kerberos and LDAP howto](http://www.ofb.net/~jheiss/krbldap/howto.html)
   
   
 #  See also  #  See also 
   
   * [mount_nfs(8)](http://netbsd.gw.com/cgi-bin/man-cgi?mount_nfs+8+NetBSD-current) manpage    * [mount_nfs(8)](http://netbsd.gw.com/cgi-bin/man-cgi?mount_nfs+8+NetBSD-current) manpage 
   
   

Removed from v.1.1  
changed lines
  Added in v.1.2


CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb