|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
|
|
There are a number of commands in Solaris that you can use to obtain information from and about the NIS database. You can also use these commands to test the functionality of the NIS service. You do not have to be the superuser to use these commands. The most commonly used NIS commands are: ypcat, ypmatch, ypwhich.
|
|
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.
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>
...
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
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>
...
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.
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
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
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 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.
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 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.
Google matched content |
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-domainYou 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!
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 default class 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.confNote: The format of passwords already in /etc/master.passwd will not be updated until a user changes their password for the first time after the 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.conf gives 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 md5Having 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.
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: September 12, 2017
