solaris nis map
Solaris NIS maps
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
Notes:
· Files ending in .dir contain an index in the .pag files containing the key/value pair for faster searching.
· An NIS record has a maximum size of 1024 bytes. This limitation applies to all NIS map files. For example, a list of users in a group can contain a maximum of 1024 characters in single-byte character set file format. NIS cannot operate correctly with map files that exceed this maximum.
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.
Map
Nickname
Source file
passwd.byname
passwd
/etc/passwd
passwd.byuid
group.byname
group
/etc/group
group.bygid
hosts.byaddr
hosts
/etc/hosts
hosts.byname
ethers.byaddr
ether
/etc/ethers
ethers.byname
networks.byaddr
networks
/etc/networks
networks.byname
rpc.bynumber
/etc/rpc
services.byname
service
/etc/service
protocols.byname
protocols
/etc/protocols
protocols.bynumber
netgroup
/etc/netgroups
netgroup.byhost
netgroup.byuser
bootparams
/etc/bootparams
mail.aliases
aliases
/etc/aliases
mail.byaddr
publickey.byname
/etc/publickey
netid.byname
/etc/passwd , /etc/groups /etc/hosts /etc/netid
netmasks.byaddr
/etc/netmasks
ypservers
N/A
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 hosts9.3.240.59 alpha9.3.240.58 beta127.0.0.1 loopback localhost # loopback (lo0) name/address10.47.1.2 gamma10.47.1.1 delta
To update the NIS maps (on the master server), complete the following steps:
Update the text files in your source directory (typically, /etc, unless it was changed in the Makefile file).
Change to the /var/yp directory
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:
Edit the source file on the NIS master, for example vi /etc/timezone
Remake and push the NIS maps to the slave servers. cd /var/yp; /usr/ccs/bin/make
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
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 runypxfr 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 ofNIS 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 shouldanswer yes.
The ypinit command can also ask whether the existing files in the /var/yp/domainnamedirectory can be destroyed. This message is displayed only if NIS has been previously installed. You should answer yes in ordere to be ableto 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 maps。
本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/10132/showart_421104.html
页:
[1]