NIS， 表示网络信息服务 (Network Information Services)， 最初由 Sun Microsystems 开发， 用于 UNIX® (最初是 SunOS™) 系统的集中管理。 目前， 它基本上已经成为了业界标准； 所有主流的类 UNIX® 系统 (Solaris™, HP-UX, AIX®, Linux, NetBSD, OpenBSD, FreeBSD, 等等) 都支持 NIS。

NIS 也就是人们所熟知的黄页(Yellow Pages)， 但由于商标的问题， Sun 将其改名为现在的名字。 旧的术语 (以及 yp)， 仍然经常可以看到， 并被广泛使用。

这是一个基于 RPC 的客户机/服务器系统， 它允许在一个 NIS 域中的一组机器共享一系列配置文件。 这样， 系统管理员就可以配置只包含最基本配置数据的 NIS 客户机系统， 并在单点上增加、 删除或修改配置数据。

尽管实现的内部细节截然不同， 这和 Windows NT® 域系统非常类似， 以至于可以将两者的基本功能相互类比。

有一系列术语和重要的用户进程将在您在 FreeBSD 上实现 NIS 时用到， 无论是在创建 NIS 服务器， 或作为 NIS 客户机：

在 NIS 环境中， 有三种类型的主机： 主服务器， 从服务器， 以及客户机。 服务器的作用是充当主机配置信息的中央数据库。 主服务器上保存着这些信息的权威副本， 而从服务器则是保存这些信息的冗余副本。 客户机依赖于服务器向它们提供这些信息。

许多文件的信息可以通过这种方式来共享。 通常情况下， master.passwd、 group， 以及 hosts 是通过 NIS 分发的。 无论什么时候， 如果客户机上的某个进程请求这些本应在本地的文件中的资料的时候， 它都会向所绑定的 NIS 服务器发出请求， 而不使用本地的版本。

这一节将通过实例介绍如何配置 NIS 环境。

基本上， 任何远程用户都可以发起一个 RPC 到 ypserv(8) 并获得您的 NIS 映射的内容， 如果远程用户了解您的域名的话。 要避免这类未经授权的访问， ypserv(8) 支持一个称为 “securenets” 的特性， 用以将访问限制在一组特定的机器上。 在启动过程中， ypserv(8) 会尝试从 /var/yp/securenets 中加载 securenet 信息。

如果 ypserv(8) 接到了来自匹配上述任一规则的地址的请求， 则它会正常处理请求。 反之， 则请求将被忽略， 并记录一条警告信息。 如果 /var/yp/securenets 文件不存在， 则 ypserv 会允许来自任意主机的请求。

ypserv 程序也支持 Wietse Venema 的 TCP Wrapper 软件包。 这样， 管理员就能够使用 TCP Wrapper 的配置文件来代替 /var/yp/securenets 完成访问控制。

在我们的实验室中， basie 这台机器， 是一台教员专用的工作站。 我们不希望将这台机器拿出 NIS 域， 而主 NIS 服务器上的 passwd 文件， 则同时包含了教员和学生的帐号。 这时应该怎么做？

有一种办法来禁止特定的用户登录机器， 即使他们身处 NIS 数据库之中。 要完成这一工作， 只需要在客户机的 /etc/master.passwd 文件中加入一些 -username 这样的项， 其中， username 是希望禁止登录的用户名。 一般推荐使用 vipw 来完成这个工作， 因为 vipw 会对您在 /etc/master.passwd 文件上所作的修改进行合法性检查， 并在编辑结束时重新构建口令数据库。 例如， 如果希望禁止用户 bill 登录 basie， 我们应该：

前一节介绍的方法， 在您需要为非常少的用户和/或机器进行特殊的规则配置时还算凑合。 在更大的网络上， 您 一定会 忘记禁止某些用户登录到敏感的机器上， 或者， 甚至必须单独地修改每一台机器的配置， 因而丢掉了 NIS 最重要的优越性： 集中式 管理。

NIS 开发人员为这个问题提供的解决方案， 被称作 netgroups。 它们的作用和语义， 基本上可以等同于 UNIX® 文件系统上使用的组。 主要的区别是它们没有数字化的 ID， 以及可以在 netgroup 中同时包含用户和其他 netgroup。

Netgroups 被设计用来处理大的、 复杂的包含数百用户和机器的网络。 一方面， 在您不得不处理这类情形时， 这是一个很有用的东西。 而另一方面， 它的复杂性又使得通过非常简单的例子很难解释 netgroup 到底是什么。 这一节的其余部分的例子将展示这个问题。

