Sun-Spots Digest, v6n96

William LeFebvre Sun-Spots-Request at RICE.EDU
Wed May 25 04:06:17 AEST 1988


SUN-SPOTS DIGEST           Monday, 23 May 1988         Volume 6 : Issue 96

Today's Topics:
          Re: CAPS lock and RESET disabled (keyboard remapping)
                   Re: 8mm Backups and read after write
             Re: reliable and customizable Franz Lisp on Sun3
                            Source for dvipage
              8mm Tape Backup System (Exabyte/Perfect Byte)
              "panic: iechkcca" from 2 machines in one night
               Missing paintop.h file from fig distribution
                 synchronous serial comm over Sun zs port
                     Help with colour text in SunView
                  Optical Character Recognition for Sun?
                  Computer Graphics Metafile Available?
                             8-bit shelltool
                      9 bit characters at 38.4Kbaud?
        IdxTex program for producing an index for LaTeX documents

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 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 at rice.edu" or mail the word "help" to the same address
for more information.

----------------------------------------------------------------------

Date:    Thu, 19 May 88 09:20:06 PDT
From:    Brent Chapman <capmkt!brent at cogsci.berkeley.edu>
Subject: Re: CAPS lock and RESET disabled (keyboard remapping)
Reference: v6n91

In v6n91, Wim Mooij discusses some of the security issues involved in that
any user can remap the abort sequence on a Sun keyboard, and writes:

# I have changed /dev/kbd to crw-r--r-- so only root may modify the keyboard
# translation tables. Suntool still works fine, even the .ttyswrc commands
# are executed. An ordinary user cannot execute the caps disable program
# anymore unless it is made setuid root.

Have you tested this (that a non-root user can _not_ remap keys with
/dev/kbd set to mode 644)?  Unless Sun has finally fixed something and
never bothered to mention it, the ioctl() to remap the keyboard works just
fine on a file descriptor that has only been opened for reading; it
doesn't matter that the person opening the kbd doesn't have write
permission, the ioctl() works anyway.  The only way you can keep random
users from remapping the keyboard is by making it mode 600 (read/write for
owner only), but this breaks lots of other stuff, including SunTools. 

Sorry...  I spent about a week working with some folks in Sun tech support
trying to solve this problem a few months ago, and we couldn't come up
with anything reasonable.  The best I've been able to do is remap the
abort sequence to something _other_ than L1-a at boot time; any person who
understands keyboard remapping, though, can remap it at any time.

Hopefully this security bug will be fixed under 4.0.  Basicly, the
particular ioctl() call needs to check whether or not the file descriptor
being used has been opened for writing before remapping the key. 

-Brent

Brent Chapman				Capital Market Technology, Inc.
Senior Programmer/Analyst		1995 University Ave., Suite 390
brent at capmkt.com			Berkeley, CA  94704
{lll-tis,uunet}!capmkt!brent		Phone:  415/540-6400

------------------------------

Date:    Thu, 19 May 88 13:21:19 PDT
From:    weiser.pa at xerox.com
Subject: Re: 8mm Backups and read after write

We use the 8mm Exabyte drive as packaged by Delta Microsystems and sold
via Group Three (in the Bay area, anyway).

This does do read-after-write, but if the read-after-write fails it
doesn't erase and move ahead, but just aborts the write at that point and
complains.  You then have a bad tape, but you know it (which is better
than not knowing...)

-mark

------------------------------

Date:    Thu, 19 May 88 21:49:52 PDT
From:    franz!akbar!cox at ucbarpa.berkeley.edu (Charles A. Cox)
Subject: Re: reliable and customizable Franz Lisp on Sun3

   From:    Anne.DeNiel at a.gp.cs.cmu.edu

   Does anyone know of a reliable, customizable (and cheap) version of Franz
   Lisp for Sun3 machines (running Sun Unix)? The customization I'm looking
   for is the possibility of enlarging the size of the namestack.

All of the original UC Berkeley (for the vax) and newer Franz Inc.
versions of Franz Lisp can be customized.  These customizations include
enlarging the namestack as well as other parameters.

Sun versions of Franz Lisp are available from Franz Inc. in Berkeley (415)
548-3600.

	Charley Cox

