Sun-Spots Digest, v6n29
William LeFebvre
Sun-Spots-Request at RICE.EDU
Wed Mar 16 15:06:29 AEST 1988
SUN-SPOTS DIGEST Tuesday, 15 March 1988 Volume 6 : Issue 29
Today's Topics:
Administrivia
Re: Disk Setup on Server
Re: Where to put swap partition for clients running CLisp
Re: vt100 emulator
Re: Problem uudecoding 'calc'
Sun 386
WORM, Tape archiving info sought
reading mouse clicks from shell?
VT640 tool?
Anyone have the 900 Mbyte Disk Drive?
Changing a scsi shoebox from 0 to 1?
More than one dump on a 1/4 inch cartridge tape?
Using RAM as disk?
sendmail.cf--name server interaction problem & suggested fix (long)
Send contributions to: sun-spots at rice.edu
Send subscription add/delete requests to: sun-spots-request at 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 at rice.edu".
----------------------------------------------------------------------
Date: Tue, 15 Mar 88 14:54:07 CST
From: William LeFebvre <phil at Rice.edu>
Subject: Administrivia
How many times has someone said "it's so hard to find a specific message
in the archived digest issues"? Well, I have a solution. I finally took
the time to create automatically generated "master indexes". There are
now two additional files in the archives that contain Subject line and
volume/issue number for every article: one for volume 5 and one for
volume 6 (the latter will get updated periodically). They are sorted by
the contents of the Subject field. This is not a sophisticated
keyword-retrieval system by any means. I made no attempt to generalize
the content of each article into a few keywords. But it does provide you
with the data to do your own keyword searching (by just searching through
the file if nothing else). The files are stored in the "sun-spots"
section of the archives under the names "v5.index" and "v6.index". They
are currently 47499 and 18731 bytes respectively (the latter amount will
increase with time). I hope that this helps alleviate the problem of
finding information in the back issues.
Also, Volume 5 issue 10 is now a proper-looking digest. Originally it was
missing the digest information at the front, but I had to add that back to
get the automatic index generator to work correctly.
Finally, I have taken the liberty to add an extra field to the header of
each message in the digest: the "Reference" field. For a message that is
in response to another, this field will contain the volume and issue
number of the digest in which the original message appeared.
William LeFebvre
Department of Computer Science
Rice University
<phil at Rice.edu>
------------------------------
Date: Tue, 1 Mar 88 00:40:12 EST
From: mcgrew at topaz.rutgers.edu (Charles)
Subject: Re: Disk Setup on Server
Reference: v6n21
I'd suggest something like this:
swap space for your 3/60's - 25-30, unless you plan to use one as a
'lisp-engine' or something.
root partitions for client - the 7 meg default is ok - we get away with
less than 2 by simlinking most of /etc on the client to /pub/etc (a copy
of the client's /etc on the server), and mounting /usr/client/tmp/hostname
as /tmp for space and nsf-speed reasons.
root partitions for server - the 7 meg default is usually ok (especially
since /bin and /lib point of to /pub; but with all that disk space, why
not make it 10?
swap space for the server - the 17 meg default for the server is ok (but
with all that space, 25-30 is cheap), unless you want to put real users on
it (which is probably a bad idea), in which case up to 75 Meg. is
desirable.
Hope this helps,
Charles
------------------------------
Date: Tue, 1 Mar 88 00:47:15 EST
From: mcgrew at topaz.rutgers.edu (Charles)
Subject: Re: Where to put swap partition for clients running CLisp
Reference: v6n21
If all you've got is 4 suns on this network, I wouldn't worry about
overrunning the net with swapping. Its my opinion that its not very
different to have a scsi disk vs. the net - scsi disks are SLOW. I'd
suggest you just use the net, and spend the money on extra memory.
Charles
------------------------------
Date: Mon, 29 Feb 88 15:50:50 EST
From: Edward L. Lafferty <ell%linus at mitre-bedford.arpa>
Subject: Re: vt100 emulator
[ Note for version 3.4: There has been a rearrangement of files within
the library libsuntool.a in version 3.4 which prevents the makefile in
libdir from working correctly. Until I can get the sources to fix this you
will have to find a library from 3.2 to compile with. If you can't get
one, I have put one in the ftp/pub/version3.2 directory below under the
name nlibsuntool.a. (It is large, so don't ftp it if you don't have to.) ]
There is now a source port of vt100tool to sun-3 running version
3.2(3.0). It can be accessed via anonymous FTP via arpanet as follows:
1. FTP to mitre-b-ed (192.12.120.58)
2. login as anonymous (password: anonymous)
3. get pub/version3.2/* <read the manual pages for FTP for how to do
this>
4. Make sure that your fonts are in /usr/local/lib/fonts/vtfonts since
this has been compiled into this version.
5. Make sure that you set the "binary" option in FTP for the .o files.
You will need as a minimum the following (depending on whether you want to
just run it, whether you have the original distribution, etc):
If you have the original distribution including the fonts and you just
want to run the tool just get the compiled version and run it:
get pub/version3.2/vt100tool
If you have the fonts and want to recompile the tool:
get pub/version3.2/* and pub/version3.2/libdir/*. Run make in the two
directories.
If you don't have the fonts either:
get pub/version3.2/*, pub/version3.2/libdir/* and
pub/version3.2/fontdir/*. Run make in the two directories and install
the fonts in the correct place.
..and there you are.
If you have trouble, send mail and I'll try to help.
There have been a few new changes (after 1 July 1987) so you might want to
recopy if you got it earlier.
Regards,
Ed
<ell at mitre-bedford.ARPA>
<ell at linus.UUCP>
[[ Before everyone asks, I will try to place a copy in the archives when I
get the chance. --wnl ]]
------------------------------
Date: Tue, 15 Mar 88 14:54:07 CST
From: William LeFebvre <phil at Rice.edu>
Subject: Re: Problem uudecoding 'calc'
Reference: v6n27
Turns out that the problem with the 'calc' utility has to do with
uninvertible EBCDIC-ASCII translations. If you try to send a uuencoded
file through a site that speaks EBCDIC, it will translate the message to
EBCDIC on the way in and back to ASCII on the way out and in the process
alter some of the characters. The only reasonable solution is to send it
along a different path. I have been told that the source to the
calculator and the Russel compiler will be available in about a month, but
will likely be too large to distribute via the archive service.
William LeFebvre
<phil at Rice.edu>
------------------------------
Date: Mon, 29 Feb 88 23:19:57 -0500
From: Steve Dyer <dyer at spdcc.com>
Subject: Sun 386
>From Computerworld 2/29/88:
Sun Microsystems, Inc. will reveal in early April its long-awaited
80386-based microcomputer, able to run both Microsoft Corp.'s MS-DOS and
Sun's UNIX-based SunOS operating system, according to Sun.
The system, codenamed Roadrunner, will be available in two versions,
offering 20- and 25-mhz clock speeds, those sources said. A basic
configuration will offer 8M bytes of memory, expandable to 32M bytes.
Entry-level pricing for the Sun 386 will be set at about $8000, sources
said.
Sun Chainman and Chief Executive Officer Scott McNealy declined to comment
on the system.
Phoenix Technologies Ltd., sources said, provided Sun with a software
coprocessor, allowing DOS sessions to be run under Unix through a
combination of board-level hardware as well as software. It enables
workstations with incompatible operating systems like Unix to simulate a
complete IBM Personal Computer environment so that they can run PC based
applications.
The system is currently being betatested by Sun end-users and OEM's.
Sun's Intel Corp. 80386-based system, the company's first Intel-based
machine, was developed first at its Billerica, Mass., division. The
system has been ready for several months but was delayed while company
officials wrestled with positioning issues, sources said.
...
Initially, Sun will remarket the system primarily through value- added
resellers, thereby avoiding direct competition with IBM PC-compatible
makers like Compaq Computer Corp., that sell directly through retail
channels. Last November, Sun launched its VAR program. The number of
VAR's qualified under that program remains undisclosed.
...
------------------------------
Date: Tue, 1 Mar 88 09:22:08 pst
From: ucbcad!island!daniel at ucbvax.berkeley.edu (Dan Smith)
Subject: WORM, Tape archiving info sought
I would like to hear of experiences people are having with WORM drives for
the Sun. The company I work for is going to be evaluating one for archival
purposes. I am also interested in 8mm tape backup systems. Please reply
to me, and I'll summarize. Thanks!
dan
dan smith, island graphics, marin co, ca
uucp: {ucbvax!ucbcad,sun}!island!daniel
uucp: pixar!unicom!daniel, well!daniels
Phones: 332 FAST (H), 332 EASY (H), 491 1000 (W)
------------------------------
Date: 29 Feb 88 06:25:03 GMT
From: mkhaw at teknowledge-vaxc.arpa (Mike Khaw)
Subject: reading mouse clicks from shell?
I have an application that I'd rather write as a shell script than a C
program, for which I'd like the script to solicit and respond to a mouse
click in a manner analogous to "read" in /bin/sh or "set foo = $<" in csh.
Any simple way to do this?
Thanks,
Mike Khaw
internet: mkhaw at teknowledge-vaxc.arpa
usenet: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa
USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
------------------------------
Date: Mon, 29 Feb 88 23:56:40 EST
From: sundance at life.pawl.rpi.edu
Subject: VT640 tool?
Is there a vt640 retrographics emulator for SUN UNIX 4.2 (rel 3.3)?
Tektool is too bulky for most of the things I need to do and I need a
VT100 emulator for text.
------------------------------
Date: Tue, 1 Mar 88 12:00:49 EST
From: sunvice!cordis!gls at sun.com (Gls Gary_Schaps_2157)
Subject: Anyone have the 900 Mbyte Disk Drive?
I would appreciate the chance to contact anyone who has ordered/installed
the new 900 Mbyte disk drive.
Gary L. Schaps Voice: (305) 551-2157 / 800-327-2490 ext. 2157
Cordis Corporation
P.O. Box 025700 ML7A E-mail: sun!sunvice!cordis!gschaps
Miami, FL 33102-5700 gatech!codas!novavax!cordis!gschaps
------------------------------
Date: 1 Mar 88 17:47:02 GMT
From: sun!rtech!llama!sid at ucbvax.berkeley.edu (Sid Shapiro)
Subject: Changing a scsi shoebox from 0 to 1?
I've got several 3/60s with one shoebox each. I've just acquired several
maxtor shoeboxes and I'd like to add them in. I expect I've got to
re-jumper the sun shoebox so that they are addressed as scsi 1 instead of
0 (or whatever). Does anybody know how to do this?
Thanks,
/ Sid /
------------------------------
Date: Tue, 1 Mar 88 15:47:40 EST
From: darkstar!brian at uc.msc.umn.edu (Brian Utterback)
Subject: More than one dump on a 1/4 inch cartridge tape?
Does anyone have any information about using the 1/4 cartridge tapes? I
am trying to take dumps with this tape, but unfortunately, I can only seem
to get one dump per tape. I have a 141 Mb disk, partioned into / and
/usr. / takes 13% of one tape and /usr take 2.13 tapes. I therefore need
4 tapes where I should be able to use 3 tapes and have a comfortable extra
on the last tape.
Also, is there any way to make an archive of several areas on this kind of
tape? I would like to archive my copies of Sun-Spots, TeXHaX and also
/usr/local/src, but I can't afford to devote several tapes to the effort.
Is there any way that I can write them to tape and then add things later
without reading the whole tape and copying to a new tape. I would even
consider this if it did not require having the whole tape on disk. I
guess what I am saying is that I have very little disk space left, and I
cannot afford many tapes.
Brian Utterback |UUCP:{ihnp4!cray,sun!tundra}!hall!blu
Cray Research Inc. |ARPA:blu%hall.cray.com at uc.msc.umn.edu
One Tara Blvd. #301 |
Nashua NH. 03062 |Tele:(603) 888-3083
------------------------------
Date: Tue, 1 Mar 88 15:10:41 PST
From: richk at larry.cs.washington.edu (Richard Korry)
Subject: Using RAM as disk?
We (will) have 3 Sun 3/60s with 12Mb of memory hanging diskless off a
3/280 fileserver/timesharing machine. Is it reasonable to allocate some
percentage of the memory to be data ram (i.e. act like a disk) in order to
reduce the disk requests to the server? Specifically, I was thing that
the intermediate files of 'cc' could be stashed locally. Has this been
done and is it worth the hassle? Is there public domain code around to
hack the kernel to do this? thanks.
rich
------------------------------
Date: Mon, 29 Feb 88 17:39:00 PST
From: Doug Moran <moran at ai.sri.com>
Subject: sendmail.cf--name server interaction problem & suggested fix (long)
[[ For those of yo uwho do not care about this subject, this long message
is the last one of the digest. --wnl ]]
Synopsis:
=========
Attempts to send mail to a Sun from a remote site fails with the sender
getting the error message "I refuse to talk to myself" from sendmail on
the Sun. This problem does not occur from all remote sites or for all
Suns on the network. The critical factors in determining failure seems to
be that the remote mailer is NOT sendmail, and that the recipient Sun is a
host that is not likely to be in the Internet host table (e.g., it is a
recent arrival).
I am neither a sendmail nor an SMTP wizard. I have customized and
debugged a few sendmail.cf files. This is simply a report of what appears
to be happening and a report of a fix that I made that seems to handle the
problem.
The sections on "Cast of Players" and "Diagnosis" can be skipped if you
are interested only in the fix.
The Cast of Players:
====================
sri.com: a "remote" TOPS-20 host
ai.sri.com: our subdomain, also the host name for the name server
for our subdomain
pebble: a recently arrived Sun whose Internet number is 192.12.5.67
wedge: another recently arrived Sun
stinson: an "old" Sun
random: a fake user that we use in testing mail
Although "sri.com" is a host at our site, its connection to our subnet is
via a slow, heavily loaded link on which time-outs are common. This
connection is used as an approximation to connecting to a remote host over
the ARPAnet.
"stinson" has been on-site for several years and its name was part of the
Internet host table distributed prior to the switch to using name servers.
It is not known to have ever suffered from the problem described below.
"pebble" and "wedge" arrived after the switch to using name servers. Both
suffered from the problem described below. The fix described below has
been tested by installing it on "wedge" and noticing that the problem
persists for "pebble" but does not reoccurred on "wedge". "stinson" and
"pebble" are using the exactly the same sendmail.cf file.
Diagnosis
=========
I sent a message to user "random" on all three Suns listed above via
"sri.com" (same effect if sent directly from "sri.com")
mail random%pebble.ai.sri.com at sri.com \
random%wedge.ai.sri.com at sri.com \
random%stinson.ai.sri.com at sri.com
...
The relevant portion of the error message produced by the unsuccessful
attempt to deliver mail to pebble is:
----- Transcript of session follows -----
>>> HELO pebble
<<< 553 pebble I refuse to talk to myself
554 <random@[192.12.5.67]>... Service unavailable
----- Unsent message follows -----
Received: from KL.SRI.COM by pebble (3.2/4.16)
id AA05732 for random at pebble.ai.sri.com; ...<date>...
The message was delivered on both wedge and stinson and the corresponding
"Received:" line was
Received: from KL.SRI.COM by stinson (3.2/4.16)
id AA04432 for random; ...<date>...
I haven't discovered the reason for the difference in address in the "for"
fields of the "Received:" lines, but it does NOT seem to be a factor in
this problem.
What I deduce is happening is that "sri.com" does not have the address of
"pebble.ai.sri.com" in its database, so it queries our name server
("ai.sri.com") and get the Internet address of "192.12.5.67". "sri.com"
might then do a second query to get the host name for that address and
have that query times out (or that data may be missing from the database
on our name server). Alternatively, the remote mailer may use the
internet number in the address on the "envelope" so that any relays won't
have to do the same name-to-address mapping. Whatever the cause, the
remote mailer sends the message to "pebble" with an address of
"random@[192.12.5.67]" on the envelope. "pebble" then attempts to deliver
the mail to host address 192.12.5.67 (itself), and detects a potential
loop.
According to the people I have consulted about the SMTP protocol,
"random@[192.12.5.67]" is a valid address. However, it is not an address
that sendmail is prepared to handle. If you look in most sendmail.cf
files, you will find a set of lines of the form
# For numeric spec, you can't pass spec on to receiver, since rcvr's
# are not smart enough to know that [x.y.z.a] is their own name.
R<@[$+]>:$* $:$>9 <@[$1]>:$2 Clean it up, then...
R<@[$+]>:$* $#ether $@[$1] $:$2 numeric internet spec
...
Consequently, such systems will put simply "random" on the envelope that
it delivers to pebble, and this problem will not occur. However, this
would seem to be simply a case of a system avoiding a potential
deficiencies in the receiver.
The frequency of this problem was in large part due to our use of actual
hostnames in the headers, e.g., "pebble.ai.sri.com", instead of using the
domainhost ("ai.sri.com") in the reply/return-addr/... fields, and
letting the domainhost forward the messages to the user's individual
hosts. The reason for doing this was a temporary exigency, which I won't
go into.
My Fix to sendmail.cf
=====================
All the Suns in my cluster normally share a common sendmail.cf file. For
each of my Suns, I have added a line of the form
R$*<@[InternetAddr]>$* $1<@HOST>$2
at the beginning of ruleset 6 (in my sendmail.cf file, ruleset 6 is called
at the end of ruleset 3 and extracts local information for use in ruleset
0). For example, the entry for "pebble" would be
R$*<@[192.12.5.67]>$* $1<@pebble>$2
Note: I do not include domain fields ("ai.sri.com") on the RHS because
subsequent rules in ruleset 6 strip off any local domain info.
Note: Make sure that the above conversion is done before any conversions
utilizing $=w (the class of hostnames for the local host).
Alternative 1: the Internet numbers could be put in separate files for
each Sun and read in via the define-class command ("F").
I rejected this because the above was simpler to administer.
Alternative 2: the Internet numbers could be extracted from the hosts
table with a command invoked from a "F" define-class command.
This would seem to involve to much overhead to be useful.
Remember that for multi-homed hosts, "ypmatch" returns only
a single address; for them, something like
ypcat hosts | grep `hostname` | awk '{print $1}'
would be needed.
Related Problem
===============
Just as "random@[192.12.5.67]" is a valid address, so is "random@#DECIMAL"
where DECIMAL is a decimal number representing the internet address. This
could be handled in a similar fashion as the above, but since I haven't
yet seen any remote mailers generate this form, I haven't bothered with
it.
Sendmail Enhancement?
=====================
It would seem that the sendmail program needs two additional system
defined variables similar to $=w (class of names by which the host is
known) giving the Internetwork address(es): one in dot notation and one as
decimal numbers.
Douglas B. Moran
AI Center, SRI International
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list