Broken NFS server (or client?)

[Lincoln Peters]

>From: ME <dugan at passwall.com>
>Reply-To: <talk at nblug.org>
>To: talk at nblug.org
>Subject: Re: Broken NFS server (or client?)
>Date: Wed, 8 Aug 2001 21:50:37 -0700 (PDT)
>
>On Wed, 8 Aug 2001, Lincoln Peters wrote:
> > >I assume the test client has a local HD since you have LILO being used 
>for
> > >the netboot testing. This is true?
> >
> > No, LILO is installed on the boot floppy.  There is no hard disk.
> > (although since it's a VMWare virtual machine, I can add one with little
> > difficulty)
>
>Might be an option, but check other things for now. :-)
>
> > >When you boot the client from the local disk, are you able to nfs mount
> > >the exported volume and use it as you desire to use with a netbooted
> > >system?
> >
> > When I tried to mount the root filesystem on another client (it is 
>supposed
> > to be mountable to any system that wants to mount it), I got a similar 
>error
> > message.
>
>Ahhhh. This is a good pointer. Lets have a look at the list of NFS
>exports. Not sure if this is still going to be /etc/exports on your
>NFS server, but it is a place to look. I really want to see what
>rules/permissions you have for the export (who can look at it as well as
>ro?rw?) also could you show the ls -l of the volume and make sure that all
>of the dirs leading up to the volume share point are at the very least +x
>for everyone and just for testing rwxr-xr-x (755).

There is only one line in /etc/exports:
/ (rw)	# Root filesystem (for diskless clients)


>
>As the other poster wrote:
> > From: Mark Street <jet at sonic.net>
> > Do you have portmapper running?  Is it started before nfsutils?
>
>which is another very good point in this same direction.
>
>Also, related to the excellent point from Mark:
>Do you have any firewall rules on the server that we should know about?
>
>Really, it gets to the direction of thought:
>Can you do it with another non-NFSroot client? If you can't, then focus on
>the server side. Once you can get a different disk based client to NFS
>mount the export from the server, then we can look back at the client
>side.
>

There is no firewalling set up on the NFS server (I use a different computer 
as a firewall).  However, I tried mounting the NFS filesystem on my other 
test client (the one with a hard disk), and got a "Connection refused" 
error.

Perhaps the server is malfunctioning rather than the client.

> > >When you write about this error, are you saying that you can't even 
>mount
> > >your root filesystem via NFS from the client, or once you have the 
>client
> > >machine net-booted in Linux you get this error when you ry to start up 
>the
> > >vmware application?
> >
> > I can't mount the root filesystem via NFS.  I don't think that VMWare is
> > causing any problems.
>
>I agree with your conclusion based on the data we have so far. :-)
>
> > >Does the client get a different IP address fron the network when it
> > >netboots vs. when it is running from a local HD?
> >
> > It does not have a local HD, but since each system that I run with 
>VMWare
> > always seems to get the same IP address every time I run it (I'm not 
>saying
> > that they all share a single IP address), I can (hopefully) safely 
>assume
> > that the IP addresses are the same.
>
>This would be another point for testing. Fire up your test-NFS client (the
>one with a disk) and bind the same IP address you will use for the client
>that will be netbooting and mounting its root via NFS. This helps to make
>sure any IP based authentication or checks would otherwise pass when the
>IP is moved to the real netbooting client.

There are not supposed to be any IP-based authentication checks, at least 
not yet.  Although I supopse if the server is misconfigured, it might be 
trying to perform IP-based authentication using an empty list of valid 
machines.

BTW, I can't have my test client with a hard disk bind to the address of the 
diskless test client because I don't know what the IP address is.  I'm not 
even sure that the test client it is getting an IP address because I can't 
see any DHCP activity on the DHCP server when the client boots.

>
> > >Is the error logged from the server or the client or both?
> >
> > The error can't be logged by the client since it has nowhere to log to; 
>it
> > just gave me that "Error -101" message that I already described.  And I
> > cannot find any NFS logs on the server.
>
>So, the client just hangs in the middle of the kernel loading giving some
>grand message like
>"Kernel panic unable to mount /"
>?

It gives me the NFS error I described earlier, then asks me to insert a 
floppy disk with a root filesystem.

>
> > >"The client IP address is in the lilo configuration" how? is this an
> > >"append=" statement? Often those are passed to scripts that do the 
>actual
> > >work of setting up your interfaces. Is it just getting its IP and nfs 
>root
> > >server/volume from bootp/dhcp?
> >
> > The appended lines are:
> > root=/dev/nfs
> > nfsroot=192.168.0.6:/
>
>This concerns me greatly. Are you really exporting your root "/" file
>system from your server over NFS? Usually, you create a second system tree
>in a new location off of the root file system like /usr/export/system1 and
>then have your nfsroot= entry on the client look like:
>nfsroot=192.168.0.6:/usr/export/system1
>and then have an entry in your /etc/exports on the server like:
>/usr/export/system1	*.yourdomain.com(ro,insecure,all_squash)
>or perhaps
>/usr/export/system1	*.yourdomain.com(ro,all_squash)
>
>and then make sure that either:
>all of the ip addresses of client that will connect to NFS have valid
>entires in the server's /etc/host file with FQDN (Fully Qualified Domain
>Names) *or* a DNS server that will provide zone support for reverse lookup
>of the IPs and make the *.yourdomain.com check for the incoming IP address
>work.
>
>(There are other ways, but this is the most common I think.)
>
>One big issue with exporting your server's root over NFS is that even if
>is is ro, you may not have all_squash and an evil user may be able to see
>files they should not= from a client machine. Perhaps password files, etc.

This server probably does not have enough disk space to hold two operating 
system as you described.  I see why it would be a good idea to use a 
different filesystem than the root filesystem, but I doubt that any of the 
users of this system would know anything about cracking Linux (although I 
recognize the possibility).

Since nobody else is using either the client or the server at the moment, 
I'll worry about security once I have them working in some manner.

>
> > It is configured to get its network configuration from a DHCP server.
> > However, I did notice that there is no entry in the DHCP log that looks 
>like
> > my test client.  The problem still appeared on the test client as an NFS
> > error, though.
>
>This part confuses me:
> > The problem still appeared on the test client as an NFS error, though.
>
>So the problem and error appear on the screen of the test client, or the
>symptoms appear on the test client? The Server does still log the error
>message in a server log file too, eh?

The error I described appeared on the client's monitor.  I could not find 
any records that refer to the test client on the DHCP server or the NFS 
server.  Although I would expect that if neither was working, the DHCP error 
would stop the system before the NFS error would come up.

>
>Mark Street <jet at sonic.net> has some good thoughts on troubleshooting
>too. I'd go through his suggestions and look at his questions as well.
>
>-ME
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp