Xref: utzoo news.sysadmin:513 news.software.b:1077 Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!decuac!felix!bytebug From: bytebug@felix.UUCP (Roger L. Long) Newsgroups: news.sysadmin,news.software.b Subject: Re: Keeping multiple news machines in sync Message-ID: <19044@felix.UUCP> Date: 19 Jan 88 08:55:22 GMT References: <6263@oberon.USC.EDU> <13176@oliveb.olivetti.com> Sender: news@felix.UUCP Organization: FileNet Corp., Costa Mesa, CA Lines: 75 In article <6263@oberon.USC.EDU> Michael A. Cooper (mcooper) writes asking how to keep multiple news machines in sync by article number. In article <13176@oliveb.olivetti.com> Jerry Aguirre (jerry) writes: >Given that there is only one externally connected "master" system I can >think of one way to avoid the problem. First is to have ALL systems >except the master (including the secondary servers) post to the master >using the nntp inews. This avoids the problem of local postings >throwing the article numbers out of sync. Correct. This also has the effect of "hiding" the internal network of machines within an organization, since it really isn't important where a user's home machine is, as long as mail gets to the gateway machine. Here at FileNet, "felix" is the gateway, while all of the users reside on "fritz". Jerry goes on to suggest a couple of mechanisms to then distribute news to other machines on the network. The first, using rdist to distribute news and lib/active, the second using find and tar. >If I had to choose a method I would use find/tar during the day with an >rdist at night to handle dropped articles. This would minimize the >overhead while staying in sync. Jerry apparantly failed to note that Michael stated that oberon was a 750. Felix, too, is a 750. And after being spoiled by the speed of 780s and 785s, doing anything significant on a 750 seems to take forever. Doing a find on a news filesystem on a 750 while at the same time the 750 is receiving news via NNTP and probably doing one or two UUCP transfers is bound to be S-L-O-W. Thus, an alternate suggestion, which I've been mulling about from time to time here at FileNet: - modify NNTP's ihave/sendme to use the article pathname instead of Message-ID. - modify inews (or integrate this functionality into the NNTP server) to do little more than extract the Xref line from the news header and use that to cross-link the article, if required, and update the lib/active file. You'd also have to update the machine name in the Xref header when storing on the local machine, so that rn would recognize it. This leaves the problem of updating the user's .newsrc files located on various machines. Since article numbers will be the same on all of the machines, I'd suggest using rdist for this. Jerry goes on to state: >Having the news readers use the article numbers to keep track of what >has been read is the heart of the problem. Unfortunately, keeping track >of article IDs consumes a lot more overhead. Rnews has essectially the >same problem of keeping track of what it has "read" (actually received >already). The history files using article IDs consume several >megabytes. If everyone used consistant IDs like then it >would be easy but many IDs are arbitrary strings. For each user to >consume several megabytes just to keep track of what they have read is >probably not acceptable. Well, not quite. Using awk '{print $1}'