---------------------------------------------------------------------------- The Florida SunFlash Network Information Services (NIS). SunFLASH Vol 31 #7 July 1991 ---------------------------------------------------------------------------- This is an updated version of SunFlash article 28.18. The author, Tony Brooks of Sun's Technical Information Services (TIS) has made a number of changes and clarifications. -johnj ------------------------------------------------------------------- Introduction I. Becoming a NIS Master Server II. Becoming a NIS Slave Server III. Becoming a NIS Client IV. NIS Tools and Utilities 1. ypbind(8) 2. ypwhich(1) 3. yppoll(8) 4. yppush(8) vs ypxfr(8) 5. ypserv(8) 6. ypcat(1) 7. ypmatch 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 need to be in a domain (see domainname(1)) 4. You must be running /usr/etc/[ypbind, ypserv] 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 must execute "ypinit -s master_name", as root. 3. You must be running /usr/etc/[ypbind, ypserv]. 4. Propagating an NIS Map When you propagate an NIS map, you move it from one server to another - most often from the master to all NIS slave servers. Initially, ypinit propagates the maps from mater to slave as described above. From then on you MUST transfer updated maps from master to slaves by running the 'ypxfr' command. You can run 'ypxfr' two different ways: periodically through the root crontab file; or interactively on the command line. (Refer to the chapter on "The Nework Information Service, Chapter 16, page 487, for information two different ways to run 'ypxfr' - System & Network Administration manual). III. Becoming a NIS Client 1. There is no limit to the number of NIS Clients you can have on a network. You can not have NIS clients across subnets (there must be at least one NIS in the same domain on the same subnet for the clients unless you're using the ypsetme utility). 2. You need to be running /usr/etc/ypbind IV. NIS Tools and Utilities 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) 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) 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.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 already changed /etc/hosts file on the NIS Master). --------------------------------------- IMPLICITLY nis_master # cd /var/yp nis_master # make EXPLICITLY nis_master # /usr/etc/yp/yppush hosts.byname --------------------------------------- 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) 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) 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 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 passwd 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.1O OS 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. 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 1716 ------------------------------------------------- References: System & Network Administration Manual System Interface Manual Commands Reference Manual Bernie Knost, Manager, Corporate Technical Escalation (CTE) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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.