Sun-Spots-Request@RICE.EDU (Vicky Riffle) (07/16/87)
SUN-SPOTS DIGEST Wednesday, 15 July 1987 Volume 5 : Issue 26
Today's Topics:
Re: questions about new 3/280?
Re: Mounting /usr/spool/mail remotely on a SUN network . . . (1)
Re: Mounting /usr/spool/mail remotely on a SUN network . . . (2)
Sun spooling to DEC LPS40
Making X11-beta.1 on a sun3
Macsyma on Sun 3?
Null modem cable?
Sun CommonLisp to SunCore Interface?
For the rest of you who haven't bought your VAX yet
U. of Washing LaTeX/TeX?
------------------------------------------------------------------------
Date: Fri, 10 Jul 87 16:23:04 PDT
From: ihnp4!utzoo!henry@ucbvax.berkeley.edu (Henry Spencer)
Subject: Re: questions about new 3/280?
> ...Xylogics 472 tape controller and a Fujitsu GCR tape drive...
> ... the highest minor number is 12. How do I get to
> the 6250 density? ...
mt0 (etc.) is 1600, mt8 (etc.) is 6250. (We've got the same hardware.)
Isn't it wonderful that Sun documents this so well?
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
------------------------------
Date: 10 Jul 87 21:46:29 EST
From: rayan%ai.toronto.edu@relay.cs.net (Rayan Zachariassen)
Subject: Re: Mounting /usr/spool/mail remotely on a SUN network . . . (1)
# ... The reason that it's not easy to set up a system where
# /usr/spool/mail is remotely shared among several machines ...
# ... is that root access is not propagated over NFS. This means
# that when someone ... trys to deliver a mail message on a system which
# has /usr/spool/mail remotely mounted, it fails because sendmail and
# /bin/mail run setuid to root and hence has no special access to any of
# the files in /usr/spool/mail. It is NOT ... because sendmail has
# locking conflicts over the network; sendmail and the other mailing
# agents ... use a create-error-if-file-exists locking mechanism in
# /usr/spool/mail which works even over NFS ...
... but it doesn't do a lot of good if the mailbox isn't empty when
the delivery is attempted. Is this really a locking mechanism at all?
Anyway, there are two issues if you want to do local delivery of mail
onto a remotely mounted filesystem. One is locking; in SunOS 3.0 when
a couple of us started looking at this problem, locking across the network
was still a gleam in someone's eye within Sun. In SunOS 3.2, lockf()
does that, but waiting for 3.2 was not acceptable (having a separate
mail spool directory for each client is unacceptable in my opinion).
Secondly, how does mail get delivered if root on a NFS client is mapped
to an unprivilidged uid on the server?
The locking problem was reasonably straightforward. We implemented a
lock server that could be contacted over the network to do local locking
of files on behalf of a process on NFS clients. I think this is the
same approach Sun took in 3.2, but since our stuff worked long before
3.2 arrived, we've had no incentive to switch to using lockf().
Then I modified /bin/mail, /usr/ucb/Mail, MH, and GNUemacs's movemail,
to use our locking routines for all files that needed to be locked.
(Yes, you had better have source for this; if you don't, and believe
locking isn't an issue, you can skip this of course).
How does one get some suid root program to deliver mail to a file on an
rmount'ed filesystem? If the mailbox file being delivered to already
exists, the delivery program stat()'s it to get the uid of the file owner.
If the file doesn't exist, the prospective owner's uid is dug out of
/etc/passwd. The delivery program then does a seteuid(owner_uid), and
delivers the mail. There's one little problem left, namely how to create
files in the mail spool directory if the delivery program isn't root
on the server, and the mail spool directory isn't world writable. If
the group write bit for that directory is turned on, the delivery program
will do a setegid(dir_gid) before creating the mailbox file. Delivering
the same message to many mailboxes is not a problem, since the seteuid()
is reversible (ruid == 0), and similarly with the group id. The assumption
being made here, is of course that the client and server share passwd file.
The upshot of all this is that it is possible to deliver mail locally,
to rmounted filesystems, without touching *any* distribution binaries,
if you think locking is a non-issue. If you are concerned about locking,
the way it is done in existing programs is not exactly elegant, nor
effective across a network, and you will need sources to modify the
locking mechanisms used by /bin/mail and /usr/ucb/Mail.
We had reasons for writing a new program to do mail delivery, instead of
using /bin/mail: a) /bin/mail is S L O W because it buffers everything onto
disk and is inefficient about handling multiple recipients, and b) the only
reason for the suid bit being turned on, on /bin/mail, is for doing mail
delivery. Since /bin/mail can be used to create files and such, that bit
was a rather glaring needless general use of uid 0.
Therefore, we wrote a program specifically to do mail delivery (fast, with
locking across the network using the flock server we wrote, optionally
beeping to comsat), and turned off the suid bit on /bin/mail. Then in the
sendmail configuration file just replace the name of this program for
/bin/mail, and all is ready to deliver locally no matter *where* the mail
spool directory is physically located.
If people show interest in getting these programs (local delivery program,
and flock server), maybe we can be convinced to spend time on making it
available.
Regards,
rayan
Rayan Zachariassen
AI group, University of Toronto
------------------------------
Date: Sat, 11 Jul 87 17:59:47 ADT
From: elsie!ncifcrf!randy@seismo.css.gov (Randy Smith)
Subject: Re: Mounting /usr/spool/mail remotely on a SUN network . . . (2)
># the files in /usr/spool/mail. It is NOT ... because sendmail has
># locking conflicts over the network; sendmail and the other mailing
># agents ... use a create-error-if-file-exists locking mechanism in
># /usr/spool/mail which works even over NFS ...
>
>... but it doesn't do a lot of good if the mailbox isn't empty when
>the delivery is attempted. Is this really a locking mechanism at all?
Well, I speak from a wealth of inexperience (read: no source)
here, but what I meant was that the various programs that need to
interleave access on a file in /usr/spool/mail
create-error-if-file-exists a file <user>.lock in that directory to
prevent other programs from writing the file. While that file
exists, the original creating program can do whatever it wants to
the user's mail file without fear of anyone else fiddling with the
file (they sleep if they see the file) and when it's done it deletes
the file. Then the next program creates the same file and goes to
work. Yes, I think this is an effective, though kludgy locking
mechanism. And based on what I knew when I posted, this mechanism
will work over NFS. If someone knows the system better than I do
and I've made some glaring error in my description, please speak up.
As it happens, the situation is not quite so rosy (:-}) as I
described it in my original posting, because the
Create-error-if-file-exists flag to the creat system call is not an
atomic operation over NFS (thanks to jbn@glacier.stanford.edu for
pointing this out to me). The client actually first checks to make
sure the file doesn't exist, and then creates it. This would allow
one client to conclude it's all right to create the lock file, and
than another client to conclude it's all right to create the lock
file, and then both to create it leaving both thinking they could
modify the file to their heart's content at the same time. Ooops.
This window is only a few milliseconds wide, though. (I know, it's
still there. I'm afraid something like the scheme Rayan describes
(involving modification of the source) is the only way to do it
right. But you can do it *almost* right without source mods!)
Hope this helps.
-- Randy Smith
Randy Smith @ NCI Supercomputer Facility
c/o PRI, Inc.
PO Box B, Bldng. 430 Phone: (301) 698-5660
Frederick, MD 21701 Uucp: ...!seismo!elsie!ncifcrf!randy
------------------------------
Date: Friday, 10 July 1987 18:34:26 EDT
From: Lawrence.Butcher@g.cs.cmu.edu (Lawrence Butcher)
Subject: Sun spooling to DEC LPS40
I used the SUN Decnet software to snoop the Ethernet packets sent between a
VMS machine and the DEC Printserver 40. I guessed enough about the protocol
to write a program to spool from the SUN to the printer via LPR. I did not
discover what happens when there are exceptional conditions in the printer.
The software will not survive changes that DEC makes to the printing protocol.
I do not look inside Postscript files for structuring info. I wrote this
bare-bones program simply to print my own Postscript documents directly from
the SUN. I will send this (horrible hack) software to any programmer willing
to improve it to use it. The program could be converted to run under ULTRIX.
The LPS40 is a complicated and polished product. It prints at a furious clip.
The printer contains a microvax with lots of memory and no local disk. DEC
provides VMS software to boot the machine over the Ethernet. Our LPS40 has
never broken, but I assume that DEC field service would want to download
diagnostics from a VMS machine. DEC's VMS spooling software gets interesting
messages about printer status back from the LPS40. Without detailed
documentation of the printing protocol it would be impossible to duplicate
the quality of DEC's supporting software. Our printer is booted and managed
from a VMS microvax.
Lawrence.Butcher@g.cs.cmu.edu
------------------------------
Date: Sat Jul 11 09:36:11 1987
From: ihnp4!hou2d!avr@ucbvax.berkeley.edu (Adam V. Reed)
Subject: Making X11-beta.1 on a sun3
I have managed to modify the X11-beta.1 Makefiles to get make to
complete on a sun 3/50. Here is a summary of what's needed to
make X11-beta.1 on a sun3 set up for system V compatibility:
1. Make sure that :/usr/ucb:/bin:/usr/bin are ahead of /usr/5bin in
your $PATH - the Makefiles depend on the ucb stuff.
2. In the top-level makefile, change server to =Xsun
3. Run link-setup.
4. Make sure thet there is enough space in all the directories used
by the Makefiles. For example, if there is not enough space
in the / filesystem, which includes /tmp, make /tmp a
symbolic link to a tmp subdirectory in a roomier one.
5. In the server/os/4.2bsd/Makefile, and also in the Xlib, toolkit,
and clients/xterm Makefiles, remove dependencies on
/usr/include/machine/machparam.h
since it does not exist on a typical sun3.
The information is in
/usr/include/sys/param.h
6. As distributed, the ./server/ddx/mfb/Makefile uses $* outside the
documented context of substitution macros. Some versions of
make may accept this, but the /bin/make on out SUN 3/50
silently ignores it. The result is
ar: mfbpgbwht.o cannot open
ar: mfbpgbblak.o cannot open
ar: mfbpgbinv.o cannot open
ar: mfbigbwht.o cannot open
ar: mfbigbblak.o cannot open
ar: mfbpawhite.o cannot open
ar: mfbpablack.o cannot open
ar: mfbpainv.o cannot open
I edited the Makefile manually to correct this.
7. Since /usr/include/mit-copyright.h is not supplied, remove the
dependency of XGetDflt.o on this file from Xlib/Makefile,
and then
mkdir include/X
cd include
ln copyright.h .
Similarly with references to /usr/include/X/mit-copyright.h
in clients/xpr/Makefile, clients/xwud/Makeffile,
and clients/xwd/Makefile. Remove dependency and
ln -s include/X X
in the base X11-beta.1 directory.
Have fun,
Adam Reed (hou2d!avr)
------------------------------
Date: 10 Jul 87 22:47:05 GMT
From: km@emory.UUCP (Ken Mandelberg)
Subject: Macsyma on Sun 3?
We just got a copy of Symbolic's Macsysyma 309.6 for the
Sun 3. I was disappointed to find that on a 4 Megabyte
Sun 3 it performs quite poorly relative to a Vax 780. Its
cpu time is better than a Vax, but the run time is a good
deal worse. If you watch it with vmstat, it obviously pages
much more than on a Vax with the same amount of memory.
I was surprised to notice that Macsyma does not seem to do a
vadvise on the Sun, like it does on the Vax, and my guess
is that this is the problem. Symbolics sent us object code
only so I can see no easy way to turn it on.
We are running Sun OS 3.3, and I have verified that vadvise
does in fact work on the OS. For some reason Macsyma/Franz
must just not do one.
Has anyone else noticed this problem?
--
Ken Mandelberg | gatech!emory!km USENET
Emory University | km@emory CSNET,BITNET
Dept of Math and CS | km.emory@csnet-relay ARPANET
Atlanta, Ga 30322 | Phone: (404) 727-7963
------------------------------
Date: Mon, 13 Jul 87 22:05 EDT
From: Hartmuller@dockmaster.arpa (Roger Hartmuller)
Subject: Null modem cable?
We have a brand new SUN 3/180S, with the 16-port ALM. We are trying to
connect a variety of PC's and compatibles to the SUN using these
asynchronous channels, building our own null-modem cables.
First, we constructed a cable with 25-pin connectors at each end,
crossing pins 2&3 and 4&5, and connecting 7&7. This worked fine,
allowing any pc with a 25-pin serial port to talk to the SUN at 9600
baud, using kermit, I should add.
Second, we had a vanilla IBM PC/XT with a 9-pin serial port borrowed
from an AT clone. We plugged a 9-pin prefabricated modem cable in the
9-pin connector on the XT, and plugged the other end into a cable built
as above. This combination worked fine also.
As a third step, we wanted to connect 3 or 4 Kaypro PC/XT equivalents to
the ALM. These machines use a 9-pin serial port also. Rather than try
the 2 cable approach used above, we constructed a 25-pin to 9-pin cable
as follows:
ALM(25) Kaypro(9)
2 TXD 2 RXD
3 RXD 3 TXD
4 RTS 8 CTS
5 CTS 7 RTS
7 GND 5 GND
Using this cable, we could not get any Kaypro to establish a connection
to the SUN. As one last test, I unhooked the modem cable from the PC/XT
and plugged that into the Kaypro, and that would not connect either,
even though it works fine in the XT. I also discovered that plugging
the 25 to 9 pin cable directly into the PC/XT wouldn't allow a
connection either.
Does anyone know how to make a null modem cable to connect a 9-pin
serial connector to an ALM on a SUN?
Roger Hartmuller
ARPA: Hartmuller@Dockmaster
hartm@louie.udel.edu
Bell: 301-854-6889
------------------------------
Date: Mon, 13 Jul 87 10:22 EST
From: AIDEL%ecs.umass.edu@relay.cs.net (Eugene C. Libardi, Jr.)
Subject: Sun CommonLisp to SunCore Interface?
I am trying to run SunCore from Sun CommonLISP (Lucid). Has anyone
done this? Ideally, I would also like to include either the Sunview window
interface (provided by Sun) or Lucid's Window Toolkit. Will this be a problem?
Any info (people to contact, public domain code!) will be greatly
appreciated. Please respond directly to me and I will post the results if it
is warranted.
Thanks in advance,
Eugene C. Libardi, Jr.
Mechanical Design Automation Lab
Dept. of Mech. Eng.
University of Massachusetts
Amherst MA 01003
(413) 545-3599
aidel@umass-ece.csnet
------------------------------
Date: Tue, 14 Jul 87 04:43 EDT
From: ROODE@bionet-20.arpa (David Roode)
Subject: For the rest of you who haven't bought your VAX yet
SUN INTRODUCES 10-MIPS SUPERCOMPUTING WORKSTATION
NEW YORK, NY -- July 8, 1987 -- Sun Microsystems, Inc., introduced
today the Sun-4 family of 10-MIPS supercomputing workstations and
servers that give users the performance of a VAX 8800 system at
one-tenth the price.
"We expect this product family to redefine workstation computing and
create a new price/performance point in the industry," said Bernard
Lacroute, Sun's executive vice president. "Sun built its reputation
delivering workstations with industry-leading performance at unmatched
price/performance levels. The Sun-4/200 Series continues that
tradition."
"This is not a hardware-only announcement," said Sun President Scott
McNealy. "Sun has accomplished something rarely seen in the computing
industry by delivering the first supercomputing workstation with a full
complement of system and applications software available today."
Several original equipment manufacturers, including Valid Logic and LSI
Logic, have ported software applications to the new Sun platform, and
over 90 third-party software developers have either ported their
product or demonstrated intent to port to the new system.
The Sun-4/200 Series is ideally suited for all compute-intensive,
floating-point or graphics-intensive applications. The primary markets
targeted are high-end mechanical-CAD (MCAD) applications, such as
solids modeling and finite element analysis, electrical-CAD (ECAD)
applications including IC and PC layout and routing; artificial
intelligence (AI) development, earth resources, and molecular
modelling.
The Sun-4 family is source-code compatible with the Sun-3 and
Sun-2 families of 680X0 microprocessor-based products, allowing all
three product-families to use the same software and be combined in
network installations. Sun is also supplying software tools to ease the
porting process, allowing migration to the newer, high-performance
family of workstations at the user's discretion.
Key to the supercomputing workstation series is its new scalable
architecture based on RISC (Reduced Instruction Set Computer)
technology. Called SPARC for Scalable Processor ARChitecture, it
is readily scalable to deliver dramatic performance increases in the
future.
Sun also announced a new server series based on the SPARC technology
that offers the highest performance of any UNIX-based system on the
market at dramatically lower costs than conventional
superminicomputers. Used as fileservers, compute servers,
communication gateways or as cost-effective timesharing systems, these
servers are ideal for building highly optimized networks.
A Sun-4/260 high-resolution, monochrome deskside workstation with 8
Mbytes of main memory is priced at $39,900. A Sun-4/260 color deskside
workstation with 32 Mbytes of main memory, a 560-Mbyte disk subsystem
and a 60-Mbyte 1/4-inch cartridge tape system is $85,500. Sample
server configurations range from $36,900 for the Sun-4/260S pedestal
model with 8 megabytes of main memory to $104,900 for a Sun-4/280S
server with 32 megabytes of main memory and 1.2 gigabytes of disk and
tape storage. The Sun-4 systems are available 60 to 90 days after
receipt of order depending on configuration.
Upgrades for Sun-3/260 and Sun-3/160 workstations to the 10-MIPS Sun-4
performance are also available. The upgrades are priced at $13,900 for
the Sun-3/260 and at $23,900 for the Sun-3/160.
Sun to License RISC Architecture
Sun also announced that it will license the new SPARC architecture,
operating system and related development tools and compilers to
semiconductor and systems manufacturers. This is the first time a
major computer systems manufacturer is making its own advanced CPU
architecture available to the open market. The licensees will in turn
supply chips, boards, and/or complete SPARC-based systems to the open
market. SPARC licensees announced today are Fujitsu Microelectronics,
Cypress Semiconductor, and Bipolar Integrated Technology.
Sun Reduces Base Price of Current 4-MIPS Systems
In conjunction with today's announcement of the 10-MIPS Sun-4 family,
Sun Microsystems has reduced the base price of its high-end Sun-3/200
Series of 4-MIPS systems by 15-19 percent. With this price reduction,
Sun now offers a fully expandable, high-end workstation at a mid-range
price.
New Software Targets AI Development
Sun also introduced the Symbolic Programming Environment (SPE), a set
of sophisticated software tools for the development of artificial
intelligence applications on Sun's general-purpose workstations. The
new tools, which improve productivity and ease program development in
the Lisp programming language, offer the first true symbolic
programming environment for general-purpose workstations. The Symbolic
Programming Environment lists for $3,500 and will be available in the
first quarter of 1988 for the Sun-4 and Sun-3 families of
workstations.
Sun Microsystems, Inc., of Mountain View, California, is the leading
supplier of distributed computing systems based on industry standards.
------------------------------
Date: Sun, 12 Jul 87 11:04:19 EDT
From: fishwick%beach.cis.ufl.edu@relay.cs.net (Paul Fishwick)
Subject: U. of Washing LaTeX/TeX?
We are having some problems installing U. of Washington's LaTeX/TeX
package for the SUN 3's. Making the binaries was not a problem; however,
we are getting "cannot find XXXX font" or "checksum error" when running
iptex (the Imagen .DVI -> IMPRESS program). Apparently many of the
necessary fonts are not in the primary font directory (/usr/lib/font/tex..
or whatever it is..). We have tried to make and then use utilities such
as "gftopxl" and "pktopx" to create the required .pxl files but some
files do not seem to be there: for instance, one iptex error is:
can't find font cmti10.2160pxl
One would presume that there would be a file such as cmti10.432gf
(5 x 432 = 2160) somewhere, but there isn't.
Has anyone got U.W. LaTeX to work ok on their SUN's? If so, do you have
any scripts or suggestions to aid in getting the right magnifications
(do we have to unpack everything?). Many thanks.
Please send mail to both: fishwick@ufl.edu AND ajw@ufl.edu
if you have any thoughts...
------------------------------
End of SUN-Spots Digest
***********************