假设您在实验室中成功地部署 NIS 引起了上司的兴趣。 您接下来的任务是将 NIS 域扩展， 以覆盖校园中的一些其他的机器。 下面两个表格中包括了新用户和新机器， 及其简要说明。

如果您尝试通过一个一个地阻止用户来实现这些限制， 就需要在每一个系统的 passwd 文件中， 为每一个不允许登录该系统的用户添加对应的 -user 行。 如果忘记了任何一个， 就可能会造成问题。 在进行初始配置时， 正确地配置也许不是什么问题， 但随着日复一日地添加新用户， 总有一天 您会忘记为新用户添加某个行。 毕竟， Murphy 是一个乐观的人。

使用 netgroups 来处理这一状况可以带来许多好处。 不需要单独地处理每一个用户； 您可以赋予用户一个或多个 netgroups 身份， 并允许或禁止某一个 netgroup 的所有成员登录。 如果添加了新的机器， 只需要定义 netgroup 的登录限制。 如果增加了新用户， 也只需要将用户加入一个或多个 netgroup。 这些变化是相互独立的： 不再需要 “对每一个用户和机器执行 ……”。 如果您的 NIS 配置经过了谨慎的规划， 就只需要修改一个中央的配置文件， 就能够允许或禁止访问某台机器的权限了。

第一步是初始化 NIS 映射 netgroup。 FreeBSD 的 ypinit(8) 默认情况下并不创建这个映射， 但它的 NIS 实现能够在创建这个映射之后立即对其提供支持。 要创建空映射， 简单地输入

并开始增加内容。 在我们的例子中， 至少需要四个 nergruop： IT 雇员， IT 学徒， 普通雇员和实习生。

IT_EMP, IT_APP 等等， 是 netgroup 的名字。 每一个括号中的组中， 都有一些用户帐号。 组中的三个字段是：

每一个字段都可以包括通配符。 参见 netgroup(5) 了解更多细节。

激活并分发新的 NIS 映射非常简单：

这个操作会生成三个 NIS 映射， 即 netgroup、 netgroup.byhost 和 netgroup.byuser。 用 ypcat(1) 可以检查这些 NIS 映射是否可用了：

第一个命令的输出， 应该与 /var/yp/netgroup 的内容相近。 第二个命令， 如果没有指定本机专有的 netgroup， 则应该没有输出。 第三个命令， 则用于显示某个用户对应的 netgroup 列表。

客户机的设置也很简单。 要配置服务器 war， 只需进入 vipw(8) 并把

改为

现在， 只有 netgroup IT_EMP 中定义的用户会被导入到 war 的口令数据库中， 因此只有这些用户能够登录。

不过， 这个限制也会作用于 shell 的 ~， 以及所有在用户名和数字用户 ID 之间实施转换的函数的功能。 换言之， cd ~user 将不会正常工作， 而 ls -l 也将显示数字的 ID 而不是用户名， 并且 find . -user joe -print 将失败， 并给出 No such user 的错误信息。 要修正这个问题， 您需要导入所有的用户项， 而 不允许他们登录服务器。

这可以通过在 /etc/master.passwd 加入另一行来完成。 这行的内容是：

+:::::::::/sbin/nologin， 意思是 “导入所有的项， 但导入项的 shell 则替换为 /sbin/nologin”。 通过在 /etc/master.passwd 中增加默认值， 可以替换掉 passwd 中的任意字段。

完成上面的修改之后， 在 IT 部门有了新员工时， 只需修改一个 NIS 映射就足够了。 您也可以用类似的方法， 在不太重要的服务器上， 把先前本地版本的 /etc/master.passwd 中的 +::::::::: 改为：

相关的用于普通工作站的配置则应是：

一切平安无事， 直到数周后， 有一天策略发生了变化： IT 部门也开始招收实习生了。 IT 实习生允许使用普通的终端， 以及不太重要的服务器； 而 IT 学徒， 则可以登录主服务器。 您增加了新的 netgroup IT_INTERN， 以及新的 IT 实习生到这个 netgroup 并开始修改每一台机器上的配置…… 老话说得好：“牵一发， 动全身”。

NIS 通过 netgroup 来建立 netgroup 的能力， 正可以避免这样的情形。 一种可能的方法是建立基于角色的 netgroup。 例如， 您可以创建称为 BIGSRV 的 netgroup， 用于定义最重要的服务器上的登录限制， 以及另一个成为 SMALLSRV 的 netgroup， 用以定义次重要的服务器， 以及第三个， 用于普通工作站的 netgroup USERBOX。 这三个 netgroup 中的每一个， 都包含了允许登录到这些机器上的所有 netgroup。 您的 NIS 映射中的新项如下所示：

