Solaris NIS maps

(part 2 of the Solaris NIS mini-tutorial)

Managing NIS maps

Creating the list of slave servers on the master

Updating NIS Server Maps

Building Maps with make

NIS maps are databases that specify certain system information such as user names, passwords, and host names, in a database format called DBM. Whenever you need to modify an NIS map, you should do so on the master server and then propagate the changes to the slave servers. The only exception to this rule is when users change their password with the yppasswd command.

Most maps are constructed from a standard text files by associating an index key with a value. For example, the information in the master server's /etc/hosts file is used to create a map that uses each host name as a key and the IP address as the value. The key and value pairs (also known as records) that are created from the entries in the /etc/hosts file comprise the hosts.byname map. In addition to the hosts.byname file, a hosts.byaddr file is also provided for reverse name resolution. For these two functions, name resolution and reverse name resolution, a total of four files are needed:

• hosts.byname.dir
• hosts.byname.pag
• hosts.byaddr.dir
• hosts.byaddr.pag

The most commonly used maps have nicknames that some commands can translate into map names. For example:

# ypcat hosts

The output you receive is actually the contents of the hosts.byname map, because there is no map called hosts in the NIS database. The ypcat -x command produces a list of available nicknames.  

Managing NIS maps

System information, such as a new user account or a changed password, can require constant updating. Whenever you need to modify an NIS map, you should do so on the master server and then propagate the changes to the slave servers. The only exception to this rule is when users change their password with the yppasswd command. When changing a map, you need to start with editing the source file.

For example, in editing /etc/hosts, add server1 (9.3.240.56) to the file. Even though the source file has been edited, the NIS subsystem is not yet aware of the changes:

# ypcat hosts
9.3.240.59      alpha
9.3.240.58      beta
127.0.0.1       loopback localhost      # loopback (lo0) name/address
10.47.1.2       gamma
10.47.1.1       delta

To update the NIS maps (on the master server), complete the following steps:

1. Update the text files in your source directory (typically, /etc, unless it was changed in the Makefile file).
2. Change to the /var/yp directory
3. Refresh the NIS database maps using the make utility ( /usr/ccs/bin/make ).

Updating NIS Server Maps

Password map is a special case as for some strange reason only for it NIS provides automatic synchronization capability (may be because out of selection of NIs-controlled files it is the most frequently changed ).  If the NIS master is running the rpc.yppasswdd daemon, any client system can update the NIS password map by using the yppasswd or passwd commands. You need first to ensure that the rpc.yppasswdd daemon is running on the NIS master server

# /usr/lib/netsvc/yp/rpc.yppasswdd /$PWDIR/passwd -m passwd

When users change their NIS passwords, the rpc.yppasswdd daemon updates the NIS master’s /$PWDIR/passwd file and passwd map. The passwd map is then pushed to all slave servers.

If the daemon is running you can enter the passwd command on any NIS client.  passwd in Solaris 2.6 and higher check to see if the password file is managed by NIS, and invoke yppasswd if this is the case. The procedure of changing the password should end with the line "NIS entry changed on alpha" where alpha is the name of a NIS master.

$ passwd

Changing NIS password for joeuser on server1.
Old password:
New password:
Retype new password:
NIS entry changed on alpha

Updating the NIS Slave Server Map

The following steps manually update the NIS timezone map on the master server and propagate all maps to the slave servers:

1. Edit the source file on the NIS master, for example vi /etc/timezone
2. Remake and push the NIS maps to the slave servers. cd /var/yp; /usr/ccs/bin/make
3. If the push from the master fails, the following commands run on the slave server and manually “pull” only the timezone map from the master server /usr/lib/netsvc/yp/ypxfr timezone.byname
4. To pull all of the maps from the master server at once use the command ypinit -s nis_master

While the reliability of NIS is much better then NIS+ it is not 100% and sometimes maps fail to propagate. To ensure periodic updating and propagating of NIS maps on slave servers, it is recommended to run  ypxfr as cron job. Because maps have different rates of change, scheduling a map transfer by using the crontab command enables you to set specific propagation intervals for individual maps. The Solaris OE provides several template scripts in the /usr/lib/netsvc/yp directory that you can use and modify to meet your local site requirements. These scripts are useful when slave servers are down during NIS map propagations. When slave servers are down, they might not receive the update until the cron script run again unless you run a “safety valve” script on startup. Sun provides as an example the ypxfr_1perhour script that can be run hourly by cron:

... ... ...
PATH=/bin:/usr/bin:/usr/lib/netsvc/yp:$PATH
export PATH
# set -xv
ypxfr passwd.byname
ypxfr passwd.byuid

Building Maps with make

The Unix make utility that originally was created to simplify compilation and linking of large project is used to builds NIS maps (targets).  It is an overkill for such a simple purpose but as a universal mechanism such a usage makes sense. Make is well described in Sun's Introduction to the make Utility.  The make utility is essentially a build manager that maintains integrity of a collection of program modules, a collection of programs or a complete system - does not have be programs in practice can be any set of interdependent ( e.g. chapters of text in book being typeset).  The reasons for make creation were the following:

• It is time consuming to compile a .c module - if the module has been compiled before and not been altered there is no need to recompiled it. We can just link the object files in. However, it will not be easy to remember which files are in fact up to date. If we link in an old object file our final executable program will be wrong.
• It is error prone and laborious to type a long compile sequence on the command line. There may be many of our own files to link as well as many system library files. It may be very hard to remember the correct sequence. Also if we make a slight change to our system editing command line can be error prone.
• Dependencies can represent other targets that must be completely built before the original target is considered “made.”
• If we use the make utility all this control is taken care by make. In general only modules that have older object files than source files will be recompiled.

