From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513

Description of problem:
I am running a kick-started, NFS install of RH 7.3.  My "%post"
post-installation script mounts an NFS volume, (with the "-o nolock" option,)
and runs a set of configuration scripts that do everything from installing
additional RPMS to installing or patching config files.

At some point (this also appeared in RH7.2,) I realized that my unattended,
kickstart installations were taking much longer than they should have.  The post
installation script, rather than taking a couple of minutes to run, was taking
nearly half an hour.

I have finally tracked down what the big slowdown is.  After changing the
nsswitch.conf file to use NIS, everytime I execute a "chown <directory>" command
in my post-install scripts, the system waits exactly 120 seconds before
completing the command.  Similarly, anywhere I execute a "/usr/bin/install
--directory --owner=  --group=" command, it takes exactly 120 seconds to complete.

This seems to be some kind of timeout associated with NIS, even though the uids
and guids involved can be resolved completely by /etc/passwd and group files.

This phenomenon can be observed on the VT2 debugging shell during installation
as well.

Version-Release number of selected component (if applicable):
fileutils-4.1-10, glibc-2.2.5-34

How reproducible:
Always

Steps to Reproduce:
1.  NFS install of RH 7.3, with kickstart.  Details of kickstart seem unimportant.
2.  After RPM installation completes, go to VT2
3.  chroot to /mnt/sysimage
4.  Replace all "nisplus" in /etc/nsswitch.conf with "nis".
5.  date; /usr/bin/install --verbose --directory --owner=4 --group=7 --mode=700
/var/spool/lpd/foo; date

or

5.  mkdir -p /var/spool/lpd/foo; date; chown 4:7 /var/spool/lpd/foo; date
	

Actual Results:  
Thu Jun 13 19:17:09 EST 2002
/usr/bin/install: creating directory `/var/spool/lpd/foo'
Thu Jun 13 19:19:09 EST 2002

Duration is exactly 120 seconds.

Expected Results:  A simple "chown" of a directory should take place just about
instantaneously, not take two minutes.

Additional info:

I have duplicated this problem in both RH7.2 and RH7.3, on a variety of
i386-class machines.
Chowning and installing files instead of directories does not display this
problem.  This problem manifests itself only during the installation process --
once the machine reboots for the first time, everything seems to be normal.

The lines in /etc/nsswitch.conf that I change are these:
the default entries

passwd:     files nisplus
shadow:     files nisplus
group:      files nisplus

are changed to

passwd:     files nis
shadow:     files nis
group:      files nis

Now, I realize that this change to the nsswitch.conf file causes glibc to wish
to perform NIS lookups from an NIS server that won't be available until after
the install, but I am providing numeric uids and gids here -- there really
shouldn't be anything to lookup.

I'm sure there is some subtle reason why it waits two minutes for a nonexistent
NIS server, but doesn't seem to mind a nonexistent nisplus server, but this
really isn't the behavior I expected.

The workaround is easy enough -- don't change nsswitch.conf until everything
else in the post-installation script is done.  But the implication is clear that
setting the line to

passwd: files nis

does not cause uid resolution to stop with "files" even if the answer is present
in said files.  It waits on some kind of connection with the NIS server.