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:
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Control Your Linux Desktop with D-Bus
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
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