UNIX-WIZARDS Digest V1#110
Mike Muuss
Unix-Wizards-Request at BRL.ARPA
Wed Jul 24 19:45:47 AEST 1985
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 at wdl1.UUCP
Subject: Re: extracting files with tar can corrup
Date: 15 Jul 85 23:57:13 GMT
Sender: notes at wdl1.UUCP
Nf-ID: #R:sdcc3:-293900:wdl1:64000002:000:157
Nf-From: wdl1!jbn Jul 15 15:08:00 1985
To: unix-wizards at 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 at wdl1.UUCP
Subject: Re: Vax 4.2 UDP Bradcast woes followup..
Date: 15 Jul 85 23:57:26 GMT
Sender: notes at 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 at 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 at druil.UUCP (WilliamsonK)
Subject: Question about spl() levels in clock.c
Date: 15 Jul 85 22:20:32 GMT
To: unix-wizards at 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 at cuae2.UUCP (Ron Heiby)
Subject: Re: Speeding up the 3B2...
Date: 16 Jul 85 03:09:22 GMT
To: unix-wizards at brl-tgr.arpa
In article <292 at timeinc.UUCP> greenber at 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 at cuae2.UUCP (via ihnp4)
AT&T-IS, /app/eng, Lisle, IL (312) 810-6109
-----------------------------
From: greenber at timeinc.UUCP (Ross M. Greenberg)
Subject: Re: Speeding up the 3B2...
Date: 16 Jul 85 15:02:11 GMT
To: unix-wizards at 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 at 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 at brl-tgr.arpa
In article <2424 at sun.uucp> gnu at 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 at mit-athena.ARPA
-----------------------------
From: guy at sun.uucp (Guy Harris)
Subject: Re: Need help preserving permissions when using tar?
Date: 17 Jul 85 08:10:25 GMT
To: unix-wizards at 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 at 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 at 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 at investor.UUCP (Bob Peirce)
Subject: Re: Idle time logout mechanism (daemon)
Date: 17 Jul 85 17:44:57 GMT
To: unix-wizards at 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 at investor.UUCP (Bob Peirce)
Subject: Re: Idle time logout mechanism (daemon)
Date: 17 Jul 85 18:49:39 GMT
To: unix-wizards at 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 at 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 at 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 at umcp-cs ARPA: chris at maryland
-----------------------------
From: jeff at mcnc.UUCP (Jeffrey Copeland)
Subject: Re: bug using doublebox in tbl with ditroff
Date: 17 Jul 85 13:01:53 GMT
To: unix-wizards at 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 at kitty.UUCP (Larry Lippman)
Subject: Re: System V vs. BSD
Date: 18 Jul 85 04:18:10 GMT
To: unix-wizards at 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 at hammer.UUCP (David Elliott)
Subject: Re: National Semi announces 4.2 BSD :-)
Date: 17 Jul 85 16:57:36 GMT
To: unix-wizards at brl-tgr.arpa
In article <399 at spar.UUCP> malcolm at 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 at im4u.UUCP
Subject: Re: Vax 4.2 UDP Bradcast woes followup..
Date: 18 Jul 85 23:41:23 GMT
To: unix-wizards at 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 at ut-sally.ARPA, {ihnp4,seismo,ctvax}!ut-sally!jsq
-----------------------------
From: nancy at 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 at 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 at riacs.ARPA
-----------------------------
From: phil at amdcad.UUCP (Phil Ngai)
Subject: Re: Xenix Shared Data Bugs (and friends)
Date: 18 Jul 85 18:13:28 GMT
To: unix-wizards at brl-tgr.arpa
In article <183 at medstar.UUCP> robin at 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
**************************
More information about the Comp.unix.wizards
mailing list