Unix-Wizards-Request@BRL.ARPA (Mike Muuss) (07/24/85)
UNIX-WIZARDS Digest Fri, 19 Jul 1985 V1#110 Today's Topics: Re: extracting files with tar can corrup Re: Vax 4.2 UDP Bradcast woes followup.. Question about spl() levels in clock.c Re: Speeding up the 3B2... Re: Need help preserving permissions when using tar? Re: shorts vs. ints on a VAX 11/750 Re: Idle time logout mechanism (daemon) Re: Vax 4.2 UDP Bradcast woes followup.. Re: bug using doublebox in tbl with ditroff Re: System V vs. BSD Re: National Semi announces 4.2 BSD :-) Re: Vax 4.2 UDP Bradcast woes followup.. Dump(8) and the Modified Tower of Hanoi Re: Xenix Shared Data Bugs (and friends) ----------------------------------------------------------------- From: jbn@wdl1.UUCP Subject: Re: extracting files with tar can corrup Date: 15 Jul 85 23:57:13 GMT Sender: notes@wdl1.UUCP Nf-ID: #R:sdcc3:-293900:wdl1:64000002:000:157 Nf-From: wdl1!jbn Jul 15 15:08:00 1985 To: unix-wizards@brl-tgr.arpa That's a nifty security hole. One of many good reasons not to buy packages whose installation instructions begin ``log in as root''. J. Nagle ----------------------------- From: jbn@wdl1.UUCP Subject: Re: Vax 4.2 UDP Bradcast woes followup.. Date: 15 Jul 85 23:57:26 GMT Sender: notes@wdl1.UUCP Nf-ID: #R:osu-eddi:-42000:wdl1:64000003:000:431 Nf-From: wdl1!jbn Jul 15 15:15:00 1985 To: unix-wizards@brl-tgr.arpa Sites with nontrivial networks should be very careful with broadcast IP packets. We have problems with some Masscomp systems that want to broadcast to every host on our class B network, asking for all of [128.5.xxx.xxx]. This sends to our sites in Michigan, California, Colorado, and Texas, clogging the long-haul lines with ``rwho'' packets. 4.xBSD needs to know about subnets. More on this later. J. Nagle ----------------------------- From: khw@druil.UUCP (WilliamsonK) Subject: Question about spl() levels in clock.c Date: 15 Jul 85 22:20:32 GMT To: unix-wizards@brl-tgr.arpa In clock.c in several versions of UN*X the code checks to see if the spl level was non-zero before the clock interrupt (i.e. we were already in an interrupt or a kernel critical section). If so it doesn't bother with the callout processing. My question is this: At the beginning of the callout processing it lowers the spl level so that the clock interrupt can be interrupted. But it doesn't raise the interrupt level at the end of the callout processing where the branches rejoin (at the label "out:"). This means that after "out:" is reached there are two possible spl levels: the original clock interrupt level, and the level set before doing the callout. If it is important that the code after "out:" not be interruptible, then the spl() level should be raised again for the case where it is lowered. If it is not important, then general principals about not keeping interrupts masked longer than absolutely necessary should dictate that the spl() level be lowered always after "out:". Is this an oversight on the part of the Un*x developers, or what am I missing? Karl Williamson ATT ISL Denver ihnp4!drutx!druil!khw 303-538-4583 ----------------------------- From: heiby@cuae2.UUCP (Ron Heiby) Subject: Re: Speeding up the 3B2... Date: 16 Jul 85 03:09:22 GMT To: unix-wizards@brl-tgr.arpa In article <292@timeinc.UUCP> greenber@timeinc.UUCP (Ross M. Greenberg) writes: >Claims that a program (written in CoBlech) takes about two minutes >to run on his vanilla PC-AT and over fifteen minutes to run on the >3B2. You don't mention what version of System V your friend is running on the 3B2. Is it 1.0, 1.0.1, SVR2v1, SVR2v2, or SVR2.1 (or something I never heard of)? What Cobol is being used? Does it compile to pseudo-code that is then interpreted by a "runcobol" command? Does it do a lot of floating point arithmetic? We all know that the 3B2/300 has rather marginal floating point emulated in software. You don't even mention what configuration 3B2 you are talking about. Is it a 3B2/400 with math co-processor (MAU)? Without these details, it's really hard to come up with any solution, but (assuming you are talking about SVR2v1 or later) you should look in the System Administrator's Guide under performance and system tuning to find out what the tunable parameters do and how to adjust them. Are you using one or two hard disks? If two, put /usr on the second drive. More details get better answers. Good luck. -- Ron Heiby heiby@cuae2.UUCP (via ihnp4) AT&T-IS, /app/eng, Lisle, IL (312) 810-6109 ----------------------------- From: greenber@timeinc.UUCP (Ross M. Greenberg) Subject: Re: Speeding up the 3B2... Date: 16 Jul 85 15:02:11 GMT To: unix-wizards@brl-tgr.arpa Ron: I would like to take this opportunity to thank you for your help in advising my friend of what to do to help speed up his 3B2. Now at least I know what questions to ask him. Some of us out here, you see, have very little experience with the 3B2 (if any!). So the important details that you mentioned would have been unknown to me. -- ------------------------------------------------------------------ Ross M. Greenberg @ Time Inc, New York --------->{vax135 | ihnp4}!timeinc!greenber<--------- I highly doubt that Time Inc. would make me their spokesperson. ---- "I was riding a wombat this morning, 'till it broke its leg. I had to shoot it" -- Ranger on Camel ----------------------------- From: jtkohl@mit-priam.UUCP (John T. Kohl) Subject: Re: Need help preserving permissions when using tar? Date: 17 Jul 85 15:53:56 GMT To: unix-wizards@brl-tgr.arpa In article <2424@sun.uucp> gnu@sun.uucp (John Gilmore) writes: >> Does anyone know of a way to preserve file and directory permissions >> and ownerships when using tar? > >The tar in 4.2bsd (and maybe other Berkeley releases) puts directory >permissions into the tar file and creates the directories with those >permissions when you read the tar file. But it only sets ownerships if the user who extracts is root. -- The opinions expressed above, if any, are mine. John T. Kohl UUCP: ...!decvax!mit-athena!jtkohl ARPA: jtkohl@mit-athena.ARPA ----------------------------- From: guy@sun.uucp (Guy Harris) Subject: Re: Need help preserving permissions when using tar? Date: 17 Jul 85 08:10:25 GMT To: unix-wizards@brl-tgr.arpa > The tar in 4.2bsd (and maybe other Berkeley releases) puts directory > permissions into the tar file and creates the directories with those > permissions when you read the tar file. It only creates the directories with those permissions if you use the "p" flag when reading the tape in. (It creates files with the permissions from the tape under all circumstances, but it proceeds to change the mode of the file from the mode it was created with to the very same mode if you specify the "p" flag! To add a bit of confusion, the System V Release 2 "tar" has an "o" flag - conflicting, alas, with the Berkeley "o" flag which tells it *not* to put directories on the tape - which tells it not to change the owner and group owner of the files to the values from the tape. I guess this wasn't in V7 because only the super-user can change the ownership of a file. The only reason I can assume for why it wasn't changed in the first USG release it was on is that none of the people using USG releases use "tar" - they use "cpio" instead. Having all files read in from a "tar" (or "cpio"!) file from another site owned by whatever random users have the same numeric user ID as the owner of the file at that site gets old *real* quickly... Guy Harris ----------------------------- From: faustus@ucbcad.UUCP (Wayne A. Christopher) Subject: Re: shorts vs. ints on a VAX 11/750 Date: 17 Jul 85 18:12:05 GMT To: unix-wizards@brl-tgr.arpa > I noted today that variables in "ex_vis.h" were declared to be type "short" > rather than type "int." Now my own experience with our VAX 11/750 has been > that it pays to declare (non-array) variables to be "int" rather than "short"; > this avoids all sorts of "cvtxx"s at run time, and seems to more than > compensate for the extra memory fetches involved in using "int"s rather > than "short"s. And yet I've got to believe that there was a good reason > for using shorts in vi. Well, there isn't any extra overhead with fetching a long as opposed to a short -- the fetch is always 32 bits. > If you have insights in to using shorts versus using ints on the VAX 11/750 > in general, or shorts versus ints in vi in particular, I'd appreciate hearing > from you. I can think of a few: if you are using a lot of them, then maybe you are concerned with space -- with just a few of them probably that isn't a problem though. Also, in something like vi, which should be pretty portable and was written on a 16-bit machine, it seems like good style to me to be clear about whether you want a variable to have 16 or 32 bits -- an int can be either, depending on what machine you are running on, and you can get used to thinking of an int as 32 bits and get into trouble when it isn't... Wayne ----------------------------- From: rbp@investor.UUCP (Bob Peirce) Subject: Re: Idle time logout mechanism (daemon) Date: 17 Jul 85 17:44:57 GMT To: unix-wizards@brl-tgr.arpa > Does anyone have (or know of) a daemon which will monitor users idle time, > and logout any user idle longer than a given amount of time. > Please respond via mail and as usual, I will summarize for the net. Sorry, I don't have a path to you, but this works on SYS III. I use it as part of my el-cheapo, one modem both ways set-up. Stick it in cron to run every once in a while. You may want to modify this to handle several lines. # -- ckmod # Robert B. Peirce; Cookson, Peirce & Co., Inc. # If anyone is inactive on a modem > $GRACE minutes log them off # This version gives no quarter. # Have to look for hung outgoing uucp stuff too. if [ $# -ne 1 ] then echo "usage: ckmod tty#" exit 1 fi MODEM=$1 GRACE=15 # minutes of no activity HM=/usr/lib/uucp LOG=/u/rbp/kill.log SPOOL=/usr/spool/uucp cd $HM # If set doesn't produce anything, force it. set `who | grep tty$MODEM || echo XXX` U=$1 if [ $U = XXX ] then U="" fi # Get current time set `date | tr ":" " "` M=$2 D=$3 HC=$4 MC=$5 # Get time device last accessed set `/usr/ucb/ls -l /dev/tty$MODEM | tr ":" " "` HL=$8 ML=$9 # Check for midnight crossover if [ $HL -gt $HC ] then HL=`expr $HL + 24` fi # Calculate time since last access of device TIME=`expr \( 60 "*" $HC + $MC \) - \( 60 "*" $HL + $ML \)` if [ $U ] then if [ $TIME -ge 1 ] then echo "$U tty$MODEM ($M $D $HC:$MC $HL:$ML) $TIME minutes.\c"\ >> $LOG if [ $TIME -lt $GRACE ] then echo >> $LOG fi fi if [ $TIME -ge $GRACE ] then # Let him have it P=`ps -ft$MODEM | awk 'BEGIN{FS=" "}/'$U'/{print $2;exit}'` if [ $P ] then kill -9 $P echo " Killed after $TIME minutes." >> $LOG else echo >> $LOG fi fi else # Nobody logged on from outside LCK=`ls $SPOOL | egrep "LCK\.\..|.lock"` # locks placed in uucp if [ "$LCK" -a $TIME -ge $GRACE ] # uucp has hung then cd $SPOOL rm -f $LCK fi fi -- Bob Peirce uucp: ...!{allegra, bellcore, cadre, idis} !pitt!darth!investor!rbp ----------------------------- From: rbp@investor.UUCP (Bob Peirce) Subject: Re: Idle time logout mechanism (daemon) Date: 17 Jul 85 18:49:39 GMT To: unix-wizards@brl-tgr.arpa > # -- ckmod > # Check for midnight crossover > if [ $HL -gt $HC ] > then > HL=`expr $HL + 24` > fi Peirce, you're an idiot. If HL is already greater than HC, adding 24 hours isn't going to help! Change that to HC=`expr $HC + 24`. Then, in the next calculation you have a shot at finding a time difference when midnight is overlapped. -- Bob Peirce uucp: ...!{allegra, bellcore, cadre, idis} !pitt!darth!investor!rbp ----------------------------- From: chris@umcp-cs.UUCP (Chris Torek) Subject: Re: Vax 4.2 UDP Bradcast woes followup.. Date: 18 Jul 85 07:56:55 GMT To: unix-wizards@brl-tgr.arpa 4.3BSD *does* know about subnets. (Also uses all-ones by default. Hooray!) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland ----------------------------- From: jeff@mcnc.UUCP (Jeffrey Copeland) Subject: Re: bug using doublebox in tbl with ditroff Date: 17 Jul 85 13:01:53 GMT To: unix-wizards@brl-tgr.arpa Your problem with tbl and ditroff sounds more like the line drawing characters aren't tuned correctly. The four characters, em, rn, ul, and ru should all meet at their ends, so horizontal lines can be drawn. The vertical character br should meet the rn on the top and the ul on the bottom. ul should run under the baseline; ru at the baseline. If the characters are tuned properly, the "smallest possible constructed box", \(br\z\(rn\(ul\(br (see Troff User's Man, sect 12.2) will have corners that match. ----------------------------- From: larry@kitty.UUCP (Larry Lippman) Subject: Re: System V vs. BSD Date: 18 Jul 85 04:18:10 GMT To: unix-wizards@brl-tgr.arpa > I am curious about the number of sites using BSD as opposed > to the number of sites using System V. > > Send me mail. I love mail. > -- > > Alan Fargusson. > > { ihnp4, amdahl, mot }!drivax!alan We are strictly System V. Our Usenet site is an AT&T 3B2 (which was a real trip installing the Usenet software). We also use Unisoft System V on 68010-based VME-bus machines. ----------------------------- From: dce@hammer.UUCP (David Elliott) Subject: Re: National Semi announces 4.2 BSD :-) Date: 17 Jul 85 16:57:36 GMT To: unix-wizards@brl-tgr.arpa In article <399@spar.UUCP> malcolm@spar.UUCP (Malcolm Slaney) writes: >The following is being typed in on my Sun Workstation running 4.2BSD. It >is offered without comment..... > >Today's EE Times has the following story in today's issue: > National Offers 4.2 Unix on 32-Bit uP by Stan Baker > > Santa Clara, CA - National Semiconductor Corp. is now > offering Genix 4.2, its port of the Berkeley 4.2 BSD Unix > operating system, for the company's 32000 32-bit microprocessor > line. > > This is the first port of the Berkeley 4.2 version for a > microprocessor. And for the first time, it brings local-area > networking on Unix to microprocessors. The system is aimed at > designers of high-end engineering workstations Tektronix announced the 6000 Series workstations 10 months ago. These workstations run UTek, which is based on 4.2BSD with many of the features of System V, and are based on the NSC 32000 microprocessor line. Not only is National not the first company to port 4.2BSD to a micro, they *probably* aren't even the first to port it to their own micro. David Elliott Graphics Workstations Division Tektronix, Inc. tektronix!tekecs!dce ----------------------------- From: jsq@im4u.UUCP Subject: Re: Vax 4.2 UDP Bradcast woes followup.. Date: 18 Jul 85 23:41:23 GMT To: unix-wizards@brl-tgr.arpa Note that the 4.3BSD subnet scheme is not that of RFC936 (the former Berkeley scheme) nor that any of the other three (four?) competing schemes, but something new that's pretty close to RFC940 (the supposed standard). Unfortunately, every host on a subnet that wants to talk to hosts on other subnets of the same network must have at least a small hack to its networking software to know about subnets. -- John Quarterman, jsq@ut-sally.ARPA, {ihnp4,seismo,ctvax}!ut-sally!jsq ----------------------------- From: nancy@resonex.UUCP (Nancy Blachman) Subject: Dump(8) and the Modified Tower of Hanoi Date: 18 Jul 85 00:28:50 GMT Keywords: dumps, tower of hanoi, backups To: unix-wizards@brl-tgr.arpa The UNIX manual page for dump(8) suggests dumping a file system according to a modified Tower of Hanoi algorithm. If you know how the sequence suggested, i.e., 0 3 2 5 4 7 6 9 8 relates to the Tower of Hanoi algorithm, would you please write to me and tell me. The Tower of Hanoi algorithm is the sequence required to move rings of different sizes from one peg of three pegs to another with the restriction that no ring may lie on top of a smaller ring. Do you know who invented the Tower of Hanoi? /\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\/ Nancy Blachman UUCP: {hplabs,ihnp4,ucbvax!sun}!resonex!nancy (408) 720 8600 x37 ARPA: nancy@riacs.ARPA ----------------------------- From: phil@amdcad.UUCP (Phil Ngai) Subject: Re: Xenix Shared Data Bugs (and friends) Date: 18 Jul 85 18:13:28 GMT To: unix-wizards@brl-tgr.arpa In article <183@medstar.UUCP> robin@medstar.UUCP (Robin Cutshaw) writes: > >As usual, this posting relates to IBM Xenix 1.0 for the PC/AT... > >On the previous posting reguarding the "Panic Kernel (easy to do)", IBM has >really shown their colors. The jist of the article was that if you call >getcwd() between sdenter() and sdleave() you will get a kernel panic (if you >have stdio.h included and a few other things). IBM's official response to >this is "SEE PAGE 2-194 of the Software Command Reference where it says 'system >calls should be avoided between sdenter and sdleave calls'". This is their >only response! So now everyone who doesn't read and follow the directions on >page 2-194 will be able to easily panic and crash the Xenix kernel. Why are you using sdenter if you haven't read the man page for it? Or is reading two whole pages of documentation too much effort? -- ----------------------------- End of UNIX-WIZARDS Digest **************************