Centralized Authorization Using a Directory Service, Part II
NIS slave servers are NIS clients that redistribute the maps they receive from the NIS master server to other NIS clients. Make sure the newest portmap, ypserv, ypbind and yp-tools RPMs are installed on all your slave server machines. The first step in configuring an NIS slave server is to configure it as an NIS client. See the next section for how to do this.
Once the NIS client is configured, start it with:
# service ypbind start
On your NIS master server, add the name of the new NIS slave server to the file /var/yp/ypservers and run the following commands:
# cd /var/yp # /usr/lib/yp/makedbm ypservers /var/yp/nis.example.com/ypservers
You also need to change the definition of NOPUSH in the file /etc/YP/Makefile on your NIS master server from true to false in order to get updated NIS maps pushed from your master server to your slave server(s).
Back on your new NIS slave server, initialize the slave server with:
# /usr/lib/yp/ypinit -s nismaster
where nismaster is the name of your NIS master server. This needs to be the fully qualified domain name (FQDN) if your DNS returns the FQDN for a name lookup. Copy the file /var/yp/securenets from your NIS master server over to the new slave server, and start the new NIS slave server with:
# service ypserv start
Remember to update your disaster recovery plan to reflect the new dependency of your NIS slave server on your NIS master server.
Install the latest ypbind, yp-tools and portmap RPMs on all your clients. Edit the file /etc/yp.conf to tell the client about your NIS server:
Add a line for each of your slave servers as well, if you have some. Use a random order for these servers on your clients to get somewhat even load balancing over all available servers.
Add a line to /etc/sysconfig/network to define the NIS domain of the client:
and set the NIS domainname with the command:
# domainname nis.example.com
Start the portmapper with:
# service portmap start
on each client.
The command ypwhich should now output the NIS server to which this client has bound.
Use the ypcat command to check the content of your NIS maps. For example:
% ypcat passwd
Next, you have to tell all lookups on your client to use NIS. This is done in the name service switch configuration file /etc/nsswitch.conf(5). Change the passwd, group and netgroup entries to:
passwd: compat group: files nis netgroup: nis
This defines the search order for group lookups: start with the local /etc/group file and then try an NIS lookup. Netgroups come only from NIS. I return to the compat entry for passwd later.
The name service caching dæmon nscd(8) sometimes has problems updating its internal cache. The effect is that changes in an NIS map are not visible on a particular client. Restarting nscd on that machine is the only solution to this problem.
Two commands you should be familiar with to query information from NIS are ypcat(1) and ypmatch(1). ypcat prints values of all keys in an NIS map. The command ypcat passwd prints all entries in your NIS passwd map. ypmatch prints the values of one or more keys from an NIS map; ypmatch jane passwd outputs the passwd entry for account jane.
A typical use of the NIS group map is to allow file sharing between multiple users. This works with local files as well as with files in NFS. Here is how to set it up. Let's say you have two users (this technique works for any number of users) with the following passwd map entries:
- Epiq Solutions' Sidekiq M.2
- Android Browser Security--What You Haven't Been Told
- Readers' Choice Awards 2013
- The Many Paths to a Solution
- Nativ Disc
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Synopsys' Coverity
- Tech Tip: Really Simple HTTP Server with Python
- Securing the Programmer
- Returning Values from Bash Functions
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide