Product Support Document (PSD) for Sun NIS
Revision: 2.0
Date: April 21, 1998
TABLE OF CONTENTS
=================
1.0: About NIS
2.0: Debugging NIS
2.1: ypwhich
2.2: ypcat
2.3: ypmatch
2.4: getent
2.5: Files
2.6: The Network
3.0: Common How Tos
3.1: How to Setup a NIS Master Server?
3.2: How to Setup a NIS Slave Server?
3.3: How to Add a New NIS Slave to an Existing NIS Environment?
3.4: How to Setup a SunOS NIS Client?
3.5: How to Setup a Solaris NIS Client?
3.6: How to Run NIS from a Remote Subnet?
3.7: How to Remove NIS From a SunOS Client?
3.8: How to Remove NIS From a SunOS Server?
3.9: How to Remove NIS From a Solaris Client?
3.10: How to Use DNS without NIS?
3.11: How to Start yppasswd on the NIS Master Server?
3.12: How to Change a password in the NIS map?
3.13: How to Change IP address, Host Name, or domainname of a NIS machine?
3.14: How to Set Up Secure NIS?
3.15: How to Use Netgroups?
4.0: Some Frequently Asked Questions
4.1: Miscellaneous Questions
4.2: ypinit Problems
4.3: NIS make Problems
4.4: NIS Update Problems
4.5: General NIS Client Problems
4.6: ypcat Problems
4.7: NIS passwd Problems
5.0: Patches
5.1: SunOS NIS Patches
5.2: Solaris NIS Patches
6.0: Known Bugs & RFEs
6.1: Bugs
7.0: References
7.1: Important Man Pages
7.2 Sunsolve Documents
7.3 Sun Educational Services
7.4: Solaris Documentation
7.5: Third Party Documentation
7.6: RFCs
8.0: Supportability
9.0: Additional Support
1.0: About NIS
This PSD documents a wide variety of information concerning NIS as
implemented in the SunOS and Solaris operating systems. It is intended
as both an introduction to NIS, and as a guide to the most common
problems. There are many more complete references to NIS, a few of
which are noted in section 7.0.
In this document, the terms YP and NIS should be understood to be
interchangeable. YP was the original name for the information service
now known as NIS. NIS/YP is not the same thing as NIS+.
The following terms are crucial for an understanding of NIS:
A NIS SERVER is a machine which responds to requests for NIS service.
The MASTER server actually contains all of the files which the NIS
maps are built from, while the SLAVE servers just contain copies of
those maps. The YPSERV daemon is run on all servers. It is what
answers NIS requests. YPXFRD is usually run on the master server, to
speed up transfers to the slaves.
A NIS CLIENT is a machine which is allowed to access the NIS maps.
The YPBIND daemon takes care of making these requests.
All of NIS is bundled with SunOS. However, on Solaris versions from
2.0 up to 2.5.1, the bundled software only allows machines to be set up
as NIS clients (Solaris 2.6 now has the NIS server side software back in
it). If you want to set up a pre-2.6 Solaris machine as a NIS server
you will need to download or purchase NSKIT. Please contact your local
Sun sales office.
A seperate PSD exists for NSKIT specific issues if you are running
into problems involving the NSKIT, you should request the NSKIT PSD
from SunService. For all intents and purposes NSKIT on Solaris 2.x is
administered the same as NIS on SunOS 4.1.x except for some minor
differences such as directory locations and source and Makefile differences
2.0 Debugging NIS
2.1: ypwhich
ypwhich will show you which NIS server you are currently bound to:
%% /usr/bin/ypwhich
rainbow-16
This is useful to know, because in some cases, one particular NIS
server will give incorrect info, while everything else is fine. If you
find that only one of your slave servers gives outdated information,
you will probably want to follow the instructions in Section 3.3, to
update your ypservers map information. You can also use ypwhich to
learn what server a remote machine is bound to. This might be useful
if you wish to examine load balance, or something similar:
%% /usr/bin/ypwhich rainbow-16
rainbow
The above showed that the remote machine, rainbow-16, is bound to the
server rainbow.
2.2: ypcat
ypcat is one of the most obvious commands to use for NIS debugging.
If, for example, a user can not log in, you might want to consult
ypcat, to verify that their passwd does appear in the NIS map:
%% /usr/bin/ypcat passwd
ypcat will not always gives you the full info, because by default it
does not show the column that the map is being indexed (or keyed) off
of. To ensure that you are seeing everything, you can run ypcat with
the -k option:
%% /usr/bin/ypcat -k passwd
2.3: ypmatch
ypmatch can be used to look at an individual item in a NIS map, with
the follow syntax:
%% ypmatch entry mapname
For example, to find the host 'psi' in the hosts map, you would type:
%% ypmatch psi hosts
Essentially, the information you get with ypmatch is the same as that
available with ypcat, but is slightly easier to read.
2.4: getent
On a Solaris machine, you can use the command getent to look up NIS
entries, as follows:
%% getent mapname entry (opposite order of ypmatch)
For example:
%% getent passwd root
The difference between ypmatch and getent is that ypmatch only looks
up entries in the NIS maps, while getent consults the nsswitch.conf
file, and then looks up the query according to that order. For
example, if nsswitch.conf reads as follows:
passwd: files nis
The above getent would first have looked at the /etc/passwd file, then
the NIS passwd map.
Essentially, getent should do exactly the same lookup as any normal
program would. If you find that you have to troubleshoot something
specific in your NIS database you should use the yp commands instead
to make sure you dont get the information from your local files or DNS.
getent is only documented as able to consult passwd and groups.
However, you may be able to getent hosts and other databases on newer
OS'es.
2.5: Files
If the above commands do not make it clear what your problem is, you
might want to consult the NIS files. If a NIS server is doing
something incorrect during map distribution, you should look at the
/var/yp/Makefile on the NIS server. It is particularly helpful to
compare the Makefile to the original one that was shipped with the
system:
%% diff /var/yp/Makefile /usr/lib/NIS.Makefile
If the files are substantially different, you should revert to the
original, and see if that fixes the problem.
Note that Solaris NSkit or Solaris 2.6 does not include an original
Makefile in /usr/lib. As with most config files you should consider
making a backup copy of the file before making changes.
If a Solaris NIS Client is not correctly accessing NIS, you should
consult the file /etc/nsswitch.conf, and verify that it includes a
reference to NIS. SunOS NIS clients, once bound to a NIS domain,
will continue to use NIS and will not look at their local files for
any lookups.
2.6: The Network
If all else fails, especially in the case of very intermittent
problems, you may wish to investigate your overall network for
problems. Most problems of this sort are due to either hardware issues
or performance problems. These topics are beyond the scope of the help
that SunService can provide. Consult Sections 8.0 amd 9.0 for where
you can get additional assistance from within Sun.
3.0 Common How Tos
3.1: How to Setup a NIS Master Server
First, initialize the NIS Makefile:
# cp /usr/lib/NIS.Makefile /var/yp/Makefile
(Note that on Solaris 2.x you will already have a Makefile in that
directory providing you have NSKit installed or are running 2.6 or newer.)
Afterwards, you will want to set your nis-domain. In the example
below, simply replace 'example-name' with the name that you have
chosen for your nis-domain. Note that this nis-domain name does not
have to have any relationship to your DNS domain name. It should
simply be a name which is set identically on all your NIS machines.
It is actually more secure to use a nis-domain-name that is totally
unrelated to your DNS domain.
# domainname example-name
# domainname > /etc/defaultdomain
If you are planning on using DNS with NIS, you will need to change the
/var/yp/Makefile to reflect this. Remember that SunOS 4.1.x machines
cannot do DNS lookups on their own and have to submit their requests
to the NIS server which then does the DNS lookup for them.
Near the top of the Makefile you will find the following lines:
# Set the following variable to "-b" to have NIS servers use the domain name
# resolver for hosts not in the current domain.
#B=-b
B=
In order for DNS to work with NIS, you must change the last two lines,
as follows:
B=-b
#B=
Finally, you can initialize NIS by running the ypinit script. When
ypinit queries you for server names, make sure you include all slave
servers that you are planning to set up in the near future:
# cd /var/yp
# /usr/etc/yp/ypinit -m
If you wish to immediatelly start NIS, you can simply start the NIS
daemons on your server:
# ypserv
# ypbind
# ypxfrd
Afterwards, you should make sure that ypserv, ypbind and ypxfrd are
all in your /etc/rc.local file (if on SunOS 4.1.x), and not commented out.
On Solaris 2.x these daemons will be started by the S71rpc script in your
/etc/rc2.d directory for you automatically on the next boot (it checks for
and starts up the appropriate daemons if the /etc/defaultdomain file exists
and you have the directory /var/yp/`domainname` (which ypinit made for you)).
Assuming you made the proper change to your rc.local file (if you are on SunOS
4.1.x) the next reboot for either OS version will start NIS services for you.
3.2: How to Setup a NIS Slave Server?
Start off by setting your nis-domain name on your slave. This name
(example-name below) must be identical to the nis-domain name on your
NIS master.
# domainname example-name
# domainname > /etc/defaultdomain
Start the ypbind daemon:
# ypbind
Verify the NIS master knows about the slave Server
# ypcat -k ypservers
master-name
slave-no-1
slave-no-2
new_slave
IF THE NIS SLAVE IS NOT IN THE LIST, USE THE PROCEDURE IN SECTION
3.3 of this document.
Otherwise:
Run the ypinit script. master-server-ip in the example below must be
the ip address of the master server:
new_slave# ypinit -s master-server-ip
(/usr/sbin/ypinit on Solaris 2.x)
(/usr/etc/yp/ypinit on SunOS 4.1.x)
NOTE: If you get the following error from ypinit:
"Can't enumerate maps from $master. Please check that it is running"
then you should rerun ypinint and specify the hostname of the
master server
e.g. ypinit -s master-hostname
You can immediatelly get your machine running as a NIS slave by
running ypserv:
new_slave# ypserv
Afterwards, you should make sure that ypserv and ypbind are both in
your /etc/rc.local file, and not commented out (SunOS 4.1.x ONLY).
Whenever you reboot your machine at this point, NIS should
automatically be started.
3.3: How to Add a New NIS Slave to an Existing NIS Environment?
When you initialize your NIS master, you give it a list of NIS slaves.
If you later add additional NIS slaves, or remove one of these
original NIS slaves, you must update the NIS list of servers. This is
done entirely from the NIS master server. First, you must output the
list of NIS servers:
nis_master# cd /var/yp/`domainname`
nis_master# makedbm -u ypservers > /tmp/ypservers
nis_master# vi /tmp/ypservers add new slave to bottom of list.
(don't change order or format.)
nis_master# makedbm /tmp/ypservers ypservers
(/usr/sbin/makedbm on Solaris 2.x)
verify addition via:
nis_master# ypcat -k ypservers
now go to the new slave (it must already be a client... ypinit -c)
Run the ypinit script. master-server-ip in the example below must be
the ip address of the master server:
new-slave # /usr/etc/yp/ypinit -s master-server-ip
NOTE: If you get the following error from ypinit:
"Can't enumerate maps from $master. Please check that it is running"
then you should rerun ypinint and specify the hostname of the
master server
e.g. /usr/etc/yp/ypinit -s master-hostname
You can immediatelly get your machine running as a NIS slave by
running ypserv:
new-slave # ypserv
Afterwards, you should make sure that ypserv and ypbind are both in
your /etc/rc.local file, and not commented out (SunOS 4.1.x ONLY).
Whenever you reboot your machine at this point, NIS should
automatically be started.
3.4: How to Setup a SunOS NIS Client?
(Both this section and the next one assume that you have yp servers
on the same subnet as they will broadcast bind (broadcasts do not
typically cross routers) to a server. If no need to bind to a
specific server across a subnet please see section 3.6)
Start off by setting your nis-domain name. This name (example-name
below) must be identical to the nis-domain name on your NIS master.
# domainname example-name
# domainname > /etc/defaultdomain
Start the ypbind daemon:
# /usr/etc/ypbind
You should also make sure that ypbind is listed in your /etc/rc.local
file. It will be started from S72inetsvc in /etc/rc2.d on a Solaris
2.x machine.
3.5: How to Setup a Solaris NIS Client?
Start off by setting your nis-domain name. This name (example-name
below) must be identical to the nis-domain name on your NIS master.
# domainname example-name
# domainname > /etc/defaultdomain
Put the NIS nsswitch file in place.
# cp /etc/nsswitch.nis /etc/nsswitch.conf
If you are using DNS as well, you will want to modify the hosts: line,
by adding dns, as follows:
hosts: files nis dns
You will also need an /etc/resolv.conf file for DNS to work. See the
DNS PSD or the man page for resolv.conf for details on this.
The normal method for starting NIS under Solaris, is to give it a list
of yp servers. They may be supplied by simply running ypinit, answering
the questions, and then rebooting the machine:
# ypinit -c
If you prefer to start NIS in the less secure broadcast mode, rather than
running ypinit, then execute:
# mkdir -p /var/yp/binding/`domainname`
NIS checks for the existence of this directory before binding to the domain.
Reboot the client machine and it will come up running NIS in broadcast mode.
Broadcast mode is considered less secure because it sends a broadcast to
the network for a server for its domain. It would be possible then for
a fake server to reply and give you login requests and trap your passwords,
etc. Specifying a list of servers to bind to tends to make it more secure
than just asking for any server that will reply to you
3.6: How to Run NIS from a Remote Subnet?
By default, you can not run a NIS client if your NIS server is on a
different subnet. This is because NIS usually runs in broadcast mode,
which means that it only queries local servers when starting.
In Solaris, if you want to bind to a remote server, simply initialize
the client with the -c flag:
# ypinit -c
(/usr/sbin/ypinit on Solaris 2.x)
In SunOS, instead of running ypbind normally you must run it with the
-ypsetme option, and then run ypset, using the NIS server's ip address
as an argument:
# ypbind -ypsetme
# ypset nis-server-ip
(/usr/lib/netsvc/yp/ypbind on Solaris 2.x)
(/usr/sbin/ypset on Solaris 2.x)
In this case, be sure to also modify the rc.local file appropriately.
It is recommended that you have at least one NIS slave on each subnet.
If you do this, only your NIS slave server will need to follow the
above procedures all other machines on the subnet will be able to run
normally, and they will bind to the local NIS slave.
3.7: How to Remove NIS From a SunOS Client?
To remove NIS from a SunOS client, remove the NIS files, as follows:
# rm -r /var/yp/`domainname`
# rm /etc/defaultdomain
If you just want to temporarily disable NIS, you should move the
objects to different names, rather than removing them.
Afterwards, reboot the machine.
3.8: How to Remove NIS From a SunOS Server?
Removing NIS from a SunOS Server is a two-part process. First, you
must edit the ypservers map on your NIS master, removing the defunct
slave from the list of servers. Section 3.3 explains how to modify the
ypservers map. Second, on the NIS slave, you must follow the normal
procedure to remove NIS, described in Section 3.7 above.
3.9: How to Remove NIS From a Solaris Client?
To remove NIS from a Solaris client, remove the following NIS files:
# rm -r /var/yp/binding/`domainname`
# rm /etc/defaultdomain
If you just want to temporarily disable NIS, you should move the
objects to different names, rather than removing them.
Afterwards, you must also modify the nsswitch.conf file:
# cp /etc/nsswitch.files /etc/nsswitch.conf
If you are continuing to run DNS, you will want to modify the hosts:
line of the nsswitch.conf, by adding dns:
hosts: files dns
Finally, reboot the machine.
3.10: How to run DNS without NIS
If you are running DNS on a SunOS machine, without NIS, you will find
that it will react in a very erratic and unexpected manner. Lookups
might not go to DNS at all, or they might go to DNS only in some
specific cases. In order to run DNS in a Sun-supported manner, you
should setup at least a minimal NIS configuration where you would have
your SunOS clients bind to your NIS master and slaves and allow them to
do the DNS lookups for your clients.
If you are unwilling to do this, Sun SRDB #3886 explains how to modify
your libc to remove any NIS dependencies. This procedure does work,
but SunService is unable to support DNS on sites which use this
configuration.
On Solaris machines, you can run DNS without NIS by just modifying
the 'hosts:' line in your /etc/nsswitch.conf file. See the man page
for nsswitch.conf for how to do this.
3.11: How to Start yppasswd on the NIS Master Server?
rpc.yppasswdd must be run on the master server, in order for users to
be able to change their yppasswds. To start rpc.yppasswdd from the
command line, execute the following:
# /usr/etc/rpc.yppasswdd /etc/passwd -nosingle -m passwd DIR=/etc
If you are storing your passwd file somewhere besides /etc, you will
need to change the '/etc/passwd' and 'DIR=/etc' arguments.
Note: the -nosingle option works around a bug seen in various SunOS
releases.
On SUNOS 4.x :
To start the yppasswdd daemon automatically after system reboot on
your NIS master server, add the following to /etc/rc.local:
# Automate rpc.yppasswdd startup
/usr/etc/rpc.yppasswdd /etc/passwd -m all
echo -n ' yppasswdd'
Its best to use "all" instead of just passwd, because when updating
the passwd map, the netid also needs to be updated as well. Usually
there isnt a need to specify the DIR= option, make will automatically
use /var/yp.
NOTES
The password file specified to rpc.yppasswdd may not be a
link.
3.12: How to Change a password in the NIS map?
Previous to Solaris 2.5.1, from any NIS client, any user may run
the command:
# yppasswd
As of 2.5.1 you should be using the passwd command since
it follows the naming services currently in use on the machine
and changes the appropriate password database (from the
/etc/nsswitch.conf file). Read the man page for passwd(1) for
more details. All three commands: passwd, nispasswd (for NIS+) and
yppasswd (for NIS) are hard links to the same binary
3.13: How to Change IP address, Host Name, or domainname.
If you are changing the IP address, host name or domainname of a NIS
machine, you must tear down NIS on the affected machine, make the
changes, and then rebuild it. The standard procedure is:
1) remove the NIS files and reboot, per Section 3.7 or 3.8
2) edit the appropriate files to make the desired changes
3) rebuild your NIS environment per sections 3.1 through 3.5
If you are removing a NIS master server permanently you should choose
a new machine to be the master and update the ypservers file and rebuild
that new machine as the master.
If you are removing a NIS slave server permanently you should make sure
you update the ypservers file
3.14: How to Set Up Secure NIS?
SunOS 4.1.3_u1 and 4.1.4 allow you to increase security on your NIS
server, as do older versions of SunOS, with patch 100482 installed. If
you would like to restrict who may retrieve your NIS maps, you should
create the file /var/yp/securenets. The contents of this file should
be a number of lines which each read:
netmask address
For example, if you only wanted the machines 150.101.16.28 and
129.45.16.29 to be able to retrieve your NIS maps, you could enter the
following two lines:
255.255.255.255 150.101.16.28
255.255.255.255 150.101.16.29
If you wanted everyone on the network 150.101.16.0 to be able to
retrieve your maps, you could enter the line:
255.255.255.0 150.101.16.0
CAUTION: If you are attempting to setup a new client on a new subnet
and are having problems getting it to bind to a server on the remote
network check the server to see if you have enabled securenets. If
so, you will not be able to get the machine to bind until you enable
that subnet.
3.15: How to Use Netgroups?
Netgroups are only available to sites running NIS or NIS+. There
is no local files implementation of netgroups. They are used to
group machines or users together in order to make certain sysadmin
tasks easier. The man page for negroups defines example useage of
netgroups quite nicely as does Managing NFS and NIS by Hal Stern
(An O'Reilly and Associates Nutshell book).
A standard netgroup triple reads as follows:
(hostname, username, domainname)
A example netgroup line reads as follows:
netgroup-name triple1 triple2 triple3
Though netgroup triples group together hostnames, usernames and
domainnames, nothing really reads them in that manner. Thus, you'll
usually want to use a triple just to list hosts or users i.e. in order
to share NFS file systems or restrict logins to a system.
For example, the following would be a typical /etc/netgroup file, on a
NIS master:
# cat /etc/netgroup
root-users (,user1,), (,user2,), (,user3,)
trusted-machines (machine1,,), (machine2,,), (machine3,,)
Netgroups are limited to 1024 characters in size. If you need to put
together a longer netgroup, you can do so by making a meta-group:
meta-group netgroup1 netgroup2
netgroup1 (,user1,), (,user2,)
netgroup2 (,user300,), (,user301,)
The following netgroup will not do what you expect:
bogus-group (machine1,user1,), (machine2,user2,)
You might think this means user1 at machine1 and user2 at machine2,
but in actuality, it is a netgroup of two users (user1 and user2) and
two machines (machine1 and machine2). Always seperate out machine and
user netgroups, as shown in the /etc/netgroup example above, and you
will avoid confusion. Note that we reference the /etc/netgroup file
but this file only exists in order to be your 'flat' source file. This
file must be in your NIS or NIS+ databases.
User netgroups can be used in the /etc/passwd file (and /etc/shadow if
using Solaris 2.x).
The following entry would include all of the users in the root-users
group in your /etc/passwd + /etc/shadow files:
# cat /etc/passwd
...
+@root-users
# cat /etc/shadow
...
+@root-users
On Solaris 2.x you must also edit /etc/nsswitch.conf in order to use
that +/- syntax as follows:
passwd: compat
group: compat
Machine netgroups can be used when exporting file systems. The
following entry in /etc/exports on a SunOS machine would allow
machines in the trusted-machines netgroup access to the /export
filesystem:
# cat /etc/exports
/export -access=trusted-machines
Remember that you must be running NIS or NIS+ for netgroups to work.
Simply having an /etc/netgroup file will do nothing it is ONLY the
netgroup NIS or NIS+ map which is used. Do a man on ypfiles to find
out the names of the NIS or NIS+ maps.
rpc.yppasswdd's lock file is '/etc/.pwd.lock'. The admin can prevent
the daemon from doing the edit by making that file unwritable ("chmod
000 file" should do it). She should see a syslog msg from the daemon
(if a pw change is attempted) "...Passwd file(s) busy...". She should
be sure to remove that lock file (or make it writable) when she is
done with the hand edit.
Another (if a bit crude) workaround is to kill the daemon and restart
when the hand edit is done.
4.0 Some Frequently Asked Questions
4.1: Miscellaneous Questions
Q: Does NIS support password aging?
A: No.
4.2: ypinit Problems
Q: Why does 'ypinit -m' crash with the following error:
...
"Running /var/yp/Makefile..."
"make: Fatal error: No arguments to build"
"Error running Makefile."
...
A: /var/yp/Makefile does not exist. Copy it over before rerunning
ypinit:
# cp /usr/lib/NIS.Makefile /var/yp/Makefile
# cd /var/yp
# ypinit -m
Q: Why does 'ypinit -s' crash with the following error, when trying to
initialize a slave:
"can't bind for domain <domainname>"
"reason: internal NIS server or client error"
"can't enumerate maps from <master server>"
A: Your slave was not running ypbind, or it does not have access to
NIS currently. You can verify this by running 'ypwhich' you will see
that you are not currently bound to a NIS domain. Try following the
procedure in Section 3.2 precisely. If that does not work, you may be
on a different subnet than your master, and need to initialize ypbind
per the instructions in Section 3.6.
We have also seen the error corrected by specifying the hostname
of the master server instead of the IP address.
Q: Why does 'ypinit -s' crash with the following error, when trying to
initialize a slave:
"ypxfr(get_misc_recs) RPC call to <master> failed: RPC: Timed out."
A: ypxfrd is not running on the NIS master server. Login to the master
server and start it:
# ypxfrd
4.3: NIS Make Problems
Q: Why does yppush refuse to transfer my brand new map when I do a make?
-or-
Q: Why do I get the following message when doing a make:
"Can't bind master to send ypclear message to ypserv for map mail.aliases."
{ See also the next question for another possible answer to this error. }
There are two solutions to this problem. If you are running a mix of
operating systems on your network (Solaris, IRIX, HPUX) you should probably
consider the second solution since the maps should be built by the slave
servers themselves as the dbm format may be different on different OS'es.
A1: ypxfr is confused, because copies of the new map do not exist on
one of your NIS slaves. You must manually copy the maps.
This can be done by copying /var/yp/`domainname`/map.* from the master
to /var/yp/`domainname` on each of the slaves, using either rcp or ftp.
A2: First make the map on your master without pushing it to the slaves
since it is the push (and thus the resulting ypxfr) to hang:
# cd /var/yp
# make -DNOPUSH mapname.byname mapname.bynumber
Now, on each slave server, transfer the map over from your master server:
# cd /var/yp
# ypxfr -h NIS-master mapname.byname
Q: Why do I get the following message when doing a make:
"Can't bind master to send ypclear message to ypserv for map mail.aliases."
A: This error can sometimes occur if the servers are not bound to the
master. If you see it, you should find out what your servers are bound to:
# ypwhich
If you find your master (or slave) is bound to something other
than the master, force it to bind to the master by killing ypbind on
that machine and then restarting it like this:
# ypbind -ypsetme
# ypset master-nis-ip
Q: Why do I get the following error when I run a make:
"can't get address for server ."
A: There is a blank line in your ypservers map. You can verify this by
running the following:
ypcat -k ypservers
Remove the blank line by following the standard procedure for
adjusting the ypservers map that is described in Section 3.3.
Q: Why do I get the following errors when making the netgroup map:
"entry too big, problem storing netgroup"
"error code 1"
A: netgroup maps have a maximum of 200 entries, or 1024 characters per
line. You will get the above errors if you have a netgroup larger than
this. You can correct this, by breaking your netgroup down into
subgroups, for example:
big-group: big-group-sub1 big-group-sub2
big-group-sub1: half of huge netgroup
big-group-sub2: half of huge netgroup
4.4: NIS Update Problems
Q: Why doesn't my new slave server get NIS maps when they are made?
A: You have not added the new slave to your ypservers map. You can
verify this by examining the ypservers map:
# ypcat -k ypservers
Section 3.3 explains how to update the ypservers map.
You may also have problems if your slave server doesn't already have
copies of the maps. See the first questions in section 4.3 for how to
remedy this situation.
Q: Why does my groups map not get correctly distributed?
A: Because the netid was not distributed, the groups map does not have
all the correct info. Run the following on the master to ensure that
the netid is also distributed:
# cd /var/yp
# rm netid.time
# make netid
For groups updates to occur, both groups and netid must be distributed.
It is always best to just run 'make' and let the processes make and distribute
whatever maps have changed. Running make source-file may not update all
maps that require changes.
Q: Why is my change to the NIS maps not showing up?
A1: You did not do a make on the NIS master. You can verify this by
examining the map with ypcat. To resolve the problem, go to the NIS
master and make the files:
# cd /var/yp
# make
A2: If make has been run, you are probably bound to a NIS slave which
is not getting updates. You may wish to retry the make, in case the
NIS slave was down the first time it was run. Otherwise, you probably
need to update the ypservers map. Run ypwhich to see which slave you
are bound to, and then examine the ypservers map to verify the
problem:
# ypwhich
slave-3
# ypcat -k ypservers
master
slave-1
slave-2
If you find that the name which appears in 'ypwhich' does not appear
when you look at the ypservers map, follow the instruction in Section
3.3 to update your ypservers map.
4.5: General NIS Client Problems
Q: Why do I get the following error message on my NIS client:
"NIS server not responding for domain..."
A1: Your NIS server is currently down. Verify that you can ping it
by IP address and if that works, login and check for the ypserv process.
If it is not running then start it up.
A2: The netmasks file on your NIS client is incorrect, and thus the
netmask and broadcast addresses are being set wrong. This can be
verified by booting the client single user, and then comparing the
/etc/netmasks file on the client and server. They should be identical.
A3: Your server is on a different subnet from your client, and you
have not followed the appropriate procedures to take this into
account. Examine Section 3.6 for an explanation of what to do in this
case. The machine will probably need to be booted single user before
these changes can be made.
A4: If you are seeing "NIS server not responding" intermittently, but
NIS is working in between these messages, your network is likely
overloaded. This is a performance issue that SunService can not
provide assistance on. Consult Sections 8.0 and 9.0 for alternatives
in this situation.
Q: Why can a user not log into my Solaris machine, even though I can
see his passwd entry on that machine with 'ypmatch his-name passwd'?
A: Your nsswitch.conf is set up wrong on the client. Section 3.5 gives
info on putting the nsswitch.conf file in place when setting up a
Solaris client.
4.6: ypcat Problems
Q: How come I can't ypcat a map that I know exists in NIS?
A1: You might have this problem when you try and look at a map in NIS,
as follows:
# ypcat netmasks
no such map in server's domain
This occurs because NIS maps actually have unique names that are
dependent upon how the map is indexed. Certain NIS maps (ethers,
group, hosts, aliases, passwd, protocols, services) have standard
nicknames, to make them easier to access. Run ypcat -x to see the list
of aliases:
# ypcat -x
Use "passwd" for map "passwd.byname"
...
You can access maps without aliases by using the real name. For
example, the real name for the netmasks map is netmasks.byaddr:
# ypcat netmasks.byaddr
If you cd into /var/yp/`domainname` on your master server, you will
see the complete list of actual NIS map names. Ignore the .dir and
.pag suffixes.
A2: It may also be that the server you are bound to does not have that
map on it. Do a ypwhich to find out what machine you are bound to. If
for example, you are bound to a slave server and you cannot ypcat aliases
you should check on both that slave server and the master server in the
/var/yp/'domainname' directory for the existence of files called
mail.aliases.dir and .pag Chances are your master has that map while
the slave does not. Follow the procedure listed in the first question
in section 4.3 for how to remedy this situation.
Q: Why does ypcat show incomplete info?
A: You might find that when you do a ypcat of a map, some of the info
is missing, for example:
# ypcat netmasks.byaddr
255.255.255.0
255.255.255.0
In this case, you should run ypcat with the -k option, which also
shows you the column that is being indexed off of:
# ypcat -k netmasks.byaddr
150.101 255.255.255.0
150.102 255.255.255.0
Q: After I add an entry to a source file and run a make I don't see it
in the output of ypcat?
A: NIS maps are not guaranteed to list the information in the same order
as it is in your source files due to the dbm format. Some other things to
be sure of is that you 1) made the change on your NIS master and not on
a slave machine (see next paragraph), 2) you made the change to the source
file that your NIS Makefile points to and not some other local copy, and
3) the yppush or ypxfr completed in order to give the slave server a new
copy of the map.
ypwhich -m on any machine in the same domain should always report the same
master as owning the map. If you have any discrepancies in the output you
should make sure that you are only running a make on your master and not
on a slave machine.
Q: Why, when I ypcat a map, do I see multiple lines that are exactly the
same sometimes?
A: For example, if you see this:
# ypcat hosts | grep machineA
192.115.12.1 machineA mailhost datehost loghost
192.115.12.1 machineA mailhost datehost loghost
192.115.12.1 machineA mailhost datehost loghost
192.115.12.1 machineA mailhost datehost loghost
This is because you are not seeing the keys that the map is indexed with.
You should ypcat -k the same map and grep for the same machine and you will
see this:
# ypcat -k hosts | grep machineA
machineA 192.115.12.1 machineA mailhost datehost loghost
mailhost 192.115.12.1 machineA mailhost datehost loghost
datehost 192.115.12.1 machineA mailhost datehost loghost
loghost 192.115.12.1 machineA mailhost datehost loghost
This map is your hosts.byname map and everytime a lookup for host 'datehost'
or host 'machineA' is done the keys are examined in the map and then the
appropriate entry is returned. The fact that you have 4 machine names that
refer to the same IP address still requires you to have 4 differently keyed
entries in the map.
4.7: NIS passwd Problems
Q: Why do I get the following error when running yppasswd:
"can't find rpc.yppasswd server"
A: This means that you have not enabled rpc.yppasswdd on your NIS
master server. Section 3.11 explains how to do this.
Q: Why do I get the following errors when running yppasswd:
"RPC timed out"
"yppasswd couldn't change entry, RPC call failed."
or
"passwd file is busy"
A: The passwd file has gotten locked. If there is genuinelly nothing
else that should be using it, remove the lock file on the NIS master:
%% rm /etc/passwd.tmp
Q: How do I hand edit the passwd file when yppasswdd is running?
A: rpc.yppasswdd's lock file is '/etc/.pwd.lock'. The admin can prevent
the daemon from doing the edit by making that file unwritable ("chmod
000 file" should do it). She should see a syslog msg from the daemon
(if a pw change is attempted) "...Passwd file(s) busy...". She should
be sure to remove that lock file (or make it writable) when she is
done with the hand edit.
Another (if a bit crude) workaround is to kill the daemon and restart
when the hand edit is done.
5.0: Patches
The following is the list of all of the NIS related patches for 4.1.3,
4.1.3_u1, 4.1.4, 5.3 and 5.4. If you are having NIS problems,
installing the patches is a good place to start, especially if you
recognize the general symptoms noted below.
In order for a machine to be stable, all of the recommended patches
should be installed as well. The list of recommended patches for your
operating system is available from sunsolve.sun.com.
5.1: SunOS NIS Patches
102159 SunOS 4.1.3: modifications to create services.byservicename nis
Corrects an oversight in the NIS Makefile which prevented the
services.byservicename map from getting created, and slowed some NIS
lookups of the service map.
100342 SunOS 4.1 4.1.1 4.1.2 4.1.3: NIS client needs long recovery tim
Fixes an error in ypbind which slowed clients rebinding after
a server had been rebooted. Should be installed on NIS clients if
you are experiencing this problem.
100482 SunOS 4.1 4.1.1 4.1.2 4.1.3: ypserv and ypxfrd Jumbo Patch
Closes several NIS security holes, and also fixes some NIS/DNS
interoperability problems.
101435 SunOS 4.1.3_U1: ypserv and ypxfrd fix
Fixes an interoperability problem, between NIS and DNS, which could
cause DNS to fail if the first nameserver in the /etc/resolv.conf
was not available.
101718 SunOS 4.1.3_U1: C2 rpc.yppasswdd patch
If you are running C2 security, this patch must be installed, or you
will not be able to correctly change your passwd from NIS clients,
via yppasswd.
102617 SunOS 4.1.3_U1: POINT PATCH to ypbind
Fixes problems in binding to a slow NIS+ server running in compat mode
and other binding problems with slow servers.
102733 SunOS 4.1.4: mknetid fails when a user is in more than 16 group
Fixes a problem where the netid map would not get made correctly if
the user was in more than 16 groups.
5.2: Solaris NIS Patches
102707 SunOS 5.3: NIS commands fail to work with servers running in C2
102704 SunOS 5.4: Jumbo patch for NIS commands
102705 SunOS 5.4_x86: Jumbo patch for NIS commands
Fixes a variety of problems with ypcat, ypmatch, ypwhich, ypxfr,
makedbm and ypinit, many of them related to C2 security.
101973 SunOS 5.4: Jumbo patch for ypbind and libnsl
Corrects ypbind limitations, and also a bug which caused problems
connecting to a 4.1.3_u1 SunOS yp server.
In general, patch lists are too dynamic for this document to accurately
track so those listed are the latest at the last time this document was
updated. For a more complete list you should search sunsovle at
http://sunsolve.sun.com or if you have a specific question about a patch
you should open a call with SunService regarding the patch number and your
question about it.
6.0: Known Bugs & RFEs
6.1: Bugs
1078027 ypwhich -m does not dump maps if too many to list
1076214 ypwhich -m results in ypwhich(v2dumpmaps): can't get maplist: RPC:
These document a bug on older SunOS systems, where ypwhich -m will
get RPC errors if there are more than ~60 maps present in the NIS
domain. This Bug-ID has been closed as will not fix, as it is with
a dramatically older OS.
1184919 print daemon doesn't always start up
This documents a bug in SunOS which can occasionally cause failures
in printing service, usually with the error "printer/tcp: unknown
service". Other services called from the inetd may sometimes fail
similarly. This Bug-ID has been closed as will not fix. If you are
experiencing it, you may work-around it by putting a 'sleep 30'
statement after the start of 'ypbind' in your rc.local file.
There are probably more bugs or RFE's that may be outstanding or may
be fixed. The list is generally too dynamic for this document to track.
If you suspect a bug you should browse in sunsolve http://sunsolve.sun.com
or if you have a question about a particular bug you should place
a call into SunService with the appropriate bug number and your question
about it.
7.0: References
7.1: Important Man Pages
ypbind
ypcat
ypinit
ypmatch
yppasswd
yppasswdd
yppush
ypserv
ypwhich
ypxfr
ypxfrd
nsswitch.conf
7.2: Sunsolve Documents
There are a large number of Sunsolve documents concerning NIS.
The ones listed below are simply those which contain some information
that is not already in this document.
7.2.1: Sun Infodocs
2105 Convert existing NIS(yp) network to C2 domain
7.2.2: Sun SRDBs
3376 NIS Binding
4327 makedbm usage to view nis map
4734 NIS make fails with: unknown NIS client errorcode
5714 ypbind fails - access denied by server
5781 restricting logins on a machine using netgroups
6452 What is NIS
7.3: Sun Educational Services
Solaris 1.X System Administration
7.4: Solaris Documentation
_System and Network Administration_, Part #800-3805-10
The Network Information Service chapter provides some minimal
information on NIS.
7.5: Third Party Documentation
_Managing NFS and NIS_, by Hal Stern, published by O'Reilly &
Associates, ISBN #0-937175-75-7
The definitive source for NIS under SunOS. Largely the same for
Solaris, although there are some slight differences.
7.6: RFCs
None.
FORUM HardWare.fr
Bien sur qu'il est running mon serveur !!!!!! 