>>>>> "Bill" == Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us> writes:
    >> As does /etc/dhclient.db or something like that.  I think that
    >> the solution to this problem is to run dhclient in a mode where
    >> it pulls the lease info out of the kernel's copy of dhclient
    >> (since you probably booted diskless in my opinion, or you
    >> couldn't have an NFS /var before configured the network)
    >> 
    >> dhclient then does its things, confirms the lease without doing
    >> a new DISCOVER, and then, from dhclient's script, you do a
    >> "mount -t nfs". The rest of system waits or doesn't, as makes
    >> sense.

    Bill> I don't think it's that simple.  What happens when the lease
    Bill> expires while the DHCP server is off the air?  According to
    Bill> the DHCP spec, when this happens, you're supposed to drop
    Bill> off the net except for periodic attempts to get a new
    Bill> lease..

  Yes, clearly that is a more difficult problem.
  I think the current dhclient does not do this anyway at this point.

    Bill> I think that the core of a real DHCP client on a diskless
    Bill> system will have to be pinned in memory (which, for now,
    Bill> means, in the kernel).

  Hmm. Maybe. Is there no way that we can pin it in memory from use
space via madvise or something? If we have a DHCP client in the kernel
for that kind of booting, then I guess there is little reason to have
much at the user level. Since if the lease expires you are
essentially back to near the boot stage (no network), then this is
probably okay.

  It would be nice for the kernel/dhclient when it sees that less than
one minute remains in the lease and the renewal has either been denied
or has not yet responded, that it should notify the nfsd processes and
they might do some magic to internally remount their mounts as
read-only? At least they should flush all outstanding writes.. of
course that doesn't do the same thing as fflush() on all processes,
which is kinda impossible anyway.

]              Have encryption. Will travel.                    |1 Fish/2 Fish[
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |Red F./Blow F[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [