Skip to main content

Configure NIS Services in a Linux server

What is NIS?

Network Information Service (NIS) is used for keeping a centralized repository of users, hostnames and other useful information in a computer network. In single server UNIX environments, the list of users and groups is usually kept in a file such as /etc/passwd. Using NIS adds a "global" directory which is used for authenticating users from any host on the network.

Install the Packages:

Install the yp-tools, ypbind and  ypserv rpm packages on the server.

[root@nissrv1 /]# rpm -qa |grep ypbind
[root@ nissrv1 /]# rpm -qa |grep ypserv
[root@ nissrv1 /]# rpm -qa |grep yp-tools

Defining the NIS Domain Name:

Edit the /etc/sysconfig/network file 

We need to add the NIS domain name we wish to use in the /etc/sysconfig/network file. 

For this example, we will call the domain "LINUX-NIS". 

Note: Use Non-FQDN Names.Edit /etc/hosts file as well to make the server using Non-FQDN name.

NIS servers also need to be NIS clients themselves, so we will have to edit the yp.conf to point this file towards the server itself, or localhost

# /etc/yp.conf - ypbind configuration file

NIS Server Daemons:
The following is a list of NIS server daemons and their functionality. 

The foundation service for RPC
Allows users to change their NIS passwords
NIS server daemon
NIS client daemon
The NIS map transfer daemon

Starting the NIS Server Related Daemons:

We now need to start a couple of the NIS daemons in the /etc/init.d directory. In this case we will only be starting the portmapyppasswdd, and ypserv daemons so that we can initialize the NIS domain. 

On RHEL we would issue the following commands: 

[root@nissrv1]# /etc/init.d/portmap start
Starting portmapper: [  OK  ]
[root@nissrv1]# /etc/init.d/yppasswdd start
Starting YP passwd service: [  OK  ]
[root@nissrv1]# /etc/init.d/ypserv start
Setting NIS domain name LINUX-NIS:  [  OK  ]
Starting YP server services: [  OK  ]
we would use the chkconfig command to configure these daemons to start after every reboot. 

[root@nissrv1]# chkconfig portmap on
[root@nissrv1]# chkconfig yppasswdd on
[root@nissrv1]# chkconfig ypserv on

We need to make sure these daemons are running before continuing to the next step. We can use the rpcinfo command to do this: 

[root@nissrv1]# rpcinfo -p localhost

program     vers proto  port
   100000    2   tcp    111  portmapper
   100000    2   udp    111  portmapper
   100009    1   udp    681  yppasswdd
   100004    2   udp    698  ypserv
   100004    1   udp    698  ypserv
   100004    2   tcp    701  ypserv
   100004    1   tcp    701  ypserv

The ypbind and ypxfrd might be listed as running, even though they do not start properly until after the initialization of the NIS domain. If they are running, we will restart these daemons after the domain initialization is completed.

Initializing the NIS Domain:

Now that we have decided on the name of the NIS domain, we will have to use the ypinitcommand to create the associated authentication files for the domain. We will be prompted for the name of the NIS server, which in this case is nis-server

[root@nissrv1]# /usr/lib/yp/ypinit -m 

At this point, we have to construct a list of the hosts which will run NIS servers. nissrv1 is in the list of NIS server hosts. We must continue to add the names for the other hosts, one per line. When we are done with the list, simply type "a". 

next host to add:  nissrv1
next host to add:
The current list of NIS servers looks like this:
Is this correct?  [y/n: y]  y
We need a few minutes to build the databases...
Building /var/yp/LINUX-NIS/ypservers...
Running /var/yp/Makefile...
gmake[1]: Entering directory `/var/yp/LINUX-NIS'
Updating passwd.byname...
Updating passwd.byuid...
Updating group.byname...
Updating group.bygid...
Updating hosts.byname...
Updating hosts.byaddr...
Updating rpc.byname...
Updating rpc.bynumber...
Updating services.byname...
Updating services.byservicename...
Updating netid.byname...
Updating protocols.bynumber...
Updating protocols.byname...
Updating mail.aliases...
gmake[1]: Leaving directory `/var/yp/LINUX-NIS'
nissrv1 has been set up as a NIS master server.

Now we can run ypinit -s nissrv1 on all slave servers (If we have any slave NIS servers). 

Note: Make sure portmap is running before trying this step or you'll get errors, such as: 

failed to send 'clear' to local ypserv: RPC: Port mapper failureUpdating group.bygid... 

You will have to delete the /var/yp/LINUX-NIS directory and restart portmap, yppasswd, and ypserv before you'll be able to do this again successfully.

Start The ypbind and ypxfrd Daemons:

