NIS on Linux
Now, the arguable point about dynamic binding is that you rarely need it, and that it introduces a security problem: ypbind blindly believes whoever answers, which could be a humble NIS server as well as a malicious intruder. Needless to say this becomes especially troublesome if you manage your password databases over NIS. To guard against this, NIS does not use ypbind by default, but rather picks up the server host name from a configuration file.
NIS and NIS+ share little more than their name and a common goal. NIS+ addresses many of the concerns with NIS, most notably in the areas of security. NIS+ is structured in an entirely different way. Instead of maps, tables are used that are made up of rows and columns, where each row represents an object in the NIS+ database, while the columns cover those properties of the objects that NIS+ knows and cares about. Each table for a given NIS+ domain comprises of its parent domains. In addition, an entry in a table may contain a link to another table. These features make it possible to structure information in many ways.
Configuring a Master NIS Server
For running the NIS service, we installed the following components on the system:
Check for their presence using the following command:
rpm - q rpm-package-name
The sample configuration files mentioned in this document are given for the disney.com and the host name of the machine on which all configurations is being done is goofy.
Now, we set the domain-name of the NIS Service as follows:
where goofy.disney.com is the domain-name of NIS.
We added the following line in the /etc/sysconfig/network file:
So that the /etc/rc.d/init.d/ypserv script at booting time would come to know of the domain-name.
After that, we decided which files were needed to share via NIS. The files were:
We shared these files by editing the /var/yp/Makefile. This file is used when NIS builds its maps through the make utility. Our /var/yp/Makefile looked like this: