通常我们都会建议，一部 Linux 主机的功能越单纯越好，也就是说，一部 Linux 就专门进行一项服务。这样有许多的好处，这包含功能单纯所以系统资源得以完整运用， 并且在发生入侵或者是系统产生状况的时候，也比较容易追查问题所在。因此，一个公司内部常常会有好几部 Linux 主机，有的专门负责 WWW 、有的专门负责 Mail 、有的专门负责 SAMBA 等等的服务。

不过，这样虽然有分散风险、容易追踪问题的好处，但是，由于是同一个公司内的多部主机，所以事实上所有的 Linux 主机的账号与密码都是一样的！哇！那如果公司里面有 100 的人的话， 我们就需要针对这么多部的主机去设定账号密码了！而且，如果未来还有新进员工的话， 那么光是设定密码就会使系统管理员抓狂了！

这个时候，让我们换一个角度来思考：如果我设计了一部专门管理账号与密码的服务器，而其他的 Linux 主机当有客户端要登入的时候，就必须要到这部管理密码的服务器来查寻用户的账号与密码， 如此一来，我要管理所有的 Linux 主机的账号与密码，只要到那部主服务器上面去进行设定即可！ 包括新进人员的设定，反正其他的 Linux 主机都是向它查寻的嘛！没错！真是好～这个就是 Network Information Service, NIS 服务器的主要功能啦！

事实上，Network Information Service 最早应该是称为 Sun Yellow Pages (简称 yp)，也就是 Sun 这家公司出的一个名为 Yellow Pages 的服务器软件，请注意， NIS 与 YP 是一模一样的咚咚喔！这个 Yellow Pages 名字取的真是好！怎么说呢？知道黄页 (Yellow Pages) 是什么吗？就是我们家里的电话簿啦！ 今天如果你要查寻一家厂商的电话号码，通常就是直接去查黄页上面的纪录来取得电话号码啊！而这个 NIS 也一样，当使用者要登入时， Linux 系统就会到 NIS 服务器上面去找寻这个使用的账号与密码信息来加以比对， 以提供使用者登入之用的检验啊！很棒吧！ ^_^

那么 NIS 服务器提供了哪些信息呢？还记得账号与密码放置在哪里吧？NIS 就是提供那些数据啦！ 主要有底下这些基本的数据提供给有登入需求的主机喔：

服务器端文件名	档案内容
/etc/passwd	提供用户账号、UID、GID、家目录所在、Shell 等等
/etc/group	提供群组数据以及 GID 的对应，还有该群组的加入人员
/etc/hosts	主机名与 IP 的对应，常用于 private IP 的主机名对应
/etc/services	每一种服务 (daemons) 所对应的埠口 (port number)
/etc/protocols	基础的 TCP/IP 封包协定，如 TCP, UDP, ICMP 等
/etc/rpc	每种 RPC 服务器所对应的程序号码
/var/yp/ypservers	NIS 服务器所提供的数据库

至少可以提供上述这些功能，当然啦，你也可以自行定义哪些数据库需要，哪些数据库不需要！

由于 NIS 服务器主要是提供用户登入的信息给客户端主机来查询之用，所以， NIS 服务器所提供的数据当然就需要用到传输与读写比较快速的 "数据库" 文件系统， 而不是传统的纯文本数据。为了要达到这个目的，所以 NIS 服务器就必须要将前一小节提到的那些档案制作成为数据库档案， 然后使用网络协议让客户端主机来查询啰。至于所使用的通讯协议与前一章的 NFS 相同，都使用远程过程调用 (RPC) 这个玩意儿喔！

此外，如果在一个很大型的网域里面，万一所有的 Linux 主机都向同一部 NIS 服务器要求用户数据时， 这部 NIS 服务器的负载 (loading) 可能会过大。甚至如果考虑到数据使用的风险， 要是这单一的一部 NIS 服务器挂点时，那其他的 Linux 主机还要不要让 users 登入啊？ 所以啰，在较为大型的企业环境当中， NIS 服务器可以使用 master/slave (主控/辅助服务器) 架构的。

Master NIS 服务器提供系统管理者制作的数据库， slave 则取得来自 master 的数据，并藉以提供其他客户端的查询。 客户端可以向整个网域要求用户资料的响应，master 与 slave 皆可回答， 由于 slave 的数据来自于 master ，所以用户账号数据本身是同步的！ 如此一方面可以分散 NIS 服务器的负载，而且也可以避免因 NIS 服务器挂点而导致的无法登入的风险。

图 14.1-1、NIS 服务器与客户端的运作与查询方式示意图

整个 NIS 的运作就如同上图，首先必须要有 NIS server 的存在，之后才会有 NIS Client 的存在。 那么当使用者有登入的需求时，整个 NIS 的运作程序是：

• 关于 NIS Server (master/slave) 的运作程序：
  1. NIS Master 先将本身的账号密码相关档案制作成为数据库档案；
  2. NIS Master 可以主动的告知 NIS slave server 来更新；
  3. NIS slave 亦可主动的前往 NIS master server 取得更新后的数据库档案；
  4. 若有账号密码的异动时，需要重新制作 database 与重新同步化 master/slave。
  
  
• 关于当 NIS Client 有任何登入查询的需求时：
  1. NIS client 若有登入需求时，会先查询其本机的 /etc/passwd, /etc/shadow 等档案；
  2. 若在 NIS Client 本机找不到相关的账号数据，才开始向整个 NIS 网域的主机广播查询；
  3. 每部 NIS server (不论 master/slave) 都可以响应，基本上是『先响应者优先』。

从上面的流程当中，你会发现 NIS client 还是会先针对本机的账号数据进行查询，若本机查不到时才到 NIS server 上头寻找。因此，如果你的 NIS client 本身就有很多一般使用者的账号时，那跟 NIS server 所提供的账号就可能产生一定程度的差异啰！所以，一般来说，在这样的环境下，NIS client 或 NIS slave server 会主动拿掉自己本机的一般使用者账号，仅会保留系统所需要的 root 及系统账号而已。 如此一来，一般使用者才都会经由 NIS master server 所控管啊！ ^_^

根据上面图 14.1-1 的说明，我们的 NIS 环境大致上需要设定的基本组件就有：

• NIS Master server ：将档案建置成数据库，并提供 slave server 来更新；
• NIS Slave server ：以 Master server 的数据库作为本身的数据库来源；
• NIS client ：向 master/server 要求登入者的验证数据。

就如同上面提到的，在大型环境中才会使用到这么复杂的 NIS master/slave 架构。因此，本章仅会介绍 NIS Master 的建置， 以及 NIS client 的设定而已。其实，NIS 服务使用的环境大概越来越仅局限在学术数值模式仿真的丛集计算机架构中 (PC cluster)， 在那样的架构中，老实说，鸟哥认为仅要学会 NIS master 即可。如果还有其他账号方面的要求，例如跨平台的帐户信息提供， 那可能就得要参考 Samba 或更进阶的 LDAP 才好呦！这里我们不谈啦～现在，就让我们开始来玩一玩这个 NIS 的设定吧！