------------------------------

Date:    Fri, 20 May 88 10:43:16 -0400
From:    James J Dempsey <jjd at alexander.bbn.com>
Subject  Re: Sun 4/110 memory
Reference: v6n92 

>> From:    David F. Dow <dow at mcc.com>
>> Note that whichever upgrade path you choose, you will end up discarding
>> some of the 1/4MB SIMMS.  Perhaps you can order another 4/110 without any
>> memory (fat chance). 

We tried to order a 3/60 without any memory and were flatly refused.  We
also tried to order it with the standard 4MB, but have the 4MB shipped
later when Sun gets around to it, but were also refused.

It seems ironic to me that Sun isn't shipping machines because they don't
have the memory, yet we can get the memory from third parties.  It seems
it would be in Sun's best interest to work this out somehow.

Perhaps if you have memory, you could send it to Sun and they could ship
your machine with that memory installed?  As David said, Fat Chance.

--Jim Dempsey--
BBN Communications
jjd at bbn.com (ARPA Internet)
..!{decvax, harvard, ihnp4, wjh12, linus}!bbn!jjd

------------------------------

Date:    Tue, 24 May 88 12:13:35 CDT
From:    William LeFebvre <phil at Rice.edu>
Subject: Source for dvipage

Neil Hunt <hunt at spar.slb.com> at Schlumberger Palo Alto sent this to me
quite a while ago, and I was raher negligent in making it available.  But
now it's really ready.  I've unpacked, compiled, and tested it and it
looks very good!  The introductory comment from the first shell file says
it better than I can.  So here it is.

Dvipage is a program for previewing DVI files on Sun workstations.  On a
machine with a colour display, it renders each page of the document at
high resolution and then filters and samples down the image to a lower
spatial resolution, using grey scale resolution to maintain readability
for the small character sizes. A magnifier is provided for close
inspection of details of a page. On a monochrome display, these sampling
features are not available, but rendering at low resolution is performed.

This program is a significant development from the dvisun program which is
in common use, offering improved user interfaces as well as advanced
display features.

The principle limitation of the current version is that it uses the PXL
font description files, rather than any of the more compact forms which
are available.  [[ In fact, this limitation prevented me from testing out
the grey scale stuff because we don't keep PXL files of a sufficient size
on-line anymore.  To use that feature, dvipage expects 300 dpi sized PXL
files (which, because of the funny numbering of PXL files is really
1500pxl and up).  --wnl ]]

Note that parts 2, 3 and 4 of this shar archive describe parts of the same
file (dvipage.c) and must be unshared in order.
__________

The files are stored in "sun-source" as "dvipage-shar1", "dvipage-shar2",
"dvipage-shar3", and "dvipage-shar4".  They can be retrieved via anonymous
FTP from the host "titan.rice.edu" or via the archive server.  For more
information about the archive server, send a mail message containing the
word "help" to the address "archive-server at rice.edu".

			William LeFebvre

------------------------------

Date:    Thu, 19 May 88 18:12:34 EDT
From:    mstan!dpk at uunet.uu.net (Douglas P. Kingston)
Subject: 8mm Tape Backup System (Exabyte/Perfect Byte)

I sent a note to the list about 8mm tape backup systems several
weeks/months ago, and thought that I should report back our experiences to
date.

In short, we choose the Exabyte drive marketed by Perfect Byte Inc.  and
are very happy.

There are a number of people selling the basic Exabyte drive.  We choose
Perfect Byte because of their attention to quality control and support.
They were very helpful in helping us get the drive running on a new
configuration (3/280 with the NEW Sun SCSI board).  The solution was to
switch to SunOS 3.5, and used the Sun supplied driver which will support
the Exabyte drive.  We will be trying it under SunOS 4.0 soon but expect
no problems.  The 4.0 SCSI driver appears to have the same Exabyte support
code in place.

The NEW Sun SCSI board and drivers (SunOS 3.5 and later) seem to be winners.

A couple of answers to common questions:

Yes. The drive DOES have read after write and will detect marginal tape
(dropout) and skip past it.

