home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / sun / admin / 5938 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  2.1 KB
  1. Xref: sparky comp.sys.sun.admin:5938 comp.unix.admin:4761
  2. Newsgroups: comp.sys.sun.admin,comp.unix.admin
  3. Path: sparky!uunet!math.fu-berlin.de!informatik.tu-muenchen.de!LRZnews!k2
  4. From: k2@bl.physik.tu-muenchen.de (Klaus Steinberger)
  5. Subject: Re: NIS, slave servers and DNS access
  6. Message-ID: <k2.715070649@woodstock>
  7. Sender: news@news.lrz-muenchen.de (Mr. News)
  8. Organization: Leibniz-Rechenzentrum, Muenchen (Germany)
  9. References: <92241.144541QQ11@LIVERPOOL.AC.UK>
  10. Date: Sat, 29 Aug 1992 06:44:09 GMT
  11. Lines: 36
  12.  
  13. QQ11@LIVERPOOL.AC.UK (Alan Thew) writes:
  14.  
  15. >I have a machine that requires DNS access which normally means running
  16. >NIS (yes I know it can be done without NIS but that's not possible in my
  17. >case). The machine will be a mail hub.
  18.  
  19. >I would like to know if I can do 2 things:
  20. >1) prevent NIS clients from binding to my slave 'server' (I need to be a
  21. >   slave server to make it more robust since if I am just a client and the
  22. >   server on my subnet goes down (happened before), my machine will go
  23. >   AWOL :-( -- no other servers on my subnet currently) and impacting
  24. >   performance.
  25. There is no mechanism to prevent the clients from this.
  26.  
  27. >2) Can I take the password maps and somehow disable the passwords so that I
  28. >   have a list of usernames but they cannot logon to the mail hub.
  29. Yes, just make a entry like this into your /etc/passwd:
  30. +::::::/etc/noshell
  31.  
  32. (/etc/noshell could be a program which tells the user why he isn't
  33. authorized to login, just simple to write such a beast)
  34.  
  35. I would consider to run real DNS on your machine, instead through
  36. NIS. If you resolve hostnames through NIS, sendmail will have no chance
  37. to see if a failure is temporarily, or permanent. So you would get
  38. delivery failures even in the case of temporarily unreachable nameservers,
  39. or even when your query times out due to long delay between here and there!
  40. Also no chance for MX queries, so you are completly lost!
  41.  
  42. Sincerely,
  43. Klaus Steinberger
  44. --
  45. Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
  46. Phone: (+49 89)3209 4287        Hochschulgelaende
  47. FAX:   (+49 89)3209 4280        D-8046 Garching, Germany
  48. Internet: Klaus.Steinberger@Physik.Uni-Muenchen.DE
  49.