scott@DSG.Tandem.COM (Scott Hazen Mueller) (01/26/91)
I'm thrashing about, trying to get NIS to work properly on our MIPS Magnum workstations. These are pilot systems for my organization, and if I cannot get them fully functional I will be recommending that we don't buy any more of these until MIPS gets their act together. However, maybe I'm just screwed up and am not doing my setup correctly. The basic issue here is that ypbind dies immediately when I start it from /etc/init.d/netdaemons. Our other Unix admin here says that she had that problem under RISC/os 4.50, but thought it was fixed under 4.51, which is what I'm working with. By dying immediately, I mean that there is no indication that ypbind even lasts a few seconds; a /etc/ypbind followed by a /usr/bin/ypwhich in netdaemons yields the error 'ypwhich: bambi is not running ypbind'. The irritating part is that when I log into the workstation as soon as it finishes booting in and type 'ypbind', it starts up fine. Two successive ypwhich commands yield 'Domain .dsg.tandem.com not bound.' and the name of one of my Sun YP servers, respectively. The material in the 'RISC/os System Administrator's Guide, Volume I' that discusses NIS is spectacularly useless with respect to *exactly* how and when you invoke ypbind in the startup process, so I'm not even confident I'm starting ypbind correctly, though it strikes me as being particularly hard to screw this up. Since it may be relevant, my /etc/vis.conf contains: passwd: files nis group: files nis host: nis files net: nis files netgroup: nis files services: nis files proto: nis files So, if anyone has made it through all of my long-winded description, is there anyone out there who has seen and conquered this problem under 4.51, or who has a fully functional yp running? If so, I'd like to know what you did to make it work. Thanks, -- Scott Hazen Mueller scott@tandem.com (apple|sun)!tandem!scott Tandem Computers DSG, Unix System Administrator +1 408 285 5762
datri@convex.com (Anthony A. Datri) (01/31/91)
>I'm thrashing about, trying to get NIS to work properly on our MIPS Magnum >workstations. These are pilot systems for my organization, and if I cannot >get them fully functional I will be recommending that we don't buy any more >of these until MIPS gets their act together. That's rather drastic. Why not just chuck YP altogether? It's easy enough to work around. -- --
sandrock@aries.scs.uiuc.edu (Mark T. Sandrock) (02/01/91)
scott@DSG.Tandem.COM (Scott Hazen Mueller) writes: >The material in the 'RISC/os System Administrator's Guide, Volume I' that >discusses NIS is spectacularly useless with respect to *exactly* how and when >you invoke ypbind in the startup process, so I'm not even confident I'm >starting ypbind correctly, though it strikes me as being particularly hard >to screw this up. Check section 3.15 of the RISCos 4.51 Release Notes: Starting NIS "NIS must be started before the automounter and after the portmapper. This suggests that the proper place is a file called /etc/rc2.d/S38nis_local..." They go on to provide a sample startup file for NIS (which does not include yppasswdd nor rpc.passwd, BTW, but we added rpc.passwd to our own version). We have been running NIS under 4.51 for a good month now without problem. Hope this helps. Mark Sandrock -- BITNET: sandrock@uiucscs Univ. of Illinois at Urbana-Champaign Internet: sandrock@aries.scs.uiuc.edu Chemical Sciences Computing Services Voice: 217-244-0561 505 S. Mathews Ave., Urbana, IL 61801 "...make every effort to supplement your ...virtue with knowledge" 2 Peter 1:5
kdenning@pcserver2.naitc.com (Karl Denninger) (02/02/91)
In article <1991Jan25.225242.14654@tandem.com> scott@dsg.tandem.com writes: >I'm thrashing about, trying to get NIS to work properly on our MIPS Magnum >workstations. These are pilot systems for my organization, and if I cannot >get them fully functional I will be recommending that we don't buy any more >of these until MIPS gets their act together. However, maybe I'm just screwed >up and am not doing my setup correctly. > >The basic issue here is that ypbind dies immediately when I start it from >/etc/init.d/netdaemons. Our other Unix admin here says that she had that >problem under RISC/os 4.50, but thought it was fixed under 4.51, which is >what I'm working with. By dying immediately, I mean that there is no >indication that ypbind even lasts a few seconds; a /etc/ypbind followed by >a /usr/bin/ypwhich in netdaemons yields the error 'ypwhich: bambi is not >running ypbind'. Yep. >The irritating part is that when I log into the workstation as soon as it >finishes booting in and type 'ypbind', it starts up fine. Two successive >ypwhich commands yield 'Domain .dsg.tandem.com not bound.' and the name of >one of my Sun YP servers, respectively. > >The material in the 'RISC/os System Administrator's Guide, Volume I' that >discusses NIS is spectacularly useless with respect to *exactly* how and when >you invoke ypbind in the startup process, so I'm not even confident I'm >starting ypbind correctly, though it strikes me as being particularly hard >to screw this up. > >So, if anyone has made it through all of my long-winded description, is there >anyone out there who has seen and conquered this problem under 4.51, or who >has a fully functional yp running? If so, I'd like to know what you did to >make it work. Yes, we did get it all to work. And work quite well too. First, get the YPBIND fix from MIPS. If you don't, you will have HORRIBLY slow YP service (although it WILL work regardless, you just will be VERY upset at the performance. The patch fixes this entirely). Second, start ypbind with a "nohup". I know it's silly, but it needs to be done. Here's the extract from our rc scripts... .... sleep 2 nohup ypbind & sleep 2 ypwhich >/dev/null 2>&1 sleep 2 ypwhich ..... One other note. If you're using the automounter, make darn sure ypbind starts first! Once you do this, it works great. Our 3260 plays quite nicely with a network of about 60 Suns, and outperforms them as well, including a 4/490. The 3260 (which isn't even in the same class as a 4/490) hasn't had a problem yet that could be considered an "OS / implementation bug". Sun could learn a few things from these folks. -- Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285 kdenning@nis.naitc.com "The most dangerous command on any computer is the carriage return." Disclaimer: The opinions here are solely mine and may or may not reflect those of the company.