这种定义登录限制的方法， 在您能够将机器分组并加以限制的时候可以工作的相当好。 不幸的是， 这是种例外， 而非常规情况。 多数时候， 需要按机器去定义登录限制。

与机器相关的 netgroup 定义， 是处理上述策略改动的另一种可能的方法。 此时， 每台机器的 /etc/master.passwd 中， 都包含两个 “+” 开头的行。 第一个用于添加允许登录的 netgroup 帐号， 而第二个则用于增加其它帐号， 并把 shell 设置为 /sbin/nologin。 使用 “全大写” 的机器名作为 netgroup 名是个好主意。 换言之， 这些行应该类似于：

一旦在所有机器上都完成了这样的修改， 就再也不需要修改本地的 /etc/master.passwd 了。 所有未来的修改都可以在 NIS 映射中进行。 这里是一个例子， 其中展示了在这一应用情景中所需要的 netgroup 映射， 以及其它一些常用的技巧：

如果您正使用某种数据库来管理帐号， 应该可以使用您的数据库的报告工具来创建映射的第一部分。 这样， 新用户就自动地可以访问这些机器了。

最后的提醒： 使用基于机器的 netgroup 并不总是适用的。 如果正在为学生实验室部署数十台甚至上百台同样的机器， 您应该使用基于角色的 netgroup， 而不是基于机器的 netgroup， 以便把 NIS 映射的尺寸保持在一个合理的范围内。

这里是一些其它在使用 NIS 环境时需要注意的地方。

FreeBSD 的 ypserv 提供了某些为 NIS v1 客户提供服务的支持能力。 FreeBSD 的 NIS 实现， 只使用 NIS v2 协议， 但其它实现可能会包含 v1 协议， 以提供对旧系统的向下兼容能力。 随这些系统提供的 ypbind 服务将首先尝试绑定 NIS v1 服务器， 即使它们并不真的需要它 (有些甚至可能会一直广播搜索请求， 即使已经从某台 v2 服务器得到了回应也是如此)。 注意， 尽管支持一般的客户机调用， 这个版本的 ypserv 并不能处理 v1 的映射传送请求； 因而， 它就不能与较早的支持 v1 协议的 NIS 服务器配合使用， 无论是作为主服务器还是从服务器。 幸运的是， 现今应该已经没有仍然在用的这样的服务器了。

在多服务器域的环境中， 如果服务器同时作为 NIS 客户， 在运行 ypserv 时要特别小心。 一般来说， 强制服务器绑定自己要比允许它们广播绑定请求要好， 因为这种情况下它们可能会相互绑定。 某些怪异的故障， 很可能是由于某一台服务器停机， 而其它服务器都依赖其服务所导致的。 最终， 所有的客户机都会超时并绑定到其它服务器， 但这个延迟可能会相当可观， 而且恢复之后仍然存在再次发生此类问题的隐患。

您可以强制一台机器绑定到特定的服务器， 这是通过 ypbind 的 -S 参数来完成的。 如果不希望每次启动 NIS 服务器时都手工完成这项工作， 可以在 /etc/rc.conf 中加入：

参见 ypbind(8) 以了解更多情况。

在实现 NIS 时， 口令格式的兼容性问题是一种最为常见的问题。 假如您的 NIS 服务器使用 DES 加密口令， 则它只能支持使用 DES 的客户机。 例如， 如果您的网络上有 Solaris™ NIS 客户机， 则几乎肯定需要使用 DES 加密口令。

要检查您的服务器和客户机使用的口令格式， 需要查看 /etc/login.conf。 如果主机被配置为使用 DES 加密的口令， 则 default class 将包含类似这样的项：

其他一些可能的 passwd_format 包括 blf 和 md5 (分别对应于 Blowfish 和 MD5 加密口令)。

如果修改了 /etc/login.conf， 就必须重建登录性能数据库， 这是通过以 root 身份运行下面的程序来完成的：

接下来， 为了确保所有的口令都按照您选择的格式加密了， 还需要检查 /etc/auth.conf 中 crypt_default 给出的优先选择的口令格式。 要完成此工作， 将您选择的格式放到列表的第一项。 例如， 当使用 DES 加密的口令时， 对应项应为：

在每一台基于 FreeBSD 的 NIS 服务器和客户机上完成上述工作之后， 就可以肯定您的网络上它们都在使用同样的口令格式了。 如果在 NIS 客户机上做身份验证时发生问题， 这也是第一个可能出现问题的地方。 注意： 如果您希望在混合的网络上部署 NIS 服务器， 可能就需要在所有系统上都使用 DES， 因为这是所有系统都能够支持的最低限度的公共标准。