SUMMARY: weird DNS and NFS problem

From: Qing Chang <qchang_at_sten.sunnybrook.utoronto.ca>
Date: Mon Jul 29 2002 - 10:46:51 EDT
Hi there,

sorry for the late summary. For the first problem I got no response.
For the second I got one reply from Bryan J. Smith:

Linux 2.2's NFS client implementation is non-IETF compliant and only v2
(e.g., uses an "async" mode that doesn't verify the write).  Not until
Linux 2.4 did they start addressing it (including true NFS v3 sync and
async support).

For kernel 2.2, I _highly_recommend_ Trond+Higgen's patches which are
backports and other reworks from 2.4.  If you upgrade to 2.2.18 or
later, many of them have been integrated into the stock kernel.  Still
not as compliant and capable as kernel 2.4, but far better.

Thanks to Bryan. I hope users will actually upgrade before our next
reboot:-)

Qing

Original questions:

> Hi there,
>
> our NFS/DNS(master) server had been up for 100 days before it was
> rebooted.
> The basic configuration is as follows:
> SunOS sten 5.8 Generic_108528-10 sun4u sparc SUNW,Ultra-60
> During this time Sun's DHCP server was installed. DHCP server is
> running well.
>
> Problem 1:
> After reboot the server, DNS server was not initialized correctly, it
> did not
> recognize itself as a DNS server. in.named did not complain about any
> thing though. A kill -HUP would bring it to normal
> operation, as well as kill it and run "/usr/sbin/in.named". But this is
> certainly not the way it should work.
> in.named is started after NIS and NFS client, and before in.dhcpd.
> As mentioned above, DHCP server is the only change I recall on the
> machine.
>
> Problem 2:
> After rebooted the server, Linux NFS clients runnig kernel 2.2.16-22 and
> older lost
> users home directory which was NFS mounted with follwoing error:
> kernel: call_verify: unknown auth error: 5
> kernel: call_verify: server requires stronger authentication.
> On the server side, follwing showed up on console:
> mountd[515]: [ID 770583 daemon.error] linux_client denied
> access to /export/home
> Rebooting Linux boxes did not fix the problem. Only when
> we shutdown all those Linux boxes and rebooted the server, and
> then booted the Linux boxes up, they were happy. Again this
> is such a stupid procedure.... We did not change our authentication
> machenism.
>
> I don't see any relation between these two things, but they happened at
> the same
> time. Can anybody shed some light on these?
>
> Thanks so much, I will summarize.
>
> cheers,
> Qing
> --
> ----
> Qing Chang
> Senior Systems Administrator
> Research Computing
> Sunnybrook & Wemen's College Health Sciences Centre
> 2075 Bayview Ave.
> M4N 3M5
> (416) 480-6100 x3263
> ----
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
Received on Mon Jul 29 10:50:36 2002

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:50 EST