Red Hat Bugzilla – Bug 88063
request for netfs to start after ybind
Last modified: 2014-03-16 22:35:31 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.3) Gecko/20030327
Description of problem:
We have many workstations that use hostname NFS mounts, with /etc/hosts
supplemented by NIS. NFS hostname (rather than IP address) mounts fail when the
host IP address is provided by NIS, because netfs is linked at S25 while ypbind
is linked as S27. We move rc?.d/S25netfs to rc?.d/S29netfs in all of our
workstations so we are free to move the NFS and NIS servers around and have host
to IP info coming from NIS and have successful NFS (hostname in fstab) mounts,
without having to update /etc/hosts in every client.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Put hostname NFS mount entries in /etc/fstab for a client, without specifying
host to IP map in the client's hosts file.
2. Make portmap, nfslock, netfs, and ypbind start at boot.
Actual Results: NFS mounts are attempted prior to starting ypbind, and they
fail due to inability to locate host (by name).
Expected Results: This should work, rather than having to resort to DNS or to
manually update hosts file in multiple clients.
Suggested fix is to link netfs to S2x (x > 5), so it comes after S25, which
links to ypbind.
Braino in the additional subject -- we would like netfs to start _after_ ypbind.
The issue here is that currently the ypbind init script relies on programs in
/usr, which could be mounted via NFS, which leads to circular dependencies.
Right, I did not think about that. We'll just swap netfs and ypbind starts and
stops here since it works better for us that way.
Perhaps start ypbind in the netfs initscript (only if necessary and possible
[i.e. /usr is available] -- I'm not sure how to check the "necessary" part),
then exit the ypbind initscript straightaway if ypbind is already running. It's
awfully convenient for us to be able to move around the NFS and NIS servers
without having to update local host tables. Actually, it seems resorting to
(local) DNS would be better than hacking on initscripts.