> From: Richard Chycoski [mailto:rskiad...@chycoski.com] > > If the server that is currently pointed at fails, NIS takes too long to > fail over to a new server.
This hasn't been my experience. At one site, we have 2 NIS servers (a master & slave) and we regularly alternate reboots of the servers, to apply updates to one, and then the other. (Or for various other reasons.) There have never been any problems with this, unless it manifests itself in some transparent way that we've never noticed. Maybe what you're talking about was a problem bygone that has since been solved? All of our NIS servers and clients are RHEL4, RHEL5, centos 4 & 5, and solaris 10. > There's nothing stopping anyone from > building a caching NIS client, which would erase much of this > advantage, > but I've yet to see a caching NIS client. At one point, I wanted to support laptops and network outages, so each machine at some other job became a NIS slave. It worked fine, except for the pushing of updates. Before too long, we abandoned the idea. So I agree, a caching NIS client would be very nice. _______________________________________________ Tech mailing list Tech@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
