bob@reed.UUCP (Bob Ankeney) (12/01/89)
I have recently been trying to install Cnews on a pair of systems:
A MicroVAX II running Ultrix V2.3, and a Sun4/330 running SunOS 4.0.3.
I'm not too sure how the Sun version is doing, since the VAX provides the
feed, and that's where I seem to have the most problems. I'll describe
some of the problems I encountered and how I solved them, then describe
those I still see.
I encountered a lot of permission problems installing Cnews with
the doit.* scripts, executing them su'ed to whatever. Why isn't there
just a single doit.root script with appropriate chown's?
I tried applying the first Cnews patch, and found that all but the
last few patches had already been applied to the release I pulled off.
The first problem I had was that Ultrix df has two header lines,
so the free space calculation in spacefor didn't work. Changing nr to
3 in the awk expression solved this.
When I ran mkhistory, it exited after finding <trash@swill> entries
in history.n. These entries were all empty files. Is this appropriate
behaviour? We used to have problems with our news directory filling up
which is why these files were zero-length. I removed them, and all seems
well now.
Also, several of the installed shell scripts had their execute
bit set, but not the read bit (e.g. mode 751). These scripts are owned
by bin.bin, and executed by news. Perhaps the install scripts should
do a chmod +rx instead of a chmod +x so this won't happen.
Another problem was that uucp doesn't have write permission on
the in.coming directory (which is owned by news.news). I've had some
other permission-related problems of this nature too. Is there a
recommended solution for this?
I didn't look too carefully at the explist file, and started to use
it as-is. Unfortunately, the '@' field proved to be a problem as the
recommended crontab additions for doexpire did not specify a '-a'. So
doexpire failed initially. Since we don't plan to archive anything, I just
changed the '@' to a '-', and also tossed some other unneeded lines.
On the unsolved side:
Running the regression test in the expire directory, I have a problem
with superkludge and get the following:
: "and that's mkhistory done, finally try superkludge"
test -r arts/foo/1
test -r arts/foo/10
NEWSARTS=`pwd`/arts NEWSCTL=`pwd` NEWSBIN=`pwd`/nbin ./superkludge foo
./superkludge: message-id format problems:
1 <wont1>
99 <multi99>
test ! -r arts/foo/1
*** Error code 1
Stop.
I haven't looked into this yet. Any ideas?
Running newsdaily by hand, I get:
find: bad status < * >
I haven't looked into why this happens, either.
At any rate, we now have some freshly unbatched news, so things are
looking up. Any help on the remaining problems would be appreciated.
Bob Ankeney
---------------------------------------------------------------------------
Bob Ankeney | "Wise men talk because they have |
...!tektronix!reed!bob | something to say; fools, because |
...!tektronix!bob@reed.BITNET | they have to say something." |
...!tektronix!reed!arnav!bob | |
| "He who talks by the yard and acts by |
| the inch should be kicked by the foot." |
---------------------------------------------------------------------------henry@utzoo.uucp (Henry Spencer) (12/03/89)
In article <13657@reed.UUCP> bob@reed.UUCP (Bob Ankeney) writes: > I have recently been trying to install Cnews on a pair of systems... A generic note, by the way: C News problems will get more prompt attention if they are posted to news.software.b or mailed to the address given in the documentation. We don't always read comp.sources.bugs frequently. > Why isn't there just a single doit.root script with appropriate chown's? Geoff and I belong to the old school of sysadmins, who consider root privileges dangerous and use them as sparingly as possible to avoid costly mistakes. In particular, we are *very* reluctant to execute other peoples' code as root unless we can proofread it first. Hence the *.root scripts are small and short so you can easily read them and tell that they're not doing anything evil, and nothing else needs to run as root. I know of nothing that would break if you just ran everything as root, although it's not something I would ever do. > I tried applying the first Cnews patch, and found that all but the >last few patches had already been applied to the release I pulled off. This is an ongoing nuisance, but it's difficult to avoid with any widely distributed software. Things may be mitigated a little bit when FTP from zoo.toronto.edu becomes available, at which point at least Internet sites will be able to get a copy that is *guaranteed* current. > The first problem I had was that Ultrix df has two header lines, >so the free space calculation in spacefor didn't work. Changing nr to >3 in the awk expression solved this. Yeah, DEC compounded Berkeley's botch by messing up df output further. You'd think nobody ever considered that *programs* might want to use the output. There is probably going to be an Ultrix df as part of the distribution, along with one or two others, as soon as I find time to go through my low-priority-to-do queue. > When I ran mkhistory, it exited after finding <trash@swill> entries >in history.n. These entries were all empty files. Is this appropriate >behaviour? ... The current version issues a warning and continues. This problem turned out to be rather more common than we'd originally thought, justifying intelligent action rather than "oh my, something incomprehensible has happened, better call in human help". > Also, several of the installed shell scripts had their execute >bit set, but not the read bit (e.g. mode 751). These scripts are owned >by bin.bin, and executed by news. Perhaps the install scripts should >do a chmod +rx instead of a chmod +x so this won't happen. I'd appreciate it if you could investigate and find out how this happened, actually. The only way I know of that stuff could get created unreadable is if your umask was set to turn off the read bits, and chmod will *not* override that (i.e., "chmod +rx" probably wouldn't have helped). I don't understand why somebody would set a umask like 026 (turn off ----w-rw-) rather than 027 (turn off ----w-rwx); is that what happened? > Another problem was that uucp doesn't have write permission on >the in.coming directory (which is owned by news.news)... This should not be an issue if newsspool is setuid-news, as it should be. Can you investigate? > I didn't look too carefully at the explist file, and started to use >it as-is. Unfortunately, the '@' field proved to be a problem as the >recommended crontab additions for doexpire did not specify a '-a'... Oops. Hmm. I'm going to have to revise things a bit so the default stuff is consistent. I guess most people customize explist before running expire; this one hasn't been reported before. > Running the regression test in the expire directory, I have a problem >with superkludge and get the following: > ... >./superkludge: message-id format problems: > ... >I haven't looked into this yet. Any ideas? We've seen this one before; it probably means your system's awk has a bug. Superkludge is doing a sweep of its data with awk for sanity checking before doing anything drastic, and some versions of awk misbehave when you ask them to do a pattern match on a nonexistent field. The 14-Sep-1989 patch fixed superkludge to avoid this. -- Mars can wait: we've barely | Henry Spencer at U of Toronto Zoology started exploring the Moon. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
djm@twiddle.eng.umd.edu (David J. MacKenzie) (12/05/89)
In article <1989Dec3.014328.9176@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >The only way I know of that stuff could get created unreadable >is if your umask was set to turn off the read bits, and chmod will *not* >override that (i.e., "chmod +rx" probably wouldn't have helped). However, "chmod a+rx" *will* override the umask. -- David J. MacKenzie <djm@eng.umd.edu>
henry@utzoo.uucp (Henry Spencer) (12/06/89)
In article <8912041651.AA01167@twiddle.eng.umd.edu> djm@twiddle.eng.umd.edu (David J. MacKenzie) writes: >>The only way I know of that stuff could get created unreadable >>is if your umask was set to turn off the read bits, and chmod will *not* >>override that (i.e., "chmod +rx" probably wouldn't have helped). > >However, "chmod a+rx" *will* override the umask. I'm reluctant to do so as default, however, on the assumption that the umask is usually set for a good reason. We've had a suggestion in the past that it would be nice to have a permission checker to report odd-looking permissions on a supposedly-correctly-installed system... -- Mars can wait: we've barely | Henry Spencer at U of Toronto Zoology started exploring the Moon. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
jfh@rpp386.cactus.org (John F. Haugh II) (12/06/89)
In article <1989Dec5.181020.29682@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <8912041651.AA01167@twiddle.eng.umd.edu> djm@twiddle.eng.umd.edu (David J. MacKenzie) writes: >>However, "chmod a+rx" *will* override the umask. > >I'm reluctant to do so as default, however, on the assumption that the >umask is usually set for a good reason. and what was the good reason berzerkeley used to change the behavior of chmod so that it used the umask? -- John F. Haugh II +-Things you didn't want to know:------ VoiceNet: (512) 832-8832 Data: -8835 | In Ham lingo DEC is rot-13 for "Low InterNet: jfh@rpp386.cactus.org | Power". "CPU?" "QRP Vax-11." UUCPNet: {texbell|bigtex}!rpp386!jfh +--------------------------------------
henry@utzoo.uucp (Henry Spencer) (12/08/89)
In article <17410@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: >>I'm reluctant to do so as default, however, on the assumption that the >>umask is usually set for a good reason. > >and what was the good reason berzerkeley used to change the behavior >of chmod so that it used the umask? They didn't. This was a property of chmod as shipped by Bell Labs in V7. On the whole, it's a good one. -- 1233 EST, Dec 7, 1972: | Henry Spencer at U of Toronto Zoology last ship sails for the Moon. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
decot@hpisod2.HP.COM (Dave Decot) (12/09/89)
> >I'm reluctant to do so as default, however, on the assumption that the > >umask is usually set for a good reason. > > and what was the good reason berzerkeley used to change the behavior > of chmod so that it used the umask? For the reason that the user has set their umask that way for a good (to them) reason. Sloppy users and scripts who do "chmod +x" when they really meant "chmod u+x", as evidenced by their umask, are likely to get themselves in trouble if +x is taken to mean "a+x". The current draft of POSIX.2 requires the umask to be consulted when the "who" part of the mode specification is omitted. Dave Decot
alan@numm.nu.oz (Alan Hargreaves) (12/11/89)
In article <1989Dec8.001602.11796@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <17410@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: >> >>and what was the good reason berzerkeley used to change the behavior >>of chmod so that it used the umask? > >They didn't. This was a property of chmod as shipped by Bell Labs in V7. >On the whole, it's a good one. hafta agree with henry, just checked my src to make sure, chmod in V7 (hey we must be one of the few v7 sites left, let alone the fact that it is very close to the 1st non dec port) definately checks the umask. alan. -- Alan Hargreaves (vk2mgl) SysCleric alan@numm.nu.oz Phone: (049) 685 597 SNAIL: c/- Computing Centre, University of Newcastle, NSW 2308, Australia. F u cn rd ths u cnt spl wrth a dm!
guy@auspex.auspex.com (Guy Harris) (12/13/89)
>and what was the good reason berzerkeley used to change the behavior >of chmod so that it used the umask? Mu. What was the good reason you used to assume that it was Berkeley who changed it? V7's "chmod" command, when you said chmod +w file used the umask; S3's and S5's did not. Berkeley just did what AT&T first told them to do, and didn't change their mind when some other group at AT&T changed theirs....