Tải bản đầy đủ
[Chapter 9] 9.3 Network Information Service

[Chapter 9] 9.3 Network Information Service

Tải bản đầy đủ

[Chapter 9] 9.3 Network Information Service

same map list on both our Solaris and Linux sample systems. Your server may display a longer list.
Here is the list from my Solaris system:
% ypcat -x
Use "passwd"
Use "group"
Use "networks"
Use "hosts"
Use "protocols"
Use "services"
Use "aliases"
Use "ethers"




The advantage of using NIS is that these important administrative files can be maintained on a central
server, and yet completely accessible to every workstation on the network. All of the maps are stored
on a master server that runs the NIS server process ypserv. The maps are queried remotely by client
systems. Clients run ypbind to locate the server.
The NIS server and its clients are a NIS domain - a term NIS shares with DNS. The NIS domain is
identified by a NIS domain name. The only requirement for the name is that different NIS domains
accessible through the same local network must have different names. Although NIS domains and
DNS domains are distinct entities, Sun recommends using the DNS domain name as the NIS domain
name to simplify administration and reduce confusion.
NIS uses its domain name to create a directory within /var/yp where the NIS maps are stored. For
example, the DNS domain of our imaginary network is nuts.com, so we also use this as our NIS
domain name. NIS creates a directory named /var/yp/nuts.com and stores the NIS maps in it.
While the NIS protocols and commands were originally defined by Sun Microsystems, the service is
now widely implemented. To illustrate this, the majority of examples in this section come from Linux not from Solaris. The syntax of the commands is very similar from system to system.
The command domainname checks or sets the NIS domain name. The superuser can make nuts.com
the NIS domain name by entering:
# domainname nuts.com
The NIS domain name is normally configured at startup by placing the domainname command in one
of the startup files. On Linux and Solaris systems, the value for the NIS domain name is taken from the
/etc/defaultdomain file. This file is used as input to a domainname command in one of the startup
files. As shown below, defaultdomain contains only the name of the NIS domain.
% cat /etc/defaultdomain

file:///C|/mynapster/Downloads/warez/tcpip/ch09_03.htm (2 of 5) [2001-10-15 09:18:31]

[Chapter 9] 9.3 Network Information Service

Initialize the NIS server and build the initial maps with make. The /var/yp/Makefile contains the
instructions needed to build the maps. As noted above, it creates a directory using the NIS domain
name. The Makefile reads the files in the /etc directory and places maps created from them in the new
directory. To initialize a Linux system as a NIS server:
# domainname nuts.com
# cd /var/yp
# make
make[1]: Entering directory '/var/yp/nuts.com'
Updating hosts.byname...
Updating hosts.byaddr...
Updating networks.byaddr...
Updating networks.byname...
Updating protocols.bynumber...
Updating protocols.byname...
Updating rpc.byname...
Updating rpc.bynumber...
Updating services.byname...
Updating passwd.byname...
Updating passwd.byuid...
Updating group.byname...
Updating group.bygid...
Updating netid.byname...
make[1]: Leaving directory '/var/yp/nuts.com'
After initializing the maps, start the NIS server process ypserv and the NIS binder process ypbind.
# ypserv
# ypbind
Our system is now running as both a NIS server and a NIS client. A quick test with ypwhich shows
that we are bound to the correct server. ypcat or ypmatch test that we can retrieve data from the
# ypwhich
# ypcat hosts

cow cow.nuts.com
pig pig.nuts.com
island.nuts.com island

The clients need only to define the correct domain name and to run the binder software ypbind:
# domainname nuts.com

file:///C|/mynapster/Downloads/warez/tcpip/ch09_03.htm (3 of 5) [2001-10-15 09:18:31]

[Chapter 9] 9.3 Network Information Service

