jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) (08/07/90)
What is the correct method to pass along news in groups that we do not
wish to keep locally? If there is no line in the active file for the
newsgroup, it gets junked. If the line in the active file has a
trailing 'x', the group is not taken, nor is it passed on. Have I
missed something somewhere?
Any pointers would be greatly appreciated.
j
--
Jeffrey L. Bromberger
System Operator---City College of New York---Science Computing Facility
jeffrey@sci.ccny.cuny.edu jeffrey@ccnysci.BITNET
Anywhere!{cmcl2,philabs,phri}!ccnysci!jeffreygary@sci34hub.UUCP (Gary Heston) (08/08/90)
In article <1990Aug7.143458.1770@sci.ccny.cuny.edu> Jeffrey L Bromberger <jeffrey@sci.ccny.cuny.edu> writes: >What is the correct method to pass along news in groups that we do not >wish to keep locally? If there is no line in the active file for the >newsgroup, it gets junked. If the line in the active file has a >trailing 'x', the group is not taken, nor is it passed on. Have I >missed something somewhere? The easiest way I know of is to treat it as a normal group, and run expire on it with -e 1 to clear out everything more than a day old. This means you have 1 days worth of news in each of these groups on your system, but this shouldn't be a very large impact. The articles must be in place for sendbatch to retrieve a copy for the outgoing batch. I don't know of any way to "pass-thru" without actually posting the articles. -- Gary Heston { uunet!sci34hub!gary } System Mismanager SCI Technology, Inc. OEM Products Department (i.e., computers) "The esteemed gentlebeing says I called him a liar. It's true, and I regret that." Retief, in "Retiefs' Ransom" by Keith Laumer.
henry@zoo.toronto.edu (Henry Spencer) (08/09/90)
In article <747@sci34hub.UUCP> gary@sci34hub.sci.com (Gary Heston) writes: >The articles must be in place for sendbatch to retrieve a copy for the >outgoing batch. I don't know of any way to "pass-thru" without actually >posting the articles. Gary's comments are phrased in terms of B News, but the situation is similar for C News. The articles have to exist on your system to be passed on, although you can set a short expiry for them in explist. In C News (at least) there is one further wrinkle, however: an article in "junk" can be passed on, because relaying and filing are semi-independent operations, so an unknown newsgroup can go into "junk" and still go on to your neighbors. This isn't a wonderful idea on a routine basis, though, as the stuff is *still* there on your system, and it runs the "junk" article numbers up awfully quickly. -- It is not possible to both understand | Henry Spencer at U of Toronto Zoology and appreciate Intel CPUs. -D.Wolfskill| henry@zoo.toronto.edu utzoo!henry
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (08/10/90)
This is an interesting question, so I did a little experiment. I set
the permissions on a directory in /usr/spool/news to 600. Then I
submitted an article or two. They got posted okay, but no one but news
could read them. A little playing with the setuid bit in things
connected with sendbatch, and it seems willing to send things out.
The point of this excercise is to be able to pass a group through my
site, not allow my readers to see it, and have an expire on it
controllable at the group level.
I make no claims that this is a perfect solution, just that it
indicates a possible solution to the problem.
--
bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
"Stupidity, like virtue, is its own reward" -mejeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) (08/10/90)
In article <1990Aug9.152342.29200@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >however: an article in "junk" can be >passed on, because relaying and filing are semi-independent operations, so >an unknown newsgroup can go into "junk" and still go on to your neighbors. I have realized this - that was the initial setup, until disk space got excessively tight. There were days we couldn't get new news because of the old stuff. >This isn't a wonderful idea on a routine basis, though, as the stuff is >*still* there on your system, and it runs the "junk" article numbers up >awfully quickly. I'm not all that concerned about the article numbers in junk. Worse comes to worse, it can be reset by hand. What I *do* worry about is the downstream site that wants to subscribe to (let's say) most of the binaries groups (the groups with the smallest demand here). It would appear to be (diskwise) more convenient to receive the article just long enough to batch/compress it, and then kill our copy of it. What it looks like (through email and followups) is that I *do* have to have a local copy, at least until the batcher gets run, and the article is packed up for transmission. Thanks for the answers and suggestions. j -- Jeffrey L. Bromberger System Operator---City College of New York---Science Computing Facility jeffrey@sci.ccny.cuny.edu jeffrey@ccnysci.BITNET Anywhere!{cmcl2,philabs,phri}!ccnysci!jeffrey
ske@pkmab.se (Kristoffer Eriksson) (08/10/90)
In article <1990Aug9.205409.28967@sci.ccny.cuny.edu> jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) writes: > It would >appear to be (diskwise) more convenient to receive the article just >long enough to batch/compress it, and then kill our copy of it. How about letting the site that feeds you, batch the groups that you don't want but your downstream site wants, separately, and address it directly to that site in two hops, with your site just passing it along without having to look into it. -- Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden Phone: +46 19-13 03 60 ! e-mail: ske@pkmab.se Fax: +46 19-11 51 03 ! or ...!{uunet,mcvax}!sunic.sunet.se!kullmar!pkmab!ske
geoff@ITcorp.com (Geoff Kuenning) (08/11/90)
In article <1990Aug9.205409.28967@sci.ccny.cuny.edu> jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) writes: > binaries groups (the groups with the smallest demand here). It would > appear to be (diskwise) more convenient to receive the article just > long enough to batch/compress it, and then kill our copy of it. > > What it looks like (through email and followups) is that I *do* have > to have a local copy, at least until the batcher gets run, and the > article is packed up for transmission. The above paragraphs suggest another answer: arrange to have the unwanted articles batched separately, perhaps in "togo.nothere" or under a different directory. Then run a modified sendbatch that rm's the articles immediately after batching them up. You might even run that batcher more often so that the directories stay clean. A little more cleverness in the sendbatch.nothere script will even handle multiple feeds nicely. The only problem I can see with this scheme is that expire, upon seeing that an article has disappeared, might not keep the message-ID around for duplicate-prevention purposes. My guess is that this is similar to cancelled messages, and thus not a problem, but I haven't investigated personally. Do Henry or Geoff care to comment? Geoff Kuenning geoff@la.locus.com geoff@ITcorp.com
henry@zoo.toronto.edu (Henry Spencer) (08/11/90)
In article <15112@.la.locus.com> geoff@ITcorp.com (Geoff Kuenning) writes: >The only problem I can see with this scheme is that expire, upon seeing >that an article has disappeared, might not keep the message-ID around for >duplicate-prevention purposes. My guess is that this is similar to >cancelled messages, and thus not a problem, but I haven't investigated >personally. Do Henry or Geoff care to comment? I cannot speak for B News expire, but C News expire does not even look to see whether the article exists until it's time to expire it. And even then, if it's missing, C expire just says "hmph, must have been cancelled", and carries on. Cancellation removes the article but does not affect the history file, because it's seriously painful to alter a history-file entry that is already in place, and it's not worth the trouble. Neither expire nor the news readers can see any difference between an article which has been cancelled and one that has mysteriously disappeared for reasons unknown; since the first case is a normal occurrence, there is no problem with the second. In any case, *all* message-IDs stick around in the history file for duplicate prevention. -- It is not possible to both understand | Henry Spencer at U of Toronto Zoology and appreciate Intel CPUs. -D.Wolfskill| henry@zoo.toronto.edu utzoo!henry
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (08/13/90)
In article <1990Aug11.031724.11712@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: | I cannot speak for B News expire, but C News expire does not even look to | see whether the article exists until it's time to expire it. And even then, | if it's missing, C expire just says "hmph, must have been cancelled", and | carries on. Cancellation removes the article but does not affect the | history file, because it's seriously painful to alter a history-file | entry that is already in place, and it's not worth the trouble. Yes, this is a good design decision. There just doesn't seem to be much to gain from doing it the hard way, and there could be some major performance hits on a busy system. I confess, that when certain system get low on spool space that there is a script I run which calculates the "time-size" product and blows away the big old articles right now. For performance reasons this is done brute force, since it has to happen quickly to prevent loss of incoming information. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "This is your PC. This is your PC on OS/2. Any questions?"
clewis@eci386.uucp (Chris Lewis) (08/15/90)
In article <1990Aug11.031724.11712@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: | In article <15112@.la.locus.com> geoff@ITcorp.com (Geoff Kuenning) writes: | >The only problem I can see with this scheme is that expire, upon seeing | >that an article has disappeared, might not keep the message-ID around for | >duplicate-prevention purposes. My guess is that this is similar to | >cancelled messages, and thus not a problem, but I haven't investigated | >personally. Do Henry or Geoff care to comment? | I cannot speak for B News expire, but C News expire does not even look to | see whether the article exists until it's time to expire it. And even then, | if it's missing, C expire just says "hmph, must have been cancelled", and | carries on. Cancellation removes the article but does not affect the | history file, because it's seriously painful to alter a history-file | entry that is already in place, and it's not worth the trouble. B-news expire works in more-or-less the same fashion. Manually removing an article doesn't affect the history, even after the article would normally have been expired. That is, under normal usage. If you do an "expire -r" (rebuild database), expire doesn't look at the history file at all, and any articles no longer there have their history entries discarded. Which is why it ain't a good idea to run B-news expire unless you're convinced that it's lost a lot of entries. -- Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis Ferret mailing list: eci386!ferret-list, psroff mailing list: eci386!psroff-list Psroff information/questions: psroff-request@eci386
rick@uunet.UU.NET (Rick Adams) (08/15/90)
B-news expire works in more-or-less the same fashion. Manually removing an article doesn't affect the history, even after the article would normally have been expired. That is, under normal usage. If you do an "expire -r" (rebuild database), expire doesn't look at the history file at all, and any articles no longer there have their history entries discarded. Which is why it ain't a good idea to run B-news expire unless you're convinced that it's lost a lot of entries. Bnews has saved old history when rebuilding since patch 15. If you're going to pick on Bnews deficiencies, at least pick on the real ones rather than imaginary ones. --rick
michael@fts1.uucp (Michael Richardson) (08/15/90)
In article <3939@pkmab.se> ske@pkmab.se (Kristoffer Eriksson) writes: >In article <1990Aug9.205409.28967@sci.ccny.cuny.edu> jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) writes: >> It would >>appear to be (diskwise) more convenient to receive the article just >>long enough to batch/compress it, and then kill our copy of it. >How about letting the site that feeds you, batch the groups that you don't >want but your downstream site wants, separately, and address it directly to >that site in two hops, with your site just passing it along without having >to look into it. That puts another stage of newsgroup turning on/off. Why doesn't my downfeed just pick it up themselves? Better, I think, would be to have another form of 'F' flag ('L' if it isn't already taken) where a sub-group of junk-- junk.site (or a directory 'junk.site') where a LINK to the articles to be batched would be placed. The batcher would unlink() the articles as the are batched. This defeats one nice advantage of batching: if the link dies or the downfeed goes down, then provided you are running something like nbatcher (maybe the C news batchers allow this too) then you won't fill up your outbound directory and the articles waiting for them can still be expired. Yes, they miss articles that way, but if it is comp.sys.ibm.pc, well, I'm not crying... -- :!mcr!: | < political commentary currently undergoing Senate > Michael Richardson | < committee review. Returning next house session. > Play: mcr@julie.UUCP Work: michael@fts1.UUCP Fido: 1:163/109.10 1:163/138 Amiga----^ - Pay attention only to _MY_ opinions. - ^--Amiga--^
henry@zoo.toronto.edu (Henry Spencer) (08/15/90)
In article <101429@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes: > ... If you do an "expire -r" (rebuild > database), expire doesn't look at the history file at all, and > any articles no longer there have their history entries discarded... > >Bnews has saved old history when rebuilding since patch 15. C News, in fact, doesn't. I am debating changing this, but it's not entirely obvious that it's a good thing. The trouble is that there are two situations in which one wants to rebuild history: to pick up articles thought to be missing (the degenerate case of this is when you have no history file at all!), and to recover after the history file gets horribly mangled somehow. In the former case you want to save old history; in the latter you don't. It is probably necessary to distinguish the two cases. -- It is not possible to both understand | Henry Spencer at U of Toronto Zoology and appreciate Intel CPUs. -D.Wolfskill| henry@zoo.toronto.edu utzoo!henry
jerry@olivey.olivetti.com (Jerry Aguirre) (08/16/90)
In article <1990Aug15.164651.26664@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >history file at all!), and to recover after the history file gets horribly >mangled somehow. In the former case you want to save old history; in the >latter you don't. It is probably necessary to distinguish the two cases. If the history file is so mangled that it is useless to recover expired IDs from then there is this marvelous and powerful tool called "rm". Using it will very effectively eliminate the corruption without complicating the code used to rebuild history.
brian@ucsd.Edu (Brian Kantor) (08/16/90)
>In article <101429@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes: >>Bnews has saved old history when rebuilding since patch 15. And if for some reason (file is horribly mangled, etc) you don't want to, you just rm the history file before rebuilding. Obviously expire can't preserve old history if it doesn't have any, eh? - Brian
henry@zoo.toronto.edu (Henry Spencer) (08/16/90)
In article <49281@olivea.atc.olivetti.com> jerry@olivey.olivetti.com (Jerry Aguirre) writes: >>... In the former case you want to save old history; in the >>latter you don't. It is probably necessary to distinguish the two cases. > >If the history file is so mangled that it is useless to recover expired >IDs from then there is this marvelous and powerful tool called "rm". Unfortunately, there is also a Unix tradition that "rm" isn't necessary, rebuilding something overwrites the old version automatically. I worry about naive sysadmins being tripped up by a non-traditional user interface in a time of stress. Emergency tools are the last place you want to get creative or minimalist about user interface. I may try to do something more elegant about the whole business, actually, for another reason. The costly part of a history-file rebuild is reading all those articles to get newsgroups and message-IDs. If you only want to pick up a few missing ones, that is incredibly wasteful: there is no need to re-read any article that is already in the history file. The pick-up- missing-articles operation would be much more efficient if it didn't start from scratch. -- It is not possible to both understand | Henry Spencer at U of Toronto Zoology and appreciate Intel CPUs. -D.Wolfskill| henry@zoo.toronto.edu utzoo!henry
jerry@olivey.olivetti.com (Jerry Aguirre) (08/17/90)
In article <1990Aug16.163107.1166@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >Unfortunately, there is also a Unix tradition that "rm" isn't necessary, >rebuilding something overwrites the old version automatically. I worry >about naive sysadmins being tripped up by a non-traditional user interface >in a time of stress. Emergency tools are the last place you want to get >creative or minimalist about user interface. Yea, but the stressed out sysadmin is probably going to run the expire or rebuild as root. If he is running C news then the ownerships will be wrong and stress will turn to panic. The damn tools should at least abort if they are not being run as the news owner. Your idea about just adding missing articles to the history file sounds very appealing. I feel it would be a useful tool. One could process the history file into a bunch of sorted file names and compare that against a scan of the spool directory. (Sed, sort, find, and comm, that could all be done in a shell script!) Then one only needs a mini rnews that will add a history line for each of the missing articles without trying to recreate them in the spool area or forward them to neighbors. Presumably the date on the file should be used as the date of reception. The only remaining question is the order of the history file. Traditionally it has been kept in cronological order and the B news rebuild goes to the extra overhead of sorting it into that order. Is there any real reason one can't just append to the end? Jerry Aguirre
clewis@eci386.uucp (Chris Lewis) (08/17/90)
In article <101429@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes: | That is, under normal usage. If you do an "expire -r" (rebuild | database), expire doesn't look at the history file at all, and | any articles no longer there have their history entries | discarded. Which is why it ain't a good idea to run B-news | expire unless you're convinced that it's lost a lot of | entries. | Bnews has saved old history when rebuilding since patch 15. | If you're going to pick on Bnews deficiencies, at least pick on the | real ones rather than imaginary ones. Oops. Sorry, didn't notice that when I upgraded to PL 19 from 14. I don't think I've even run -r since then. Didn't mean to pick - after all, I *still* run B-news and am not planning to change in the near future. I'll just run expire -r more often... -- Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis Ferret mailing list: eci386!ferret-list, psroff mailing list: eci386!psroff-list Psroff information/questions: psroff-request@eci386
henry@zoo.toronto.edu (Henry Spencer) (08/17/90)
In article <49289@olivea.atc.olivetti.com> jerry@olivey.olivetti.com (Jerry Aguirre) writes: >... the stressed out sysadmin is probably going to run the expire >or rebuild as root. If he is running C news then the ownerships will >be wrong and stress will turn to panic. The damn tools should at least >abort if they are not being run as the news owner. How? It is not easy to tell. In particular, it is *very* difficult to reliably determine the login name or user id from the shell in a portable way. (Look at all the hassles inews goes through to try to find the login name if you don't believe me.) There is also a difference between deliberately confronting people with unfamiliar conventions, and expecting them to remember familiar ones ("the files belong to whoever you were when you created them"). >The only remaining question is the order of the history file. >Traditionally it has been kept in cronological order and the B news >rebuild goes to the extra overhead of sorting it into that order. Is >there any real reason one can't just append to the end? NNTP, in particular, really wants to see the file in chronological order. I consider it a bug that C News doesn't do that on a rebuild, and plan to fix it. -- It is not possible to both understand | Henry Spencer at U of Toronto Zoology and appreciate Intel CPUs. -D.Wolfskill| henry@zoo.toronto.edu utzoo!henry
urlichs@smurf.sub.org (Matthias Urlichs) (08/18/90)
In news.software.b, article <1990Aug15.152345.13048@fts1.uucp>, michael@fts1.uucp (Michael Richardson) writes: < In article <3939@pkmab.se> ske@pkmab.se (Kristoffer Eriksson) writes: < < Better, I think, would be to have another form of 'F' flag ('L' if < it isn't already taken) where a sub-group of junk-- junk.site < (or a directory 'junk.site') where a LINK to the articles to be batched < would be placed. The batcher would unlink() the articles as the are < batched. And if you run the batcher only once a day, then you have these huge directories with 4000+ files in them -- each of which has to be traversed for each new incoming article. Imminent death of your ability to process News as fast as they come in, predicted. :-) -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(Voice)/621227(PEP)
peter@ficc.ferranti.com (Peter da Silva) (08/19/90)
In article <1990Aug17.155959.1331@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: > In article <49289@olivea.atc.olivetti.com> jerry@olivey.olivetti.com (Jerry Aguirre) writes: > >... the stressed out sysadmin is probably going to run the expire > >or rebuild as root. If he is running C news then the ownerships will > >be wrong and stress will turn to panic. The damn tools should at least > >abort if they are not being run as the news owner. > How? It is not easy to tell. Huh? It's hard to determine the login name, but it's easy enough to determine if you've got the same user ID as a known login (such as the news owner). > In particular, it is *very* difficult to > reliably determine the login name or user id from the shell in a portable > way. Sounds like a job for a portable custom C program. Doing a "getpwnam" on the news owner and then comparing "pw_uid" with "getuid" should be completely portable. Or do what I do, chown all the files after creating them. > There is also a difference between deliberately confronting people with > unfamiliar conventions, and expecting them to remember familiar ones > ("the files belong to whoever you were when you created them"). Unfamiliar conventions like "root can do everything"? -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com (currently not working) peter@hackercorp.com
henry@zoo.toronto.edu (Henry Spencer) (08/20/90)
In article <RGA59O9@ggpc2.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >Huh? It's hard to determine the login name, but it's easy enough to determine >if you've got the same user ID as a known login (such as the news owner). From C; it's decidedly awkward from the shell. And we made a decision some time ago that we are not especially interested in defending ourselves against sysadmins who don't know what they're doing. (We rate ignorance of basic notions of file ownership and permissions as such.) >Or do what I do, chown all the files after creating them. Apart from being a nuisance, this assumes that there is a portable syntax for chown, which there isn't. I wish it were otherwise. -- Committees do harm merely by existing. | Henry Spencer at U of Toronto Zoology -Freeman Dyson | henry@zoo.toronto.edu utzoo!henry
peter@ficc.ferranti.com (Peter da Silva) (08/20/90)
In article <1990Aug20.011536.3323@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: > In article <RGA59O9@ggpc2.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > >Huh? It's hard to determine the login name, but it's easy enough to determine > >if you've got the same user ID as a known login (such as the news owner). > From C; it's decidedly awkward from the shell. So use a C program. > And we made a decision some > time ago that we are not especially interested in defending ourselves against > sysadmins who don't know what they're doing. (We rate ignorance of basic > notions of file ownership and permissions as such.) And this is why people are reluctant to move to C news from B news. > >Or do what I do, chown all the files after creating them. > Apart from being a nuisance, this assumes that there is a portable syntax > for chown, which there isn't. Huh? Where is there a UNIX system where "chown $NEWSMASTER $NEWSCTL/active" won't work? Sure, some places allow the extension "chown user.group file..." but you don't need to do that for this. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com (currently not working) peter@hackercorp.com
per@erix.ericsson.se (Per Hedeland) (08/21/90)
In article <1990Aug16.163107.1166@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes: |> In article <49281@olivea.atc.olivetti.com> jerry@olivey.olivetti.com (Jerry Aguirre) writes: |> >If the history file is so mangled that it is useless to recover expired |> >IDs from then there is this marvelous and powerful tool called "rm". |> |> Unfortunately, there is also a Unix tradition that "rm" isn't necessary, |> rebuilding something overwrites the old version automatically. I worry |> about naive sysadmins being tripped up by a non-traditional user interface |> in a time of stress. Emergency tools are the last place you want to get |> creative or minimalist about user interface. Unfortunately, too, the mkhistory script will not properly install the newly-built files if you have used the abovementioned tool on the old ones; you have to use the less powerful and more complex tool "cp /dev/null >". Of course, reading the script reveals what happened and what can be done about it, but as long as we're talking about emergency and stress... --Per Hedeland per@erix.ericsson.se or per%erix.ericsson.se@uunet.uu.net or ...uunet!erix.ericsson.se!per
henry@zoo.toronto.edu (Henry Spencer) (08/21/90)
In article <4.B5C74@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >> And we made a decision some >> time ago that we are not especially interested in defending ourselves against >> sysadmins who don't know what they're doing. (We rate ignorance of basic >> notions of file ownership and permissions as such.) > >And this is why people are reluctant to move to C news from B news. Somehow I doubt this; B News didn't exactly hold your hand every step of the way either. >> Apart from being a nuisance, this assumes that there is a portable syntax >> for chown, which there isn't. > >Huh? Where is there a UNIX system where "chown $NEWSMASTER $NEWSCTL/active" >won't work? ... Systems where chown is in some strange place, like /etc, that isn't in the default search path. -- Committees do harm merely by existing. | Henry Spencer at U of Toronto Zoology -Freeman Dyson | henry@zoo.toronto.edu utzoo!henry
cudep@warwick.ac.uk (Ian Dickinson) (08/22/90)
In article <1990Aug21.161506.21784@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >Somehow I doubt this; B News didn't exactly hold your hand every step of >the way either. B news was not good - C news is different - you can't win :-( >>> Apart from being a nuisance, this assumes that there is a portable syntax >>> for chown, which there isn't. >>Huh? Where is there a UNIX system where "chown $NEWSMASTER $NEWSCTL/active" >>won't work? ... >Systems where chown is in some strange place, like /etc, that isn't in the >default search path. What's wrong with something like: PATH=/bin:/etc:/usr/whatever (chown $NEWSMASTER $NEWSCTL/active) Cheers, -- \/ato. Ian Dickinson. GNU's not got BSE. Cut Cerebus some slack! vato@cu.warwick.ac.uk Plinth. vato@tardis.cs.ed.ac.uk Sabeq. gdd046@cck.cov.ac.uk "Nuke me tender, nuke me good!"
peter@ficc.ferranti.com (Peter da Silva) (08/22/90)
In article <1990Aug21.161506.21784@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes: > Somehow I doubt this; B News didn't exactly hold your hand every step of > the way either. It did a better job than C news. Really. C news is a far superior product once you get it installed, but it's a pain to install and there are all sorts of administration gotchas. Yes, you should make sure that you don't run as root, and make sure any changes to your scripts are copied out before running the doit files, and so on... but it's a lot of stuff to remember when you're doing news administration in your spare time. Some of us have other duties. :-< > >Huh? Where is there a UNIX system where "chown $NEWSMASTER $NEWSCTL/active" > >won't work? ... > Systems where chown is in some strange place, like /etc, that isn't in the > default search path. What is this, more BSD fascist file system fallout? Geeze. It's one thing to be incompatible, but gratuitously incompatible? Of course, the "build" script does ask where chown is, so you do know the strange place when you install the scripts... -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
stealth@caen.engin.umich.edu (arrakis) (08/22/90)
In article <1990Aug21.161506.21784@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <4.B5C74@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >>And this is why people are reluctant to move to C news from B news. ... >>> Apart from being a nuisance, this assumes that there is a portable syntax >>> for chown, which there isn't. >> >>Huh? Where is there a UNIX system where "chown $NEWSMASTER $NEWSCTL/active" >>won't work? ... > >Systems where chown is in some strange place, like /etc, that isn't in the >default search path. I quote from the "build" script in the cnews/conf directory: ------------------ echo chown=`ask 'What is the full pathname of the chown command' ${chown-/etc/chown}` echo "Can I say \`$chown $newsuid.$newsgid file' to change both the user id" chboth=`yesno 'and group id of a file' ${chboth-yes}` case "$chboth" in no) chgrp=`ask 'What is the full pathname of chgrp' ${chgrp-/etc/chgrp}` ;; yes) chgrp="/etc/chgrp" ;; esac ------------------ -- Michael V. Pelletier | "We live our lives with our hands on the CAEN UseNet News Administrator | rear-view mirror, striving to get a better Systems Group Programmer | view of the road behind us. Imagine what's | possible if we look ahead and steer..."
henry@zoo.toronto.edu (Henry Spencer) (08/23/90)
In article <1990Aug22.151531.29862@caen.engin.umich.edu> stealth@caen.engin.umich.edu (arrakis) writes: >>Systems where chown is in some strange place, like /etc, that isn't in the >>default search path. > >I quote from the "build" script in the cnews/conf directory: Build is asking that so it can construct its own shell scripts appropriately... but build already sticks its tentacles into far too many places. I do *not* want to see it editing every shell program we supply! (And that's about what it would take.) Look guys, I'm sorry -- a little -- but fixing everything in C News to catch errors by careless or incompetent sysadmins is way, way down on my list of priorities. It's too much work for too futile an objective. -- Committees do harm merely by existing. | Henry Spencer at U of Toronto Zoology -Freeman Dyson | henry@zoo.toronto.edu utzoo!henry
richard@pegasus.com (Richard Foulk) (08/24/90)
>>>Systems where chown is in some strange place, like /etc, that isn't in the >>>default search path. >> >>I quote from the "build" script in the cnews/conf directory: > >Build is asking that so it can construct its own shell scripts >appropriately... but build already sticks its tentacles into far too many >places. I do *not* want to see it editing every shell program we supply! >(And that's about what it would take.) > >Look guys, I'm sorry -- a little -- but fixing everything in C News to >catch errors by careless or incompetent sysadmins is way, way down on >my list of priorities. It's too much work for too futile an objective. Obstinance. That often seems to be the biggest problem with taking Cnews the extra few inches necessary for wider acceptance. Henry's a good guy, and Cnews is a superior package. But the "not invented here" attitude. And the "let's make a statement while we're at it" approach is stifling things. Our favorite OS is better than yours. We hate patchlevels so we'll dream up something of our own (Cnews will suffer, but that's beside the point). Bnews is so awful that we won't even keep a copy online to look at -- better to reinvent the wheel (and the bugs) wherever possible. We can't use Configure, we didn't invent that either. I've been using Cnews for about ten months. It does a good job and it's very fast. No disrespect meant. I'm not in a very diplomatic mood at the moment -- this outburst has been percolating for some time, I guess. There's some constructive criticism in there somewhere. . . -- Richard Foulk richard@pegasus.com
henry@zoo.toronto.edu (Henry Spencer) (08/24/90)
In article <1990Aug24.020520.19928@pegasus.com> richard@pegasus.com (Richard Foulk) writes: >But the "not invented here" attitude. And the "let's make a statement >while we're at it" approach is stifling things. The opposite of "not invented here" is "no quality control here". We're happy to accept ideas from others -- many of the changes made since the official release have been suggestions from outside, and some have been code from outside -- but we are not going to adopt everything anybody suggests. >Our favorite OS is better than yours... ??? Apart from Unix in general, we have no favorite OS. > We hate patchlevels so we'll dream up something of our own... We still don't care for patch numbering, but would probably have thought harder about it if we'd appreciated how many patches there would end up being. We'd hoped for rather fewer. >Bnews is so awful that we won't even keep a copy online to look at... We do have one online, actually. In fact, we have several online. (You didn't think there was just one B News, did you? Some of the places where people complain about us "not being B News compatible" are places where we are compatible with B2.10.1 and think the changes made in B2.11 are mistakes.) >We can't use Configure, we didn't invent that either. We didn't use Configure because (a) our early experiences with it were bad enough to turn us off it completely, (b) most of its automatic features do little for us (very few of the C News "build" questions could be answered automatically) and they interfere badly with things like cross- compilation, and (c) it is too complex for our simple minds. -- Committees do harm merely by existing. | Henry Spencer at U of Toronto Zoology -Freeman Dyson | henry@zoo.toronto.edu utzoo!henry
henry@zoo.toronto.edu (Henry Spencer) (08/25/90)
In article <3ND5KOC@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >> Somehow I doubt this; B News didn't exactly hold your hand every step of >> the way either. > >It did a better job than C news. Really. C news is a far superior product >once you get it installed, but it's a pain to install and there are all >sorts of administration gotchas... Opinions vary on this. We've had no shortage of "went in fine, no problems" comments, and several comments that it's much more sysadmin-friendly (!). It may be that one's background makes a difference, with some things not being done the way some people are used to. -- Committees do harm merely by existing. | Henry Spencer at U of Toronto Zoology -Freeman Dyson | henry@zoo.toronto.edu utzoo!henry
peter@ficc.ferranti.com (Peter da Silva) (08/26/90)
In article <1990Aug24.204636.8619@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: > In article <3ND5KOC@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > >It did a better job than C news. Really. C news is a far superior product > >once you get it installed, but it's a pain to install and there are all > >sorts of administration gotchas... > Opinions vary on this. We've had no shortage of "went in fine, no problems" Probably from BSD sites. System V/386 requires hacking the free space scripts. And of course our Xenix System III/286 nodes were pure hell. BNews was easier to handle, but much slower and buggier. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
michael@fts1.uucp (Michael Richardson) (08/27/90)
In article <9&c[e2.[51@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >< it isn't already taken) where a sub-group of junk-- junk.site >< (or a directory 'junk.site') where a LINK to the articles to be batched >And if you run the batcher only once a day, then you have these huge >directories with 4000+ files in them -- each of which has to be traversed for Good point. However, in my case, the groups that I might want to pass on without keeping them around longer than necessary would be those nasty binary groups. --- low posting rate, but big postings. I'm also half thinking of discussions that I was having with another Amiga person (Gregory Kritsch) concerning news batching. The AmigaDOS file system tends to have a hashed directory structure (but file systems are dynamically mountable, so this may not be the case for all file systems.) -- :!mcr!: | 'Golf sucks anyway --- give the land to the Michael Richardson | Indians' --- recent CANACHAT comment. Play: mcr@julie.UUCP Work: michael@fts1.UUCP Fido: 1:163/109.10 1:163/138 Amiga----^ - Pay attention only to _MY_ opinions. - ^--Amiga--^
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (08/27/90)
In article <5JG5B9A@ggpc2.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: | > Opinions vary on this. We've had no shortage of "went in fine, no problems" | | Probably from BSD sites. System V/386 requires hacking the free space scripts. | And of course our Xenix System III/286 nodes were pure hell. BNews was easier | to handle, but much slower and buggier. Too true. You don't hear much about the systems which work fine with configure, but there are a lot of common machines which are not stock BSD, and they install B news without problems. Naturally no one has done all machines, but we've been sucessful with Sun 2, 3, 386i, 4, Ultrix, Xenix[23]86, {SCO,ISC} UNIX, and a couple of Motorola and Stellar machines who's models I forget, but which were either very stock SysV, or highly hacked SysV. C news on a Sun went pretty well for install, was dropped due to admin effort (training time, not that it was all that hard). C news didn't go in on the Xenix or 386 UNIX boxes, although I believe it could be done. I'm hoping to try TMNN on V.4 in the next few days, and I'll give you a report if I get to try it. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) VMS is a text-only adventure game. If you win you can use unix.
henry@zoo.toronto.edu (Henry Spencer) (08/27/90)
In article <5JG5B9A@ggpc2.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >> Opinions vary on this. We've had no shortage of "went in fine, no problems" > >Probably from BSD sites. System V/386 requires hacking the free space scripts. No, from System V sites too. There *is* a peculiar belief in some quarters of academia that System V doesn't exist, but we've never subscribed to it. We don't have many of them around here, but we do have one or two, and they were supplemented with several elsewhere during our beta test. The problems they reported, we fixed. On some fraction of System Vs, it goes in cleanly. I admit to being somewhat dismayed at how much stupid variability there is in System V df output format. The System V spacefor we ship was built with advice from some contacts within the AT&T System V empire, and it worked on all the System Vs we had handy, but it looks like everybody messes with the df output format. -- Committees do harm merely by existing. | Henry Spencer at U of Toronto Zoology -Freeman Dyson | henry@zoo.toronto.edu utzoo!henry