SENGER@LAX.WISC.EDU (06/08/91)
I recall seeing a number of postings several months ago regarding problems with net news on Apollo's. I am just starting to think about getting a news connection to our network (I currently receive this group via mail). Could some kind soul point me to the latest versions of the sources I will need and point out any configuration problems I should be aware of? Much Thanks in Advance steve senger@lax.wisc.edu
johnb@HOBBES.MDC.COM (John Breen) (06/08/91)
>Could some kind soul point me to the latest versions of the sources [of news >software] I will need and point out any configuration problems I should be >aware of? Ditto. Actually, I've been researching this a bit lately, so I'll throw out what I've found and see if anybody has any corrections/additions. For an internet (read non-UUCP ?) site, I've been told (by a news administrator that I'm going to try to get a feed from) that I would need the following (we're connected to the news "source" via NSFNet): " - cnews - nntp - rn, nn, or trn - plenty of disk space..." It looks like the news is actually transferred between the news servers by nntp. The part cnews plays isn't apparent to me (although I've only glanced at the documentation); also, some people have been recommending bnews - I don't know if this is due to problems with cnews, or if it's just because it's the one they're currently using. rn, nn, and trn are the "user interfaces" to the news system. I've used rn (on another system that I no longer have access to) and it seemed very nice, although I've seen postings here that indicated that rn/telnet/apollos don't mix (there is a "remote" form of rn - would this get around the problems?). I've also seen postings about problems with file locking between the news server and the node that the user is reading from (similar, I assume, to the sendmail problem described in the FAQ). The above software should be available by anonymous ftp from wuarchive.wustl.edu (and undoubtedly others), although I have no idea if it's the latest versions. The only other tidbit that I've got is the mention of the following book (from the cnews README file): "Managing UUCP and Usenet", by Tim O'Reilly and Grace Todino, O'Reilly & Associates, 1989, ISBN 0-937175-48-X. This latest edition covers C News as well as B News. It's not perfect but it's lots better than nothing. Inquiries to nuts@ora.com or uunet!ora!nuts. I have not yet been able to locate a copy of this (although I haven't looked that hard). If anyone out there who has access to a newsfeed is kind enough to forward this thread to one of the news.* groups, please stress that comp.sys.apollo must receive the followups, or else most of us who really need the answers won't get them. Actually, some of the biggest problems I have are more administrative in nature, namely: - finding someone in my company who has the resources (e.g., disk space) to store the news. - getting the company to spring for the fee the news "source" charges for support (it's a very small fee, one that I would almost be willing to pay out of my own pocket, but even getting $1 out of this place can take months). - worrying whether receiving newsgroups like "rec.*" and "alt.*" violate the NSFNet "access rules" (or company rules, for that matter - I would hate to get fired for reading "rec.woodworking" on a company machine :-). ----- John A. Breen | johnb@hobbes.mdc.com McDonnell Douglas Missile Systems Co. | DISCLAIMER: They speak for them, Tel: (314)234-4341 | I speak for me.
system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) (06/09/91)
In article <9106072205.AA12094@hobbes.mdc.com> johnb@HOBBES.MDC.COM (John Breen) writes: >>Could some kind soul point me to the latest versions of the sources [of news >>software] I will need and point out any configuration problems I should be >>aware of? > >For an internet (read non-UUCP ?) site, I've been told (by a news administrator >that I'm going to try to get a feed from) that I would need the following (we're >connected to the news "source" via NSFNet): >" - cnews > - nntp > - rn, nn, or trn > - plenty of disk space..." Correct on all counts (though you can use B News I suppose). We have been running NNTP, C News and rn on our Apollo network with no real problem for a year. >It looks like the news is actually transferred between the news servers by nntp. That is the easiest way, if you have direct TCP service between the systems. >The part cnews plays isn't apparent to me (although I've only glanced at the >documentation); also, some people have been recommending bnews - I don't know if >this is due to problems with cnews, or if it's just because it's the one they're >currently using. rn, nn, and trn are the "user interfaces" to the news system. NNTP handles the transferring of batches of articles between the systems, C News (or B News) handles the "unpacking" of the articles into the local /usr/spool/news directory and preparing lists of articles to be forwarded to other sites; rn/nn/trn are the actual news reading programs that the users use to read and reply to articles. >I've used rn (on another system that I no longer have access to) and it seemed >very nice, although I've seen postings here that indicated that >rn/telnet/apollos don't mix (there is a "remote" form of rn - would this get >around the problems?). I've also seen postings about problems with file locking >between the news server and the node that the user is reading from (similar, I >assume, to the sendmail problem described in the FAQ). Telnet is broken on all Apollo systems, so it messes up anytime the port is put into "raw" or "cbreak" mode - rn, vi, ..., do this, so a carriage return gets converted to a line feed; to avoid it, use rlogin. This problem also causes kermit file transfers to fail over telnet connections since the carriage return at the end of the packet is never seen. [Editorial note: come on HPollo, fix this !!!] The only catch is that you must not permit news readers on remote Apollo systems to get at the "active" file on the real news node, since they will lock it, and jam your news unspooling. We avoid this by copying the active file to each node every so often, and also fake news posting on the remote nodes so they do a 'rsh' to the master node. You can also hack on the source of 'rn', which others have done according to previous postings here. You can also let the news readers access a copy of the active file on the master news node, and just update the master copy every so often. >The above software should be available by anonymous ftp from >wuarchive.wustl.edu (and undoubtedly others), although I have no idea if it's >the latest versions. You can also get NNTP and rn from uunet.uu.net, C News from cs.utoronto.ca (the uunet version should be up to date also, but C News is/was developed at U/T so they always have the latest). >The only other tidbit that I've got is the mention of the following book (from >the cnews README file): > "Managing UUCP and Usenet", by Tim O'Reilly and Grace Todino, > O'Reilly & Associates, 1989, ISBN 0-937175-48-X. This latest Haven't read this (I set up our news before this book was available). I can send you config files if you want, though they're pretty standard if you have set up news before. -- Mike Peterson, System Administrator, U/Toronto Department of Chemistry E-mail: system@alchemy.chem.utoronto.ca Tel: (416) 978-7094 Fax: (416) 978-8775
ianh@resmel.bhp.com.au (Ian Hoyle) (06/10/91)
johnb@HOBBES.MDC.COM (John Breen) writes: >>Could some kind soul point me to the latest versions of the sources [of news >>software] I will need and point out any configuration problems I should be >>aware of? >For an internet (read non-UUCP ?) site, I've been told (by a news administrator >that I'm going to try to get a feed from) that I would need the following (we're >connected to the news "source" via NSFNet): >" - cnews > - nntp > - rn, nn, or trn > - plenty of disk space..." I have been administering net news/mail at this site for about 3 years using a DN3500 as the primary node providing these services. For about 2 1/2 yrs we received our feed from a site using some Australian developed software called MHSnet (well to be precise there was a precursor to this called SUN III, but that complicates matters :-) which acts as a store/ forward message transport system **much** better than uucp - ie. it is resilient to breaks in connection and allows partial resending of messages (and the message could be a mail item, compressed news batch, remotely requested file etc.). Suffice to say I can't comment on uucp and in any case we are now internet connected so that problem has gone away now .... As for the news transport system, we used for some time B-news 2.11.19, but as many news administrators know this is SLOW. We now take a full feed of ~1000 newsgroups and the overheads involved in unwrapping news batches are really quite daunting for a slow machine like the 3500. A few months back I took the plunge and started using Cnews (now at the most recent patch level). I'm impressed by the quality of this software and the speed with which it does it's stuff. Henry Spencer and Geoff Collyer are great contributors to news.software.b where the news transport software is discussed and bug fixes/improvements are contributed regularly - in short a well engineered and supported public domain piece of code. The most recent version of nntp (1.5.11) runs just fine (I live under bsd and use the cc6.7 compiler and not the newer ANSI beast) and allows the use of remote news readers and also transport of news itself to other machines over TCP/IP. News readers tend to rely on personal taste more than anything - I support the following readers on a variety of machines including DECstations, SUN, Apollo, Mac (AUX) & SGI using nntp. vn - v. old reader under no further development rn - a new version 4.4 about to be released nn - LOTS of bells and whistles (I use it a lot) Generally these are mature pieces of code and will compile with not too many problems on Apollos. Nothing much more to add. You can probably pick up most of these goodies from a kind net-neighbour !!, ian -- Ian Hoyle /\/\ Image Processing & Data Analysis Group / / /\ BHP Research - Melbourne Laboratories / / / \ 245 Wellington Rd, Mulgrave, 3170 / / / /\ \ AUSTRALIA \ \/ / / / \ / / / Phone : +61-3-560-7066 \/\/\/ FAX : +61-3-561-6709 E-mail : ianh@resmel.bhp.com.au
wjw@ebh.eb.ele.tue.nl (Willem Jan Withagen) (06/10/91)
In article <9106072205.AA12094@hobbes.mdc.com>, johnb@HOBBES.MDC.COM (John Breen) writes:
=> >Could some kind soul point me to the latest versions of the sources [of news
=> >software] I will need and point out any configuration problems I should be
=> >aware of?
=>
=> Ditto.
=>
=> Actually, I've been researching this a bit lately, so I'll throw out what I've
=> found and see if anybody has any corrections/additions.
=>
=> For an internet (read non-UUCP ?) site, I've been told (by a news administrator
=> that I'm going to try to get a feed from) that I would need the following (we're
=> connected to the news "source" via NSFNet):
=> " - cnews
=> - nntp
=> - rn, nn, or trn
=> - plenty of disk space..."
=>
I'll try to make a clean as possible reply to this question as to what
I know about running news, especially on apollo's. (This is for shure not
complete!!!!! )
First the're two different parts to news:
1) the newsfeed side, which involves the retrieval
of the articles.
2) the user side, where the reading is done
1)
The news system revolves around the news-article database, which consists
of at least the following files:
active The system keeps a file ( ~news/active ) in which it keeps
the article numbers of the available articles.
spool The tree where all articles are kept.
Note: an article is just a file in the news-spool tree,
where the groups are translated into directories.
history Which is a dbm-files for fast retrieval of certain info.
sys tells what systems can feed news, and what groups,
what systems are to be loaded with news.
(there are more but these are the most essential.)
Then there's the program inews which is the maintainer of this database.
It excepts articles from other hosts, and if they comply puts them in the
database. If any systems get a feed from this system, they might be forwarded
by inews. (NOTE: might)
The problem on Apollo's lies in the fact that inews wants to be the only
one writting this database. And that includes inews on other systems.
MUltiple access is not counted for. If another workstation has a read access
on this file, the inews will fail updating the database, creating possible
problems.
Who the newsfeed is arranged depends on the connecntion type of the systems:
- There might be UUCP. Then batches of newsarticles are created and these
batches get transfer on regular basis by an apropriate program.
- If there's a faster link (ethernet,.. ) the this still could work this way.
Only the program which does the actual transfer is different.
In both case the batches are setup by inews and subprograms.
- Then there's the nntp protocol, which runs on TCP/IP, and allows for
faster access. The nntp-daemon can look into the database and supply
the client with all kinds of info. It can also accept new articles which
then get inserted into the database by inews.
nntp clients could be other systems which require a newsfeed, but also
certain types of newsreaders (see 2) )
This NNTP protocol can be used in two ways:
1) The upstream newsfeed uses the protocol to download news into a
downstream system. Compare this with the batches.
The client and the server first negotiate which articles are new,
after which the new ones are downloaded.
(A possible program for this could be nntpxmit)
2) The reverse aproach is also possible: The downstream site polls the
upstream site for new articles. The interaction is more or less
the same.
(A possible program for this is nntpxfer)
(I know most about the nntp-stuff, since that is what we use.)
The question is where do terms like {B,C}-news fit in. {B,C}-news implement
the nntp-daemon and the programs to do the database management.
Supposedly is C-news more effective. (I can't tell since we only run B-news)
The last item to discuss is the generation on articles. As long as they are
local, there's no problem. They are insterted into the database by inews
at that's it.
If however the article has a larger distibution then it needs to be transfered
to other systems. For this a backbone has been created, once you get the
message at a backbone site, it'll get distributed to all apropriate systems.
The configuration of what to do with 'home'-generated articles is described
in the 'sys'-file. It specifies what articles go where. The transport is again
taken care of by inews. Inews can diffentiate between downloaded and uploaded
articles by looking at the path in the article. Any of the hosts in the sysfile
not in the path, get a 'copy' of the article processed by inews.
The sysfile entry also supplies the program which has to do the transfer.
This could be a queueing program: the article gets queued, and once there's
enough data, or time has expired, then the lot is transmited. (UUCP or NNTP
or others. )
It could also be put in a mail message, and mailed to a system which has
a special program for receiving news-articles (connected to an account name).
This special program calls upon inews to actually do the news processing.
So it again gets distributed along the entries in the sysfile.
(One could use this method to download news as regular feed, but it gives
a tremendous overhead in mail-messages)
At our site is the local ammount of articles generated very low, so we use the
last method to upload 'not-local' news to our Univeristy central news system.
What happens there, I don't know, and I do not have to know, since the
connections to the outerworld are not in the path of the uploaded articles.
And hence they get transfered to our national news system. (I guess)
From there they'll go across the big pool, where the worlds other users get it.
INTER:
I've once got a responce within the hour form somebody in California.
APOLLO:
The apollo problems arise from the fact that if node A is the site where
somebody is reading the database (mainly the active,history-files)
then running inews on node B causes lots of trouble because of the
implementation of the file system. (On SUN/ea. this is solved in a dirty way
by NFS )
The solution is to run all actions on the database on one system. So only one
node really runs inews. On other systems there's a fake inews which forwards
the inews-stuff to the real inews. (This requires running NNTP)
This still leaves us the trouble that newsreader might require the active file
for reading too. For this I've created active.copy which gets updated from
the actual active file every time inews updates the active file.
The newsreaders are then patched to use the copy, which can be read by all.
If inews wants to copy then it fails on the 'copy', but the original is still
in good order.
The problem lies in collecting all the required items. The hacking is only
a matter of small changes to pathnames in config files.
2)
Let's assume that we already have a news system up and runing.
Then the user has a newsreader program, which uses a ~/.config-file
to keep a log of what the user has read up to now.
The news system has it's active file.
Reading both gives the newsreader the info of what articles to represent to the
user.
Now there's two category of nesreaders: (certainly not complete)
Those that use the news-database directly:
- rn, vnews, nn, readnews, ....
Those that go through a NNTP server.
- rrn, xrn, ......
The first require that care is taken of the problems with inews and access to
the database. The second require a NNTP-sever on a per active user.
APOLLO:
The second one has two disadvantages.
1) It requires an up and running deamon per user reading news.
And before 10.3 this was a serious problem on systems
running as gateways, which would usually also be news-gateway.
2) All transfers go through a deamon and TCP/IP which is not the faster
way of accessing things.
The advantage is that all the available programs can be run as found on
the net. They require very little hacking.
The first aproach requires slight modifications to the readers and the
scripts with the readers. But the speed is a LOT more impressive, and the
burden on the gateway is negliable.
[ rn however runs in raw pad/vt100 mode, which is not flawless as we all know
my rn alias is
stty -cbreak; \
/usr/local/bin/rn -F'''=> ''' -g5 -H -S -hMessage-ID -hDate ; \
stty -cbreak
which seems to take care of most problems. ]
Hope it's usefull info to someone,
Ciao,
Willem Jan
--
Eindhoven University of Technology DomainName: wjw@eb.ele.tue.nl
Digital Systems Group, Room EH 10.10
P.O. 513 Tel: +31-40-473401
5600 MB Eindhoven The Netherlandsrees@pisa.citi.umich.edu (Jim Rees) (06/10/91)
In article <1991Jun9.134222.13142@alchemy.chem.utoronto.ca>, system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) writes:
Telnet is broken on all Apollo systems, so it messes up anytime the port
is put into "raw" or "cbreak" mode - rn, vi, ..., do this, so a carriage
return gets converted to a line feed; to avoid it, use rlogin.
I don't think this is a telnet bug, I think it's a result of the fact that
pads are not ttys. A pad can be either raw or cooked, and if it's raw it
doesn't do cr->nl translation. I try to avoid using pads in raw mode. I
always run telnet and friends from an xterm.pulcher@bgrgh51.BNR.CA (Harold Pulcher) (06/11/91)
In article <9106072205.AA12094@hobbes.mdc.com>, johnb@HOBBES.MDC.COM (John Breen) writes: |>... |>For an internet (read non-UUCP ?) site, I've been told (by a news administrator |>that I'm going to try to get a feed from) that I would need the following (we're |>connected to the news "source" via NSFNet): |>" - cnews |> - nntp |> - rn, nn, or trn |> - plenty of disk space..." |> |> |>It looks like the news is actually transferred between the news servers by nntp. |>The part cnews plays isn't apparent to me (although I've only glanced at the |>documentation); also, some people have been recommending bnews - I don't know if |>this is due to problems with cnews, or if it's just because it's the one they're |>currently using. rn, nn, and trn are the "user interfaces" to the news system. I would strongly reccomend Cnews. I have read news on both systems and both seem to work equally well. However, Bnews is not as robust as Cnews and will require more work to keep it running well. I have just recenlty inherited a Bnews system and can attest to the fact that it takes more work than Cnews. As far as news readers go, RN is the true work horse. I would reccomend though that you find yourself the source for TRN. TRN is an extension to RN. It will do everything RN does, but adds the ability to read news by the subject threads. This is a very nice feature and RN is hard to go back to once you have been exposed. By way, 200 megs should give you enough room for all of news. If you have more use it. The 200 megs works well with expire times of about 5-7 days. If you don't know what expire times are, you will find out as you get into news. |>I've used rn (on another system that I no longer have access to) and it seemed |>very nice, although I've seen postings here that indicated that |>rn/telnet/apollos don't mix (there is a "remote" form of rn - would this get |>around the problems?). I've also seen postings about problems with file locking |>between the news server and the node that the user is reading from (similar, I |>assume, to the sendmail problem described in the FAQ). Here comes the other use for nntp. RN and TRN can be set up in remote mode. They use nntp to contact the server node ( much like how the news is transferred ). However, RN/TRN only request the newsgroup articles that you are about to read. |>The above software should be available by anonymous ftp from |>wuarchive.wustl.edu (and undoubtedly others), although I have no idea if it's |>the latest versions. They are. |>The only other tidbit that I've got is the mention of the following book (from |>the cnews README file): |> |> "Managing UUCP and Usenet", by Tim O'Reilly and Grace Todino, |> O'Reilly & Associates, 1989, ISBN 0-937175-48-X. This latest |> edition covers C News as well as B News. It's not perfect but |> it's lots better than nothing. Inquiries to nuts@ora.com or |> uunet!ora!nuts. |> |>I have not yet been able to locate a copy of this (although I haven't looked |>that hard). Good book, but news software has changed some since the book was written. It will give you a good ideal of how set things up. ( ----- /\ |\ /| | I ride a moped and I'm proud of it!!!! ) ( | /__\ | \/ | | Whats mine is mine!!! ) ( \_| | | | | | Harold Pulcher ) ( M a e s t r o | pulchar@bnr.ca )
system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) (06/12/91)
In article <52174230.1bc5b@pisa.citi.umich.edu> rees@citi.umich.edu (Jim Rees) writes: >In article <1991Jun9.134222.13142@alchemy.chem.utoronto.ca>, system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) writes: > > Telnet is broken on all Apollo systems, so it messes up anytime the port > is put into "raw" or "cbreak" mode - rn, vi, ..., do this, so a carriage > return gets converted to a line feed; to avoid it, use rlogin. > >I don't think this is a telnet bug, I think it's a result of the fact that >pads are not ttys. A pad can be either raw or cooked, and if it's raw it >doesn't do cr->nl translation. I try to avoid using pads in raw mode. I >always run telnet and friends from an xterm. Telnet fails to handle CR properly for telnet sessions from our terminal server to Apollo, which is the main method of accessing our Apollos. I think the problem actually lies in telnetd, but for Apollo-Apollo telnet, it does work properly. The terminal server telnet works properly to SGI, IBM and SUN systems. -- Mike Peterson, System Administrator, U/Toronto Department of Chemistry E-mail: system@alchemy.chem.utoronto.ca Tel: (416) 978-7094 Fax: (416) 978-8775