---------------------------------------------------------------------------- The Florida SunFlash Network Information Services (NIS). SunFLASH Vol 28 #18 April 1991 ---------------------------------------------------------------------------- This is an article by Tony Brooks of Sun's Technical Information Services (TIS). Please send any comments, corrections etc to me and I will forward them to Tony. -johnj ------------------------------------------------------------------- Introduction I. Becoming a NIS Master Server II. Becoming a NIS Slave Server III. Becoming a NIS Client IV. NIS Tools and Utilities V. Problems with NIS References ------------------------------------------------------------------- Introduction NIS or Network Information Services, used to be called YP or yellow pages. NIS is nothing more than a repository of information on one machine which is called the NIS Master Server. It's really analogous to the phone book that the Telephone company leaves at your door step. Whenever you need to find a particular person or business you let your fingers do the walking in the phone book. In the case of NIS though you have all the general information located on one machine. This makes it very easy to update the information and also propogate it out to the rest of the world. NIS is very pratical on large networks that's continuously adding or deleting host names and addresses to or from the network. For example instead of everyone maintaining there own local /etc/hosts file this task can now be handle on the NIS Master Server machine; which would update it's NIS /etc/host ascii file and propogate the updated database or dbm (see ndbm(3)) map out to the rest of the network. I. Becoming a NIS Master Server 1. You can only have 1 NIS Master Server per domain 2. You execute "ypinit -m" on the designated NIS Master Server machine, as root a) it will prompt you for adding NIS Slave Servers 3. You must be running /usr/etc/[ypbind, ypserv] 4. You need to be in a domain (see domainname(1)) II. Becoming a NIS Slave Server 1. There is no limit to the number of NIS Slave Servers that a network can have 2. You execute "ypinit -s master_name", as root a) this is only necessary if you did not initially specify NIS Slave Servers when you ran "ypinit -m" on the NIS Master. 3. You must be running /usr/etc/[ypbind, ypserv] III. Becoming a NIS Client 1. There is no limit to the number of NIS Clients you can have on a network 2. You need to be running /usr/etc/ypbind IV. NIS Tools and Utilities +1. ypbind(8) 1. ypbind(8) Running ypbind enables a machine to bind to a NIS Server which has NIS look-up information or maps. It's perfectly okay for a machine to bind to itself if it's a NIS Server. 1.1 ypbind Running ypbind without any options is the most secure method i.e. when you bind to a machine for NIS map information your machine is safe from some other machine on the net running ypset to change the binding of your machine. Think about that for a second! If you're in a secure environment someone could create their own NIS maps on their machine and have others on the network bind to that machine; they could then have a password specified for root that would enable them to log into other NIS machines on the net as ROOT! 1.2 ypbind -ypset Running ypbind with the "-ypset" option: --------------------------------------- nis_client # /usr/etc/ypbind -ypset nis_server # /usr/etc/yp/ypset -h nis_client nis_server --------------------------------------- this used to be the default when you ran ypbind, however, this created security problems. The "-ypset" option enables anyone else on the network to run ypset and have your machine bind to some other machine. This is if you started ypbind with the "-ypset" initially. This is no longer the default. 1.2 ypbind -ypsetme this will enable `root` or `super-user` (ONLY on the machine that initially invoked ypbind with the "-ypsetme") to bind to another machine e.g. --------------------------------------- mach_a # /usr/etc/ypbind -ypsetme mach_a # /usr/etc/yp/ypset another_server --------------------------------------- Again, the above only works if you run ypset on `machine_a` (see ypbind(8)). +2. ypwhich(1) 2. ypwhich(1) ypwhich tells which NIS server supplies NIS services to a NIS client, or which is the master for a map. If invoked without arguments, it gives the NIS server for the local machine. Some of the options are explained below: -m map name Find the master NIS server for a map. mname can be a map-name, or a nickname for a map. When mname is omitted, produce a list of available maps. -x Display the map nickname table. This lists the nicknames (mnames) the command knows of, and indicates the mapname associated with each nickname. --------------------------------------- nis_client % ypwhich cte OR nis_client % ypwhich -m hosts.byaddr hard2get ... ... ethers.byaddr hard2get ethers.byname hard2get passwd.byuid hard2get hosts.byname hard2get OR nis_client % ypwhich -x Use "passwd" for map "passwd.byname" Use "group" for map "group.byname" Use "networks" for map "networks.byaddr" Use "hosts" for map "hosts.byaddr" Use "protocols" for map "protocols.bynumber" Use "services" for map "services.byname" Use "aliases" for map "mail.aliases" Use "ethers" for map "ethers.byname" OR nis_client % ypwhich -m aliases nis_server --------------------------------------- using `ypwhich -m` is one method of determining if there is more than ONE NIS Master machine in that domain - you can only have ONE per domain. In the case of more than ONE NIS Master you would notice different machines owning different maps i.e. `ypwhich -m`. +3. yppoll(8) 3. yppoll(8) yppoll asks a ypserv(8) process what the order number is, and which host is the master NIS server for the named map. --------------------------------------- nis_master % /usr/etc/yp/yppoll -h cte ethers.byname Domain ESG.Eng.Sun.COM is supported. Map ethers.byname has order number 655162718. The master server is nis_master. nis_slave % /usr/etc/yp/yppoll -h raid ethers.byname Domain ESG.Eng.Sun.COM is supported. Map ethers.byname has order number 655162700. The master server is nis_master. --------------------------------------- This utility is useful for determining whether or not a map on a NIS Slave Server is not a current with that of the NIS Master Server. Notice that the order numbers above are slightly different 655162718 vs. 655162700. See "4. yppush vs ypxfer" below to transfer maps from the NIS Master Server. +4. yppush(8) vs ypxfr(8) 4. yppush(8) vs ypxfr(8) 4.1 yppush Yppush forces propagation of changed NIS maps from the NIS Master Server to all the NIS Slave Servers, it is normally run only on the NIS Master by the Makefile in /var/yp after the master databases are changed (in the example below assume that you've changed /etc/hosts file on the NIS Master). --------------------------------------- IMPLICITLY nis_master # vi /etc/ethers nis_master # cd /var/yp nis_master # make EXPLICITLY nis_master # /usr/etc/yp/yppush ethers --------------------------------------- 4.2 ypxfr ypxfr transfers NIS maps from a NIS server to HERE! HERE being a NIS Slave Server (you want to get the NIS maps from the NIS Master Server) --------------------------------------- nis_slave # /usr/etc/yp/ypxfr -h nis_master ethers.byname --------------------------------------- Maps have different rates of change. For instance, some may not changed for months at a time, such as protocols.byname among the default maps and auto.mater among the non-default, but publickey or passwd.byname may change several times a day. Scheduling map transfer through the crontab command allows setting specific propagation times for individual maps. For more information - Systems Network Administration, chp 16, pg. 487, "Using crontab with xpxfr". +5. ypserv(8) 5. ypserv(8) Both ypserv and ypbind (see "1. ypbind" above) are daemon processes typically activated at system startup time from /etc/rc.local. ypserv runs only on NIS Server machines which has a complete set of NIS maps. Earlier we talked about ypbind and how it enables a machine to bind to an NIS Server from NIS requests. A NIS client sends out a broadcast packet to the network requesting NIS look-up information; which ever machine is RUNNING YPSERV CAN SERVICE THAT REQUEST - THIS CAN CAUSE MAJOR PROBLEMS IF THE SERVICING MACHINE HAS BOGUS INFORMATION OR NO INFORMATION AT ALL. (We will address some of the problems below). By default the /usr/etc/ypserv line in /etc/rc.local on all Sun machines is NOT COMMENTED OUT; if you inadvertently create /var/yp/`domainname` on a NON- NIS Server machine, /usr/etc/ypserv will still run when the machine is rebooted. The /usr/etc/ypserv daemon will now be running and accepting NIS broadcast requests from other NIS machines on the net. However, accepting those requests but not giving the requestor any information and no error messages. +6. ypcat(1) 6. ypcat(1) ypcat prints out values in a Network Information Service (NIS) map specified by mname, which may be either a map name or a map nickname. --------------------------------------- nis_machine % /usr/bin/ypcat -x Use "passwd" for map "passwd.byname" Use "group" for map "group.byname" Use "networks" for map "networks.byaddr" Use "hosts" for map "hosts.byaddr" Use "protocols" for map "protocols.bynumber" Use "services" for map "services.byname" Use "aliases" for map "mail.aliases" Use "ethers" for map "ethers.byname nis_machine % /usr/bin/ypcat hosts|grep machine_name 129.114.23.10 machine_name --------------------------------------- +7. ypmatch 7. ypmatch ypmatch prints the values associated with one or more keys from the Network Information Service (NIS) map specified by mname, which may be either a mapname or an map nickname. Multiple keys can be specified; the same map will be searched for all . The KEYS MUST BE EXACT VALUES insofar as capitalization and length are concerned. No pattern matching is available. If a key is not matched, a diagnostic message is produced. --------------------------------------- nis_machine % /usr/bin/ypmatch -x Use "passwd" for map "passwd.byname" Use "group" for map "group.byname" Use "networks" for map "networks.byaddr" Use "hosts" for map "hosts.byaddr" Use "protocols" for map "protocols.bynumber" Use "services" for map "services.byname" Use "aliases" for map "mail.aliases" Use "ethers" for map "ethers.byname nis_machine % /usr/bin/ypmatch jackson hosts jw:1f24uHrjrzigs:1368:40:Jackson Wong:/home/cte/jw:/bin/csh OR nis_machine % /usr/bin/ypmatch jw aliases jackson@jafo --------------------------------------- Also, when adding new people to the network the system administrator should check both the NIS password file and aliases file for the login name of that new person. The new name may not be in the NIS password file but it may very well be in the NIS aliases file which could cause mail to be sent to the person that's specified in the aliases file. V. Problems with NIS Scenario 1 ---------- NIS Master Server ^ __|___ | | | A | |______| | | / \ / \ / \ ____/ \_____ | | | | NIS Client-->| C |-------| B |<---NIS Slave Server | | | | ------ ------- 1) Machine B is bound to machine A 2) Machine C is bound to machine B 3) Someone on machine B inadvertently removes /var/yp/`domainname` directory, which hosts all of the NIS dbm look-up maps 4) Machine B is still getting good information but machine C is not, in fact it's not getting anything back when it issues a NIS request 5) To fix the problem you will need to rerun "ypinit -s" on machine B Scenario 2 ---------- NIS Master Server ^ __|___ | | | A | |______| | | / \ / \ / \ ____/ \_____ | | | | NIS Client-->| C |-------| B |<---NIS Slave Server | | | | ------ ------- 1) Machine A (NIS Master Server) reboots and binds to machine B (NIS Slave Server), this is not a problem i.e. Master binding to a Slave Server. 2) Machine B was bound to machine A before machine A rebooted, it is still bound to machine A when it comes back up. 3) For some reason both machine A and B loose there NIS maps. 4) This is probably the worst type of situation because all NIS request will return blank information to the requestor but no error messages. 5) To fix the problem kill ypbind on the the NIS Master Server and rerun "ypinit -m" on that machine. Scenario 3 ---------- NIS Master Server ^ __|___ | | | A | |______| | | / \ / \ / \ ____/ \_____ | | | | NIS Client-->| C |-------| B |<---NIS Client | | | | ------ ------- 1) Someone on machine B inadvertently creates a directory in /var/yp called `domainname`. Prior to 4.1 SunOS this was an easy situation to get into because all the makefiles and dbm files where in /var/yp whether or not the machine was a Server. One of the things that /var/yp/make will do is create /var/yp/`domainname` if the appropriate files exist in /var/yp. 2) Machine B is rebooted and /usr/etc/ypserv now starts running automatically from the /etc/rc.local script i.e. if [ -f /usr/etc/ypserv -a -d /var/yp/`domainname` ]; then ypserv; echo -n ' ypserv' 3) Machine B is now able to services request from other NIS machines on the network which means that they are binding to an NIS Client machine with no NIS maps. However, no errors are reported. 4) To fix the problem, remove the /var/yp/`domainame` on Machine B and kill 'ypserv' e.g.: ------------------------------------------------- machine_B # rm -ri /var/yp/domainname machine_B # ps ax|grep ypserv PID TT STAT TIME COMMAND 1716 p2 S 0:00 grep ypbind machine_B # kill -9 1716 ------------------------------------------------- References: System & Network Administration Manual System Interface Manual Commands Reference Manual ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ For information send mail to info-sunflash@sunvice.East.Sun.COM. Subscription requests should be sent to sunflash-request@sunvice.East.Sun.COM. Archives are on solar.nova.edu and paris.cs.miami.edu. All prices, availability, and other statements relating to Sun or third party products are valid in the U.S. only. Please contact your local Sales Representative for details of pricing and product availability in your region. Descriptions of, or references to products or publications within SunFlash does not imply an endorsement of that product or publication by Sun Microsystems. John McLaughlin, SunFlash editor, flash@sunvice.East.Sun.COM. (305) 776-7770.