technicalinfo

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.

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.

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.

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 " "reason: internal NIS server or client error"
"can't enumerate maps from "
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 failed: RPC: Timed out."
A: ypxfrd is not running on the NIS master server. Login to the master server and start it:
# ypxfrd

This is quite an old thread but in case someone else needs help --
1. Stop volmgt (if running)/etc/init.d/volmgt stop
2. Confirm it has stoppedps -ef grep vold
3. Locate the CD/DVD device
(a)iostat -Eneg: c0t0d0then device would be/dev/dsk/c0t0d0s2
(b) If not detected, either reboot - use "boot -r"ordevfsadm -Cdevfsadm
4 Manually mount the CD
mkdir -p /tmp/cdrom
mount -F hsfs -o ro /dev/dsk/c0t0d0s2 /tmp/cdrom
5 Check contents ls /tmp/cdrom
6 Unmountumount /tmp/cdrom
7. Mount using correct path (if required)eg: /cdrom/cdrom0
8 Restart vol mgt/etc/init.d/volmgt startcheck /vol directory for inconsistencies...

ifconfig hme0 plumb
hme0: flags=842 mtu 1500 inet 0.0.0.0 netmask 0 ether 8:0:20:9c:6b:2d
#ifconfig hme0 192.168.1.132 netmask 255.255.255.0 up
#ifconfig hme0:1 172.20.15.4 netmask 255.255.0.0 up Virtual Interfaces
hme0: flags=843 mtu 1500 inet 192.168.1.132 netmask ffffff00 broadcast 192.168.1.255 ether 8:0:20:9c:6b:2d hme0:1: flags=842 mtu 1500 inet 172.20.15.4 netmask ffff0000 broadcast 172.20.255.255

Configuration Files
/etc/hostname.hme0 (enter hostname of machine )
/etc/netmasks (146.122.157.0 255.255.255.0)
/etc/hosts (146.122.157.__ hostname)

Change the hostname in the following files manually:
/etc/nodename
/etc/hostname.*interface
tc/inet/hosts
/etc/inet/ipnodes

On most Unix/Linux distributions XDMCP is disabled by default.
In order to enable your server to accept XDMCP connections you need to modify a few configuration files.
The configuration files are located in different directories depending on the distribution.
Please select the version you are currently using:
XDMCP: Red Hat Linux and Other GNOME based systems
On many versions of Red Hat Linux and other versions of Unix which have the GNOME desktop environment, enabling XDMCP only takes a few clicks.
1. Log in as root
2. Open a terminal
3. type gdmsetup (a dialog box will appear)
4 Click on the XDMCP tab
5. Check the Enable XDMCP box
6. Press Close

XDMCP: Fedora Core 5
On many versions of Red Hat Linux and other versions of Unix which have the GNOME desktop environment, enabling XDMCP only takes a few clicks. Note that on Fedora Core 5 systems, gdmsetup has changed1. Log in as root2. Open a terminal3. type gdmsetup (a dialog box will appear)4 Click on the Remote tab5. Change Style to Plain6. Press Close
XDMCP: SuSe Linux
On SuSE linux systems you must manually edit the configuration files.
1. Log in as root2. Open /etc/sysconfig/displaymanager Change DISPLAYMANAGER_REMOTE_ACCESS=”yes”3. Open the files /etc/opt/kde3/share/config/kdm/kdmrc and /etc/opt/kde3/share/config/kdm/kdmrc.SuSEconfigFind the XDMCP section and set Enable to true[Xdmcp]Enable=trueWilling=/etc/X11/xdm/XwillingXaccess=/etc/X11/xdm/Xaccess4. Open /etc/X11/xdm/XaccessMake sure there is no # to the left of the * in the following host line* #any host can get a login window5. Open /etc/X11/xdm/xdm_configChange the DisplayManager.requestPort line to DisplayManager.requestPort: 1776. Restart the system
XDMCP: Solaris 9 and below
Solaris machines have XDMCP enabled by default. In case it has been disabled for some reason
1. Log in as root2. Open a terminal3. type “cd /usr/dt/config”4 edit the Xconfig file5. Comment out the lineDtlogin.requestPort: 06. Save and restart the server
XDMCP: Solaris 10

Solaris 10’s desktop environment is JDS which is basedoff of GNOME.
1. Log in as root2. Open a terminal3. type gdmsetup (a dialog box will appear)4 Click on the XDMCP tab5. Check the Enable XDMCP box6. Press Close
XDMCP: General Instructions
Here are general instructions to enable XDMCP manually editing files on unix systems.
1. Log in as root.2. From /etc/X11/xdm/Xaccess file, uncomment the line ”# * #any host can get a login window”.3. From /etc/X11/xdm/xdm-config file, comment out the line “DisplayManager.RequestPort: 0”.4. From /etc/X11/gdm/gdm.conf file, set the enable status to True (or 1) in [xdmcp] section.5. From /etc/kde/kdm/kdmrc file, set the enable status to True (or 1) in [xdmcp] section.6. The system needs to run in init level 5 (/etc/inittab).7. Reboot the Linux system after modification. Log in as root to the Linux machine again. Go to system settings, security level. Reduce the firewall security so that you can connect remotely. Do this only until able to connect with X-Win32, then you can properly reconfigure the firewall to accept XDMCP connections.
Don’t forget to open up your Firewall ports. For help configuring your firewall

What ports need to be opened for XDMCP




X-Win32 can connect to linux hosts even behind a firewall.
Open up TCP port 6000-6005 (plus X-Win32’s base display number) in both directionsOpen up UDP port 177 to accept incomming connections from any port.
If you are using Gnome open up TCP ports 16001 and TCP 35091 in both directions.
If you are behind a router using NAT, map those ports to the IP address of your local computer on your LAN. The only other thing is make sure on the Network tab under the X-Config menu, that your display is the correct IP address. This is the address you are telling the host to send the session back to.

If you are using SuSE linux firewall, edit /etc/sysconfig/SuSEfirewall2 changing the default options to the following

FW_SERVICES_EXT_UDP=“177 bootpc”FW_ALLOW_FW_BROADCAST_EXT=“yes”