NNR (S_1.3.3) and (R_1.3.3) update announcement. SPECIAL THANKS: Arty Ecock @ City University New York Ken Hornstein @ Pennsylvania State University * NNR (RXSOCKET) as of NNR S_1.3.2 the principal version of RXSOCKET will be V2. i have hooks into NNR to support REXTCPIP which could easily be modified if there were a need to adapt RXSOCKET V1. please let me know if you have a situation where migration to RXSOCKET V2 is impossible and i'll generate the necessary updates. as of *_1.3.3 NNR will be sensitive to the INN news server. there are excerpts from the INN FAQs following the usual announcement stuff. one note, although INN is much faster for posting it is also less forgiving. you will find when following-up an article you will need to supply more new text than re-posted old text. /* FX133S1 * add ability to migrate to a new server and preserve groups */ nnr has the ability to talk to multiple news servers and will maintain a "NNReader" for each. in many cases a user will check other servers primarily for groups that do not exist on his/her primary server as in the instance of the regional groups which do not have the world wide distribution. this fix may be overkill for the above mentioned user since his/her "Personal_Subscription" list will be propagated. this fix is ideally suited for those sites migrating a user base to a new news server where it is desirable to preserve the users "Personal_Subscription" list partially intact. partially? the list of groups and personal HLI's will be rebuilt for the new server and a new "NNReader" file will be generated. the new server will be interrogated to determine the first and last articles known to the server. this process will not maintain any history associated with a group. it is possible to comment this fix in the "NNR$XEDI AUXRXS" file but it is far easier to remove groups from the "Personal_Subscription" list than to add them. /* FX133S2 * fix newgroups, for INN compatibility */ the INN server command "NEWGROUPS" returns more information than the same command on the old nntp servers. /* FX133S3 * say the server name on screen banners */ a cosmetic change was made to all screens so that the news server name can appear. /* FX133S4 * add XOVER */ XOVER is a new extension to the NNTP protocol which will allow access to the Overview database. the Overview database contains header information about all the articles in all the groups. the client (nnr) can now with a single command get most anything it needs concerning an article with a single command (XOVER). you will notice on the Preferences Screen that the entry for selecting the display headers has been replaced with a similar entry. the new entry has 5 pre-configured Header screen setups: 1 mode="Subject . . From" 2 mode="Subject Lines . From" 3 mode="Subject . . From" 4 mode="Subject Lines Date From" 5 mode="Subject . . ." /* FX133S5 * replace POST with SORT on Headers screen */ the "Post" function was remove from the Headers screen and replaced by the "Sort" function which was formerly only a command line feature. /* FX133S6 * get preferred name for posting and mail */ during a posting or mailing nnr will detect that a user doesn't an entry for himself/herself in the "userid() names" file, at this time a message will be sent to the screen suggesting that they enter the PREFERences screen to add one. the preferred name will be maintained as a nnr name and not a Names file name. /* FX133S7 * allow for sorted headers */ there is now an entry on the Preferences screen to tell nnr to sort each Header screen prior to display. this will align all a subjects and have the same effect as doing the "Thread" function for subject thread. /* FX133S8 * pack and unpack session variables to and from session file */ now that we can set several session values it is important to preserve them across nnr sessions. to do this nnr maintains a "SESSION NNR A" file which can be user modifiable. this file overrides select system configured golbalv variables. /* FX133S9 * check the news server, see if xover available. */ this fix checks the server to see if we can user any of the INN server features. /* FX133SA * add XHDR stuff to do the XOVER equivalent */ in order to add the XOVER stuff i was forced to remove the old way of handling the same function. once XOVER was working to my satisfaction the XHDR section had to be reworked. /* FX133SB * miscellany, tweak previous fixes */ this fix removed the "X-Newsreader" header. the general consensus on the network revealed that it was not a worthwhile header. /* * add version number */ added version number for reporting problems. * NNRLIST /* * add version number */ added version number for reporting problems. ***************************************************************** many thanks to the University of Stuttgart and the Instituto Tecnologico de Monterrey for the anonymous ftp ----------- Anonymous FTP to VMTECQRO.QRO.ITESM.MX or 132.254.90.1 CD NNR 8:00-23:00 CST Mon. to Fri. 9:00-16:00 CST Sat. & Sun. ----------- FTP rusmv1.rus.uni-stuttgart.de or 129.69.1.12 cd /soft/kommunikation/news/beginner/software/nnr ----------- source.vers130 - nnr sequenced source and support files updates.vers133 - individual updates nnrrxtcp.noas133 - nnr (without rextcpip) nnrrxsoc.noas133 - nnr (without rxsocket) (requires fal version 2) nnrdocs.vers133 - nnr users guide (script and postscript) the above mentioned files are in a punch format and the following procedure will unpack them. SPOOL PUN * PUNCH Filename Filetype ( NOH ORDER RDR READCARD * * notice that the pre-packaged files no longer contian any of the assembler code (RXSOCKET or REXTCPIP). if you need RXSOCKET: if on BITNET: TELL LISTSERV at CUNYVM get rxsocket package if on Internet (mail only): send mail to "listserv@cunyvm.cuny.edu" the body of the message should contain 1 line "get rxsocket vmarc ( f=uue" (you will need the uuencode and vmarc to unpack the mail file) if you need REXTCPIP: if on BITNET: TELL LISTSERV at OHSTVMA get rextcpip package if on Internet (mail only): send mail to "listserv@ohstvma.acs.ohio-state.edu" the body of the message should contain 1 line "get rextcpip package" use the command "gnnrx" to generate the rxsocket version and "gnnrt" for the rextcpip version from source.vers130 and updates.vers132. In NNR exec: set variable ipaddr : ip address mailer : mail machine organization : your organization thisnode : yournode.yourdomain make appropriate update for link to production tcpmaint 592 make appropriate update for printing See "NNR SAMPLEFX" - update, make changes to this file for your site and file it as "NNR SITEFIX". /pc ------------- Paul Campbell The MITRE Corporation Bedford, MA, USA 01730 : (617)271-3984 nnrprod@mbvm.mitre.org from INN FAQs: > From: tal@Warren.MENTORG.COM (Tom Limoncelli) >Subject: INN FAQ Part 1/3: General Information, how to compile, how to operate > Subject: What is INN? > > InterNetNews is a complete Usenet system. The cornerstone of the > package is innd, an NNTP server that multiplexes all I/O. Think of > it as an nntpd merged with the B News inews, or as a C News relaynews > that reads multiple NNTP streams. Newsreading is handled by a > separate server, nnrpd, that is spawned for each client. Both innd > and nnrpd have some slight variances from the NNTP protocol (although > in normal use you will never notice); see the manpages. INN > separates hosts that feed you news from those that have users reading > news. If you need to support a mixed environment you will have to do > some extra work; the installation manual gives some hints. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >From: rob@agate.Berkeley.EDU (Rob Robertson) >Subject: FAQ: Overview database / NOV General Information > >------------------------------ > >Subject: What is the Overview/NOV database? > >The Overview or News OverView (NOV) database was designed by Geoff >Collyer. Its a more generalized database, it it contains *no* >threading information, just the information needed to thread. The >overview database is just a database of files, one for each group, >containing a reference to each article, with seven or eight of the >most popular headers. Thus, the newsreader client can get most of the >information it needs to thread, but it does the threading the way it >wants to. Yes, the downside is that now the threading occurs on the >client's CPU, but that's not as expensive as it may seem, if done >properly. > >------------------------------ > >Subject: What is XOVER? > >XOVER is an NNTP extension for accessing the Overview database. It >is becoming a defacto standard for accessing bulk header/thread >information via NNTP. > >It is used after establishing a current group with the GROUP command, >and operations on that group. It's syntax is > > XOVER artnumber1[-artnumber2] > >Where artnumber1 is < artnumber2. If successful, it returns a 224 >reply code, and the overview data [as in the Overview database] for >the requested articles. It is terminated by a "." (dot) on a line by >itself. > >NNTP servers implementing the XOVER command should try to ensure that >the data is as consistant as possible, they should avoid handing out >XOVER information for articles that don't exist, and should generate >XOVER information on the fly for articles that do exist, but aren't >found in the Overview database for some reason. While the job of >XOVER is to provide access to the Overview database, validating the >Overview data is best done in the NNTP server, rather than having the >NNTP client go through contortions to do it.