Yes. The drive performs at the stated speed.  I have a feeling that the
optional blocking factor may in fact be less than they reccommend (which
0.5 Megabytes, 1024 sectors).  The behavior I see in writing tapes is
about 1 second of disk read and 2 seconds of tape write.  Given that the
drive has 256K of buffering I suspect that a good buffering factor may be
around 64 to 100K, but I will need to experiment.  This is particularly
true if you have a double buffered I/O mechanism (i.e. dbcp).

The nicest thing though is that my entire backups for a system fit on one
tape which means I can now have un-attended backups.

Cheers,
	-Doug-

------------------------------

Date:    19 May 88 16:22:59 GMT
From:    roy%phri at uunet.uu.net (Roy Smith)
Subject: "panic: iechkcca" from 2 machines in one night

Early this morning, both of our 3/180 file servers (running 3.2) crashed
with the same message (see extracts from the two /usr/adm/messages below).
Curiously, one crashed 4 hours later than the other.  Both rebooted by
themselves without any problems.  Any guesses what might have caused this?
A Friday the 13th timebomb 6 days late?  [[ Oh please!  Let's not start
any more rumors.  --wnl ]]

I don't think it's power problems because a vax in the same room which is
usually much more sensitive to supply glitches didn't crash.  Nothing else
on the ethernet seems to have had any trouble either.  The only thing I
can think of which changed is that I installed a new 3/50 (with a new
vampire tap) yesterday afternoon and another new 3/50 (and tap) a few days
earlier, neither of which show any problems other than some "server not
responding" errors in /usr/adm/messages.  We regularly get "ie0: no
carrier" messages a few times a day from both servers which I generally
ignore.

	----------------
	May 19 09:00
	ie0: no carrier

	May 19 09:22
	ie0: cmd not accepted
	panic: iechkcca
	syncing disks... ie0: cmd not accepted
	panic: iechkcca
	----------------
	May 19 05:26
	ie0: no carrier
	ie0: no carrier
	ie0: cmd not accepted
	panic: iechkcca
	syncing disks... ie0: cmd not accepted
	panic: iechkcca
	----------------

Roy Smith, System Administrator
Public Health Research Institute
455 First Avenue, New York, NY 10016
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy at uunet.uu.net

------------------------------

Date:    Thu, 19 May 88 17:43:08 PDT
From:    Born Again Hacker <janaka at ee.pdx.edu>
Subject: Missing paintop.h file from fig distribution

Having a growing fig  user community here  (Portland State University  -
EE), I immediately grabbed the shar files for fig 1.4 from the sun-spots
archives.  The first thing that happened when I tried to make it was the
complaint about a missing paintop.h file.  Can't seem to find it in  any
of the nine shar files.

Did I miss something?

