The Linux NIS server (Network Information Service) is a server used for sharing critical data stored in flat files between systems on a network, it is often ideal to have a common repository (such as NIS) for storing user and group information that is traditionally stored in flat files such as /etc/passwd and /etc/group files.
So what is the benefit of that?
By making such files available via the NIS server, that would allow any remote NIS client machine to access or query the data in these shared files and use them as extensions to the local versions.
NIS is not limited to sharing files. Any tabular file which at least has one column with a unique value can be shared via NIS like /etc/services file.
The main benefit from using NIS server is that you can maintain a central copy of the files, and whenever that data is updated, it automatically propagates to all network users.
Some users, especially windows users might think this is sort of Active Directory like service, but the Linux NIS server is older than Active Directory and not a replicate for it.
Table of Contents
- 1 What is NIS?
- 2 Linux NIS Servers
- 3 NIS Domain Name
- 4 Installing Master Linux NIS Server
- 5 Configuring NIS
- 6 Editing the Makefile
- 7 Using ypinit
- 8 Configuring NIS Client
- 9 The/etc/nsswitch.conf File
- 10 NIS Tools
What is NIS?
The NIS is a simple database that clients can query. It contains a series of tables. Each table is created from text files like /etc/passwd, /etc/services and any other tabular files that have at least one column that is unique for every row. It is a key value pair.
You can query these tables in two ways:
- Listing the entire table
- Pulling a specific entry by searching
When a program makes a request to search for a user password details, the client checks the local /etc/passwd file and sees if the user doesn’t exist there; the client then makes a request to the NIS server to look for a corresponding entry in the /etc/passwd table.
The following list is the list of daemons that are associated with NIS server:
ypserv: This daemon listens for queries from clients and responds with answers.
ypbind: This is a client-side of NIS. It is responsible for finding an NIS server to be queried for information.
ypxfrd: This daemon is used for propagating and transferring the NIS databases to slave servers.
Linux NIS Servers
You can have only one authoritative server where the original data files are kept. This is called the master NIS server.
You may need to distribute the load across more than one machine by setting up one or more secondary (slave) NIS servers. It can be helpful in case of failure of the master server.
Secondary NIS servers receive updates when the primary NIS server is updated, so they kept synced. This process called server push.
NIS Domain Name
Primary NIS servers establish so-called domains that are similar to the domains of a domain controller in windows. The big difference is that the NIS domain does not require the NIS server administrator explicitly to allow a client to join.
Keep in mind that you should use names that are different from your DNS domain names.
Installing Master Linux NIS Server
On Red hat based distros, you can install it like this:
$ dnf -y install ypserv
On Debian based distros, you can install it like this:
$ apt-get -y install nis
After successful installation, you need to set the NIS domain name by using the domainname command.
Let’s name it nis.example.com
$ domainname nis.example.com
To persist our NIS domain name in Red hat based distros, we can create a variable called NISDOMAIN in the /etc/sysconfig/network file.
On Debian-based distros, you can achieve the same result by adding the domainname command with the correct value to one of the rc scripts which run at boot time.
As we mentioned earlier, the ypserv daemon is responsible for handling NIS requests.
NIS is a Remote Procedure Call (RPC) based service, so you need to make sure that the rpcbind program is up and running before you attempt to start the Linux NIS server.
On new Linux distros that rely on systemd as the service manager, systemd will automatically take care of service intra-dependencies that exist between rpcbind and ypserv.
If your distro is not one of them, you can start rpcbind like this:
$ systemctl start rpcbind
On our distro which has systemd, we can start the service like this:
$ systemctl start ypserv
To confirm that the service is running, you can use the rpcinfo command.
$ rpcinfo -p | grep ypserv
Editing the Makefile
The make command keeps track of what files need to be compiled and then invokes the necessary program to perform the compilation.
The file that contains the instructions for make is called Makefile.
Taking this concept to work on NIS is straightforward. In this case, a series of text files need to be converted into database format. We want a tool that will reconvert any files that have been changed, we can use the make command.
Under /var/yp directory, you will see a file called Makefile. This file lists the files that get shared via NIS.
Let’s discuss the options in the Makefile.
If you plan to have NIS slave servers, you will need to tell the master Linux NIS server to push the resulting maps to the slave servers. Change the NOPUSH variable to false if you want to have support for slave servers.
Keep in mind that you need to list the hostnames of your slave servers in the /var/yp/ypservers file and ensure to list a corresponding entry in the /etc/hosts file.
Min UIDs GIDs
Every user on Linux has a user id and group id, you can get your id by typing the id command and gid command respectively.
Set the minimum UID and GID values that you are willing to share via NIS like this:
Merging Shadow Passwords with Real Ones
The Linux NIS server can be used to authenticate their users, you will need to allow the encrypted password entries to be shared through NIS. If you are using shadow passwords, NIS server will automatically handle this for you by taking the encrypted field from the /etc/shadow file and merging it into the NIS shared copy of /etc/passwd.
This is done using MERGE_PASSWD option:
Merging Group Shadow Passwords with Real Ones
The /etc/group file allows passwords to be applied to group settings. Since the /etc/group file needs to be publicly readable, most distros have taken to support shadow group files /etc/gshadow, these are similar in nature to shadow password files.
The option is called MERGE_GROUP:
In Makefile, there is an option that specifies what is shared, it is (all) option
all: passwd group hosts services shadow networks
The option YPPWDDIR specifies the location of the passwd, group, and shadow files, so you don’t need to type the full path.
Once you’ve finished editing options in Makefile, you need to initialize the YP (NIS) server using the ypinit command:
$ /usr/lib64/yp/ypinit -m
Or if you are using a 32bit system the command will be:
The -m option tells ypinit to set up the system as a master NIS server.
It will prompt you to enter the secondary NIS servers.
These entries will be stored in the /var/yp/ypservers file.
Once you finish, ypinit will run the make program automatically for you, build the maps, and push them to any secondary servers that you specified.
Configuring NIS Client
On Red hat based distros, you can install NIS client like this:
$ dnf -y install ypbind
On Debian-based distros, you can install it like this:
$ apt-get install nis
The /etc/yp.conf file is the configuration for the client-side daemon.
You can start ypbind now:
$ systemctl start ypbind
$ systemctl enable ypbind
The /etc/nsswitch.conf file is responsible for telling the system where it should search for a specific information.
passwd: files nis
This entry means that search requests for password entries will first be done in the /etc/passwd file. If the requested entry isn’t found there, check NIS server.
To work better with the Linux NIS server, there are some useful tools that can help you manage the information in the database.
ypcat: dumps the contents of an NIS map. This is useful for scripts that need to pull information out of the NIS server.
ypwhich: returns the name of the Linux NIS server that is answering your requests.
ypmatch: rather than grabbing the entire map, you can supply a key value to ypmatch, and only the entry corresponding to that key is pulled.
I hope you find the post useful and interesting. Keep coming back.