On Redhat, you can now start the ypbind and the ypxfrd daemons because the NIS domain had been initialized and the files have been created. 

[root@nissrv1]# /etc/init.d/ypbind start
Binding to the NIS domain: [  OK  ]
Listening for an NIS domain server.

[root@nissrv1]# /etc/init.d/ypxfrd start
Starting YP map server: [  OK  ]

[root@nissrv1]# chkconfig ypbind on

[root@nissrv1]# chkconfig ypxfrd on

Verify the Daemons Are Running:
All the NIS daemons use RPC port mapping and, therefore, are listed using the rpcinfo command when they are running correctly. 
[root@nissrv1]# rpcinfo -p localhost
    program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100021    1   udp   1024  nlockmgr
    100021    3   udp   1024  nlockmgr
    100021    4   udp   1024  nlockmgr
    100004    2   udp    784  ypserv
    100004    1   udp    784  ypserv
    100004    2   tcp    787  ypserv
    100004    1   tcp    787  ypserv
    100009    1   udp    798  yppasswdd
 600100069    1   udp    850  fypxfrd
 600100069    1   tcp    852  fypxfrd
    100007    2   udp    924  ypbind
    100007    1   udp    924  ypbind
    100007    2   tcp    927  ypbind
    100007    1   tcp    927  ypbind

Adding New NIS Users:
New NIS users can be created by logging into the NIS server and creating the new user account. Edit passwd and shadow files on NIS directory to add user accounts. Once this is complete, you then have to update the NIS domain's authentication files by executing the make command in the /var/yp directory. 

This procedure makes all NIS-enabled, nonprivileged accounts become automatically accessible via NIS, not just newly created ones. It also exports all the user's characteristics stored in thepasswd and group files, such as the login shell, the user's group, and home directory. 

You can check to see if the user's authentication information has been updated by using theypmatch command, which should return the user's encrypted password string. 

[root@nissrv1]# ypmatch nisuser passwd

You can also use the getent command, which has similar syntax. Unlike ypmatchgetentdoesn't provide an encrypted password when run on an NIS server, it just provides the user's entry in the passwd file. On a NIS client, the results are identical with both showing the encrypted password. 

[root@nissrv1]# getent passwd nisuser


Popular posts from this blog


The BCD registry file controls which operating system installation starts and how long the boot manager waits before starting Windows. Basically, it’s like the Boot.ini file in earlier versions of Windows. If you need to edit it, the easiest way is to use the Startup And Recovery tool from within Vista. Just follow these steps: 1. Click Start. Right-click Computer, and then click Properties. 2. Click Advanced System Settings. 3. On the Advanced tab, under Startup and Recovery, click Settings. 4. Click the Default Operating System list, and edit other startup settings. Then, click OK. Same as Windows XP, right? But you’re probably not here because you couldn’t find that dialog box. You’re probably here because Windows Vista won’t start. In that case, you shouldn’t even worry about editing the BCD. Just run Startup Repair, and let the tool do what it’s supposed to. If you’re an advanced user, like an IT guy, you might want to edit the BCD file yourself. You can do this

DNS Scavenging.

                        DNS Scavenging is a great answer to a problem that has been nagging everyone since RFC 2136 came out way back in 1997.  Despite many clever methods of ensuring that clients and DHCP servers that perform dynamic updates clean up after themselves sometimes DNS can get messy.  Remember that old test server that you built two years ago that caught fire before it could be used?  Probably not.  DNS still remembers it though.  There are two big issues with DNS scavenging that seem to come up a lot: "I'm hitting this 'scavenge now' button like a snare drum and nothing is happening.  Why?" or "I woke up this morning, my DNS zones are nearly empty and Active Directory is sitting in a corner rocking back and forth crying.  What happened?" This post should help us figure out when the first issue will happen and completely avoid the second.  We'll go through how scavenging is setup then I'll give you my best practices.  Scavenging s

AD LDS – Syncronizing AD LDS with Active Directory

First, we will install the AD LDS Instance: 1. Create and AD LDS instance by clicking Start -> Administrative Tools -> Active Directory Lightweight Directory Services Setup Wizard. The Setup Wizard appears. 2. Click Next . The Setup Options dialog box appears. For the sake of this guide, a unique instance will be the primary focus. I will have a separate post regarding AD LDS replication at some point in the near future. 3. Select A unique instance . 4. Click Next and the Instance Name dialog box appears. The instance name will help you identify and differentiate it from other instances that you may have installed on the same end point. The instance name will be listed in the data directory for the instance as well as in the Add or Remove Programs snap-in. 5. Enter a unique instance name, for example IDG. 6. Click Next to display the Ports configuration dialog box. 7. Leave ports at their default values unless you have conflicts with the default values. 8. Click N