Sun-Spots-Request@RICE.EDU (William LeFebvre) (09/11/87)
SUN-SPOTS DIGEST Thursday, 10 September 1987 Volume 5 : Issue 41
Today's Topics:
/etc/rc* doesn't log on disk, nor correctly mount via gateways
Re: TCP negative sequence number problem
Resposes to question about accton
single-user boot: the sequel
Problem with sscanf %[^] conversion?
GKS versus GP
Information about disk controllers
Need basic info about Suns
Legal status of RCS for Suns (2)
Press Release: DocuPro signs $5 million OEM contract with Sun
----------------------------------------------------------------------
Date: 9 Sep 1987 0220 EDT (Wednesday)
From: geoff@utstat.toronto.edu
Subject: /etc/rc* doesn't log on disk, nor correctly mount via gateways
Description:
/etc/rc doesn't log enough of what it is doing, nor does it log
errors, nor does it log it on disk, so it all vanishes when the
console scrolls.
/etc/rc doesn't understand that NFS mounts from a diskless machine
require mounting /usr, fixing the default route, and then trying
other NFS mounts.
Repeat-By:
Try to determine what when wrong during start up, an hour later.
Try to quickly bring up a machine which mounts NFS file systems
via a gateway; observe the failure or long delay.
Fix:
I have enclosed rewritten /etc/rc* files. They are denser than
the 3.0 ones, mostly because I prefer to start a daemon using
one line, rather than four (check its existence, start it,
log it, "fi").
There is much more console chatter during start up, which is a
help if something should go wrong, yet it is achieved by "set -x"
at the top instead of periodic use of "echo", so it is sure to be
correct and complete. All output and errors are printed by
redirecting standard output and standard error for the entire
start up file instead of redirecting only standard output and only
for select commands. (The inheritance of process groups is
finessed by the use of "trap '' 1 2 3", courtesy of V9.) There is
an on-disk copy of the console chatter in /etc/bootlog, which
means that one can examine the console messages after startup,
even from home.
Machines should start up faster, even if other machines are down.
Local file systems (if any) are mounted first, file systems on the
server for this machine are mounted next, network routing is
corrected (in particular the correct default route is established
so mounts through the gateways will work), and all non-server file
systems are mounted in the background as they are non-essential
and can take a long time if a machine or gateway is down.
Messages about NFS mounts of non-server file systems now go into
/usr/spool/log/mountlog.`hostname` to avoid filling /etc/bootlog
if they should run on. Diskless machines now typically start up
in 2 minutes or less.
The root file system is now always repaired before use, which should
prevent repetitive crashes.
/etc/rc.local has been replaced by a handful of very short files
which isolate the truly machine-dependent parts. /etc/rc is
identical on all our machines now; only the other, short files
differ.
Separate files are executed to start uucp and news running, courtesy
of Henry Spencer.
--
Geoff Collyer utzoo!utstat!geoff, utstat.toronto.{edu,cdn}!geoff
[[ A shar file containing the rc files described above is available via
anonymous FTP from host "titan.rice.edu" as "sun-source/newrc.shar".
Those without Internet FTP access can use the archive server---send a
message containing the word "help" to "archive-server@rice.edu" for more
information. --wnl ]]
------------------------------
Date: Tue, 8 Sep 87 23:10:40 PDT
From: John B. Nagle <jbn@glacier.stanford.edu>
Subject: Re: TCP negative sequence number problem
How did that one creep back in? That bug was in the 4.3BSD beta test
version back in 1985; I found it back then and the fix was in the official
4.3 release. Did Sun back off to some ancient version of TCP?
If it's the bug I found, it's one induced by the strange semantics of
unsigned arithmetic in C; the difference of two unsigned numbers is also
unsigned, never negative. The fix is one cast to int.
John Nagle
------------------------------
Date: Tue, 08 Sep 87 16:28:36 CST
From: AARON KONSTAM <79343382@trinity.bitnet>
Subject: Resposes to question about accton
I thank those who answered my question about accton. There answers made it
clear that there is an unspoken assumption hidden in the Sun supplied
kernel configuration files that is worth noting for those like myself who
are only recent initiates into Sun lore.
The question was why when I execute accton on a 3/50 do I get:
accton: illegal arguments.
The answer is that my kernel configuration file was missing the line:
options SYSACCT
which enables system accounting. However I noticed that all the Sun
supplied configuration files for diskless clients (e.g., ND50 and ND75)
are missing this line. Thus the assumption on Sun's part that system
accounting is not necessary on diskless clients. This seems not to be a
valid assumption. I would be interested to know if I am missing something.
Aaron Konstam Trinity University
------------------------------
Date: Wed, 9 Sep 87 11:40:38 CDT
From: maeder@symcom.math.uiuc.edu
Subject: single-user boot: the sequel
The problem was to prevent the workstations from being booted single-user
without a password. The solution (which can be found somewhere in the
manuals) is to put a line
login root
into /.profile.
This works only if root's login shell is not /bin/sh, otherwise you go
into a loop. (/.profile is for sh what .cshrc is for csh)
But: you should probably not do this on your server. If there is a syntax
error in your rc.boot you are in trouble. The only way to fix such an
error is to boot with option -b. rc.boot is then not executed and you get
a shell immediately after the kernel is booted. As no file systems are
mounted at that time, 'login' is not available! One of the first things
rc.boot does is to mount the public partition unto /pub, making /bin
available. The option -b seems not to be a security problem though: if you
try to boot -b on a workstation with the above line in .profile you get an
error message and I could not proceed from there in any way, except with
halting the system again. Try it out!
If your fileserver is not in a physically secure location, people could
always boot from tape anyway, so the above procedure helps little against
a determined intruder.
An (unrelated) amusing fact:
Ever wondered where the shell that executes rc.boot comes from? As
mentioned, /bin is not yet available when rc.boot starts executing. It
turns out that the mount point /pub is not empty, but contains a directory
'bin' which contains a lonely 'sh'. You normally don't see it as rc.boot
mounts the public partition onto /pub, even in single-user boot. (BTW: is
there a way to umount /pub? I always get "device busy".)
The only way to get at this /pub/bin/sh is to boot with "-b", so you get
your shell before /pub is mounted. I found that out the hard way when a I
accidentally deleted /pub/lib/sh and then tried to reboot. the system
just does nothing, no error message, if sh cannot be found. I had to boot
from tape, copy sh to /pub/lib/sh and then reboot.
Roman E. Maeder, 127 AH (3-7719)
Dept. of Mathematics UUCP: ...!uiucuxc!symcom!maeder
Univ. of Illinois at Urbana-Champaign Internet: maeder@symcom.math.uiuc.edu
------------------------------
Date: Tue, 8 Sep 87 20:57:53 PDT
From: sdk@cs.ucla.edu (Scott D Kalter)
Subject: Problem with sscanf %[^] conversion?
I was trying to recompile the Berkeley VLSI cad tool Crystal on our Sun 3.
It appears that in the file command.c there is a sscanf using the
conversion %[^] to accept a string made up of any characters including
white space. This seems to work if there are no characters to convert
(sscanf returns that it did not match anything), however, if there are
characters to match sscanf returns -1 !!!!
The offending line appears as follows:
nargs = sscanf(line, " %99s %[^]", cmd, residue);
If there is something to match residue then nargs gets -1.
Also, if there is something removed from the scanset like %[^\n] then it
does appear to work properly.
Finally, I did read the man page for scanf a few times and could not find
a way to interpret the spec such that this behaviour might be acceptable.
-Scott Kalter <sdk@oahu.cs.ucla.edu>
------------------------------
Date: Thu, 10 Sep 87 04:08:25 PDT
From: Greg Earle <earle@mahendo.jpl.nasa.gov>
Subject: GKS versus GP
Has anyone gotten a GKS application to run successfully using a GP? A
user at Rockwell has an application that draws a globe, then tries to do a
simple fill_area (with Green). If a GP+ & GB board are installed, then
this croaks; GP complains that it can't handle the array size of the
polygon to be rendered. The number of polygons was brought down to 360
(from 2000) and it still happens; the globe does not get drawn nor the
area filled. If there is no GP+/GB, and everything is done in software,
it works fine. For yet even more bizzareness, if one takes the GP+/GB out
of the 3/160C that produces the above results, and places them into a
3/260C, it doesn't even get that far; something like `gp1_createfromfd'
dies with a `valloc' failure, and then down at the pixrect level `pr_open'
claims it can't do anything with the frame buffer (`pr_open failed for
/dev/fb'). The GP+ gets the microcode downloaded normally on the 3/260C,
and /dev/fb gets mapped to /dev/gpone0a etc. OK. I checked the existence
and permission of all the correct /dev entries, and they all match those
on the 3/160C yet I get complaints from a fundamental layer of the O/S
(i.e. the pixrect level) rather than from the GKS level or the GP level.
Any ideas/workarounds? Not much point having a graphics accelerator when
it can't even handle simple polygons to fill ...
- Greg
--
Greg Earle earle@mahendo.JPL.NASA.GOV
Sun Consultant earle%mahendo@jpl-elroy.ARPA [aka:]
Rockwell International earle%mahendo@elroy.JPL.NASA.GOV
Seal Beach, CA ...!cit-vax!elroy!jplgodo!mahendo!earle
------------------------------
Date: Wed, 09 Sep 87 11:31:24 MEZ
From: schuster@dkauni13.bitnet
Subject: Information about disk controllers
In the last issues of SunSpots, I read a lot of good news about some VME
disk controllers (Ciprico 3200 Rimfire, 4200 Cheetah). Unfortunately, I
don't have any address to get more information (user manuals etc.) about
the controllers. It would be nice if someone could give me hints where to
get the desired information. Thanks in advance.
Michael Schuster
-- EMAIL: schuster@dkauni13.bitnet
schuster@germany.csnet
------------------------------
Date: 4 Sep 87 17:40:03 GMT
From: ihnp4!houxs!daw@ucbvax.berkeley.edu (Dave Wolverton)
Subject: Need basic info about Suns
This question has probably been asked 1024 times before, but I don't
normally follow this newsgroup, so here goes....
Request
-------
My group wants to buy a Sun workstation to use for software development in
C (mostly stuff like compilers, but maybe some window-based user interface
prototyping and such too). Since I know zilch about Suns, I need some
advice from people with experience using their systems:
What sort of a configuration should we be getting? What is the cost?
(ballpark is OK)
Are there specific software packages that will be needed? Do you have
favorite packages that, while strictly speaking are not "required", give a
more productive software developement environment?
Can I connect it over Ethernet to our VAX 8600? over <something> to 3B2's?
Is the documentation like "typical UNIX docs"?
Can you hang multiple (ASCII?) terminals off it? If so, does it have
enough horsepower to support 3-5 people doing compiles, editing, etc.?
What should I know about administering a Sun? (how hard is it for someone
with a technical background but little UNIX admin experience?)
I would appreciate receiving any comments, flames, gripes, praises, etc.
by mail. As usual, I will summarize to the net (unless requested otherwise).
Dave Wolverton
AT&T
ihnp4!houxs!daw
[[ Please send replies directly to Mr. Wolverton. Upon receiving his
summary, I will either put it in a digest or place it in the archives for
the next person who asks these questions (likely the latter). --wnl ]]
------------------------------
Date: 08 Sep 87 13:59:21 EDT (Tue)
From: elsie!ncifcrf!randy@seismo.arpa
Subject: Legal status of RCS for Suns
Well, I spent about a month tracking the legal, moral, and ethical
implications of this all over the net, and I've seen several requests for
the information since then, so I thought that I would post details. Here
goes.
RCS source is not public domain. One reason for this is that it includes
modified versions of the commands 'diff' and 'diff3' (extra options).
These of course include ATT source code. However (happy day!) Sun OS 3.2
and up have these modifications already in. The other reason that it's
not is that it's author (Walter Tichy, formerly at purdue, email:
tichy@germany.csnet) didn't want to make it so. He is fairly agreeable
about redistribution, though. He makes you sign a statement that you will
not redistribute without his permission and that you will specifically
negotiate with him if you wish to include it in your commercial
distribution. I'll include a copy of the form he'd like you to send him
along with his requirements at the end of this letter. Note that in the
requirements he asks for a copy of your ATT source license; he indicated
to me that this was not necessary if you didn't need the modified versions
of diff and diff3. Just make sure to specify in your letter that you do
*not* have an ATT source license and that you do *not* need the modified
versions of 'diff' and 'diff3'.
Lastly, there are several patchs to rcs (posted by Guy Harris to the net
some months ago) that are necessary to get the thing running on the suns
(null-dereferencing bugs and etc.). I think they were posted to
comp.unix.wizards; I probably have them lying around somewhere if people
need them (if not I can get ahold of them, though it's somewhat more
difficult) (note that this is an offer to provide the sun-specific
patches, *not* the original sources. That is the author's prerogative,
both legally and morally). With these patches, it works fine. I've been
running it on my system for a couple of weeks now.
-- Randy Smith
Randy Smith @ NCI Supercomputer Facility
c/o PRI, Inc. Phone: (301) 698-5660
PO Box B, Bldng. 430 Uucp: ...!uunet!mimsy!elsie!ncifcrf!randy
Frederick, MD 21701 (Use ...seismo!elsie... until Sept. 1st)
------------------------------
Date: 08 Sep 87 13:59:21 EDT (Tue)
From: Walter Tichy <tichy%germany.csnet@relay.cs.net>
To: elsie!ncifcrf!randy%seismo.css.gov@RELAY.CS.NET
Subject: Legal status of RCS for Suns
[[ Here is the message from Walter Tichy that Randy included. It is
rather lengthy and includes a form letter, so it has been placed toward
the end of the digest. The only message that follows this one is a press
release. --wnl ]]
The legal status of RCS is all very unclear. The following form spells out
the details.
-Walter Tichy
=====================
RCS release 3 is still available for free, if you retrieve it yourself
over the UUCP or ARPA net, or if you get it from Berkeley Unix or a friend
who has it. If you prefer a tape, there is a handlig charge of $100. In
any of those cases, type the non-disclosure form below on company
stationary and have it signed by the person who handles your Unix
licenses. Upon receipt of the completed form, we will do one of the
following (as per your requirements):
a. send you detailed instructions on how to retrieve RCS over the network
from Purdue University,
b. send permission to your friend to release a copy of RCS to you
(don't forget to tell us his address, e-mail is strongly preferred),
c. send you a tape (if you included the handling charge).
Since RCS contains modified AT&T source code, we need to verify that you
have a Unix or Ultrix license (source or binary). Please include a copy
of the first 5 pages of your Unix license agreement. If this requirement
presents a problem, let us know. If demand is high enough, we plan to
replace the AT&T proprietary components with our own.
The whole package consists of RCS proper, the manual pages for it, and
modified versions of the Unix commands diff and diff3. If you need more
information on RCS before getting it, read one of the following:
1. "RCS -- A System for Version Control," by Walter Tichy,
in Software--Practice & Experience, Vol 15, No. 7, 637--654, (July 1985)
(general introduction to RCS, suitable as user's manual).
2. "RCS Revision Control System on Unix," by Dan Ligett,
Technical Report TR-86-20, Wang Institute of Grad. Studies,
Tyng Road, Tyngsboro, MA 01879
(RCS Tutorial for the novice).
Walter Tichy
(tichy@purdue.edu, tichy%germany.csnet@csnet-relay)
===========================================================================
Type the following form on company stationary:
To: Walter Tichy
Insterburgerstr. 10e
D-7500 Karlsruhe 1
West Germany
From: <Name>
<Name and address of your lab or institution>
<reliable network address, if available>
<phone number>
<Date>
By this letter, we agree to the following:
1. RCS shall be used internally only.
2. RCS shall not be distributed in any form or by any means without prior
written permission by the author, Walter Tichy.
3. There are no warranties, express or implied, with regard to materials
provided. Accordingly, the author assumes no obligation to provide any
assistance of any kind whatsoever, or to furnish any additional
materials.
4. Copyright notices on all RCS source programs shall be maintained
and respected.
5. The author shall be given credit where appropriate.
It is understood that if we decide to incorporate RCS into a product,
we have to come to a separate licensing arrangement with the author.
<Name>
<Position>
------------------------------
Date: Mon, 31 Aug 87 13:03:39 PDT
From: marleen@sun.com (Marleen Martin McDaniel)
Subject: Press Release: DocuPro signs $5 million OEM contract with Sun
DOCUPRO SIGNS $5 MILLION OEM CONTRACT WITH SUN
MOUNTAIN VIEW, CA -- August 31, 1987 -- Sun Microsystems, Inc. and
DocuPro, Inc., announced today the signing of an OEM contract, valued at
$5 million over 18 months. Under the agreement, DocuPro will purchase
Sun-3 technical workstations, including UNIX system and networking
software, for resale with its own electronic publishing software, called
the DocuPro Professional Publishing System.
"DocuPro is a true professional publishing system," said Farouk Arjani,
DocuPro president. "The Sun workstation ideally complements the enormous
power and versatility of the DocuPro software." The DocuPro system is
used in a broad spectrum of corporate and traditional publishing
applications.
"The flexibility and network base of the Sun workstation family make it a
natural fit for publishing groups using the DocuPro system," said Joseph
Roebuck, vice president of sales for Sun.
The DocuPro system is available from DocuPro's direct sales offices as
well as through selected dealers. DocuPro is a private company that is
financed by over a dozen prominent venture capitalists. The company is
headquartered in Mountain View, California.
Sun Microsystems is a registered trademark of Sun Microsystems, Inc. UNIX
is a registered trademark of AT&T. DocuPro is a trademark of DocuPro,
Inc.
FOR MORE INFORMATION
Karen Rohack Sun Microsystems Press Relations 415/691-7841
Austin F. Ford, Jr. Corporate Communications DocuPro, Inc.
415/960-1214
------------------------------
End of SUN-Spots Digest
***********************