home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / sgi / 16519 < prev    next >
Encoding:
Text File  |  1992-11-17  |  2.0 KB  |  53 lines
  1. Newsgroups: comp.sys.sgi
  2. Path: sparky!uunet!ukma!darwin.sura.net!spool.mu.edu!agate!stanford.edu!leland.Stanford.EDU!dhinds
  3. From: dhinds@leland.Stanford.EDU (David Hinds)
  4. Subject: Re: Install problem
  5. Message-ID: <1992Nov17.014909.12730@leland.Stanford.EDU>
  6. Keywords: Install CDROM remote
  7. Sender: news@leland.Stanford.EDU (Mr News)
  8. Organization: DSG, Stanford University, CA 94305, USA
  9. References: <YFF=#z@engin.umich.edu> <srp.721956667@cgl.ucsf.edu>
  10. Date: Tue, 17 Nov 92 01:49:09 GMT
  11. Lines: 40
  12.  
  13. In article <srp.721956667@cgl.ucsf.edu> srp@cgl.ucsf.edu (Scott R. Presnell) writes:
  14. >hillig@U.Chem.LSA.UMich.EDU (Kurt Hillig) writes:
  15. >
  16. >>I've disabled logins on the guest account ("*" in the password field
  17. >>in /etc/passwd on the 360), and edited its /usr/etc/inetd.conf's tftp line:
  18. >
  19. >>    tftp    dgram   udp     wait    guest   /usr/etc/tftpd \
  20. >>        tftpd -l -s /usr/local/boot /CDROM/dist
  21. >>(folded for legibility).
  22. >
  23. >Looks ok, but I run it as root and say for the secure directory: /CDROM.
  24.  
  25. I thought it was generally a bad idea to use root as the uid (though with
  26. the -s flag it may not matter); the man page says to give tftpd the uid of
  27. the least privileged user.  We also use /CDROM instead of /CDROM/dist, but
  28. I don't know if it matters.
  29.  
  30. >0) Are you running cdinstmgr ?  (I assume that it just does the
  31. >    automounting as you describe above - but maybe it does more...)
  32.  
  33. I don't think this matters -- cdinstmgr seems to mainly be a convenient
  34. way of making sure the CD only gets ejected at appropriate times.  It is
  35. not essential.
  36.  
  37. >1) Are all the client machines in /etc/hosts.equiv on uranium?
  38. >2)     or is the uranium:~guest/.rhosts file set correctly?
  39.  
  40. I think this is the real problem.
  41.  
  42. >3) It is my recollection that the remote user of inst under 3.3.X was
  43. >"inst," consequently the .rhosts file had to let "inst" use the login..
  44. >i.e. the <server>:~guest/.rhosts file had:
  45. >
  46. >    hostname1    inst
  47. >    hostname2    inst
  48.  
  49. It seems to do it as user 'guest', not 'inst'.
  50.  
  51.         - David Hinds
  52.           dhinds@allegro.stanford.edu
  53.