🚀 go-pugleaf

markb@spock.dis.cccd.edu (Mark Bixby) writes:
: 
: I notice that innd supports a "mode reader" command to force the socket to
: be handed off to nnrpd.  Therefore, if I get CERFnet to initially speak the
: innd command set with me, I can innxmit just fine.  I could also use NNTP-mode
: trn if I could convince it to issue a "mode reader" command right after
: connecting to innd.
: 
: Has anybody out there solved this problem?  Am I overlooking anything obvious?
: Trn 2.2 shouldn't be too hard to patch to try a "mode reader" command after
: connection; I thought I'd ask first to save myself the trouble of re-inventing
: the wheel.

This was implemented in the 'tin' newsreader, and I'm preparing a patch for
the NNR newsreader for VM.  As INN propagates, I expect this to be a problem
more often... in fact, it'll be a problem for sites that both forward news
via NNTPXMIT/INNXMIT/NNTPLINK and retrieve news via nntpxfer/nntpget as
well, because the latter have to switch to MODE READER as well.

It looks pretty trivial.  We don't run TRN here, so I'll have to leave
the specifics for Wayne to deal with.

Here's a few tips I've found by reading the INN and reference implementation
source, and poking the news-server at one of my feed-sites:

(1) If you are talking to a reference-implementation nntpd, rather than
    INN, MODE READER will get a 500 unrecognized command response.  No
    biggie.

(2) If you're connected to innd and enter MODE READER, it will kick you
    to nnrpd, which will validate your host and respond with a numeric/text
    response code.

(3) If your host isn't a peer, you'll be kicked directly to nnrpd.  Nnrpd
    will accept the MODE READER command as well, although it's pretty-much
    a no-op.  You should get a response, just as in case 2 above.

(4) If your host isn't allowed read/post access you'll get a 502 in response
    to MODE READER, and nnrpd will drop the connection.

(5) If you are allowed to post, you'll get a 200 response.  If you're read-
    only, you'll get a 201 response.

(6) If the server is not accepting connections due to load, disk space, etc
    it appears you'll get a 400 response.  Send a QUIT and close the con-
    nection.
--
Doug Sewell, Tech Support, Computer Center, Youngstown State University
doug@cc.ysu.edu	   doug@ysub.bitnet	<internet>!cc.ysu.edu!doug

cat core | uuencode bunny.dropping | mail jp@tygra.michigan.com

In <1gof2bINNpi1@spock.dis.cccd.edu> markb@spock.dis.cccd.edu (Mark Bixby) writes:
>Trn 2.2 shouldn't be too hard to patch to try a "mode reader" command after
>connection;
It is trivial.  Look at lib/clientlib.c in the INN distribution.

INN includes the NNTP1.5 'clientlib' API, built on top of the INN routines
documented in libinn.3.  I have built rn with them.  I have never built trn,
but as long as it doesn't stray outside the clientlib set, it should be
possible to edit trn/Makefile so that it links with libinn.a before 
the NNTP clinetlib.
	/r$

The INN model is that there are two classes of hosts:
	Those that give you articles via IHAVE;
	Those that do (almost) everything but IHAVE.
Those in the first class are called newsfeeds; those in the latter are
called readers.

This model does not fit everyone.  I never claimed that it did, and
sometimes you have to do a bit of fine-tuning to make your reality fit the
INN model.  I don't want to change the INN model because I believe it's a
good one.  Instead there are some things to help:
	My 'clientlib' emulation can be linked into newsreaders to make
	sure they get to the newsreader.

	You can run the reference implementation nntpd instead of nnrpd,
	and put only true newsfeeds in your hosts.nntp file.  See the
	install manual.

In article <1gqdsgINNom1@rodan.UU.NET> rsalz@rodan.UU.NET (Rich Salz) writes:
>INN includes the NNTP1.5 'clientlib' API, built on top of the INN routines
>documented in libinn.3.  I have built rn with them.  I have never built trn,
>but as long as it doesn't stray outside the clientlib set, it should be
>possible to edit trn/Makefile so that it links with libinn.a before 
>the NNTP clinetlib.