# ypbind
Most NIS clients use ypbind to locate the server. Using the NIS domain name, ypbind broadcasts a
request for a server for that domain. The first server that responds is the server to which the client
"binds." The theory is that the server that responds quickest is the server with the least workload.
Generally this works well. However, it is possible for the client to bind to an inappropriate system,
e.g., a system that was accidentally configured to run ypserv or one that was maliciously configured to
be a false server. Because of this possibility, some systems allow you to explicitly configure the server
to which the client will bind. Linux provides the /etc/yp.conf file for this purpose. The syntax of the
entries in different versions of this file varies, so see your system documentation before attempting to
use it.
Place the NIS domain name in the /etc/defaultdomain file and the ypserv and ypbind commands in a
startup file so that the NIS setup will survive the boot. These commands may already be in your startup
file. On our Linux client all we needed to do was uncomment the appropriate lines in /etc/rc.d/rc.inet2.
On the Linux NIS server it was a little more complicated. In addition to uncommenting the lines for
domainname and ypbind we added lines to start ypserv.
NIS is a possible alternative to DNS but most systems use both NIS and DNS. Hostnames can be
converted to IP addresses by DNS, NIS, and the host file. The order in which the various sources are
queried is defined in the nsswitch.conf file.

9.3.1 The nsswitch.conf file
The Name Service Switch file (nsswitch.conf) defines the order in which the sources of information are
searched. Despite its name, it applies to more than just name service. All of the databases handled by
NIS are covered by the nsswitch.conf file, as shown in this example:


nis files


The first entry in the file says that a hostname lookup is first passed to DNS for resolution; if DNS fails
to find a match, the lookup is then passed to NIS and finally looked up in the hosts file. The second
entry says that network names are looked up through NIS. The [NOTFOUND=return] string says to
use the networks file only if NIS fails to respond, that is, if NIS is down. In this case, if NIS answers
that it cannot find the requested network name, terminate the search. The last two entries search for
services port and protocol numbers through NIS and then in the files in the /etc directory.

9.3.2 NIS+
Before leaving the topic of NIS, we should say a word about NIS+. It is just a short discussion,
because I do not use NIS+ and I do not know much about it.

file:///C|/mynapster/Downloads/warez/tcpip/ch09_03.htm (4 of 5) [2001-10-15 09:18:31]

[Chapter 9] 9.3 Network Information Service

NIS+ replaces NIS on Sun systems. It is not a new version of NIS, but a completely new software
product that provides all of the functionality of NIS and some new features. The new features are:

Improved security. NIS does not authenticate servers, as we noted in the ypbind discussion
above, or clients. NIS+ provides authentication of users with a secure DES-encrypted
authentication scheme. NIS+ also provides various levels of access so that different users have
authority to look at different levels of data. NIS can only provide the same access to everyone
in the NIS domain.
A hierarchical, decentralized architecture. NIS+, like DNS, is a distributed, hierarchical
database system. This allows for a very large namespace. It also allows distributed management
of the information structure while maintaining consistent access to the data. NIS is a flat
structure. All information about a NIS domain comes from a single master server and NIS
domains are not interrelated.
Enhanced data structures. NIS converts ASCII files into simple keyed files that the NIS+
documentation calls "two-column maps." NIS+ builds multicolumn database tables. Tables can
be searched in a variety of ways to retrieve information about an entry. In addition, NIS+ tables
can be linked together to provide related information about an entry.

Clearly NIS+ has some excellent new features and advantages over NIS. So why don't I use it? Good
question! The hierarchical architecture and enhanced data structures are important if you have a very
large network and lots of data in your namespace. However, many sites evolved using NIS on local
subnets and do not see the need to move the entire enterprise under NIS+. Improved security seems
like a real winner, but sites with low security requirements don't see the need for additional security
and sites with high security requirements may already be behind a firewall that blocks external NIS
queries. Additionally, NIS+ is not available for as many operating systems as NIS. Taken together,
these reasons have slowed the move to NIS+.
To learn more about NIS+ and how to install it on your system, read the NIS+ Transition Guide, the
Name Service Configuration Guide, and the Name Service Administration Guide. All of these are
available from Sun as part of the Solaris System and Network Administration manual set.
NIS and NIS+ provide a wide range of system configuration information to their clients. However,
they cannot provide all of the information needed to configure a TCP/IP system. In the next two
sections, we look at configuration servers that can do the entire job.

Previous: 9.2 Line Printer
9.2 Line Printer Daemon

TCP/IP Network
Book Index

Next: 9.4 A BOOTP Server
9.4 A BOOTP Server

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

file:///C|/mynapster/Downloads/warez/tcpip/ch09_03.htm (5 of 5) [2001-10-15 09:18:31]

[Chapter 9] 9.4 A BOOTP Server

Previous: 9.3 Network
Information Service

Chapter 9
Configuring Network Servers

Next: 9.5 DHCP

