Using the ypcat Command

The following example prints the information from the hosts database.
$ ypcat hosts
192.168.30.30 instructor instructor1
127.0.0.1 localhost loghost
192.168.30.45 gamma
192.168.30.44 alpha
192.168.30.43 delta
192.168.30.42 sigma
192.168.30.41 beta
...
<output truncated>
...
Using the ypmatch Command
The following example matches individual host entries.
# ypmatch beta localhost hosts
192.168.30.41 beta
127.0.0.1 localhost loghost
The following example matches a specific user in the password database.
# ypmatch joeuser passwd
joeuser:.dJJ.oofIqCLs:4005:10::/export/home/joeuser:/bin/ksh

Using the ypwhich Command

Perform the ypwhich command to identify the master server:
$ ypwhich
alpha
When used with the -m option, the ypwhich command lists all databases and the
name of the master server for each map.

$ ypwhich -m
...
<output truncated>
...
timezone.byname alpha
netmasks.byaddr alpha
netid.byname alpha
bootparams alpha
netgroup.byhost alpha
netgroup.byuser alpha
netgroup alpha
...
<output truncated>
...

Makefiles problems
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.
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.
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
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
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.
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.
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 sunsolve1.sun.com.

Recommended Links
 In case of broken links please try to use Google search. If you find the page please
notify us about new location
Top of Form
Bottom of Form
Top of Form

Search

Bottom of Form

Managing NFS and NIS, 2nd Edition Chapter 15 Debugging Network Problems
Freebsd handbook and freebsd beginners tutorial
19.9.8 Important Things to Remember
There are still a couple of things that you will need to do differently now that you are in an NIS
environment.
• Every time you wish to add a user to the lab, you must add it to the master NIS
server only, and you must remember to rebuild the NIS maps. If you forget to do this, the
new user will not be able to login anywhere except on the NIS master. For example, if we
needed to add a new user ``jsmith'' to the lab, we would:

• # pw useradd jsmith

• # cd /var/yp

# make test-domain

You could also run adduser jsmith instead of pw useradd jsmith.

• Keep the administration accounts out of the NIS maps. You do not want to be
propagating administrative accounts and passwords to machines that will have users that
should not have access to those accounts.
• Keep the NIS master and slave secure, and minimize their downtime. If somebody either
hacks or simply turns off these machines, they have effectively rendered many people
without the ability to login to the lab.
This is the chief weakness of any centralized administration system. If you do not protect
your NIS servers, you will have a lot of angry users!
19.9.11 Password Formats
One of the most common issues that people run into when trying to implement NIS is password format
compatibility. If your NIS server is using DES encrypted passwords, it will only support clients that are
also using DES. For example, if you have Solaris NIS clients in your network, then you will almost
certainly need to use DES encrypted passwords.
To check which format your servers and clients are using, look at /etc/login.conf. If the host is configured
to use DES encrypted passwords, then the defaultclass will contain an entry like this:

default:\

:passwd_format=des:\

:copyright=/etc/COPYRIGHT:\

[Further entries elided]

Other possible values for the passwd_format capability include blf and md5 (for Blowfish and MD5
encrypted passwords, respectively).
If you have made changes to /etc/login.conf, you will also need to rebuild the login capability database,
which is achieved by running the following command as root:

# cap_mkdb /etc/login.conf

Note: The format of passwords already in /etc/master.passwd will not be updated until a user changes
their password for the first time afterthe login capability database is rebuilt.
Next, in order to ensure that passwords are encrypted with the format that you have chosen, you should
also check that the crypt_default in /etc/auth.confgives precedence to your chosen password format. To
do this, place the format that you have chosen first in the list. For example, when using DES encrypted
passwords, the entry would be:

crypt_default = des blf md5

Having followed the above steps on each of the FreeBSD based NIS servers and clients, you can be sure
that they all agree on which password format is used within your network. If you have trouble
authenticating on an NIS client, this is a pretty good place to start looking for possible
problems. Remember: if you want to deploy an NIS server for a heterogeneous network, you will
probably have to use DES on all systems because it is the lowest common standard.