This is 92-1_NI-DupsLoops.rtf in view mode; [Download] [Up]
NeXT Technical Alert 92-1
Supersedes NeXT Technical Alert 91-3
Summary
A loop in a NetInfoä database can be erroneously created; deleting this loop will destroy the information in the database. One way loops are created is by destroying erroneous duplicate directories.
Status
This Technical Alert supersedes NeXT Technical Alert 91-3, on the same topic. In this alert, the problem and preventative measure described in NTA 91-3 are documented; in addition, a program to fix this problem is described.
Description
Under various circumstances that can be encountered during normal operations, duplicate directories can be created in a NetInfo domain. For example, a subdirectory of /printers might show up in /machines. This can occur using the high-level manager applications (such as PrintManager) as well us using other tools.
This duplicate entry is benign, unless it's deleted. If this duplicate entry is deleted a loop will be formed in the database. When using NetInfoManager, this loop will appear as dir:0 in a directory. This loop will lead to NetInfo failures and long delays in retrieving information from NetInfo. If the loop is deleted, the NetInfo database may be destroyed and you'll have to revert to a backup copy.
Preventative Measure
A file called checksum is created by netinfod (the NetInfo server daemon) when it shuts down in a controlled fashion. This checksum file, one per NetInfo database, is written in the .nidb directory; its presence tells netinfod to assume that the database is consistent. As a preventative measure, this file can be removed at system startup time, before netinfod is run; this will force netinfod to check through the entire database, which will prevent new duplicates from appearing.
Warning: This measure is preventative only. It will not correct existing loops. If you have a NetInfo database with a loop, see the section on ªCorrective Measure,º below.
This preventative should be applied on each machine that's the master NetInfo server for a domain, except for machines that serve only a local domain. Even though these symptoms can appear in any NetInfo domain, network-wide or otherwise, it's rare to see them in a machine's local domain. Although it's not a problem to implement this workaround on any machine, the effort might not be worthwhile on machines that don't serve a network-wide domain. Here's an example:
Assume you have a network with three machines: master (which is the master NetInfo server of the root domain), clone (a clone server for the root domain), and client. The following table describes which machines serve which domains, and in what capacity. Let's further assume this is a two-level hierarchy.
Machine Domain Served Type of Server
master / Master Server
master /master Master Server
clone / Clone Server
clone /clone Master Server
client /client Master Server
In this configuration, we recommend applying the workaround to master, assuming that the local domains for each machine won't be modified very much. It's not necessary to apply the workaround to clone: Even though it serves the root domain, it's a clone server of the domain and thus obtains its authoritative information from master.
To implement the workaround, edit the file /etc/rc. Find the following lines (the first line shown is number 108 in the standard /etc/rc file):
# Start up the netinfo daemon
if [ -f /usr/etc/nibindd ]; then
/usr/etc/nibindd && (echo -n ' netinfo') >/dev/console 2>&1
fi
Add a line (shown below in bold), so the above lines look like this:
# Start up the netinfo daemon
if [ -f /usr/etc/nibindd ]; then
rm -f /private/etc/netinfo/*.nidb/checksum
/usr/etc/nibindd && (echo -n ' netinfo') >/dev/console 2>&1
fi
Note: To perform this procedure, you must be logged in as or sued to root.
It's not necessary to reboot the machine; the next time it's shut down or rebooted, the workaround will be in effect.
Note that if you implement this preventative measure, it will take longer to start up the machines that are network-wide NetInfo servers than before. It's also much more likely that you'll see the following message:
The following network error has occurred:
Cannot find parent NetInfo server, still looking¼
Press 'c' to continue without parent server.
See your system administrator if you need help.
This message is the result of the local domain's netinfod being unable to communicate with the its parent domain's netinfod. This is because the parent domain's netinfod is busy checking the database's consistency, and isn't responding to requests from the local domain to bind. Wait several minutes before pressing c to continue.
Corrective Measure
A program called nifix is available that removes, in a benign fashion, apparent duplicate directories and loops from a NetInfo domain. This program is available over anonymous FTP from NeXT.COM [129.18.1.2], in pub/Binaries/nifix.tar.Z. Be sure to retrieve this file with ftp in binary mode. Authorized support Customers who do not have Internet access may obtain a copy of nifix on floppy disk from NeXT Technical Support, through their normal support channel.
The checksum for nifix.tar.Z (the output of the sum command) and its contents once extracted should be as follows:
rhino% sum nifix.tar.Z nifix/*
14629 7 nifix.tar.Z
64307 16 nifix/nifix
00438 6 nifix/nifix-info.rtf
The compressed tar file contains two files: the executable program nifix, which a UNIX-level command-line utility, and nifix-info.rtf, a file with documentation on the program. Both of these files are contained in a directory ./nifix in the tar archive.
For More Information
Contact your NeXT Authorized Support Provider for more information about this problem. NeXT Authorized Support Customers should contact NeXTedge Technical Support with questions.
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.