That's the problem.  If you want to build trn with the ability to read the
threads via NNTP, it wants a few extra routines in the clientlib (those are
provided by the patches in the trn/nntp directory).  Maybe if I get time I will
try to massage the trn patches into INN's clientlib.  (Or has anyone else done
this? :-) )

--Ken

> Nntp-Posting-Host: leps5.phys.psu.edu

> In article <1gqdsgINNom1@rodan.UU.NET> rsalz@rodan.UU.NET (Rich Salz) writes:
>>INN includes the NNTP1.5 'clientlib' API, built on top of the INN routines
>>documented in libinn.3.  I have built rn with them.  I have never built trn,
>>but as long as it doesn't stray outside the clientlib set, it should be
>>possible to edit trn/Makefile so that it links with libinn.a before 
>>the NNTP clinetlib.

> That's the problem.  If you want to build trn with the ability to read the
> threads via NNTP, it wants a few extra routines in the clientlib (those are
> provided by the patches in the trn/nntp directory).  Maybe if I get time I will
> try to massage the trn patches into INN's clientlib.  (Or has anyone else done
> this? :-) )

It's easy to check.  All I did was use the nntp.h from nntp-1.5.11t 
and link trn against INN's clientlib.  Looked at the undefined symbols and
found them in the trn patch.
The only trn patches that needs to be added into INN's clientlib are
rawcheck_serv and rawget_serv. ( I didn't actually patch it into INN's
clientlib yet. )

The trn binary I built with INN libs seems to run fine.

--
|                                     ** Place Disclaimer Here  **            |
| Tasuki Hirata                "Hell, if you understand everything I say,     |
| sukes@eng.umd.edu                   you'd be me."  --  Miles Davis          |

In article <1gof2bINNpi1@spock.dis.cccd.edu>
   markb@spock.dis.cccd.edu (Mark Bixby) writes:
>I've just installed INN and I'm running it in parallel with my existing
>CNews setup (separate spools & active/history/etc files) until I'm comfortable
>with it.

Is this necessary ? And if so, why ?
I had hoped that I could just pull INN and experiment with INND as a
replacement for nntpd on a week-end without messing up the entire system
and needing to reset the news spool. If what Mark is doing is
reasonable, it willbe a long time before I can plan on having resources
to play with INN.

In article <1992Dec23.054335.3323@spectrum.CMC.COM> lars@cmc.com (Lars Poulsen) writes:
>In article <1gof2bINNpi1@spock.dis.cccd.edu>
>   markb@spock.dis.cccd.edu (Mark Bixby) writes:
>>I've just installed INN and I'm running it in parallel with my existing
>>CNews setup (separate spools & active/history/etc files) until I'm comfortable
>>with it.
>
>Is this necessary ? And if so, why ?

It all depends on how cautious you want to be.  I consider INN to be relatively
"new" software that merits some amount of testing before dumping into
"production" environments.  In my case, I've found no major bugs with INN.  I
probably could have done it over a weekend.  Since we have a relatively small
news spool (5 days of comp.*, ~ 100MB), I thought what the heck, why not run
in parallel.

Most of my time was probably spent on making trn INN-compatible.  This has been
completed with the information received after my original posting.
-- 
Mark Bixby                         Internet: markb@spock.dis.cccd.edu
Coast Community College District   1370 Adams Avenue
District Information Services      Costa Mesa, CA, USA  92626
Technical Support                  (714) 432-5064
"You can tune a file system, but you can't tune a fish." - tunefs(1M)

In <1992Dec23.054335.3323@spectrum.CMC.COM> lars@cmc.com (Lars Poulsen) writes:
>I had hoped that I could just pull INN and experiment with INND as a
>replacement for nntpd on a week-end without messing up the entire system
>and needing to reset the news spool.
This works perfectly fine.

The only warning I know to give you is that if you are not using C News you
might have to fiddle with history files and dbm/dbz databases a bit.
	/r$