Sun-Spots-Request@RICE.EDU (Vicky Riffle) (08/28/87)
SUN-SPOTS DIGEST Friday, 28 August 1987 Volume 5 : Issue 37
Today's Topics:
Modems and Security
Choosing Internet addresses
Re: Sharable libraries, Suns holding up, zs silo overflows
Sun 3.4 Upgrades and the *blame*
NEC D2362 + Ciprico controller + Rimfire driver 1.7 = OK
More info on extending video cables
SUN 3.4 problems
Suns and CDC 9766 disks?
Sun 386 based machine?
IFF on a Sun?
Pyramid tech. logo icon
----------------------------------------------------------------------
Date: Fri, 21 Aug 87 15:22 EDT
From: adler1@brandeis.bitnet
Subject: Modems and Security
I have accounts on various UNIX systems including two or three SUNs. I
usually work at home from a VT52 terminal with a modem. I've noticed that
the modems on the SUNs all have a quirk which seriously undermines the
security on these systems and that is what I want to ask about. What
happens is that I will dial up the number and instead of getting a login
promt or a CONNECT signal, I will simply find myself logged into someone's
account! It is usually someone else's but occasionally it is my own. On
one occasion, it was the account of the system manager. This suggests
that in spite of the elaborate security provisions, all one has to do to
break into the system is to find out the telephone number of the SUN's
modem and keep calling it until this high-probablility quirk connects you
to someone's account. I have been told by one person that this is a
weakness of UNIX systems in general and quite difficult to do anything
about. I am skeptical about this because I have never experienced this
quirk with VAX/UNIX whereas it happens to me an average of once or twice a
month with the SUNs.
As nearly as I can tell from my experiences, this quirk occurs when
someone dials up the SUNs telephone number just as someone else logs out
after using the SUN via a modem. Alternatively, it occurs if someone else
has been logged in via a modem and has lost control of their terminal and
tried to handle it by turning off their modem or terminal. At any rate, it
seems to be caused by some delay in disconnecting the SUN from phone line
and apparently the greater the delay, the higher the probability of this
quirk occurring. However, I am just guessing from my experience: I don't
really know anything technical about the SUN.
How can one eliminate this problem?
ADLER1@BRANDEIS.BITNET
------------------------------
Date: 25 Aug 87 02:37:43 GMT
From: hedrick@topaz.rutgers.edu (Charles Hedrick)
Subject: Choosing Internet addresses
Normally I would send this directly to the poster, but I have seen enough
things like this to feel that a general response is called for. Sun and
DEC both use Internet addresses as examples in their literature. But you
aren't supposed to use their example addresses: you're supposed to get
your own authorized Internet net number and use it on all of your
machines. (People who make wallets used to include dummy cards in the
plastic envelopes, including a dummy Social Security card. Apparently a
number of people started using these numbers as their SSN's. This seems
similar.) The folks at the NIC will assign an Internet number to anyone
using the Internet protocols. You don't need to be connected to the
Internet. (Their user assistance number is 800-235-3155. That might be a
good place to start.) Authorization to connect to the Internet is
separate. The advantage of using a real number is that when you decide
sometime later to connect to somebody nearby, you won't have to renumber
all of your hosts. The 126 address at least has the advantage that it
hasn't been assigned to anyone, and probably won't be. (It is the highest
assignable class A number. Using it as the example is probably a good
idea.) 192.9.200 is in the range of addresses that have already been
assigned, so you are almost certainly conflicting with someone.
[[ Absolutely! Forgive the divergence, but this is very important.
Please don't go making up your own Internet addresses, even if you aren't
connected to anyone else. If you do that sort of thing, you are just
asking for trouble. And it's so easy to get a real, authorized number.
--wnl ]]
------------------------------
Date: Wed, 26 Aug 87 21:58:18 EST
From: Chris Torek <chris@mimsy.umd.edu>
Subject: Re: Sharable libraries, Suns holding up, zs silo overflows
Gary Sloane asks:
>... All of [several tasks that must not swap] use several
>libraries in common: libm.a, libc.a, libI77, U77, and F77.a, etc.
>Is there any way that these libraries can be loaded into memory once and
>be shared, instead of having each process keep it's own copy of the needed
>libraries?
Neither SunOS 3.2 nor SunOS 3.4 support shared libraries. SunOS 4.0
should have full-blown shared library support---by default, the (runtime)
linker does not even look at the name of a function until it is called!
Since the kernel facilties are quite general, one could write any sort of
sharing desired.
Until then, the only way to share the code space is to make a single
executable file out of all of the tasks, and set things up so that the new
program decides at run-time which of those tasks should be performed.
This is sometimes easy, sometimes hard, and always ugly.
>Also, when you link to a library (in the default method) does the entire
>library object get attached to the process, or does the loader only draw
>into the linkage the particular sections of the library it needs?
Only the needed sections are loaded. The loading is done per archive
*file*, however, not per *routine*, and I/O routines have a tendency to
draw in all the floating point routines, and so forth. Using just a few
of the SunView windowing facilities can result in 300K of library code,
because those routines calls other SunView routines that call many other
routines.
Hal Birkeland writes:
>How well do Suns survive long-term, heavy usage?
>I have heard rumors of power supplies turning into fireballs, keyboards
>self destructing, and mouse problems.
We have had a number of power supplies quit because the fans get tired and
stop. We have had almost no mouse problems (other than the Pepsi Syndrome
:-) ), and the only keyboard problems of which I have heard were the
design problem with Sun-3/50 keyboard RETURN keys, long since fixed. Our
hardware person would know more about this than I, though.
Niall Mansfield writes:
>... sometimes I get lots of messages on the console saying
> zs1: silo overflow
>arriving every few minutes.
Every Sun-2 and Sun-3 that I have seen has four `zs' serial ports. Two
are connected to `ttya' and `ttyb', and the others are for the keyboard
and mouse. As I recall, zs0 and zs1 are ttya and ttyb. All this means,
then, is that something connected to ttyb is sending characters to your
Sun faster than your Sun can handle them.
Since the zs (`SCC') chip has only a one-character `silo', this is quite
likely to happen if you plug in a computer that can actually type at the
machine at more than about 2400 baud. Noisy terminal lines may do this as
well, by sending two characters in rapid succession.
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
------------------------------
Date: 28 Aug 87 08:18:26 GMT
From: nosc!hamachi!sloane@sdcsvax.ucsd.edu
Subject: Sun 3.4 Upgrades and the *blame*
This is being posted to comp.unix.wizards ONLY because this is where the
original article appeared. I am also posting this to comp.sys.sun
[[ sun-spots as we know and love it --wnl]] as it appears to be topical
to the group. Please do NOT bother to respond to this article unless it
is by email directly to me, ...nosc!hamachi!sloane.
In a recent article ("Sharable object libraries on a Sun-3?") I flamed Sun
Microsystems, specifically my salesperson, for not shipping the 3.4
upgrade as promised:
"...[We are running] Sun OS version 3.2, soon to be version 3.4
if our salesman ever comes through."
I received several responses to this from Sun, from both our local
salesperson ("I really appreciate your taking the extra time to place the
blame where it belongs") and a telephone query from Sun in Milpitas ("What
happened? We want to find out").
In all fairness, it was NOT directly our salespersons's fault (sorry
Steve), although he could have followed up on our problem personally
instead of letting us do it.
The problem was an internal one at Sun Milpitas, where two separate tech
support persons (to remain nameless) both claimed to have placed us on a
priority list, but neither did. Further complications ensued when one of
our company's representatives inquiring about an INGRES (yeccch) upgrade
confused someone at Sun and they decided we didn't want the OS upgrade
anyway. (Isn't INGRES an operating system?!?). [[ Yeah, I think they use
it on those new relational data-flow machines. :-) --wnl ]] To Sun's
credit, at least one person was willing to help us out, Julie Martin, who
managed to have our upgrade shipped OVERNIGHT when we finally complained
to her. I don't know exactly what her position is, but I nominate her for
president of Sun Technical Support.
------------------------------
Date: 27 Aug 87 08:32:58 GMT
From: mcvax!inria.inria.fr!shapiro@seismo.css.gov (Marc Shapiro)
Subject: NEC D2362 + Ciprico controller + Rimfire driver 1.7 = OK
In a previous posting, I badmouthed the combination of NEC D2362 (800 Mb
disk) + Ciprico controller (VME-bus) + Rimfire driver, because of
recurring bad crashes due to a couple of stupid driver bugs.
I now retract. The latest release of the driver (version 1.7) now
contains the patches we sent them. My server has been up without crashing
for 2 full weeks now. Combinations of events which were sure to crash
with the previous versions now work fine.
On the negative side, the packaging of the controller looks
un-professional to my untrained eye. The controller had to be changed
after a power failure, but I won't draw any conclusions.
This cheap and high-performance combination is sold by Digital Design.
My opinion of the professional expertise of the DD people has not gotten
any better. It took them about 2 months to fix the bugs we had pointed
out after a couple of days. We didn't even get a word of thanks from them.
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: Tue 25 Aug 87 11:54:02 N
From: Niall Mansfield <mansfiel@embl.bitnet>
Subject: More info on extending video cables
I've been asked for more info about my earlier posting
> First of all, which four pins did you need
> to extend on the monitor connector?
We followed the pinout given in "Sun-/3/260 Workstation Hardware
Installation Manual", and connected the following pins with coax
1 video+
3 hsync
4 vsync
5 video-
Then, we tied all the coax shieldings together, soldered pins 7,8,9 (all
GND) together, and then soldered the combined shields to the combined
ground pins.
> Second, what impedance did the coax you use have?
We used 50ohm, but our hardware fella says we should have used 75ohm
(but we didn't have any).
By the way, here in Germany, Sun now (since last week!) sells
EU - V20M
Video and keyboard cable extension for monochrome
screens (two cables).
Cost DM 840.00
(DM 840.00 is about $500; our cable cost us about DM 200).
Niall
Organisation: European Molecular Biology Laboratory
Postal-Address: Meyerhofstrasse 1, 6900 Heidelberg, W. Germany
Phone: (06221) 387-0 [switchboard] (06221) 387-247 [direct]
------------------------------
Date: 26 Aug 87 15:02:52 GMT
From: jmr@philabs.philips.com (Joanne Mannarino)
Subject: SUN 3.4 problems
In trying to upgrade our SUN 3/180 fileserver (named condor) to SUN UNIX
version 3.4 along with 11 diskless clients, I ran into some problems. The
upgrade procedure on condor went fine. I reconfigured the kernel for 3.4,
rebooted condor and still no problem. Then I tried booting up all of the
diskless clients (one at a time) and this is where the headaches began.
The booting process began with "requesting internet address" with the host
responding with the correct information (thus there is communication via
our Ethernet). The problem began when the booting process got to the
point for:
starting rpc and net services: portmap router biod
The boot process then halts with the following error messages:
server not responding
RPC: program not registered
mount retrying
/usr
/usr/condor
This will remain at this point until you either manually abort or power
down the unit. At this point, any active workstation on the network (ie,
SUNs either connected to our other fileserver (which still runs 3.2) or
diskful SUNs sitting on the net) displays a screenful of "ie0: no
carrier" and "Ethernet jammed" error messages.
I contacted SUN support immediately and after running tests to see if all
of the daemons that should be running were running, the conclusion was
made by SUN that the problem is somewhere within our Ethernet structure.
SUN said that 3.4 includes major changes in the Ethernet drivers that
don't correct for possible problems in the network. At this point SUN
support referred me to someone in their Data Communications support
department. After running some net stats and sending them the data, I was
told "your network looks ok". BUT still we are having problems.
We've tried some different things to see if we could isolate the problem
(actually this was done before the fileserver upgrade, but we wrote it off
as being a network problem isolated to a particular laboratory). We tried
running a diskful 3/160 as a server for a diskless 3/160 both running 3.4
and we ran across the same problems. It was suggested that we take both
units off of our main net and hook them up directly to their own mini net.
When this was done, the problem went away, ie, the client came up running
3.4.
We have also tried changing the /etc/fstab on a client and "backgrounding"
the mount process. This results in the client coming up in single user
mode. Then after trying to manually mount a filesystem, I get the above
errors of "server not responding" and "mount retrying".
As an interim solution, we have kept the 3.4 enhancements (I didn't back
out of the upgrade) and are running a 3.2 kernel. Everything seems fine,
but this still doesn't solve our problem.
Some SUN reps are claiming that it's our network structure, others say
it's a software problem. Anyone else experienced these symptoms when
upgrading to 3.4? Any suggestions on what we should do now?
thanks in advance,
Joanne Mannarino
joanne mannarino seismo!philabs!jmr
philips laboratories or
(914)945-6008 jmr@philabs.philips.com
------------------------------
Date: Wed, 26 Aug 87 08:55:54 PDT
From: <spar!parfs6!harker@decwrl.dec.com>
Subject: Suns and CDC 9766 disks?
I am tring to attach a CDC 9766 disk drive to a Sun server and need help.
This is the 300 Mb removable disk drive from CDC. It is also sold by
Systems Industries as their 300 Mb disk. I have seen it done before so I
know it can be done. What I need help with is configuring the disk
drive's hardware. I need jumper settings for the sector size and number
of sectors.
I am in desperate need of a manual for this drive. If you have an extra
one, or one you can copy I am willing to pay $50 for it.
Thanks in advance
RLH
Fairchild Palo Alto Research
(415) 858-4548
sun!sunncal\
>!spar!parfs6!harker
decwrl /
------------------------------
Date: Mon, 24 Aug 87 22:56:01 EDT
From: Greg Clary <gjc@rti.rti.org>
Subject: Sun 386 based machine?
Does anyone know anything about Sun's new 386 based machine?
i.e. When will it be available?
Price range?
Will it come equipped with Unix?
If so, will Sun have a product like Microport's Dos-Merge?
Prefer e-mail but post responses if you like.
Thanks in advance.
-Greg
(gjc@rti.UUCP)
------------------------------
Date: Tue, 25 Aug 87 14:11:43 EDT
From: (Glenn S. Elias) cognac!elias@pt.cs.cmu.edu
Subject: IFF on a Sun?
Is there anyone who knows how to display an IFF (Interleaved Bitmap) on a
sun console?
Reply to:
Gary Sherwin
cognac!hsl3!sherwin@pt.cs.cmu.edu
(412) 256-2563
[[ Excuse my possible ignorance, but are you reffering to the same IFF
format that Commodore uses for the Amiga? Or is there another entity
known as IFF? --wnl ]]
------------------------------
Date: Fri, 28 Aug 87 02:31:59 CDT
From: osu-cis!sppy00!cml@cbosgd.UUCP
Subject: Pyramid tech. logo icon
This is an icon of the pyramid tech. logo that I made for my
sun many moons ago. Please copy, use, and enjoy at will.
/* Format_version=1, Width=64, Height=64, Depth=1, Valid_bits_per_item=16
*/
0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
0x0000,0x0007,0xFFFF,0xFFFF,0x0000,0x000F,0xFFFF,0xFFFF,
0x0000,0x0001,0xF000,0x0000,0x0000,0x0001,0xF800,0x0000,
0x0000,0x0001,0xFC00,0x0000,0x0000,0x0001,0xFC00,0x0000,
0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
0x0000,0x01FF,0xFFFF,0xFFFF,0x0000,0x03FF,0xFFFF,0xFFFF,
0x0000,0x0001,0xFFE0,0x0000,0x0000,0x0001,0xFFF0,0x0000,
0x0000,0x0001,0xFFF8,0x0000,0x0000,0x0001,0xFFF8,0x0000,
0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
0x0001,0xFFFF,0xFFFF,0xFFFF,0x0003,0xFFFF,0xFFFF,0xFFFF,
0x0000,0x0001,0xFFFF,0xC000,0x0000,0x0001,0xFFFF,0xE000,
0x0000,0x0001,0xFFFF,0xF000,0x0000,0x0001,0xFFFF,0xF000,
0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
0x00FF,0xFFFF,0xFFFF,0xFFFF,0x01FF,0xFFFF,0xFFFF,0xFFFF,
0x0000,0x0001,0xFFFF,0xFF80,0x0000,0x0001,0xFFFF,0xFFC0,
0x0000,0x0001,0xFFFF,0xFFE0,0x0000,0x0001,0xFFFF,0xFFE0,
0x0000,0x0001,0xFFFF,0xFFF0,0x0000,0x0000,0x0000,0x0000,
0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000
Christopher Lott (cml@sppy00.UUCP or ...{seismo|cbosgd}!osu-eddie!sppy00!cml)
OCLC = Online Computer Library Center
6565 Frantz Road Dublin, Ohio 43017
me: 614-764-6407
[[ Archived as "sun-icons/cml-pyramid.icon". --wnl ]]
------------------------------
End of SUN-Spots Digest
***********************