pwolfe@kai.com (Patrick Wolfe) (05/30/91)
phillips@qut.edu.au writes: >They have included all the system calls and daemons for YP except >for the facilities to use yp login and yppasswd. It's not just login that doesn't support Yellow Pages. None of the system services in SVR4 support yp. The passwd, group, hosts, netgroup, services, sendmail aliases, all the get*() library routines, etc - none of them! Running "nm" on the binaries shows no sign of the rpc* or xdr* routines. I don't know why they even bothered shipping the daemons. Does anyone really need yp for anything else? I like Yellow Pages. As a system administrator of a bunch of machines, no two alike, it saves me a lot of time. Installing a new system only takes 30 minutes (from box to login) if it supports YP. Also, it's a real pain keeping track of which of our systems DON'T support yp and performing separate user/group/host administration on each of them. C'mon AT&T (or Esix, or ISC, or ...) - fix SVR4 to use Yellow Pages! Now, can anyone tell me why SVR4 always takes at least five minutes to deliver an email message to another system via SMTP? What the heck is taking so long? Also, SVR4 could use a decent activity monitor. Something on the order of u386mon and top. The only window into system activity is "ps", and it doesn't show enough about memory usage or swapping/paging activity. Patrick Wolfe (pwolfe@kai.com, uunet!kailand!pwolfe) System Programmer, Kuck & Associates
adams@trim.intel.com (Robert Adams) (06/01/91)
In article <1991May30.045643.26262@csrd.uiuc.edu>, pwolfe@kai.com (Patrick Wolfe) writes: |> Now, can anyone tell me why SVR4 always takes at least five minutes to deliver |> an email message to another system via SMTP? What the heck is taking so long? The problem is that the smtp transport daemon is trying to resolve the route by searching for MX records (broadcast resolution request, wait, timeout, broadcast resolution request, wait, timeout...). An un- successful search will take 3 to 5 minutes. For SVR4 version 3, USL added a "-N" parameter to the smtpqer invocation to tell him not to do the MX record resolution (invocation in /etc/mail/mailsurr). For version 2, a workaround is to turn on the dynamic name resolution stuff (edit /etc/resolv.conf, etc) so that the smtp system has a quick way of resolving names. -- Robert Adams adams@littlei.intel.com ...!uunet!littlei!adams Disclaimer: Any opinions expressed here are my own and are not representative of Intel Corporation.