sarima@tdatirv.UUCP (Stanley Friesen) (08/30/90)
In general, what kind of problems can I expect converting mid-stream from B to C news? Would I likely lose any articles? Or have to alert my news feed of changes? Alternatively, once I have built C news, does it just drop into place in place of B, or is some effort required to smooth the transition?
crissl@rulcvx.LeidenUniv.nl (Stefan Linnemann) (08/31/90)
In <138@tdatirv.UUCP> sarima@tdatirv.UUCP (Stanley Friesen) writes: > In general, what kind of problems can I expect converting mid-stream >from B to C news? Would I likely lose any articles? Or have to alert my >news feed of changes? Alternatively, once I have built C news, does it just >drop into place in place of B, or is some effort required to smooth the >transition? I've tried once and didn't get it right the first time, so I reverted to Bnews. Still, I'd like to try again, but better informed, so please reply to me, too, or post to the net, if the matter hasn't been chewed to the bone, yet. Thanks, Stefan.
henry@zoo.toronto.edu (Henry Spencer) (08/31/90)
In article <138@tdatirv.UUCP> sarima@tdatirv.UUCP (Stanley Friesen) writes: > In general, what kind of problems can I expect converting mid-stream >from B to C news? Would I likely lose any articles? Or have to alert my >news feed of changes? Alternatively, once I have built C news, does it just >drop into place in place of B, or is some effort required to smooth the >transition? In general, C News is 100% transport-compatible with B News, and there is no reason why you should lose articles or cause any fuss at your feed. Of course, installing a new news system is definitely a sensitive operation with penalties for mistakes. :-) The only probable rough spots in the transition are that (a) the transition process is not as well documented as it should be, and (b) you will have to learn how to run a somewhat different news system. -- TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry
larry@focsys.uucp (Larry Williamson) (08/31/90)
In article <955@rulcvx.LeidenUniv.nl> Stefan Linnemann writes: > In <138@tdatirv.UUCP> sarima@tdatirv.UUCP (Stanley Friesen) writes: > > > > In general, what kind of problems can I expect converting > >mid-stream from B to C news? Would I likely lose any articles? Or > >have to alert my news feed of changes? Alternatively, once I have > >built C news, does it just drop into place in place of B, or is > >some effort required to smooth the transition? > > I've tried once and didn't get it right the first time, so I > reverted to Bnews. Still, I'd like to try again, but better > informed, so please reply to me, too, or post to the net, if the > matter hasn't been chewed to the bone, yet. It was many months ago that I replaced B news with C news. I don't recall all the nasty details anymore, but I remember that the process was incident free. I read through the documentation a dozen times, then double checked the configuration stuff two dozen times, then backed everything that was a part of the News system twice, then built and installed C news. After I was confident that the system actually worked, I connected our feed up again. It took a little while to become comfortable with the administration of this system, but I think it was worth it. I spend essentially no time looking after this system now. It is very reliable. There is only one thing that I would *strongly* recommend you do before compiling and installing C news. Read all the documentation carefully, a number of times! Then and only then should you start actually configuring and building the system. -Larry Otherwise you are going to start complaining about things that are different, yet
jimb@silvlis.com (Jim Budler) (09/01/90)
In article <1990Aug31.155234.8788@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <138@tdatirv.UUCP> sarima@tdatirv.UUCP (Stanley Friesen) writes: >> In general, what kind of problems can I expect converting mid-stream >>from B to C news? Would I likely lose any articles? Or have to alert my >>news feed of changes? Alternatively, once I have built C news, does it just >>drop into place in place of B, or is some effort required to smooth the >>transition? Turn off your newsflow during the transition. i.e.: Shut off your inbound ports ( I just switched off the modems ), and make sure nntpd wont run if you receive news this way. Turn off your outbound news. If possible make sure all news queues are flushed. If you don't do this, your feeds may lose news. The uucp queues do not need to be flushed. Turn off your news related cron entries, as they will be different afterwards. Remember to turn everything back on afterwards 8^) The location of inews and rnews is a problem. Under Bnews inews was in /usr/lib/news, and rnews was in /usr/bin, and was probably a link to /usr/lib/news/inews. Under Cnews, both programs reside in a normal path, default /usr/bin. If you are running an nntp based newsreader, it may already have a normal path inews, perhaps /usr/local/bin/inews. If so you must insure it is specifically invoked by the newsreader with a complete path or some posting problems may occur. > >The only probable rough spots in the transition are that (a) the transition >process is not as well documented as it should be, and (b) you will have to >learn how to run a somewhat different news system. Here, here! Or is that Understatement,understatement!? I've done the transition twice now, at two different sites. The problems were: Forgot to turn off newsflow. What do you do with those batches? Forgot to flush the news queue. What do you do with *those* batches? Forgot about those nntp mini-inews. Some local posting failures resulted. Fortunately, the 'news' account has a default path, so newsflow didn't suffer. Actually, that may be wrong, since I believe Cnews has a path setting mechanism within it to insure that it finds the correct executables. Overall, I think little problem. >-- >TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology >OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry Overall: I'm extremely pleased with the improved performance, and once installed, and the expire rules stabilized, I haven't touched it in months. jim -- Jim Budler jimb@silvlis.com +1.408.991.6061 Silvar-Lisco, Inc. 703 E. Evelyn Ave. Sunnyvale, Ca. 94086
tale@turing.cs.rpi.edu (David C Lawrence) (09/02/90)
In article <1990Aug31.155234.8788@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
In general, C News is 100% transport-compatible with B News, and there is
no reason why you should lose articles or cause any fuss at your feed.
The only probable rough spots in the transition are that (a) the transition
process is not as well documented as it should be, and (b) you will have to
learn how to run a somewhat different news system.
It depends a little by what exactly you mean by "in general". I know
you and Geoff subscribe to the "be liberal in what you accept and
conservative in what you send out" philosophy and the "don't dick with
headers" philosophy, but there is a conflict between the two. Here
are a few examples of what C News will accept and batch for
redistribution:
o articles without a Date: header.
o articles with a header like:
"Sender: news@zip.eecs.umich.edu (\nNot Available)"
where \n is a newline.
o articles with a "local" distribution.
Fortunately with the last case you can tell it not to. Not so easy
with the others. All of those cases give B News systems grief. When
running nntplink the problem is compounded because of how quickly it
will empty the queue and keep trying to send the articles which the B
News site will simply never accept. Both ends waste lots of cycles
churning through them and the logs quickly grow with messages
complaining about inbound news being garbled. This is a problem I am
suffering with _all_ of my B News site connexions and there doesn't
seem to be a pleasant remedy for it readily available.
--
(setq mail '("tale@cs.rpi.edu" "tale@ai.mit.edu" "tale@rpitsmts.bitnet"))
The most remarkable thing about looking at a picture of myself was the sudden
realisation that my hair is in fact parted on the left and not the right.brad@looking.on.ca (Brad Templeton) (09/03/90)
Yes, I noticed an article come by recently with no Subject: header. It came through a fairly long path, all C-news, I assume. I am not sure this is good. I realize that relaynews was designed to do as few checks as possible, and to simply pass on rewriting nothing but the Path: at all times, but I think this could be a wrong decision. On a net of 15,000 sites, with at least hundreds of news tinkerers, anything bad that can happen, will happen. I suspect news software should try to isolate such things where it can. I once issued a message with a null message-id. It made it all over the C news subnet that I'm on, and it's permanent until you rebuild your history file. I shouldn't have done it, but it was an honest bug, and if I do it, then so will others with time. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
henry@zoo.toronto.edu (Henry Spencer) (09/04/90)
In article <!7`%+A^@rpi.edu> tale@turing.cs.rpi.edu (David C Lawrence) writes: >... a few examples of what C News will accept and batch for >redistribution: > >o articles without a Date: header. It is quite likely that C News will change to enforce RFC1036's list of required headers; Rick Adams suggested this some time ago and we're inclined to think it a good idea. Note that "enforcement" will mean "drop it on the floor if it's illegal"; we think it unwise, in general, to attempt to return bad articles by mail. >o articles with a header like: > "Sender: news@zip.eecs.umich.edu (\nNot Available)" > where \n is a newline. There are limits to what C News can do about such things without doing a complete RFC822 header parse, something we're not likely to do for several reasons (notably, the fact that minor RFC822 violations are common and relatively harmless). Ultimate responsibility for correctness of headers must rest with the originating site or gateway. >o articles with a "local" distribution. This is simply a reflection of not considering "local" to be a magic word, which we think is a correct decision, if only because it's so hard to define just what it should mean. -- TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry
tale@turing.cs.rpi.edu (David C Lawrence) (09/04/90)
Before I speak on this any further let me make it clear that I prefer C News methods to doing it in all of the cases cited here. That is, if we could make all of the systems behave one way or the other then I would rather see C News policies. In <1990Sep3.233231.1967@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) In article <!7`%+A^@rpi.edu> tale@turing.cs.rpi.edu (David C Lawrence): >... a few examples of what C News will accept and batch for >redistribution: > >o articles without a Date: header. Note that "enforcement" will mean "drop it on the floor if it's illegal"; we think it unwise, in general, to attempt to return bad articles by mail. Well, another policy could be just adding the missing header in this particular case. I personally don't feel screwing a Date: header with the current date into it would be so terrible except in cases of truly munged articles. I don't know how common this is anyway; the articles from Syracuse had other problems indicating that they tried to just plug-in Jean-Francois Lamy's inews with minimal or incorrect hacking and then just left it at that. >o articles with a header like: > "Sender: news@zip.eecs.umich.edu (\nNot Available)" > where \n is a newline. Ultimate responsibility for correctness of headers must rest with the originating site or gateway. Oh, I agree VERY much. _However_ such things shouldn't give so many sites the shits. The fact remains, in fact what I consider the most important point of my original article but which was elided in the followup, that admins are seeing the consequences now of having B News and C News systems talk to each other when they are supposedly 100% transport compatible. They are not so and the errors are having various effects from long logs to extra burned cycles to extra admin time trying to fix up some of these problems when they crop up. In the case of the above header, incidentally, I corresponded with an admin at zip and I guess she has fixed the problem by now. >o articles with a "local" distribution. This is simply a reflection of not considering "local" to be a magic word, which we think is a correct decision, if only because it's so hard to define just what it should mean. Again, I agree. However the B News sites reject them. Fortunately this is easy to avoid from _my_ end. So basically my points are: "In general, B News and C News are 100% transport compatible" is not that accurate except for the ambiguous floating disclaimer "in general"; and that it would be nice to see B News become a little more flexible as far as what it accepts. It is not that I am cutting down C News and claiming that these are insidious bugs -- I like C News very much. -- (setq mail '("tale@cs.rpi.edu" "tale@ai.mit.edu" "tale@rpitsmts.bitnet"))
jerry@olivey.olivetti.com (Jerry Aguirre) (09/06/90)
In article <-0{%D&$@rpi.edu> tale@turing.cs.rpi.edu (David C Lawrence) writes: >Well, another policy could be just adding the missing header in this >particular case. I personally don't feel screwing a Date: header with >the current date into it would be so terrible except in cases of truly >munged articles. I don't know how common this is anyway; the articles Adding a missing date header just makes it that much easier to circulate garbage, including old articles, into the net. At least now the software/person has to inject a current date into the old articles. If the news software were to add dates then simply deleting the date would be enough. If dateless articles are not so common then it will not be a big problem to not forward them. Regurgatated articles are a big enough problem to warant not forwarding them.