Path: utzoo!censor!geac!jtsv16!uunet!crdgw1!montnaro From: montnaro@sprite.crd.ge.com (Skip Montanaro) Newsgroups: comp.sys.isis Subject: Re: ISIS "homework" problem... Message-ID: Date: 14 Nov 89 17:54:56 GMT References: <34173@cornell.UUCP> Sender: news@crdgw1.crd.ge.com Reply-To: (Skip Montanaro) Distribution: comp Organization: GE Corporate Research & Development, Schenectady, NY Lines: 48 In-reply-to: ken@gvax.cs.cornell.edu's message of 13 Nov 89 18:51:36 GMT In article <34173@cornell.UUCP> ken@gvax.cs.cornell.edu (Ken Birman) writes: Question 1: is the YP server as defined by SUN suitable for use in a larger-scale high availability setting? If you believe what you read in the "YP vs. the domain name server" articles that have been posted recently to several Sun-related newsgroups and mailing lists, the answer is "no". YP as Sun currently implements it apparently does not interact well with the domain system. In particular, YP doesn't "know when to say when" (sorry Spuds) and will continue attempting to get IP info for machines not in its database (this is when configured to "work" with the dns. as I understand it). This has been known to flood portions of the Internet on occasion. A somewhat less esoteric problem is that YP has no notion of hierarchy. A domain must have all the information in its maps that it cares about. It can't have incomplete information and get the remainder from a "super domain". For instance, consider a campus-wide network with the Geography, Computer Science, and Physics departments all in the same YP domain called "Cornell". All people in the Geography, CS, and Physics will (by default) have accounts on all machines in the three departments. Administratively, this is probably a "good thing". One person can administer all the global information. Now, suppose the heads of the Physics, CS, and Geography departments get in an argument at a tailgate party, and they each go away saying, "I'll be d***ed if those bozos are going to have accounts on my department's computers." They consult their respective system administrators, who inform them, "We'll have to either override the YP passwd database on every machine in our department, or break off and create a new YP domain." Either way, they all lose. Either each machine's administrative costs increase by the amount it takes to keep each machine's passwd file up-to-date (that's a lot - ask your users to change their passwords on all N machines every six months), or each departments' administrative costs increase by nearly the amount it takes to administer a separate YP domain and replicate all the truly global information (hosts and networks databases jump to mind). In the real world (out here in industry), you don't need arguments at tailgate parties for people to decide they need their own YP domains. We're just naturally unfriendly :-). We have about 400 Suns at GE CRD, with about 40-50 servers. I'll bet we have at least 20 YP domains. We don't have to worry about how well YP scales. We have to worry about transferring hosts and networks files around... -- Skip Montanaro (montanaro@crdgw1.ge.com)