Solved [was: What part of INN is responsible for sending IHAVE?]

[Tom Kacvinsky]

Hi again,

I figured it out, I think...

In innfeed.conf, we have a peer set up.

In newsfeeds, the innfeed! channel did not have the -y option for
startinnfeed.

I added the -y back, and our problems went away.

But...

This was *after* recompiling innd, innfeed, and nnrpd using -lresolv
instead of -lbind.

So I am thinking it is a combination of the object code generated by
linking against -libind *and* not having -y in the options list for
startinnfeed that caused our problems.

Or is it that if one has a peer set up, one needs to use -y?

Does streaming have anything to do with this?

Or am I way off track?

Thanks,

Tom

On Thu, 13 Jan 2000, Tom Kacvinsky wrote:

> Hi all,
> 
> First, apologies for the misleading subject line.
> 
> I meant to write "why is article propogation failing?".
> 
> Here are some facts I left out of the first message:
> 
> uname -a:
> 
>     SunOS sun06 5.6 Generic_105181-17 sun4u sparc SUNW,Ultra-2
> 
> compiled with gcc 2.95.2.
> 
> The only `skanky' thing I did was link against libbind.a (see a
> previous post of my about this).
> 
> We are using CNFS with tradindex.
> 
> Here is the scoop: we are receiving a feed from our ISP, but locally
> posted articles (not local *newsgroups*) are not making back to our
> ISP's news server (they happen to run Cyclone).
> 
> Someone answered my original question about which part of INN sends
> IHAVEs: innfeed (or innxmit).  However, my truss output from a post I
> did from my news client did not show an exec of innfeed.  Rather,
> nnrpd took the POST'd article and wrote it out to the SM (or that is
> what I led to believe), and then wrote to the nntpin socket, sending
> an IHAVE to the main inn process.  After innd and nnrpd did their
> dance, I got a return code of 235 (article successfully posted).  So,
> once again, the article (and the overview data for the article) are
> stored on our news server.  But the article is not making it upstream.
> I know this because I can telnet to our ISP's server and send an IHAVE
> <msg-id>, and I get a return code of 335 (send me your article, I
> don't have it).
> 
> I have ruled out firewall issues, because we are receiving a feed,
> and I can telnet out to the ISP's news server on port 119.
> 
> I have also ruled out linking against libbind.a, because all other
> network functionality is there (post, receive, etc..., except sending
> IHAVEs to the upstream news server).
> 
> What should I look for?  At this point, I don't what to do...
> 
> Thanks,
> 
> Tom
> 
> 
> On Wed, 12 Jan 2000, Tom Kacvinsky wrote:
> 
> > Hi all,
> > 
> > Some background:
> > 
> > I installed the 1999/12/28 snapshot of 2.3, and since shortly after
> > then, I haven't seen messages propogated out to the 'net (today is my
> > first day back, and the regular sysadmins have mostly left news up to
> > me).
> > 
> > Anyway, we tried tcpdump (the dump of which we ran through ethereal),
> > and we didn't see outgoing connections to our ISP's news server.
> > I.e., whenever there was an article to be sent upstream, we weren't
> > sending IHAVEs to them.
> > 
> > Ugh.
> > 
> > I did a truss on on the innd and nnrpd processes, and rapidly
> > discovered that innd is listening on the socket ~news/run/nntpin, and
> > nnrpd writes to this socket.  So of course, I was seeing IHAVEs in my
> > trusses, because nnrpd was writing out to ~news/run/nntpin whenever I
> > posted to the server using my Macintosh news client (please, no flames
> > ;)
> > 
> > The upshot of the above paragraph is that I do see the messages in our
> > local "stash" of news articles.
> > 
> > But they aren't being propogated upstream.
> > 
> > I have looked over the appropriate config files (newsfeeds, inn.conf,
> > innfeed.conf), and things look kosher there (they were working before,
> > and I just mades mods for overchan [WnteO instead of WntO], etc...)
> > 
> > What other kind of debugging can I do?  I have to get the syslog stuff
> > set up, but somehow, I doubt even that is going to help...
> > 
> > 
> > Thanks,
> > 
> > Tom
> > 
> > 
> > 
> 
> 
>