make all clients ypslaves
2007-12-25 8:22:00
|>
|> Many thanks to those who replied to my orginal post of:
|>
|> >
|> >I was talking to a vendor and they suggested that in order to have high
|> >availabliity we should have all of our 140 clients be NIS slaves and bind
|> >to themselves. This would get us around a problem of having an NIS slave go down
|> >then hanging its clients till they rebound to someone else. It certainly makes
|> >me think! Has anyone tried this? If so how would you make a NIS slave
|> >bind only to itself and not let anyone else bind to it. At the same time would
|> >having all machines be NIS slaves create alot of overhead when the maps are
|> >pushed?
|> >
|> >
|> >Regards,
|> >Phil
|>
|> It seems that it would be too much overhead on the pushes.
|> Here were the replies:
|>
|>
|> We've 9 UNIX-workstations at our institute. Each of them is in its
|> own domain (regarding NIS). They all are their own server. Every night
|> the catch the new password file from ONE machine, make some changes in this
|> password (not all users are allowed on all machines) and use it as
|> their new password file.
|> Since we made this configuration we have much less trouble with the
|> availability of our workstations. There's only one 'problem': In order
|> to change your password, you have to log on the main server and the
|> change will propageted the next morning.
|>
|> If you wish, I can send you the shell-scripts we are using for this.
|>
|> Regards
|> Thomas Stuempfig
|>
|> ==============================================================================
|>
|>
|>
|> Phil,
|>
|> You really really would not want to do this. The time it would
|> take to make and push all of your maps would be insane. Also making sure
|> that all of the slaves are all up to date and such would be an administrative
|> nightmare. I worked on a domain that spanned 10 buildings and there were
|> probably at most 80-100 slaves and the pushes of the larger maps could
|> take an hour or so.
|> There is no real way to prevent clients from hanging in NIS if
|> the server goes away. This problem is solved by using NIS+ in Solaris 2.x
|> but I have no idea if you are planning on upgrading to that soon.
|>
|> If you have specific questions I would be happy to try to help.
|>
|> Shane
|>
|> P.S. The opinions expressed here are my own not those of my employer.
|>
|>
|>
|>
|>
|> Yes, we have here in a small mixed net where it was really important
|> for everything to work if many machines went down...
|>
|> >If so how would you make a NIS slave >bind only to itself and not let
|> > anyone else bind to it.
|>
|> Start up ypbind with the -ypsetme option and then do a "ypset
|> localhost"
|>
|> >At the same time would
|> >having all machines be NIS slaves create alot of overhead when the maps are
|> >pushed?
|>
|> With 140 hosts, definitely... Changing a password could cause your
|> ethernet to jam with pushes :-)
|>
|> --
|> | Paul Lindner | lindner@boombox.micro.umn.edu | Slipping into madness
|> | | Computer & Information Services | is good for the sake
|>
|> One big problem you would have is if several of the hosts went down and
|> you were updating maps on the master. For each map modified the master
|> will request each slave to retrieve the new map.
|> I belive timeout is 2 minutes. Thus if
|> you modify /etc/hosts and /etc/auto.home and 5 machines (ie slaves)
|> are down, you will wait 2x2x5 min = 20 min for the make in /var/yp.
|> (note all these examples are for SunOS). Also many sites run
|> ypxfr_1perday, ypxfr_1perhour, and ypxfr_2perday as cron jobs to ensure
|> maps on slaves are to date. A master responding to 140 slaves will
|> probably get bogged down doing this.
|>
|> -- Just a thought.
|> -- David O'Brien (obrien@sra.com)
|>
|> together. If you really want HA, you might want to find an NIS replacement,
|> perhaps rdist or track (ftp.cs.toronto.edu).
|>
|> ---
|> I never worry about a factor of two.
|> The problem is, neither do nine of my friends.
|> - Stu Feldman
|> cks@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks
|>
|>
|> Regards,
|> Phil
--
---------------------------------------------------------------
Dinah McNutt TIVOLI Systems, Inc. (512)794-9070
dinah@tivoli.com
---------------------------------------------------------------
Comments
Got something to say?
You must be logged in to post a comment.
