NIS map:
A NIS map is simply binary file (a .dbm file also called a database) generated (by makedbm(1M)) from a source text file interpreted as just two fields out of many strings within a single line of text, where the very first string is known as the key and the all remaining string(s) is(are) known as the value (even if comprised by the multiple strings beyond the key). The source text file can contain other stuff such as comments, as long as during the make process, that stuff is appropriately striped out of the resulting binary dbm file. The binary file is optimized for quick searches by its key field, of course. The binary file can be disassembled with the makedbm -u command. But loosely speaking, the source text files of each corresponding map is also called a map (at least implying its textual representation).NIS domain:
A NIS domain is simply a set of NIS maps used throughout all participating hosts on a network acting either as servers (hosts running the ypserv process) or clients (hosts running the ypbind process). The ypserv process has no other knowledge that the maps it must serve, which located on /var/yp/`domainname`. The ypbind process has no other knowledge than the server it must contact upon receiving a query. But loosely speaking, a NIS domain can be understood as just the set of NIS maps, the participating hosts on a network or both, depending on the context. A NIS domain must be give a name, such as the business.corp string.Again, so much wording.
It's probably better to watch a few examples of ordinary built-in maps:
# ypcat hosts
192.168.0.50 nfs-1
192.168.0.200 client-1
192.168.0.10 nis-1
# ypcat passwd
user3:$5$...$...:1003:1:User 3:/home/user3:/usr/bin/bash
user2:$5$...$...:1002:1:User 2:/home/user2:/usr/bin/bash
user1:$5$...$...:1001:10:User 1:/home/user1:/usr/bin/bash
# ypcat -k auto.home
user3 nfs-1:/export/home/user3
user2 nfs-1:/export/home/user2
user1 nfs-1:/export/home/user1
# ypcat -k project
users users:11:All users:1001,1002,1003::
# ypcat -k user_attr
user3 user3::::project=users
user2 user2::::project=users
user1 user1::::project=users
# ypcat -k netgroup
clients (client-1,-,business.corp) (client-2,-,business.corp)
servers (server-1,-,business.corp) (server-2,-,business.corp)
users (-,user1,-) (-,user2,-) (-,user3,-)
As seen when establishing a NIS master, an interesting place to concentrate the maps' sources is at /var/nis, a manually created symbolic to the manually created /var/share/nis directory which is stable across boot environments (BEs), typically created upon system updates or upgrades.
Each time a map's source is edited/updated, it must be rebuilt, typically with a general make command:
# cd /var/yp
# make
By default, all changed sources are rebuild according to their respective make rules and two messages are printed per updated map:
updated mapname
pushed mapname
In case slave servers exist (strongly recommended) but are eventually down, after a more or less long timeout the following message is printed in-between the aforementioned two messages:
Error talking to slave: rpcbind failure (host is down?)
Thus, the learned lesson is that if a single slave server is down, then the make will be longer and linearly proportional to the amount of maps requiring rebuild.
Depending on the chosen map distribution strategy, something I shall address when talking about slave servers, it's possible to edit /var/yp/Makefile and set a value for the variable NOPUSH or yet define some non-empty value for it when invoking make at the command-line (make NOPUSH=1), which will inhibit the default push behavior. If this is done, then an alternate distribution method must be crafted, either manually or scheduled probably taking advantage of cron(1M) and ssh(1).
