home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / aix / 9471 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  2.0 KB
  1. Path: sparky!uunet!olivea!spool.mu.edu!agate!ames!haven.umd.edu!darwin.sura.net!wupost!m.cs.uiuc.edu!sunb10.cs.uiuc.edu!ziggy.cs.uiuc.edu!cgregory
  2. From: cgregory@ziggy.cs.uiuc.edu (Christine Gregory)
  3. Newsgroups: comp.unix.aix
  4. Subject: AIX 3.2 wasn't allowing mounts...
  5. Message-ID: <1992Sep9.012803.13261@sunb10.cs.uiuc.edu>
  6. Date: 9 Sep 92 01:28:03 GMT
  7. Sender: news@sunb10.cs.uiuc.edu
  8. Organization: University of Illinois at Urbana-Champaign
  9. Lines: 29
  10.  
  11.  
  12. A week or two ago, we posted about some problems we were having after
  13. upgrading our servers to 3.2 -- some minor annoyances, and one major
  14. problem:  One nfs server would not allow mounts while the other --
  15. which also happened to be the YP server -- would.  What really puzzled
  16. us was that we were getting RPC time-out errors -- as if the network
  17. were down -- but all other network traffic (rlogin, telnet, ftp)
  18. went through just fine in all directions.
  19.  
  20. Well, thanks to lots of help from some folks over at UI's CSO
  21. (Milt Cloud and Bob Booth), we discovered some little 'bad habits'
  22. that 3.2 wasn't letting us get away with -- like having more than one
  23. nameserver listed in resolv.conf (and not all the nameservers were 'good' -
  24. some outdated addresses, and some just plain old mistakes...).
  25. The strange thing is, these little things didn't cause problems (at least
  26. that we could SEE) in 3.1, but 3.2 wasn't about to let us get away with
  27. it anymore!  :-)
  28.  
  29. The two biggest ones were -- as I mentioned -- listing more than one
  30. nameserver, and listing the 'short' hostname in the TCP menu rather than
  31. the long one.  I.e.  3.1 let us get away with "ibma0" -- 3.2 wants
  32. "ibma0.cs.uiuc.edu".
  33.  
  34. Well, we're still chugging along with upgrading the rest of the clients,
  35. but at least we're back 'in business'!  And we've found that passwd
  36. (or yppasswd) now WORKS on yp clients -- it didn't used to in 3.1.
  37. chsh and friends still don't work on the clients, but at least the
  38. error message says so.  (The old way, it used to just add a line to 
  39. the local passwd file -- so we had eventually disabled it on the clients.)
  40.