注册
登录
| 关键词： 一个 NIS 服务器 文件 byname maps 函数 passwd 信息 主机 |
当运行一个局域网时，系统管理员的目标通常是为用户提供一个透明的网络环境。要做到这一步的一个重要步骤是在所有主机之间保持重要数据（比如用户帐号信息）的同步。我们在前面已经看到，对于主机名的解析，存在一个强大而复杂的服务，即DNS。对于其他任务没有这种特殊的服务。此外，如果你只是管理一个没有Internet连接的小LAN的话，那么对于许多管理员来说安装设置DNS是不值得的。 这就是为什么Sun开发出了NIS，即网络信息系统（Network Information System）。NIS提供了通用数据库访问设施，可以实现向你的网络上的所有主机分发信息，比如象passwd和groups文件所包含的信息。这使得网络看起来象一个独立系统，在所有的主机上有着相同的帐号。你可以以同样的方式通过NIS向网络上的所有机器同步/etc/hosts中的主机名信息。 NIS是基于RPC的，是由一个服务器、一个客户端库以及几个管理工具组成。起初，NIS被称作黄页（Yellow Pages），或YP，现在仍然使用这个名称来非正式地指这项服务。另一方面，Yellow Pages是英国电信的商标，英国电信一直要求Sun更换这个名字。随着事态的发展，某些名称已与人们分不开了，所以YP一直以与NIS相关命令的前缀形式继续存在着，比如象ypserv、ypbind等等。 今天，几乎所有的UN*X都包括NIS，而且甚至有它的免费实现版本。一个是来自BSD的Net-2发行版，源自于Sun捐赠的公众域参考实现。该版的客户库代码已经存在于GNU的libc中很长时间了，而管理程序只是在最近才由Swen Thümmler [1] 移植到Linux上。在这个参考实现中漏掉了一个NIS服务器程序。Tobias Reber已经编制出了另外一个NIS软件包，其中包括所有的工具和一个服务器；该软件包称作yps。[2] 目前，一个完全重写的称为NYS的NIS代码已由Peter Eriksson [3]编制出来，它支持普通的NIS和Sun的经过许多修正的NIS+。NYS不仅提供了一个NIS工具集和一个服务器，而且还增加了一个全新的库函数集，这个库函数集可能最终会被加入到标准libc中。这包括替换目前使用host.conf的主机名解析的一个新设置方案。这些函数的特性将在下面讨论。 这一章将集中讨论NYS而非另外两个软件包，对于这两个软件包我将称它们为“传统的”NIS代码。如果你确实要想运行任何这些软件包的话，本章中的说明也许已经足够也许还不够。要获取另外的信息，请取得一本有关NIS的标准（权威）书本，比如象Hal Stern的NFS和NIS（见[Stern92]）。 目前，NYS仍处于开发阶段，因此标准的Linux工具如网络程序或login程序还没有注意到NYS的配置方案。只有到NYS合并进主流libc中时，如果你想使得所有这些执行程序使用NYS时，你才需要重新编译它们。在任何这些应用程序的Makefiles中，在libc之前，指定-lnsl作为linker的最后一个选项。这将有关函数从libnsl—NYS库中连接过来，取代从标准C库的连接。 10.1 理解NIS NIS在所谓的包含键-值对的maps中保存数据库信息。Maps被存储于运行NIS服务器的中央主机中，从该主机中，客户可以通过各种RPC调用检索信息。最频繁地，maps是存于DBM文件中的。[4] Maps本身是从主要文本文件（比如/etc/hosts或/etc/passwd）中生成的。对于某些文件，会生成几个maps，每个搜寻键类型对应一个。例如，你可以为主机名和IP地址搜查hosts文件。相应地，从中会生成两个NIS maps，分别称为hosts.byname和hosts.byaddr。表10.1列出了通用maps和它们生成的文件。 Master File Map(s) /etc/hosts /etc/networks /etc/passwd /etc/group /etc/services /etc/rpc /etc/protocols /usr/lib/aliases Hosts.byname hosts.byaddr Networks.byname networks.byaddr Passwd.byname passwd.byuid Group.byname group.bygid Services.byname services.bynumber Rpc.byname rpc.bynumber Protocols.byname protocols.bynumber Mail.aliases 表10.1 一些标准的NIS maps以及相应的文件。 在某些NIS软件包或其它软件中，还有一些你可能会觉得有用的别的文件和maps。这些文件和maps可能含有没在这本书中讨论过的应用程序的信息，比如可能用于某些BOOTP服务器中的bootparams maps，或者在Linux中目前不含有任何函数的文件（就象ethers.byname和ethers.byaddr maps）。 对于某些maps，人们通常使用绰号（nicknames），它们很短因而易于键入。要想获得一个你的NIS工具能够理解的绰号的完整列表，运行下面的命令： $ ypcat –x NIS map nickname translation table: “passwd” -> “passwd.byname” “group” -> “group.byname” “networks” -> “networks.byaddr” “hosts” -> “hosts.byname” “protocols” -> “protocols.bynumber” “services” -> “services.byname” “aliases” -> “mail.aliases” “ethers” -> “ethers.byname” “rpc” -> “rpc.bynumber” “netmasks” -> “netmasks.byaddr” “publickey” -> “publickey.byname” “netid” -> “netid.byname” “passwd.adjunct” -> “passwd.adjunct.byname” “group.adjunct” -> “group.adjunct.byname” “timezone” -> “timezone.byname” NIS服务器传统地称为ypserv。对于一个中等大小的网络来说，单个服务器通常就足够了；大型的网络可能需要在不同的网段以及不同的机器上运行几个服务器，以减轻服务器机器和路由器的负荷。通过将这些服务器之一作为主服务器（master server），其它的服务器作为次服务器（slave servers），使得这些服务器同步。Maps将只在主服务器上建立。从主服务器上将它们分发到所有次服务器上。 你可能已经注意到，我们一直很含糊地论及“网络”；当然引用这样一个网络的NIS存在着与众不同的概念，也即通过NIS共享它们部分系统配置数据的所有主机的一个集合：NIS域。不幸的是，NIS域与我们在DNS中遇到的域绝对没有一点共同之处。为了在本章中避免含糊不清的情况，我将总是指出我说的哪一类型的域。 NIS域只具有纯粹的管理功能。对于用户来说它们主要是不可见的，除了在域中所有机器之间口令的共享。因此，给NIS域取的名字仅与管理员有关。通常，可以使用任何名字，只要该名字与你的本地网络上的其它NIS域名不同就行。例如，虚拟酿酒厂的管理员可以选择建立两个NIS域，一个是给酿酒厂本身用的，另一个是个葡萄酒厂的，她分别将其命名为brewery和winery。另一个很普遍的方案是简单地用DNS域名也作为NIS的域名。为了设置和显示你的主机的NIS域名，你可以使用dommainname命令。当不加任何参数调用时，它打印出当前NIS域名；如要设置这个域名的话，你必须成为超级用户并键入： # domainname brewery NIS域决定了一个应用程序将查询哪个NIS服务器。例如，在葡萄酒厂（Winery）的主机上的login程序（当然）将只向葡萄酒厂的NIS服务器（或者是它们其中之一，如果存在多个服务器的话）查询用户的口令信息；而酿酒厂主机上的应用程序将只查询酿酒厂的服务器。 现在还有一个疑点要解决，也即一个客户如何知道要连接到哪一台服务器上去。最简单的途径是有一个配置文件，它给出了要在其上查找服务器的主机名。然而，这个办法非常不灵活，因为它不允许客户依据这些服务器存在与否使用不同的服务器（当然是指从同一个域）。因此，传统的NIS实现依赖于一个称作ypbind的特殊后台程序在它们的NIS域中来侦测一个适当的NIS服务器。在能够执行任何NIS查询之前，任何应用程序首先要从ypbind找出要使用哪个服务器。 ypbind通过向本地IP网络广播来探测服务器；第一个响应的服务器假设基本上是最快的一个并将用于随后的NIS查询。在某个间隔时间过去以后，或者如果服务器不工作了，ypbind将再次探测运行着的服务器。 现在，关于动态绑定的争论点是你很少需要它，并且它会带来安全方面的问题：ypbind盲目地相信任何应答者，而这个应答者可能会是一个谦逊的NIS服务器也可能是一个怀有恶意的入侵者。不用说如果你在NIS上管理你的口令数据库的话，这将变成特别麻烦的事。为了防范这个问题，NYS缺省地不使用ypbind，而是从一个配置文件中取得服务器的主机名。 10.2 NIS与NIS+ NIS和NIS+除了在名字上和有共同的目标以外，很少有相同之处。NIS+是用一个完全不同的方法构成的。它使用一个类似于DNS的分级名字空间，而不是一个平面的名字空间和松散脱节的NIS域。它使用一个由行和列组成的所谓的表（tables）而不是maps，在NIS+数据库中表的每一行表示一个对象，而列表示NIS+所知所关心的对象的那些属性。一个给定的NIS+域的每个表由那些它们的父域组成。另外，表中的一个条目可以包含到另一个表的链接。这些特性使得用许多方法构造信息成为可能。 传统的NIS的RPC版本号是2，而NIS+的是版本3。 NIS+至今似乎还没有被广泛地使用，而且我实际上对它也知道不多。（唔，几乎一窍不通）。由于这个原因，这里我们将不涉及它了。如果你对它感兴趣并想多学一点的话，请参阅Sun的NIS+管理手册（[NISPlus]）。 10.3 客户边的NIS 如果你熟悉编制或移植网络应用程序的话，你将会注意到上面所列出的许多NIS maps与C库中的库函数相对应。例如，要获得passwd信息，你通常使用getpwnam(3)和getpwuid(3)函数，它们分别返回与给定的用户名或数值用户id相对应的帐号信息。在通常的环境下，这些函数将在标准文件（比如/etc/passwd）中执行请求的查找。 然而，这些函数的基于NIS（NIS-aware）的实现将更改这种行为，并且会启用一个RPC调用让NIS服务器查询用户名或id。对于应用程序来说这个操作是完全透明的。这个函数可以将NIS map“附加”或“替换”掉原始的文件。当然，这并没有对文件进行实际的修改，它只是让应用程序看上去好象该文件已经被替换或附加上去了。 对于传统的NIS实现来讲，对于那些maps替换掉以及那些被添加到原始信息中，曾有某些惯例。有些maps（比如passwd maps）需要对passwd文件进行杂凑地修改，当做错时，就会打开安全方面的缺口。为了避免这个缺陷，NYS常规的配置方案，该方案确定了一个特定的客户函数集是否使用原始文件、NIS、NIS+，并且以什么次序使用。这将在本章后续小节中加以讨论。 10.4 运行一个NIS服务器 在这么多理论方面的喋喋不休之后，现在开始动手做实际的配置工作。在本节中，我们将讨论NIS服务器的配置。如果在你的网络上已经有一个NIS服务器在运行，你就不必设置你自己的 |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
