Sun-Spots-Request@RICE.EDU (William LeFebvre) (08/15/88)
SUN-SPOTS DIGEST Friday, 12 August 1988 Volume 6 : Issue 180
Today's Topics:
Re: Whither 68030
The "open systems" approach to disks and controllers?
tracing opens
'stuck' pty's
Got the CAPS key blues?
manual binders for SunOS 4.0
"Unsharing" libraries under 4.0
Running All Your Clients with One root
Problems with dbx under sys4-3.2
SMI SCSI in 3/50, 3/60, 4/110?
multiple .ttyswrc ?
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 available via anonymous FTP from "titan.rice.edu".
For volume X, issue Y, "get sun-spots/vXnY". They are also accessible
through the archive server: mail the request "send sun-spots vXnY" to
"archive-server@rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Sun, 7 Aug 88 20:55:55 PDT
From: ultra!shj@ames.arc.nasa.gov (Steve Jay)
Subject: Re: Whither 68030
Reference: v6n167
In sun-spots v6n167, Don Speck (speck@vlsi.caltech.edu) wants to know
what, if anything, Sun is doing with the 68030.
Without having any information from Sun, I can think of two responses:
1) who cares?
2) do you really think Sun is going to continue to produce machines with
three (680x0, 386, and SPARC) non-compatible architectures?
Is there something that a 680x0 based system would do better or cheaper
than a system based on one of the other two processors? Who cares what
instruction set the processor is executing?
I happen to believe that the 680x0 processors are much neater [and closer
to the way God intended things to work :-)] than the rather baroque x86
processors, but when it comes right down to it, my workstation could be
executing the 1401 instruction set, as long it greps when I tell it to
grep.
I suspect Sun would prefer to sell only their own designs, but there's a
huge pile of PC/x86 software out there that people want to run, and the
386i gives Sun a way of selling a machine that can run it, and still be a
Sun. There isn't much 680x0 specific software, except for Mac stuff.
Unless it becomes possible to clone Mac's (over Apple's dead body, I
suspect) I can't see what's in it for Sun to continue manufacturing 680x0
based machines.
It's probably necessary for me to say that I have no association with any
of the companies involved, and these opinions are strictly my own.
Steve Jay domain: shj@ultra.com
Ultra Network Technologies Internet: ultra!shj@ames.arc.nasa.gov
2140 Bering drive uucp: ...ames!ultra!shj
San Jose, CA 95131
408-922-0100
------------------------------
Date: 6 Aug 88 23:35:59 GMT
From: hedrick@athos.rutgers.edu (Charles Hedrick)
Subject: The "open systems" approach to disks and controllers?
Recently we have been finding Sun's approach to disk controllers
increasingly frustrating. We have been buying Ciprico Rimfire controllers
recently. The Suns are fine machines. But the XY451 controller (despite
all rumors of newer XY controllers, this is still all you can from Sun)
are clearly at least one generation out of date. To put such a thing on a
Sun 4 is particularly absurd, but even with Sun 3's, there are benefits to
using the Ciprico controller. On the other hand, our Sun support is
fairly good, and we'd like to get as much from them as possible. Anyway,
recently I wanted to add a file server. I ordered a 3/140 (the cheapest
system that will support an SMD controller), and attempted to buy the
whole disk subsystem from Sun except for the controller. What I tried to
order was one of the new Hitachi disks plus the mounting shelf. That's
all there is to a subsystem except for the controller and cables. What I
found is that it is impossible to order the shelf from Sun, even from the
maintenance catalog. Our salesman went to fairly high levels in Sun about
this. It appears that Sun is trying to avoid losing peripheral sales, and
so they are selling only full disk subsystems. Well, the result is
obvious: since they wouldn't sell us the shelf that we needed in order to
mount the disk, we had no choice but to start looking around at outside
disk vendors. Once we do that, it's silly not to buy the disk from them
as well. So they lost the entire peripheral sale, when all we really
wanted to do was to avoid getting yet another XY451.
We're also upset about the new policy about boot ROM's. It is possible to
get boot ROM's for Ciprico controllers for Sun 3's. Sun apparently won't
sell the source needed to do this, but they would allow Ciprico to pay
them to make the ROM, as a consulting project. Apparently they've decided
not to do this for the Sun 4. Sun will only allow Sun-supported devices
to be used as boot devices. This is another one of these silly policies
that is just going to cause trouble. In this case it's going to cause
trouble to Sun field service. We're not about to keep using XY451's
because Sun is being stubborn about boot ROM's. Instead we're planning to
boot our large multi-user Sun 4's over the Ethernet (which is a Sun
supported device). The concept of a 2 disk multi-user machine on which
you can't run standalone diagnostics can't make field service real happy.
It also modifies the way to set things up, since previously these were the
first machines we brought up after power failures, and they had things
like the primary name servers. I guess we'll now have to depend upon
Pyramids to be our primary servers. Kind of supports all the things
Pyramid has been saying about Sun...
Guys, is it really worth all this to keep your customers from buying
Ciprico disk controllers? Particularly not when all you're selling are
the blasted XY451's? I'm not interested in rumors about the wonderful
controllers you're going to sell us Real Soon Now. Those rumors have been
around for a year. I'll start buying your controllers when you're ready
to deliver controllers that are as good as the Ciprico ones. But until
then, you can't be obstinate about supporting customers who are using the
best available technology. It makes your products look good.
------------------------------
Date: Sun, 7 Aug 88 11:36:14 EDT
From: smb@research.att.com
Subject: tracing opens
SunOS 4.0 can be configured to run in ``C2 mode'' -- a mode that's
supposed to be certifiable (but not actually certified) by the National
Computer Security Center as meeting the C2 requirements in the Orange
Book. And that mode in turn requires the ability to audit file
operations, including opens. So -- when you upgrade to 4.0 you may not
need to make that mod.
------------------------------
Date: Sun, 7 Aug 1988 12:53-EDT
From: Ralph.Hyre@ius3.ius.cs.cmu.edu
Subject: 'stuck' pty's
I believe that the only real solution pty open code needs to be fixed,
since many programs will change the mode of this file when they're
running, which makes it difficult to support users running on the console
vs. remote users.
X10 xterm, in.rlogind, and in.telnetd are the most heavily used examples
that come to mind.
- Ralph
------------------------------
Date: Mon, 8 Aug 88 09:24:09 EDT
From: sjs@ctt.bellcore.com (Stan Switzer)
Subject: Got the CAPS key blues?
Got those low-down, can't tell your CAPS mode's on, vi's actin' strange,
and undo don't work blues?
If you are using NeWS (yes, this is a plug), you can stick the following
into your user.ps file to disable the obnoxious caps-lock key:
%
% Disable Caps-Lock Key
%
/CapsEnable { UI_private begin
/compute_shift_states exch { { % enabled version (original)
/letter_shift_state
control_keys_down 0 gt 0 {
caps_keys_down 0 gt shift_keys_down 0 gt or
1 2 ifelse
} ifelse store
/other_shift_state
control_keys_down 0 gt 0 {
shift_keys_down 0 gt 1 2 ifelse
} ifelse store
} } { { % disabled version
/other_shift_state
control_keys_down 0 gt 0 {
shift_keys_down 0 gt 1 2 ifelse
} ifelse store
/letter_shift_state other_shift_state store
} } ifelse store
reset_shift_state
end } def
% you can turn CAPS back on with "true CapsEnable"
false CapsEnable
OK, it's not exactly obvious, but it works!
Stan Switzer sjs@ctt.bellcore.com
------------------------------
Date: Sun, 7 Aug 88 12:52:04 CDT
From: monty%tartarus@gargoyle.uchicago.edu (Monty BSD)
Subject: manual binders for SunOS 4.0
our man packs for 4.0 fit into 16 3 inch D ring binders, although we mixed
some sections of the documentation into the same binder occasionally
(usually related material, such as the C, assembler and floating point
manuals being in the same binder). you could probably manage a 'one
section, one binder' approach (except for the reference manual, which
takes 3 binders), but then you probably also would want to vary the size
of binders too. also, you'll probably want additional binders for the
hardware installation manuals. we haven't bothered using binders for the
beginner manuals since they come in bound, glossy covers and since they
move around to new users as we add them to our net. as for the idea of
using a long rack for manuals (a la large ibm sites), we don't use that
because we prefer to have to option to take the manuals to our desks when
using them.
------------------------------
Date: 7 Aug 88 12:44 -0700
From: Dave Gagne <daveg@ee.ubc.ca>
Subject: "Unsharing" libraries under 4.0
When I was trying to set up an anonymous ftp account on one of our Suns
running SunOS 4.0, I ran across an interesting problem. The problem
concerns the use of shared libraries in 4.0.
I set up the ftp account as described in the manuals, creating an id "ftp"
with a "bin", "etc", and "pub" directories in ~ftp. In etc there is a
"passwd", and a "group" file. In bin I put "ls". Then, when I sign in as
"anonymous" using ftp and use the command "ls" I get the error: crt0: no
/usr/lib/ld.so
This occurs because ftp (or ftpd?) does a "chroot" to ~ftp when someone
signs into the anonymous ftp acct. Then, of course there is no /usr, and
the linker can't find any of the shared object modules (and in fact, the
linker itself can't be found). It is possible, of course, to put a copy
of ld.so in ~ftp/usr/lib, but the shared object modules, etc, still cannot
be found.
What I did was to copy a version of ls from a machine running 3.2, and
then things worked OK, but this seems to be a poor solution.
My question, then, is: Is it possible to "unshare" libraries for an
executable file compiled for use with shared libraries? That is, can I
take the ls from 4.0 and link the various shared object modules
permanently into it? And can I do it without source code? I believe I
could compile a C program with options telling the lnker NOT to use shared
libraries (is this true?) [[ yes: "cc -Bstatic", cc passes that on to ld
--wnl ]], but I don't have the source code, so it is a moot point here.
Dave.
daveg@ee.ubc.ca
daveg%ee.ubc.cdn%ean.ubc.ca@RELAY.CSNET
------------------------------
Date: Sun, 7 Aug 1988 12:55:56 PDT
From: Eliot Lear <lear@net.bio.net>
Subject: Running All Your Clients with One root
Well. I just spent the weekend bringing up SunOS 4.0 and I must say that
things went pretty well. (One quick note, if you install Chuck Hedrick's
hack to the domain system, don't forget to put /xlb or an appropriate link
on the clients). The canned setup does not vary too far from earlier
releases. Unfortunately, previous releases have always been an
administrative headache for big sites. These headaches occur anytime one
changes something on the root directory of a client. For example, if I
want to make a change in my name ordering for the resolver, I have to do
this on N clients. If I want to make a change in rc.boot for some bizarre
reason, I have to edit N of them. That was up until 3.X. In the
environments I work in, it is a lot nicer to treat all the clients
associated with a particular server as one system when possible. There
are some exceptions, but this is the rule. The shrewd conventional answer
to this problem has been symbolic links.
When I saw SunOS 4.0, I said to myself, ``Why not have all the clients
share one root directory?'' I will now proceed to describe this process
in gory detail.
The first question on everybody's mind must be, ``What about rc.boot?'' I
ended up deriving the hostname by using a combination of dmesg, awk, and
tail. The two latter programs gave me grief because they are both
dynamically linked. Fine, I stole the 3.4 versions and they work just
fine. These now lie in /sbin on my clients.
Next, I needed a way to separate system dependent files like mtab, fstab,
and utmp, and I also needed a separate /tmp. I created a new directory
tree on the server called /export/links. This tree contains subtrees
named after hostnames (in a similar vein to /export/root) and mostly
contains a bunch of links that point back to various filenames such as
/etc/utmp.HOSTNAME. Next, I mount this tree of links in the client's
/local and I adjust the the system dependent files such as utmp to point
to /local/etc/utmp, which, in turn, points back to /etc/utmp.HOSTNAME.
Well.. There was a little slight of hand in the scheme to mount /local on
the client. Given that you know the hostname, you can grep for your
hostname in /etc/fstab (which is really a link to /local/etc/fstab) and
you mount it. This means that I have a /local/etc/fstab that contains a
bunch of mount points for /local. Of course all of them are ``noauto'',
but this turns out not to matter. The estute person will have noticed
that I am accessing /local before mounting it. In fact, this is true, but
in the case of fstab and mtab, two copies exist - one under the mount
point, and the one that is in /export/links that is mounted.
So to summarize, here is a layout of A bunch of Suns all running of the
root partition of UK.BIO.NET:
1] utmp is a link to /local/utmp which is local to individual suns.
2] Same with psdatabase.
3] Same with mtab.
4] Same with fstab (with some hackery as described above).
5] Same with messages.
6] Same with msgbuf.
So far, I haven't noticed any performance gains or losses with this setup.
------------------------------
Date: Sun, 7 Aug 88 20:10:52 EDT
From: mc@moc.jpl.nasa.gov (Mike A Caplinger)
Subject: Problems with dbx under sys4-3.2
Has anyone else noticed some problems with dbx under sys4-3.2 on the Sun
4? It seems to lose breakpoints and single-stepping frequently; sometimes
I'll try to single-step and end up with the program running all the way to
termination before I get a dbx prompt back. I haven't been able to
characterize when this happens, though, so a Sun bug report will need some
corroboration.
Mike Caplinger, mc@moc.jpl.nasa.gov
------------------------------
Date: Mon, 8 Aug 88 09:35:09 EDT
From: dan@wind.bellcore.com (Daniel Strick)
Subject: SMI SCSI in 3/50, 3/60, 4/110?
I expect the the 3/50, 3/60, and probably the 4/110 use the older style of
SCSI interface chip which requires external intelligent direction in order
to negotiate most of the eight phases of a SCSI bus command. I presume
the intelligent direction is provided by the SUN cpu. Can anyone verify
this? Does the cpu get an interrupt after each interesting phase or does
it poll the SCSI interface chip?
Does anyone know if the SCSI interface for the 3/75, 3/100, 3/200, 4/200
(a standard vme card) has on board intelligence?
(I recently replaced my sun-3/160 with a sun-3/60 and find that the new
machine runs painfully slowly when it has to page. Only the cpu and scsi
interface have changed. Everything else is the same, including the
monitor and keyboard. Both machines have 4 MB main memory. The disk is
one of those ~70 mb ST-506 drives with an Adaptec ACB 4000 SCSI converter
card.)
------------------------------
Date: Thu, 04 Aug 88 15:18:03 SET
From: Danielle Heinzer <ESC1298@ESOC.BITNET>
Subject: multiple .ttyswrc ?
I need to program different function keys for different windows running
simultaneously. The .ttyswrc file programs the function keys for the
whole screen. Can anybody tell me how to create such a file for each
window ? The .ttyswrc file has to be changed as soon as the mouse
points a new window.
Danielle HEINZER
ECD/CS
European Space Operations Centre
Robert-Bosch-Str. 5
6100 Darmstadt
West-Germany
(49)-6151-886540
ESC1298%ESOC.BITNET@cunyvm.cuny.edu
------------------------------
End of SUN-Spots Digest
***********************