TITLE
    Mac OS X Server: Review Of Network Startup (1 of 2)
Article ID:
Created:
Modified: 		30757
9/23/98
10/30/00
TOPIC

    This article will give a brief review of the basic network startup procedures, including network interfaces, rpc, netinfo, and lookupd. More startup scripts are reviewed in the following article:

    Article 24720: " Mac OS X Server: Review Of Network Startup (2 of 2) "

DISCUSSION

    Configuring the Network Interfaces

    When your computer is bootup, it runs several scripts that configure a wide variety of services that enables the computer to use the network, and its local filesystem. Theses scripts are located in the /etc directory and are called rc scripts. If the computer is booting into single-user mode the rc.boot script is executed. When a multi-user boot is taking place the rc script is executed.

    The rc script does not do much itself, instead it executes the scripts in the /etc/startup directory. The scripts in this directory are responsible for proper configuration of the system. If you want to customize your scripts, it is best to customize the scripts in the startup directory, after backing them up.

    The /etc/startup/0800_Network script configures the network interface and sets a hostname. It does this by processing /etc/iftab and /etc/hostconfig , with the various settings there affecting whether, for example, things such as the IP address or hostname are hard-coded or are obtained from the network. These settings are changed with the Setup Assistant, the Preferences.app, or by manually editing the /etc/hostconfig file.

    This script also configures IP routing so IP packets can be sent to computers on other networks. Two types of routing are supported through the default mechanisms: "dynamic" routing, using the routed program and the RIP protocol, and ``static'' routing, where an explicit default route is specified. In the former case, routed builds a routing table based on the RIP packets obtained from network broadcasts. In the latter case, all remote networks are reached by forwarding the packet to the specified router.

    Note : When dynamic routing is specified, the -q flag is used when invoking routed. This informs routed that it should not supply routing information to the network.

    If static routing is requested, a command similar to the following is invoked (this command assumes that 192.42.172.1 is the address of the router for this network):

    /usr/etc/route add default 192.42.172.1 1 >/dev/console 2>&1

    What does this call to /usr/etc/route mean? It directs route to add a route to the kernel's routing table (the add keyword). This route should be used if no explicit routes are available (default). The router's address is specified next (192.42.172.1 in this example), and the router is one "hop" away (1 in this example). For details, see the system manual pages for route (8). For more information on routing in general see the networking references in last issue's column.

    Routing is configured before NetInfo is started. This allows netinfod to bind and lookupd to connect across networks (subnets), although it forces you to use explicit IP addresses, rather than hostnames, for static routing configuration. (If you insist on using a symbolic hostname for routing, just ensure that it's in /etc/hosts , along with its IP address, and that you keep /etc/hosts current.)

    Starting RPC

    What are ``RPC'' services? RPC stands for Remote Procedure Call. With RPC, a host can make a procedure call that appears to be part of the local processes, but it is actually executed on another machine. They are those services that use the SunRPC protocol for providing a mechanism for remote procedure invocation. RPC is complex topic and will not be fully discussed here. When a program using RPC server is launched, it tells the portmapper daemon which port it is going to listen on. When an RPC client makes a request it asks portmapper which port the program is listening on. The client can then make the request on that port. You can think of the portmapper daemon as directory assistance. The portmapper is a SunRPC-based program. It happens to have a well-known port number, just as the telephone system's directory assistance service has a well-known number (411 in the United States, for example). The portmapper is used extensively by NetInfo, NFS, and NIS, among other services. RPC is started when the /etc/startup/1000_RPC script is executed.

    Starting NetInfo

    Once the portmapper and routing are configured, it's time to start NetInfo. This is done by the very simple script /etc/startup/1100_DirectoryServices . It has one command, nibindd . Nibindd is the daemon that responds to requests from clients to become part of the network. After binding has taken place the client will have access to the information stored in NetInfo.

    When nibindd starts, it does the following:
    • Creates a ``pid file'' (a file containing its process ID number)
    • Locks the /etc/netinfo directory, so that no other nibindds will run
    • Registers the RPC service with the RPC protocol-dispatching mechanism
    • Registers its UDP and its TCP services with the portmapper
    • Runs a netinfod for each NetInfo database in /etc/netinfo

    Once started, nibindd awaits requests from clients.

    How does nibindd determine which NetInfo databases exist in /etc/netinfo ? It looks for entries in /etc/netinfo that have a suffix of .nidb, .move, or .temp. These entries represent NetInfo databases; those with a .move or a .temp suffix are temporary databases.

    For each netinfod started by nibindd, the following steps are accomplished:
      1. Check the database for consistency, if needed, calculating its checksum while so doing. Consistency checking will be needed if the checksum file is missing from the database, indicating that the previous netinfod running on that database did not terminate normally. This consistency checking verifies the internal structure of the NetInfo database.
      2. Register the RPC service with the RPC protocol-dispatching mechanism.
      3. Bind to a parent server if netinfod's tag is local (if its tag isn't local, parent binding is done lazily, only when necessary).
      4. Register its UDP and TCP ports with nibindd.
      5. If running as a clone, send a read-all request to the master, to ensure its database is synchronized with the master's. If running as a master, send a crashed request to each clone, informing the clones that the master has restarted (if the clone's database is out of date, the clone will request a new database from the master, using the readall operation).

    If there's a problem in step 3 (netinfod local binding to its parent), you'll see the following message on your console:

    Still searching for parent network administration (NetInfo) server. Please wait or press 'c' to continue without network user accounts.

    See your system administrator if you need help.

    This is the standard message; it's configurable, so yours might even be completely different from this. (The message resides in the file NetInfo.strings in the various language.lproj directories within /System/Library/CoreServices/Resources/English.lproj/NetInfo Strings ; edit the portion of the message to the right of the equals sign if you want to see what's displayed.) If you see this message, it's because netinfod local is looking for a parent and not getting an answer. It'll keep looking--forever, or until it finds a parent, or until you tell it to continue without a parent. If your network just crashed (maybe there was a power failure, for example), it might take 10 or 20 minutes after all the disks are checked for NetInfo to recover completely from the failure.

    Starting Lookupd

    NetInfo's lookupd is also started by the /etc/startup/1100_DirectoryServices script. This daemon contains information about users, computer names, and group IDs. Lookupd will iterate over users in its cache by looking through the NetInfo hierarchy. It will start at the local domain and move upward through the root domain to gather this information.

    Lookupd is covered in more detail in the following article:

    Article 30770: " Mac OS Server: What is Lookupd? "

    To iterate over the users in a domain, lookupd must connect to the domain. To start, lookupd connects to the local domain--the domain tagged local on the current machine--using the loopback interface (127.0.0.1).

    Note : The start of the domain hierarchy--the ``address'' of netinfod local on the local host--is always known: 127.0.0.1/local in NetInfo parlance.

    After connecting to the local domain and exhausting its user information, lookupd sends netinfod local a rparent message, requesting the address and tag of netinfod local's parent domain, if it has one. If there's no parent--because this machine's NetInfo is standalone and has no parent domain, even if it's on a network--the search through NetInfo ends. If there's a parent, lookupd gets the users from that parent domain--the ``second-level domain.'' Because netinfod local always binds to its parent, if it has one, before completing its startup sequence, local's parent is always available at this point, if there is one.

    When lookupd exhausts the information in the second-level domain, it asks the server providing that information for its parent--for the address of a server for the third-level domain. If the domain hierarchy is two deep, the second-level server replies that it's running the root domain; if the hierarchy is deeper than two, and if the second-level server has bound to its parent already, then the address of a server for the third-level domain will be returned.

    The review of network startup is continued in the following Tech Info Library article:

    Article 24720: " Mac OS X Server: Review Of Network Startup (2 of 2) "

Document Information
Product Area: Mac OS System Software
Category: Mac OS X Server
Sub Category: General Topics

Copyright © 2000 Apple Computer, Inc. All rights reserved.