technicalinfo

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.