[[ Yes.  You missed it in fig.shar.09.  Don't know how, since you say you
have all 9 files, but it's really there.  It's between graphics.c and
putter.c (it's also real small).  --wnl ]]

                                                          Janaka Jayawardena
LOCAL:  janaka at psueea                SysAdmin - Portland State University EE
CSNET:  janaka at ee.pdx.edu                       Portland Center for Advanced
ARPANET:janaka%ee.pdx.edu at relay.cs.net                            Technology
UUCP:   {ucbvax,uunet,ihnp4,gatech}!tektronix!psueea!janaka

------------------------------

Date:    19 May 88 23:20:24 GMT
From:    jdevries at ads.com (Jeff De Vries)
Subject: synchronous serial comm over Sun zs port

Does anyone have information (or code!) that would allow us to reprogram
the zs (serial) port on a Sun 3 (or Sun 4) to grok synchronous?  It would
be especially nice if we could find a DDCMP implementation.  Any leads
would be appreciated.

Jeff De Vries
jdevries at ads.com (arpa)

------------------------------

Date:    Tue, 17 May 88 14:39:47 EST
From:    munnari!kylie.otr.oz.au!matt at uunet.uu.net
Subject: Help with colour text in SunView

This question, I feel sure, has a simple answer.  How, using SunView, do
you display 'PANEL_TEXT' items and 'PANEL_MESSAGE' items in a colour other
than the foreground colour? 

>From what I can see SunView provides no macros for creating any
'Panel_Item' in colour.  For all items where the IMAGE (pixrect*) is
accessable (eg. PABEL_LABEL_IMAGE, PABEL_BUTTON_IMAGE, PANEL_CHOICE_IMAGE,
etc) there is no problem in supplying an 8 bit deep pixrect.  However for
text based items which are maintained by SunView the pixrect is created
and written to the pixwin without ever specifying a 'tint' with the
operation PIX_COLOR().

It is possible to do it like this
1. grabbing a Rect for a particular item with PANEL_RECT,
2. copy the pixels into a pixrect,
3. swap colours with some method in the pixrect,
4. copy the pixrect back into the pixwin.

This may work but it will need to be repainted very often.

If anyone can offer any information about this (even if it is not entirely
relavent) it would be most appreciated.

Matthew Price.
ACSnet: matt at kylie.oz
Internet: matt at kylie.oz.au@uunet.uu.net
UUCP: uunet!munnari!kylie.oz!matt

------------------------------

Date:    Thu, 19 May 88 15:30:54 EDT
From:    camille at spock.UUCP (Camille Goudeseune)
Subject: Optical Character Recognition for Sun?

We've just got an optical 300 DPI scanner for our network of Sun 3's, and
would save very much time if we could read in text instead of typing it.
The scanner produces a standard Sun rasterfile at 300 dpi of an 8.5" by
11" page.  Does anyone in Netland know of a device to perform "OCR", or
anything like it, on Sun rasterfiles?  I'd be most grateful.  (At least
one secretary said she'd "grovel" if it would help.)  Surely *someone* has
already invented this particular wheel! :-)

(This node just got on Usenet quite recently, so "reply" might bounce.
Try this path:
        ...!uunet!helios!spock!camille

        Thanks,
                Camille Goudeseune.

------------------------------

Date:    Thu, 19 May 88 17:13:00 CDT
From:    "Mahlon Stacy" <mcs at bru.mayo.edu>
Subject: Computer Graphics Metafile Available?

Does anybody know of any programs to convert any files, such as Sun
rasterfiles, to CGM, the Computer Graphics Metafile. We need to interface
medical images to our medical graphics department using this new standard.

Mahlon Stacy		(internet  mcs at bru.mayo.edu)
Mayo Foundation		(uucp   ...sun!tundra!bru!mcs)
Rochester, MN 55901

------------------------------

Date:    Thu, 19 May 88 17:42:01 PDT
From:    decwrl!SPAR.SLB.COM!navtech.UUCP!mark at ames.arc.nasa.gov (Mark Stevans)
Subject: 8-bit shelltool

In Sun-Spots V6N, Vassilis Prevelakis mentions that a version of
"shelltool" is available that allows eight bit characters, i.e. all 256
characters in a font are displayable.  How does one go about obtaining a
copy of this?

Mark Stevans
spar!navtech!mark

------------------------------

Date:    Thu, 19 May 88 22:38:15 EDT
From:    Eric Bloch <edb at cs.brown.edu>
Subject: 9 bit characters at 38.4Kbaud?

Do you know if there is any board that attaches to a Sun3 or Sun4 that
will give me serial data at 38.4 Kbaud, 8 bits plus parity?

Thanks for any help here.

-Eric Bloch
edb at cs.brown.edu

------------------------------

Date:    Thu, 19 May 88 17:01 EDT
From:    Jim Marselea <MARSELLE at gmr.com>
Subject: IdxTex program for producing an index for LaTeX documents

Fellow sun-spots readers:

I'm trying to locate someone who posted a query a few days ago concerning
a program called Idxtex, which produces an index for LaTeX documents.  I
tried sending mail to this person at rgh at shell.com, which was the net
address (I thought) was in his mail message.  I recall that he worked for
Shell Oil.  Of course, I deleted the original message.  Anyway, the mail
bounced back with an unknown host name error.  I'm not even sure if I read
this in Sun-Spots or in another Unix news group.  Does anyone recall
seeing this query?  I'd like to help the guy out since I have the code and
it runs on Suns.

jim marselle
GM Research Labs
marselle at gmr.com

------------------------------

End of SUN-Spots Digest
***********************



More information about the Comp.sys.sun mailing list