Sun-Spots-Request@RICE.EDU (William LeFebvre) (04/01/88)
SUN-SPOTS DIGEST Thursday, 31 March 1988 Volume 6 : Issue 39
Today's Topics:
Administrivia
Re: 'rexd' is 'on' something (2)
Re: Problems reading others' TAR tapes on a SUN (2)
Re: Adding a cgtwo to a 3/75M
Re: Questions about 256 entry colormap
Re: What does "Restricted" mean (2)
Re: More than one dump on a 1/4 inch cartridge tape? (3)
Interphase 4200 disk controllers and Systech MTI serial boards?
Two displays on a 3/60FC?
Converting a 2/170 TTL monitor to ECL?
Send contributions to: sun-spots@rice.edu
Send subscription add/delete requests to: sun-spots-request@rice.edu
Bitnet readers can subscribe directly with the CMS command:
TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are stored on "titan.rice.edu". For volume X, issue Y,
"get sun-spots/vXnY". They are also accessible through the archive
server: mail the word "help" to "archive-server@rice.edu".
----------------------------------------------------------------------
Date: Thu, 31 Mar 88 13:27:59 CST
From: William LeFebvre <phil@Rice.edu>
Subject: Administrivia
The backlog must be cleared. To date, my half-hearted efforts have done
very little to alleviate this problem. So, I am going to start putting a
real push on getting many digests out in less time. What I would like to
do (time permitting) is put out two or three digests a day, while cutting
back on the size of each digest to around 15K. I hope to start out with
three a day until I see that the backlog is clearing out, then cut back to
two a day until I am caught up. This has gone on far too long. I
apologize to one and all for letting this situation continue.
The Usenet readership is getting antsy again about the moderated and
digested format. I have read the comments in the news group "news.groups"
and have responded to them. Those Usenet readers who are intersted in my
ideas concerning the future of "comp.sys.sun" can read them in
"news.groups". I will scan that group periodically to look for reactions
and additional suggestions.
William LeFebvre
Department of Computer Science
Rice University
<phil@Rice.edu>
------------------------------
Date: Mon, 21 Mar 88 18:51:38 CST
From: vixen!ronbo@cs.utexas.edu (Ron Hitchens)
Subject: Re: 'rexd' is 'on' something (1)
Reference: v6n31
In v6n31 grunwald@m.cs.uiuc.edu (Dirk Grunwald) describes how he lost 80%
of a partition on his server because a find intended to clean up /tmp on a
client snuck into the server through a remote mount that rexd made in /tmp
on the client. I must admit I find this kind of amusing, though I know I
wouldn't be laughing if it happened to me. He concludes with:
> Two solutions to this are:
> 1) Don't use 'on' or 'rexd'
> 2) Have 'rexd' mount partitions somewhere else /rexd/rexdXXXX?
The proper solution is to read the man page for find which will tell you
how to prevent find from traversing NFS mounts. The final example in the
man page is:
> To remove files beneath your home directory named `a.out' or
> `*.o' that have not been accessed for a week and that aren't
> mounted using NFS:
> angel% cd
> angel% find . \( -name a.out -o -name '*.o' \) -atime +7 -exec rm {} \; -o -fstype nfs -prune
For the purposes of cleaning up /tmp, as described in the original
article, the proper find command would be:
find /tmp -atime +3 -exec rm {} \; -o -fstype nfs -prune
I must point out that running find to cleanup /tmp by removing anything
older than three days is not standard, Sun didn't set it up that way, it
must be a local hack. It's also not necessarily a good thing to do. The
/tmp directory is cleaned out at boot time, and can be tidied up by hand
if it gets too clogged.
Dirk mentions that rexd did not remove the temporary directory in /tmp
that it used for a mount point after it was finished. Rexd normally does
clean up after itself, it probably didn't clean up that time because find
had already tranversed into that directory when rexd tried to clean up.
Rexd wouldn't have been able to dismount the NFS filesystem or remove the
temp directory if find was down in there.
I guess this little catastrophe serves to prove my favorite truism:
"The most innocent looking hack can blow you head clean off."
Ron Hitchens ronbo@vixen.uucp hitchens@cs.utexas.edu
------------------------------
Date: Tue, 22 Mar 88 7:56:47 GMT
From: James Davenport <jhd%maths.bath.ac.uk@nss.cs.ucl.ac.uk>
Subject: Re: 'rexd' is 'on' something (2)
Reference: v6n31
I thought I posted something to the net on this, but can't find it.
This is a "well-known" pit-fall. "on" will leave file systems mounted in
/tmp, and the usual /tmp purger will then cause chaos. The solution we
adopt is to use the -xdev qualifier in /tmp, as in:
59 4 * * * find /tmp -xdev -atime +3 -exec rm -f {} \;
James Davenport - jhd@uk.ac.bath.maths
[[ Thanks also to dupuy@columbia.edu and nesheim@think.com for posting
similar suggestions. --wnl ]]
------------------------------
Date: 22 Mar 88 16:47 EST
From: stpeters%dawn.tcpip@ge-crd.arpa
Subject: Re: Problems reading others' TAR tapes on a SUN (1)
Reference: v6n34
The problem may not be hardware but rather one of different QIC formats on
the catridge tapes.
As Dave Elliott of Mips (dec@mips.com) put it recently:
"The various QIC formats all have their place. Some pack data better when
you stream. Some pack data better when you don't. Some allow unblocked
reads and writes. Most are incompatible."
According to Dave's posting, there are even variations on the QIC's, used
for reasons of performance. It appears that any inter-vendor
compatibility is, at this point, essentially accidental.
Dick St.Peters
GE Corporate R&D, Schenectady, NY
stpeters@ge-crd.arpa
uunet!steinmetz!stpeters
[[ I was informed by someone here at Rice "in the know" that the different
QUIC formats is almost certainly the cause of the mentioned problems.
Sorry to mislead everyone. I am not as familiar with cartridge tapes as I
am with mag tapes. --wnl ]]
------------------------------
Date: Tue, 22 Mar 88 09:11:43 PST
From: weiser.pa@xerox.com
Subject: Re: Problems reading others' TAR tapes on a SUN (2)
Reference: v6n34
Did you try reading them from both /dev/rst0 and /dev/rst8? These read in
diffrent formats, and I have sometimes been able to read tapes with one
but not the other.
-mark
------------------------------
Date: Fri, 18 Mar 88 10:52:37 EST
From: jas@monk.proteon.com (John A. Shriver)
Subject: Re: Adding a cgtwo to a 3/75M
Reference: v6n30
While the Sun-3/75 is low on power, it is even lower on cooling. This is
probably why you don't want to put a cgtwo board in it. Anything oomphier
than a SCSI board will probably die of heat prostration, or cause the CPU
card to do so. One of the goals of the Sun-3/110 chassis was to solve the
power and cooling restrictions of the Sun-[23]/75 chassis.
------------------------------
Date: Fri, 18 Mar 88 14:00:46 CST
From: carols@ncsa.uiuc.edu (Carol Song)
Subject: Re: Questions about 256 entry colormap
Reference: v6n25
This is to answer the question posted in sun-spots (text enclosed in
below).
Yes, it is possible to have the canvas and the panel share the same 256
entry colormap. The following is what I use in my code:
/* cmsname = string of chars specifying a color segment name
* panel = Panel
* canvas = Canvas
*/
Pixwin *pixw;
char red[256], green[256], blue[256];
/* red, green and blue contain the 256 entry colormap */
/* set canvas and panel to the same colormap */
pixw = (Pixwin *) window_get(panel, WIN_PIXWIN);
pw_setcmsname(pixw,cmsname);
pw_putcolormap(pixw,0,256,red,green,blue);
pixw = canvas_pixwin(canvas);
pw_setcmsname(pixw,cmsname);
pw_putcolormap(pixw,0,256,red,green,blue);
Hope this helps!
Carol X. Song UUCP: uiucdcs!song
NCSA @ U of Illinois at U-C ARPANET:carols@ncsa.uiuc.edu
605 E Springfield Ave BITNET: 12002@ncsavmsa.bitnet
mpaign, IL 61820 ATT: (217) 244-1958
------------------------------
Date: Tue, 22 Mar 88 14:09:34 EST
From: lear@aramis.rutgers.edu (eliot lear)
Subject: Re: What does "Restricted" mean (1)
Reference: v6n32
This sounds very much like you are running into a restricted shell
problem. Check to make sure that the shell on your server for root does
not have an ``r'' in its name. If you find an ``r'' change your shell.
Also check your environment to see if RSH is set. (Unset if it is...)
Good Luck...
Eliot Lear
[lear@rutgers.edu]
------------------------------
Date: Wed, 23 Mar 88 12:07:56 +0100
From: Marc Shapiro <mcvax!inria.inria.fr!shapiro@uunet.uu.net>
Subject: Re: What does "Restricted" mean (2)
Reference: v6n32
You're right! Our normal login shell is the t-csh which is named
/bin/csh, and the super-user runs the original csh, which is /bin/csh.org!
Good old System V hackery, I suppose. I would have never thought of that
one.
Thanks again.
Marc Shapiro
INRIA, B.P. 105, 78153 Le Chesnay Cedex, France. Tel.: +33 (1) 39-63-53-25
e-mail: shapiro@inria.inria.fr or: ...!mcvax!inria!shapiro
------------------------------
Date: Sun, 20 Mar 88 11:28:26 EST
From: umix!lokkur!scs@rutgers.edu (Steve Simmons)
Subject: Re: More than one dump on a 1/4 inch cartridge tape? (1)
Reference: v6n29
darkstar!brian@uc.msc.umn.edu (Brian Utterback) writes in v6n29:
> I am trying to take dumps with this tape, but unfortunately, I can only
> seem to get one dump per tape.
Several suggestions: first, use nrst8. The 'n' in the name prevents
rewind, the '8' means use QIC-24 format (denser) not QIC-11. You'll need
to set the density switches on the dump command appropriately (sorry, I
have access to neither my manual or system right now). Then write your
dump script to dump your larger partition first to /dev/nrst8, then your
smaller. With nrst0, he end result would be /usr on 2.13 tapes and /
following after the .13. But watch carefully how much tape gets used when
you switch to nrst8!!!! I back up 2 70Mb disks (three partitions of 7Mb,
46Mb, and 70Mb) onto two tapes with no problem, but its at least possible
for me to blow things away if either the 46Mb or the 70Mb gets too full --
just can't quite get 7+46 Mb onto one tape if completely full.
If you're really curious, nudge me when I get back to work next week and
I'll send my dump script -- it's only 8 lines or so.
------------------------------
Date: 22 Mar 88 01:16:59 GMT
From: Rick Lindsley <richl@penguin.uss.tek.com>
Subject: Re: More than one dump on a 1/4 inch cartridge tape? (2)
Reference: v6n29
You don't say what errors you get, but my guess is that you are hitting
physical end-of-tape before dump expects you to. Try shortening the
alleged "size" of the tape through the s option, so that dump will move to
the next volume before you hit physical EOT.
A related problem could be that dump is moving to the next volume before
it should, wasting some of the tape. The "proper" magical incantation was
discussed before in this digest, but I don't recall it. (I could tell you
what I use -- blocking factor 126, size of tape 5000 ft) but I have no
dumps that reach end of tape so mine is not accurately tested.
Rick
------------------------------
Date: Mon, 21 Mar 88 17:59:32 CST
From: vixen!ronbo@cs.utexas.edu (Ron Hitchens)
Subject: Re: More than one dump on a 1/4 inch cartridge tape? (3)
Reference: v6n29
There is no problem putting multiple dumps on one cartridge tape, you
simply have to specify the no-rewind tape device when you do the dump,
either /dev/nrst0 or /dev/nrst8. It gets tricky when you try combining
multiple dumps which might overflow the tape. Dump counts how many blocks
it has written to decide when the tape is full, if you start part way down
the tape, and dump thinks it has a full tape to work with, it will puke if
it hits the end. Believe me, it's not worth trying to figure out clever
schemes to fool dump, start a new tape if you aren't sure it will all fit
on the end of the tape.
I would question the need to do backups the way you're describing. It
would be more logical to take full level 0 dumps just once, then do daily
incrementals. The daily incrementals will contain only the files which
have changed since the full level 0 dump. You can change quite a lot of
stuff and still have it fit comfortably on one tape. The standard
approach would be like this:
Do a level 0 dump of / on one tape
Do a level 0 dump of /usr on another set of tapes
Label and date these tapes and put them on a shelf in a safe place,
like in a computer room, where they won't get damaged or lost.
Once a day, do a level 9 dump of both filesystem onto one tape,
preferably just before you leave for the day (don't leave it for
for the next morning, the disk vampyres can get your disk while
it sleeps). If you're really paranoid, you can run your daily
backups when you go to lunch also.
When you make large-scale changes to one of your disk partions, such as
upgrading to a new release, go back and start over at the top of the
list. It's a good idea to use a new set of tapes for the level 0
dumps, in case something goes wrong. The third time around you can
reuse the tapes from the first time and alternate from there on.
The above scheme would require a minimum of 5 tapes (one for root, three
for /usr and one for dailies). You can save a tape without much risk by
not doing a level 0 dump of the root. In that case you'll wind up making
a full dump of the root onto the daily tape each day, which is no biggie
if it's the standard 7-8 meg. Root can usually be rebuilt without too
much pain from the distribution tapes even with no dumps at all. This is
the way I work things on my home 3/60C with two scsi drives. I just leave
the daily incremental tape in the drive and run a daily dump script
(included below) when I finish a day of hacking. It's been a couple of
months since a full backup, I've done a LOT of hacking, and the dailies
still only fill up about half the tape.
Ron Hitchens ronbo@vixen.uucp hitchens@cs.utexas.edu
My dailydump script:
____________________
#!/bin/sh
filesystems="/ /usr /u1"
tape=/dev/nrst8
block=20
size=3850
if [ `whoami` != root ] ; then
echo "You gotta be root to do the backups"
exit 1
fi
echo ""
echo -n "Is the tape ready to go? [yn] "
read ans
if [ "$ans" != "y" ] ; then
echo "Get your act together, hoser"
exit 1
fi
clear
echo ""
echo "Doing daily dumps for $filesystems"
date
echo ""
mt -f $tape rew
for i in $filesystems ; do
dump 9ucbsf $block $size $tape $i
echo ""
echo ""
done
echo "rewinding $tape"
mt -f $tape rew
------------------------------
Date: Sat, 19 Mar 88 00:36:15 MST
From: donn@cs.utah.edu (Donn Seeley)
Subject: Interphase 4200 disk controllers and Systech MTI serial boards?
I'm trying to track down a curious problem. If you are using a Sun-3 with
an Interphase 4200 VME disk controller and Systech MTI serial boards (sold
by Sun), I'd love to compare notes with you. Do me a favor and send me
mail or give me a call if your box has this combination of hardware.
Pleez?
Donn Seeley University of Utah CS Dept donn@cs.utah.edu
40 46' 6"N 111 50' 34"W (801) 581-5668 utah-cs!donn
------------------------------
Date: Fri, 18 Mar 88 09:35:24 PST
From: chaos%gojira.Berkeley.EDU@jade.berkeley.edu
Subject: Two displays on a 3/60FC?
We purchased a 3/60FC with the understanding that it could run both a
monochrome and a color display off of its two frame buffers. It comes
configured as a 10 bit color display: 8 bits of color, 1 bit B&W, and 1
bit overlay. We are willing to give up depth for real estate.
A call to Hardware Support netted: 'It is possible, but Sun does not
support that configuration. You are on your own.'
Without documentation, I certainly am. Has anyone succeeded in this
configuration? Does anyone have relevant information? What documentation
is required to get this to work?
Jim Crutchfield
Physics
UC Berkeley
(415) 642-1287
------------------------------
Date: Fri, 18 Mar 88 09:39:23 PST
From: chaos%gojira.Berkeley.EDU@jade.berkeley.edu
Subject: Converting a 2/170 TTL monitor to ECL?
We have an extra 2/170 monitor that we would like to drive from a Sun 3
video display. The former takes TTL video in, the latter outputs ECL
video. Can the 2/170 monitor be converted to take the ECL video? Is this
just a level change? I noticed that the 2/170 syncs just fine to the ECL
video sync.
Jim Crutchfield
Physics
UC Berkeley
(415) 642-1287
------------------------------
End of SUN-Spots Digest
***********************