9.4 A BOOTP Server
A UNIX system becomes a BOOTP server when it runs the BOOTP daemon (bootpd). Some systems, such as Linux,
include the daemon with the operating system. Other systems, like Solaris, do not. Even systems that provide bootpd
as part of the system software do not run the daemon by default.
There are two ways to run the BOOTP daemon: it can be started at boot time from a startup script or it can be started
by the Internet daemon, inetd. If the server has a large number of clients that are frequently rebooted, run bootpd from
a startup file. Starting bootpd in this manner reduces the amount of "startup" overhead because the daemon is only
started once. Possible lines for starting bootpd from the rc.inet2 file on a Slackware Linux system are:
if [ -f /usr/sbin/bootpd -a -f /etc/bootptab ]; then
echo -n " bootpd"
/usr/sbin/bootpd -s
The code checks to make sure that the daemon and its configuration file are available. bootpd is then started with the s switch. This switch tells bootpd to continue running and listening to the bootps port, and not to time out even if there
is no activity on that port. The disadvantage of starting bootpd in this manner is that it continues to use system
resources even when it is not needed. The preferred way to start bootpd is from inetd. To start it from inetd on a
Slackware 96 Linux system, uncomment the bootps entry in the inetd.conf file and correct the path and daemon
name. [10] The completed inetd.conf entry is:
[10] The Slackware 96 inetd.conf file attempts to start in.bootpd instead of bootpd, which is the actual
name of the daemon on that system. I'm sure this will be corrected in later releases of Slackware.



wait root /usr/sbin/bootpd


This entry tells inetd to listen to UDP port 67 identified as bootps in the /etc/services file and, if it hears data on that
port, to run /usr/sbin/bootpd as user root. Once the line is added to the inetd.conf file, send a SIGHUP to inetd to force
it to read the new configuration, as in this example:
# ps -acx | grep inetd
93 ? S
0:00 inetd
# kill -HUP 93
If your systems does not include BOOTP software, don't panic: bootpd is available from the Internet. The same
software found in the Linux system can be downloaded in the bootp-DD2.4.3.tar file. Download and untar the source
code. su to root and compile the server software with make. The Makefile has entry points for several different UNIX
architectures. (For our sample Solaris system, we use the sunos5gcc entry point.) If the software compiles without
errors do a make install to install the executable daemon in the /usr/sbin directory. Do a make install.man to install
the manpages in /usr/local/man.
file:///C|/mynapster/Downloads/warez/tcpip/ch09_04.htm (1 of 7) [2001-10-15 09:18:32]

[Chapter 9] 9.4 A BOOTP Server

You should define all network services, including BOOTP, in the /etc/services file. Add the following lines to your
/etc/service file when bootpd is installed:


# bootp server
# bootp client

Finally, make sure that you include bootpd in the /etc/inetd.conf file as shown earlier in this section. Once it is
included and inetd is reloaded with a SIGHUP signal, you are ready to run.
Installing the daemon is only the beginning. The real challenge of managing a BOOTP server is providing the
configuration information that clients need. The package found on Linux systems and in the bootp-DD2.4.3.tar file is
the BOOTP daemon from Carnegie Mellon University (CMU). It has its own unique configuration commands. Other
BOOTP server implementations use other configuration commands. However, the type of information provided by
BOOTP is the same regardless of the implementation.
The CMU server reads its configuration from the /etc/bootptab file. The syntax used in this file is very similar to the
syntax of the /etc/termcap and the /etc/printcap files. Each bootpd configuration parameter is two characters long and
is separated from the other parameters by a colon. The general format of a bootptab entry is:
Where hostname is the hostname of the client, pa is the two character parameter name, and value is the value assigned
to that parameter for this client.
Newline characters separate each client's entry. If an entry spans multiple lines, the newline character at the end of
each line must be escaped with a backslash (\). Comments in the bootptab file begin with a sharp sign (#). Table 9.3
contains a list of the bootptab configuration parameters.
Table 9.3: bootptab Configuration Parameters
Parameter Description
Bootfile size
Cookie servers list
Dump file
Domain name
Domain name servers list
Vendor extension file
Gateways list
Hardware address
Bootfile directory
Send hostname boolean
Hardware type
Impress servers list
Host IP address
Log servers list
LPR servers list
IEN-116 name servers list


file:///C|/mynapster/Downloads/warez/tcpip/ch09_04.htm (2 of 7) [2001-10-15 09:18:32]