SunService Tip Sheet for Sun NIS
SunService Tip Sheet for Sun NIS
Revision: 1.0
Date: October 26, 1995
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 Tip Sheet 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.
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
actually answers the 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 actually making these requests.
All of NIS is bundled with SunOS. However, on Solaris machines, the
bundled software only allows machines to be set up as NIS clients. If
you want to set up a Solaris machine as a NIS server, you will need to
purchase NSKIT. Please contact your local Sun sales office.
A seperate info sheet exists for NSKIT specific issues; if you are
running into problems involving the NSKIT, you should request the
NSKIT PSD from SunService. Nothing in this document regarding NIS
servers is necessarily correct for Solaris machines running NSKIT.
2.0: Debugging NIS
==================
The following simple commands are sometimes helpful for debugging NIS
problems.
2.1: ypwhich
------------
ypwhich will show you which NIS server you are currently bound to:
% 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:
% 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:
% 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 off of. To
ensure that you are seeing everything, you can run ypcat with the -k
option:
% 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
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 root passwd
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.
Note that on Solaris prior to 2.4, getent may only be used to consult
passwd and groups files.
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 in the 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.
If a Solaris NIS Client is not correctly accessing NIS, you should
consult the file /etc/nsswitch.conf, and verify that it accesses NIS.
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
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.
% 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. 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, and not commented out.
Whenever you reboot your machine at this point, NIS should
automatically be started.
3.2: How to Setup a NIS Slave Server?
-------------------------------------
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:
% ypbind
Run the ypinit script. master-server-ip in the example below must be
the ip address of the master server:
% /usr/etc/yp/ypinit -s master-server-ip
You can immediatelly get your machine running as a NIS slave by
running ypserv:
% ypserv
Afterwards, you should make sure that ypserv and ypbind are both in
your /etc/rc.local file, and not commented out.
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.
Thus, 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:
% ypcat -k ypservers > /tmp/ypservers
At this point, you should edit /tmp/ypservers, to add the new slave
server's name. The syntax of the file is quite simple; each line
contains just the name of one NIS server. A typical file could read as
follows:
% cat /tmp/ypservers
master-name
slave-name-1
slave-name-2
slave-name-3
Finally, run the following commands to integrate your modified
ypservers information:
% cd /var/yp
% cat /tmp/ypservers | /usr/etc/yp/makedbm - /var/yp/`domainname`/ypservers
Afterwards, go to the machine you want to set up as a NIS slave, and
follow the normal procedure outlined in Section 3.2.
3.4: How to Setup a SunOS 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
Start the ypbind daemon:
% ypbind
You should also make sure that ypbind is listed in your /etc/rc.local
file.
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
The normal method for starting NIS under Solaris, is to give it a list
of yp servers. They may be done 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, reboot your client machine, and it will come up
running NIS in broadcast mode.
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
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
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 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 SunOS client, remove the NIS files, as following:
% 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, 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: dns files
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, as is described
elsewhere in this document.
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, with no problem.
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/rcp/rpc.yppasswdd /etc/passwd -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.
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/rcp/rpc.yppasswdd /etc/passwd -m passwd DIR=/etc; echo -n ' yppasswdd'
3.12: How to Change a password in the NIS map?
----------------------------------------------
From any NIS client, any user may run the command:
% yppasswd
3.13: How to Change IP address, Host Name, or domainname of a NIS machine?
--------------------------------------------------------------------------
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: remove the
NIS files and reboot, as per Section 3.7 or 3.8; edit appropriate
files to make the desired change; if you are not rebuilding the NIS
master, make sure to adjust the information in the NIS maps as well;
use Sections 3.1 through 3.5 to recreate the server or client.
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
150.101.16.29 to be able to retrieve your NIS maps, you could enter
the 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
3.15: How to Use Netgroups?
---------------------------
Netgroups are only available to sites running NIS or NIS+. They are
used to group machines or users together, to make certain sysadmin
tasks easier. A standard netgroup triple reads as follows:
(hostname, username, domainname)
A standard 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.
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,,)
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.
User netgroups can be used in the /etc/passwd file. The following
entry would include all of the users in the root-users group in your
/etc/passwd file:
% cat /etc/passwd
...
+@root-users
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 the
netgroup NIS or NIS+ map which is important.
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,
as per the instructions in Section 3.6.
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 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: NIS is confused because copies of the mail.aliases do not exist on
one of your NIS slaves. You must manually copy the mail.aliases maps
from the master server to each of the slaves. This can be done by
copying /var/yp/`domainname`/mail.* from the master to
/var/yp/`domainname` on each of the slaves, using either rcp or ftp.
Q: Why do I get the following error when I run make:
"can't bind master to send ypclear message to ypserv for map..."
A: This error can sometimes occur if the servers are not bound to the
master. If you see it, you should see what your servers are bound to:
% ypwhich
And 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:
% ypbind -ypsetme
% ypset master-nis-ip
Q: Why does ypxfr refuse to transfer my brand new map when I do a
make?
A: ypxfr is confused, because copies of the new map do not exist on
one of your NIS slaves. As above, 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.
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.
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.
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 run 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.
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: Why can I not ypcat a map that I know exists in NIS?
A: 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 odd names which 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.
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
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
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 sunsolve1.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 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.
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.
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.
7.0: References
===============
7.1: Important Man Pages
------------------------
ypbind
ypcat
ypinit
ypmatch
yppasswd
yppasswdd
ypserv
ypwhich
ypxfr
ypxfrd
7.2: Sunsolve Documents
-----------------------
There are a very 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.
8.0: Supportability
===================
SunService is not responsible for the initial configuration of your
NIS environment.In addition, SunService can not diagnose your NIS
performance problems, or suggest NIS tuning guidelines.
We can help resolve problems where NIS is not behaving correctly, but
in such cases the contact must be a system administrator who
understands how the NIS domain is setup.
9.0: Additional Support
=======================
For initial configuration, or NIS performance tuning guidelines,
please contact your local SunService office for possible consulting
offerings. Sun's Customer Relations organization can put you in touch
with your local SunIntegration or Sales office. You can reach Customer
Relations at 800-821-4643.