[news.sysadmin] NNTP woes. Please help!!!!!!!!!!!!!!!!!!

fmbutt@cloud9.Stratus.COM (Farooq Butt) (10/27/89)

Help!!!! 

     I am trying to run NNTP 1.5.6.  on a sun 3/280s running SunOS
     4.0.3 and am running into a totally bizarre problem: Clients
     on my network wishing to run "rn" have to wait about 1.3
     minutes before nntpd running on our server will start
     dealing with them.

     After much tracing, I saw that nntpd was spending about a
     minute in the routine "host_access" in "access.c," after
     which it would let me read, write or transfer files (my
     access-file has the default being that everyone can
     read/write/xfer and NO other rules).  After the first 1.3
     minute glitch, things would continue as normal (i.e.
     articles came over as fast as I could handle).  If I
     short-circuit the "host_access" routine everything works
     FAST but in "promiscous" mode (i.e no authentication).
     I am concerned enough about security for this to be a 
     problem.

     The specific line in the "host_access" module where I think all
     the time is being spent in is the gethostbyaddr call (I
     touch files before and after the gethostbyaddr call and the
     second touch happens about a minute after the first) but I
     have no clue why that could be.  To add insult to injury, I
     have tried to perform the same gethostbyaddr call in a
     separate program and things seemed to fly right along.  What
     is it about NNTP's gethostbyaddr that is screwy.  Please
     remember that I can use nntp allright but only in "insecure"
     mode (i.e.  nntpd works nice and fast if and only if I do a
     trivial return from "host_access" giving all access to the
     host in question by setting the permission bits to 1.  I am
     about rip my hair out in frustration..what *could* be the
     cause of all this.  NNTP wizards here's
     your chance to prove that it is I, not NNTP, at fault here! 


     Thanks in advance!
     Farooq Butt 
     Stratus Computer (508) 460-2798
     fmbutt@cloud9.UUCP


-- 
NOTHING  in the above article has the slightest relationship to reality. 
If any reality correspondences are found, please notify me IMMEDIATELY.  
Any threats, abuse or stupidity of any kind are purely UNINTENTIONAL. 
My employer does not know that I exist and is not responsible for anything.

eps@toaster.SFSU.EDU (Eric P. Scott) (10/27/89)

(with any question of this type)
Please provide the following additional information--
	--are you using Yellow Pages?
	--are you using the libc provided with SunOS 4.0.3, or
	  the fixed one available from uunet?
	--did you link with -lresolv?
	--does your name server provide correct PTR records for
	  your network's IN-ADDR.ARPA domain?  (You can check
	  that with nslookup)

					-=EPS=-

mikel@teraida.UUCP (Mikel Lechner) (10/27/89)

fmbutt@cloud9.Stratus.COM (Farooq Butt) writes:

  >Help!!!! 

  >     [...] Clients
  >     on my network wishing to run "rn" have to wait about 1.3
  >     minutes before nntpd running on our server will start
  >     dealing with them.

  >     After much tracing, I saw that nntpd was spending about a
  >     minute in the routine "host_access" in "access.c," after
  >     which it would let me read, write or transfer files (my
  >     access-file has the default being that everyone can
  >     read/write/xfer and NO other rules).  After the first 1.3
  >     minute glitch, things would continue as normal (i.e.
  >     articles came over as fast as I could handle).  If I

	[...]

  >     the time is being spent in is the gethostbyaddr call (I

Oh yes.  I remember this problem.  I had these same symptoms with
NNTP 1.5.6 when I installed it about 2 months ago.  The time delay
IS caused by the gethostbyaddr call.  It is attempting to contact
the nameserver network service.  You are apparently not running
the nameserver (neither do I).

The fix is to remove "-lresolv" from the "LIBS=" line in the makefile
for the NNTP server.  This needs to be mentioned in the documention,
for those sites which don't run the nameserver.

-- 
Mikel Lechner			UUCP:  mikel@teraida.UUCP
Teradyne EDA, Inc.