Linux Network Administrator Manual (10)
2000-07-29 11:21
Publisher: NetBull Readings: 1183 Translation: Zhao Wei GoHigh@shtdu.edu.cn Chapter 10 Network Information System When you run a local area network, your entire target usually provides a clear and transparent network environment for your users. . An important step in this step is to maintain a synchronization of important data (such as user account information) between all hosts. We have seen in the previous example, there is a powerful and complex service, namely DNS. There is no such special service for other tasks. Also, if you just manage a small LAN without an Internet connection, you are not worth it for many administrators to install DNS. That's why Sun has developed NIS, namely a network information system. NIS provides Universal Database Access facilities that can be used to think of all host distribution information on your network, such as information contained in Passwd and Groups files. This makes the network look like a separate system that has the same account on all hosts. In the same way, you can distribute hostname information from / etc / hosts with all machines on the network with NIS. NIS is based on RPC, consisting of a server, a client library, and several management tools. At first, NIS was called Yellow Pages, or YP, and now this name is still informally referring to this service. On the other hand, YELLOW PAGES is a trademark of the British Telecom, and the British Telecom has been asked to replace this name. With the development of the situation, some names have not been opened with people, so YP has always been present in the form of NIS related commands, such as Ypserv, Ypbind, and more. Today, almost all UN * X includes NIS, and even has its free version. One is a NET-2 distribution from BSD, which is derived from the public domain reference implementation of Sun donation. The version of the customer library code already exists in the GNU's libc for a long time, and the manager is only transplanted by Swen Thümmler [1] recently. A NIS server program is missing in this reference implementation. Tobias Reber has prepared another NIS package, including all tools and a server; the package is called YPS. [2] Currently, a completely rewritten NIS code called NYS has been prepared by Peter Eriksson [3], which supports ordinary NIS and Sun's passing NIS . NYS not only provides a NIS toolset and a server, but also adds a new library function set, which may eventually be added to the standard libc. This includes replacing a new setting scheme for host name resolution currently using Host.conf. The characteristics of these functions will be discussed below. This chapter will focus on NYS rather than two packages. I will call them "traditional" NIS code for these two packages. If you really want to run any of these packages, the description in this chapter may be enough perhaps not enough. To get additional information, obtain a standard (authority) book on NIS, such as NFS and NIS, like Hal Stern (see [Stern92]). Currently, NYS is still in the development phase, so standard Linux tools such as network programs or login programs have not noticed NYS configuration schemes. You need to recompile them if you want to make all these executors use NYS when you want to use NYS. In the Makefiles of any of these applications, -LNSL is specified as the last option of Linker before libc.
This will be connected to the libnSL-NYS library to replace the connection from the standard C library. 10.1 Understanding NIS NIS Save Database Information in a so-called key-value-paid MAPS. Maps is stored in the central host running the NIS server, from the host, the customer can call the search information through various RPC. In the most frequent, MAPS is existing in the DBM file. [4] The MAPS itself is generated from the main text file (such as / etc / hosts or / etc / passwd). For some files, several MAPs are generated, each of which corresponds to one. For example, you can search for host names and IP addresses. Accordingly, two NIS MAPs will be generated from which Hosts.byName and Hosts.byAddr are known separately. Table 10.1 lists universal MAPs and their generated files. Master file map (s) / etc / hosts / etc / networks / etc / passwd / etc / group / etc / protocols / usr / lib / aliase 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 table 10.1 some standard NIS maps and the corresponding file. In some NIS packages or other software, there are some other files and MAPs you might feel useful. These files and MAPs may contain information about applications that are discussed in this book, such as BootParams Maps that may be used in some BOOTP servers, or files currently do not contain any functions in Linux (就 Ethers.byname) And ethers.byaddr maps. For some MAPs, people usually use nicknames, they are short because they are easily typed. To get a complete list of nicknames you can understand, run the following command: $ 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.byname "" rpc "->" rpc.bynumber "" Netmasks "->" netmasks.byaddr "" publickey "->" publickey.byname "" Netid "->" NetID.byname "Passwd.adjunct" -> "passw.adjunct.byname" "group.adjunct" -> "group.adjunct.byname" "Timezone.byname" NIS server traditionally referred to as Ypserv. For a medium-sized network, a single server is usually sufficient; large networks may need to run several servers on different network segments and different machines to mitigate loads of server machines and routers.
These servers are synchronized by using one of these servers as the master server, other servers as the SLAVE Servers. Maps will only be established on the primary server. Distribute them on all servers from the primary server. You may have noticed that we have been very vagueism and "network"; of course, there is a collection of NIS with such a network, that is, a collection of all hosts of the system configuration data through NIS: NIS area. Unfortunately, the NIS domain is absolutely no common in the domain we encounter in DNS. In order to avoid embarrassing situations in this chapter, I will always point out which type of domain I said. The NIS domain has only pure management functions. For users, they are mainly invisible, except for the sharing of passwords between all machines in the domain. Therefore, the name taken by the NIS domain is only related to the administrator. Typically, any name can be used as long as the name is different from other NIS domains on your local network. For example, administrators of a virtual winery can choose to build two NIS domains, one is used by the winery itself, and the other is a winery, she is named Brewry and Winery, respectively. Another very common solution is to simply use the DNS domain name as a domain name of NIS. To set and display the NIS domain name of your host, you can use the DommainName command. When no argument is called, it prints out the current NIS domain name; if you want to set this domain name, you must be a super user and type: # DomainName Brewery NIS domain determines which NIS server will query which NIS server. For example, a login program (of course) on the mainframe of Winery (Of course) will only query the user's password information (or one of them, if there are multiple servers); while winery host The app will only query the servers of the winery. There is still a doubt to solve, and how is a customer know which server to connect to. The easiest way is to have a profile that gives the host name to find the server on it. However, this approach is very flexible because it does not allow customers to use different servers in accordance with these servers (of course, refer to one domain). Therefore, traditional NIS implementations depends on a special background program called YPBIND to detect an appropriate NIS server in their NIS domain. Before you can perform any NIS queries, any application first wants to find it from YPBIND which server to use. YPBIND detects the server by broadcasting the local IP network; the first response server assumes basically the fastest one and will be used for subsequent NIS queries. After a certain interval, or if the server does not work, YPBIND will detect the running server. Now, the debate about dynamic binding is that you rarely need it, and it will bring security questions: YPBIND blindly believes any respondents, and this respondent may be a humble NIS server or one A malicious intruder. Don't say that if you manage your password database on NIS, this will become a special trouble. In order to prevent this problem, NYS default does not use YPBind, but the host name of the server is obtained from a configuration file. 10.2 NIS and NIS NIS and NIS except for the name and a common goal, there are few things. NIS is made of a completely different way. It uses a hierarchical name space similar to DNS instead of a flat name space and loosening NIS domain.
It uses a so-called table composed of rows and columns instead of MAPS, represents an object in each row in the NIS database, and lists those properties of the object that NIS knows the objects you care. Each table of a given NIS domain consists of those parent domains. In addition, an entry in the table can contain links to another table. These characteristics make it possible to construct information in many ways. The traditional NIS RPC version number is 2, and NIS is version 3. NIS has never been used extensively, and I don't actually know it. (Oh, almost unless). For this reason, here we will not involve it. If you are interested in it and want to learn more, see the Sun's NIS Management Manual ([NISPLUS]). 10.3 NIS of the Client Side If you are familiar with the text of the network application, you will notice that many NIS Maps listed above correspond to the library functions in the C library. For example, to get Passwd information, you usually use the getPwnam (3) and getPwUID (3) function, which returns account information corresponding to the given username or value user ID. In a usual environment, these functions will perform requests in standard files (such as / etc / passwd). However, these functions of NIS-AWARE-based implementations will change this behavior and enable an RPC call to get NIS servers query the username or ID. This operation is completely transparent to the application. This function can drop the NIS MAP "Additional" or "Replace" dropped the original file. Of course, this does not have actual modifications to the file, it just allows the application to look like this file has been replaced or attached. For traditional NIS implementations, some practices have been made for those MAPS replacement and those added to the original information. Some MAPs (such as Passwd Maps) need to modify the Passwd file. When doing something wrong, open security gaps. To avoid this defect, NYS regular configuration scheme determines whether a particular customer function set uses raw files, NIS, NIS , and uses in what order. This will be discussed in subsequent section of this chapter. 10.4 After running a NIS server, after so many theoretical chattering, start the actual configuration work now. In this section, we will discuss the configuration of the NIS server. If there is already a NIS server on your network, you don't have to set your own server; in this case, you can safely skip this section. Note that if you just want to test the server, please sure you have not set a NIS domain name that is already in your network. Because this will make the entire network service and make many people unhappy and angry. For Linux, there are currently two existing free NIS servers, one in the YPS package included in the Tobias Reber, and the other in the YPSERV package in Peter Eriksson. As for which one you run is irrelevant, no matter whether you use NYS or the standard NIS customer code in LIBC. When writing this book, the code in the NIS sequence in YPS seems to be more perfect. So if you want to talk to the secondary server, YPS may be a better choice. When the server program (YPSERV) is installed in / usr / sbin, you should create a directory to store the MAP files distributed to your server. Maps will be stored in / var / yp / brewery when setting up a NIS domain for the Brewry domain. The server determines if it is serving a specific NIS domain by detecting whether there is a MAP directory.
If you disable the service for some NIS domains, please delete the directory at the same time. Maps is usually stored in the DBM file to accelerate queries. They are created from the primary file with a program called MakeDBM or DBMLOAD (for the peter server). They are not interchangeable. Converting master files into dbmload analysis forms typically require some AWK or SED skills, which is bored and difficult to remember. Therefore, Perter Eriksson's Ypserv software contains a makefile, which will do all these work for you. You should install it as a Makefile in your map directory, and edit it to reflect the MAPs you want to distribute. On the head of the file, you will find the all target, which lists the services that Ypserv will provide. By default, the row looks like this: All: Ethers Hosts Networks Protocols RPC Services Passwd Group NetID For example, if you don't want to generate ethers.byname and ethers.byaddr Maps, you only need to remove Ethers prerequisites from this rule. . In order to test your settings, start only one or two MAPs, such as services. * Maps, it is enough. In the map of the map, type "make" after editing makefile. This will automatically generate and install MAPS. You must be sure that whenever you change the primary file, you must update your Maps, otherwise what you do is still invisible to the network. The next section explains how to configure NIS customer code. If your installation setting does not work, you should find that there is any request to reach your server. If you specify the -d command line flag for the NYS server, it will print out debugging information about all access NIS queries and return the result. These will give you a prompt to determine where the problem is. Tobias's server does not have this option. 10.5 Use NYS to set a NIS customer in this chapter, we will discuss the configuration of NIS customers. Your first step should tell Nys to use which server for NIS services and set it in the /etc/yp.conf configuration file. For a simple sample file on a host on a Winery (Winery), it looks like this: # Yp.conf - yp configuration for nys library. # DomainName Winery Server VBARDOLINO The first statement tells all NIS customers, they belong to Winery NIS domain. If you omit this line, NYS will use the domain name you assigned to your system through the DomainName command. Server statement specifies the NIS server used. Of course, the corresponding IP address corresponding to VBARDOLINO must be set in the HOSTS file; in addition, you can use the IP address itself in the Server statement. In the form shown above, the server command tells NYS to use the specified server regardless of the current NIS domain. However, if you frequently move your machine in different NIS domains, you may want to save information about several domains in the YP.conf file. You can get information about servers in several NIS domains by adding NIS domain names in a Server statement. For example, you can change the above sample file for a portable machine to be like this: # Yp.conf - YP Configuration for Nys Library # Server VBARDOLINO WINERY Server VStout Brewry This allows you to set the expected NIS domain in both when the system boot Use a portable in any domain in a domain.
After creating this basic profile and confident that it is readable, you should run the first test to check if you can connect to your server. Confident to choose any of the MAPs distributed in your server, such as Hosts.byName, and try to use the YPCAT tool to retrieve it. Ypcat, like all other NIS management tools, should be present in / usr / sbin. # Ypcat hosts.byname 191.72.2.2 vbeaujolais vbeaujolais.linus.lxnet.org 191.72.2.3 vbardolino vbardolino.linus.lxnet.org 191.72.1.1 vlager vlager.linus.lxnet.org 191.72.2.1 vlager vlager.linus.lxnet.org 191.72 .1.2 vStout vStout.linus.lxnet.org 191.72.1.3 Vale Vale.linus.lxnet.org 191.72.2.4 Vchianti vchianti.linus.lxnet.org The image you have got should be similar to the above. If you get an error message, "Can't Bind To Server Which Serves Domain" or some similar information, or if you set the NIS domain name in yp.conf, there is no match server, or for some reason The server can't be found. In the latter case, be sure that ping is to the host to generate the correct result, and it is really running a NIS server. You can use RPCINFO to verify the latter, it will generate the following output: # rpcinfo -u serverhost Ypserv Program 100004 Version 2 Ready and Waiting 10.6 Selecting the correct MAPS After confident, you must decide to replace with NIS MAPS Or which configuration file is added. In general, you will use NIS MAPS to host and password search functions. The former is particularly useful for not using bind. The latter allows all users to log in into their account anywhere in the NIS domain; this usually requires a central / home directory to share between all hosts through NFS. This will be discussed in detail in Section 10.7. Other Maps, like SERVICES.BYNAME, there is no dramatic performance, but can save you some editing work. If you have installed any web application, the app uses a service name not in the standard Services file. . Usually, when a lookup function uses a local file, when you ask the NIS server, you will want to have some free choices. NYS allows you to configure functions to access the order of these services. This is controlled by the /etc/nsswitch.conf file, which refers to Name Service Switch, of course, does not limit the name service. Any data lookup function supported by NYS, which contains a row of the specified service. The correct order of the service is related to the type of data. It is not necessary to let Services.byName's Map must contain different entries from the local Services file; it can contain more entries. So, a good choice can be first queried by local files, and only find NIS when the service name is not found. On the other hand, hostname information may change very frequently, so DNS or NIS servers should always have very correct information, while local HOSTS files are only a backup that is not available in DNS and NIS. In this case, you may want to finalize the local file. The following example shows how to configure gethostByName (2), gethostbyaddr (2) function as described above, and getServbyName (2) functions.
They will try the listed services; if a look is successful, the result is returned, otherwise the next service is tried. # Small sample /etc/nsswitch.conf # HOSTS: NIS DNS FILES SERVICES: FILES NIS You can have a list of complete services in the nsswitch.conf file as shown below. The MAPS, files, servers, and objects actually queried depend on the names. NISPLUS or NIS uses NIS servers to this domain. The location of the server is obtained from the /etc/nis.conf file. NIS uses the current NIS server of this domain. The location of the server being queried is set in the yp.conf file, and the front section is shown. For HOSTS entries, you must query hosts.byname and hosts.byaddr Maps. DNS uses DNS name servers. This service type is only useful to the Hosts entry. The name server to be retrieved is still determined by the standard resolv.conf file. FILES uses local files, such as the HOSTS entry uses the / etc / hosts file. DBM looks up information from a DBM file located within / VAR / DBM. The name used by the file corresponds to NIS MAP. Currently, NYS supports the following NSSwitch.conf entry: Hosts, Networks, Passwd, Group, Shadow, Gshadow, Services, Protocols, RPC and Ethers. There will be more entries in the future. Figure 10.1 shows a more complete example, it introduces another feature of nsswitch.conf: [NOTFOUND = RETURN] keyword in the hosts entry notifies Nys, if the desired item is not found in the NIS or DNS database, returns. That is, only when a call to the NIS and DNS servers fails, NYS will continue to search for local files. Therefore, the local file is only used during start boot and the role of a backup when the NIS server is turned off. # HOSTC/NSSWITCH.CONF # HOSTS: NIS DNS [NOTFOUND = RETURN] FILES NETWORKS: NIS [notfound = return] FILES SERVICES: FILES NIS Protocols: Files NIS RPC: Files NIS 10.1 nsswitch.conf sample file. 10.7 A main application using Passwd and Group Maps NIS is to synchronize users and account information on all hosts in an NIS domain. In this regard, you usually only save a small local / etc / passwd file, for this file, information from the site range of the NIS Maps is added. However, it is not enough to enable NIS lookup for this service in nsswitch.conf. When references the password information described by NIS, you must first be confident that the value user ID of any user in your local Passwd file matches the user ID of the NIS server. You will also need this way for other purposes, such as loading NFS volumes from other hosts in your network. If the / etc / passwd or / etc / group of any value ID is deviated from the MAPS, you must adjust the ownership of the file for all files belonging to the user. First you have to change the UID and GID in Passwd and Group to a new value; then identify all the files of the user who have just changed, finally changing the ownership of these files.
Suppose NEWS has an ID 9, and Okir has an ID 103, which will be changed to other values; then you can send the following command: # Find / -uid 9 -print> /tmp/uid.9 # find / -UID 103 -Print> /TMP/UID.103 # cat /tmp/uid.9 | xargs chown news # cat /tmp/uid.103 | xargs chown okir must perform these commands for newly installed Passwd files, and This is important to collect the names of all files before the ownership of any file. In order to update the group ownership of the file, you will use a similar command. After doing these work, the value UID and GID on your system will match all other hosts in your NIS domain. The next step will be added to the NSSWitch.conf to enable NIS for users and group information: # /etc/nsswitch.conf - Passwd and Group Treatment Passwd: NIS FILES GROUP: NIS FILES This makes it to try to log in in one user When the login command and all other similar commands first query NIS MAPS, if this lookup fails, returns to use the local file. Generally speaking, you will remove all users from your local file, while leaving only ROOT and Mail's universal accounts. This is because some critical system tasks may need to map UIDs to the username or in turn. For example, the managed Cron job may perform a SU command to become a news, or the UUCP subsystem may post a status report. If NEWS and UUCP do not have an entry in the local Passwd file, these jobs will fail during NIS can't use. There are two big rings here: on the one hand, the settings described above are only adapted to the login status without the shadow password, like those included in the Util-Linux package. Complex issues for using shadow passwords with NIS will be on the above. On the other hand, the login command is not a command to access the Passwd file - see Many people almost always use the LS command. Whenever a long list is performed, the LS will display the symbolic name of the host of the user and group of the group; that is, for each UID and GID it encounter, it will query the NIS server once. If your local network is blocked, it will be severely delayed, or worse, when the NIS server is not on the same physical network, the Data report must also be transmitted via router. Things haven't ended yet. Imagine what happens if a user wants to change her password. Typically, she will execute the passwd, which will read the new password and update the local Passwd file. For NIS, this is impossible, because this file is no longer present locally, but whenever the user wants to change their password, let them log in into NIS nor a choice. Therefore, NIS provides a mixed replacement replacement replacement of Passwd, which is used to do a similar job in the current NIS. In order to change the password on the server host, it is connected to the YPPASSWDD background program on that host through RPC and provides updated password information. Usually, you can install Yppasswd in the regular program like this, you must install rpc.yppasswdd on the server at the same time, you must install rpc.yppasswdd on the server and start it from rc.inet2. This will effectively hide any distortions brought by NIS. 10.8 NIS that uses support shadow (Shadow) has not yet supported NIS support for sites using the shadow login program group.
John F. Haugh, the author of the shadow program, recently issued a version of the GNU library function to the GNU library GPL protected. It has some support for NIS, but it is not complete, and these functions have not been added to the standard C library. On the other hand, the information from / etc / shadow is released from the information from the SHADOW component is contrary to the purpose of the Shadow component. Although the NYS password lookup function does not use Shadow.byName Map or any such MAP, NYS still supports transparently using a local / etc / shadow file. When the getPwnam's NYS implementation is called to find information related to a given login name, the facility specified by the Passwd entry in nsswitch.conf is retrieved. The NIS service will simply find this name in the Passwd.byName Map of the NIS server. The Files service will check if the / etc / shadow exists, and if it exists, try to open it. If there is no existence, or if the user does not have the root privilege, it returns to the traditional processing method that only finds user information in / etc / passwd. However, if the shadow file exists and can be opened, NYS will extract the user from the shadow. The getPwUID function is also achieved. In this way, the execution file compiled with NYS will transparently handle the installation of the local shadow assembly. 10.9 Use traditional NIS code If you use the customer code currently in the standard C library, then configuring a NIS customer is slightly different. On the one hand, it uses a YPBIND Background Program (DAEMON) to broadcast the query running the server instead of acquiring (server) information from a configuration file. Therefore, you must be sure to start running Ypbind during startup. It must be set in the NIS domain and the RPC portmapper has been called. At this time, the call YPCAT shown above will work to work. Recently, there are many reports about NIS error reporting, error information saying "Clntudp_create: RPC: Portmapper Failure - RPC: Unable to receive". This is due to the incompatibility of the YPBIND and the library function about the communication (communication) method of binding information. Obtain the latest source program about NIS tools and recompile to solve this problem. [5] Similarly, traditional NIS determines whether or how to combine the NIS information with information in the local file with the method used in NYS. For example, in order to use the NIS password Maps, you must include the following lines in / etc / passwd map: : *: o: o ::: This marked the export order lookup function "Insert" NIS MAPS. Insert a similar row in / etc / group (remove the last two colons) will make the same thing to Group. * Maps. In order to use the hosts distributed by NIS. * Maps, as long as the ORDER in the host.conf file is changed. For example, if you want to use NIS, DNS, and / etc / hosts files (in this order), you must change this line to Order YP Bind Hosts Currently, traditional NIS implementations do not support any other MAPs. Note [1] can be contacted with him with Swen@uni-paderborn.de. The NIS client is in the form of YP-Linux.Tar.gz in the System / Network on Matlab.Unc.edu. [2] Current version (when writing this book) is YPS-0.21 and can be obtained from the / pub / NYS directory of ftp.lysator.liu.se.
[3] You can contact him with Pen@lysator.liu.se. [4] DBM is a simple database management library that uses a Hashing Technigues to accelerate the query operation. GNU plans to have a free implementation called GDBM, which is included in most Linux releases. [5] You can obtain YP-Linux source programs from FTP.UNI-PADERBORN.DE / pub / linux / local directory. source:
Linux free pigeon