NIS maps also need to be build from the source files, the process somewhat similar to compilation of C programs. The dependencies as simple as they are in this case can be specified in make file.  Such a structure enables you to nest the target and dependency pairs at an arbitrary depth, letting you build complex hierarchical structures of user space.  Make programming is fairly straightforward for non-programmers: basically, we write a sequence of commands which describes how your target file can be constructed from source files.

The make utility receives its instructions from the Makefile file. The Makefile file is very similar to specialized shell and like shell uses variable definitions (called macros), targets, and dependencies.  A dependency rule has two parts - a left and right side separated by a :

left side : right side

The sample NIS Makefile file provided by Sun is located in the /var/yp directory and is composed of four main sections:

• The first section contains macro definitions.
• The second section contains the first target, all.
• The third section defines the final target and dependencies.
• The fourth section contains entries for each of the dependencies.

The first section of the Makefile file contains the following macro definitions:

#B=-b
B=
DIR =/etc
INETDIR=/etc/inet
RBACDIR=/etc/security
PWDIR =/etc
DOM = ‘domainname‘
NOPUSH = ""
ALIASES = /etc/mail/aliases
YPDIR=/usr/lib/netsvc/yp
SBINDIR=/usr/sbin
YPDBDIR=/var/yp
YPPUSH=$(YPDIR)/yppush
MAKEDBM=$(SBINDIR)/makedbm
MULTI=$(YPDIR)/multi
REVNETGROUP=$(SBINDIR)/revnetgroup
STDETHERS=$(YPDIR)/stdethers
STDHOSTS=$(YPDIR)/stdhosts
MKNETID=$(SBINDIR)/mknetid
MKALIAS=$(YPDIR)/mkalias

The second section of the Makefile file contains the list of targets. The first target is all.

all: passwd group hosts ipnodes ethers networks rpc services protocols \
netgroup bootparams aliases publickey netid netmasks c2secure \
timezone auto.master auto.home \
auth.attr exec.attr prof.attr user.attr audit.user

As you can see the all target lists all source files that NIS syncroninize and thus enables the entire set of NIS maps to be built by typing:

# cd /var/yp; /usr/ccs/bin/make

The all target is not considered to be built until each of its targets is first built. Each of the targets for all depends on another target.

You can add custom maps to NIS. In this case the name of the new map to be built should be added to the all target list (auto.direct in the following example).

all: passwd group hosts ipnodes ethers networks rpc services protocols \
netgroup bootparams aliases publickey netid netmasks c2secure \
timezone auto.master auto.home \
auth.attr exec.attr prof.attr user.attr audit.user auto.direct

Note – The fourth section is covered before the third section, because the fourth section continues the dependency thread introduced by the all target.

The fourth section of the Makefile file is pretty trivial and list dependencies in the target files, one per line

passwd: passwd.time
group: group.time
project: project.time
hosts: hosts.time
ipnodes: ipnodes.time
ethers: ethers.time
networks: networks.time
rpc: rpc.time
services: services.time
protocols: protocols.time
netgroup: netgroup.time
bootparams: bootparams.time
aliases: aliases.time
publickey: publickey.time
netid: netid.time
passwd.adjunct: passwd.adjunct.time
group.adjunct: group.adjunct.time
netmasks: netmasks.time
timezone: timezone.time
auto.master: auto.master.time
auto.home: auto.home.time
auth.attr:auth.attr.time
exec.attr:exec.attr.time
prof.attr:prof.attr.time
user.attr:user.attr.time
audit.user:audit.user.time
$(DIR)/netid:
$(DIR)/timezone:
$(DIR)/auto_master:
$(DIR)/auto_home:
$(PWDIR)/shadow:
$(DIR)/auth_attr:
$(DIR)/exec_attr:
$(DIR)/prof_attr:
$(DIR)/user_attr:
$(DIR)/audit_user:

The third section of the Makefile file defines the final target and dependencies, as well as instructions on how to build each map in the domain, for example:

auto.direct.time: $(DIR)/auto_direct
-@if [ -f $(DIR)/auto_direct ]; then \
sed -e "/^#/d" -e s/#.*$$// $(DIR)/auto_direct \
| $(MAKEDBM) - $(YPDBDIR)/$(DOM)/auto.direct; \
touch auto.direct.time; \
echo "updated auto.direct"; \
if [ ! $(NOPUSH) ]; then \
$(YPPUSH) auto.direct; \
echo "pushed auto.direct"; \
else \
: ; \
fi \
else \
echo "couldn't find $(DIR)/auto_direct"; \
fi

Note: make is a very old utility and the syntax convention are pretty bizarre. The proper use of tabs nd spaces in the Makefile file is critical. See man for make command for details.

Creating the list of slave servers on the master

The initial conversion of source files into maps on the master server is done using the command:

/usr/sbin/ypinit -m

The ypinit command prompts for a list of  NIS slave servers. Type the name of the server on which you are working, along with the names of your NIS slave servers.

• The ypinit command asks whether you want the procedure to terminate at the first nonfatal error or to continue despite nonfatal errors. You should  answer yes.
• The ypinit command can also ask whether the existing files in the /var/yp/domainname  directory can be destroyed. This message is displayed only if NIS has been previously installed. You should answer yes in ordere to be able  to install a new version of NIS maps.

After the ypinit command has constructed the list of servers, it invokes the make command.

This program uses the instructions contained in the Makefile file (either the default one or the one you modified) located in the /var/yp directory. The make command strips any remaining comment lines from the source files and runs the makedbm function on them, creating the appropriate maps and establishing the name of the master server in each map.

References

Unix make

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019