Date: Fri, 5 Mar 1999 14:44:09 -0500 (EST) From: "Crist J. Clark" <cjc@cc942873-a.ewndsr1.nj.home.com> To: solca@fisicc-ufm.edu (Otto E. Solares) Cc: jktheowl@bga.com, freebsd-questions@FreeBSD.ORG Subject: Re: NFS & NIS Problems Message-ID: <199903051944.OAA14210@cc942873-a.ewndsr1.nj.home.com> In-Reply-To: <36E0241E.828CDBB0@fisicc-ufm.edu> from "Otto E. Solares" at "Mar 5, 99 12:36:14 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Otto E. Solares wrote, > We have only a master server "zeus.adm.fisicc-ufm.edu", > no slaves, one NIS domain "olympia.fisicc" and all clients ^^^^^^^^^ > are in time synch with zeus. > > The clients used to be in the same network with the > server (192.168.1.0) but that was when we was setting up > the clients 1 by 1 so we have no chance to see if has the > same problems, now each lab contains like 40 clients, we have > 4 labs (lab1: 192.168.2.0 lab2: 192.168.3.0 lab3:192.168.4.0 > and lab4: 192.168.5.0) The clients are almost 95% the day > in windows and a few days we have like 60 in FreeBSD > (student projects), very tipically it hangs in X with the user > logged in and display a message like RPC time out. I think this is your problem. NIS is intended to be run over a LAN (it uses broadcast UDP messages). Client-server communications start to get really funky on a WAN. The most straight forward way to fix this is to run a slave server on each LAN. Keeping up a client-server relationship over a WAN, in my personal experience, requires a bit of Deep NIS Magic. Of course, I was mixing OSs as well which compounded my problems. -- Crist J. Clark cjclark@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903051944.OAA14210>