Sun-Spots-Request@RICE.EDU (William LeFebvre) (07/20/88)
SUN-SPOTS DIGEST Tuesday, 19 July 1988 Volume 6 : Issue 147
Today's Topics:
Re: postscript printers under 4.0
Re: Security hole in RCP/REX software (on program)
Re: 4.0 vs kill -HUP 1
Re: cmdtool under OS 4.0
mapst.c shar archive (again)
Terminal eyestrain
Manual binders
Write errors after using yellow pages (SUN OS 3.4)
Sun 3/E Eurocard boards: comments and questions
MAX Groups Question
LWP context switch for Sun/4?
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: 11 Jul 88 11:02:14 EDT (Mon)
From: mark@cblpf.att.com (Mark Horton)
Subject: Re: postscript printers under 4.0
I've used a QMS PS 810. As I recall, the switch between HP, 630, and
PostScript modes is a hardware dial, you can't change this from software.
I'm currently using an Apple LaserWriter II, which is just as good as the
QMS except that it doesn't have a parallel port, and serial ports are in
short supply on the 386 box I have.
The official solution is to buy TransScript. You can get the Sun version
(binary only) from Sun for, I think, $2500, as the LaserWriter Interface
Kit. It consists of a tape with Transcript binaries and an ordinary RS232
cable. While the software is very nice, I was not pleased spending $2500
for binaries. Transcript includes some nice software that interfaces to
the printer spooler system, a troff back end that converts from ditroff
stuff to PostScript, and some misc programs, including one really nice
program called "enscript" which essentially runs your files through pr and
sends them to the printer as text in Courier. It puts the heading in bold
and has a -G (gaudy) option which is pretty nice. Enscript is the one
thing I miss about the transcript package. I think you can also get
transcript from Adobe directly, but I don't know the details.
Another option is something called devPS from Pipeline Associates
(pipe.UUCP, I think.) It costs a lots less (several hundred dollars, I
think) and comes with source. It does not have the fancy interface stuff
for the printer driver, and doesn't have enscript, but it does have a back
end for troff, a filter to translate text files to postscript, and a shell
script that supposedly works as a driver under System V. It claims to
support more troff stuff than transcript (more fonts, an escape to
postscript from troff, etc) but I never could get that stuff to work.
I hooked up an 810 to an AT&T 6386 once. I tried devPS and had mixed
success. The shell script lp back end worked fine when I ran it by hand,
but when it ran from the lp deamon it printed a banner page and no actual
text, no matter what I did! (I think this was a UNIX bug.) I wound up
replacing the lp command with a shell script that basically did
(cat $* ; echo ^D) > /dev/lp
and ran my jobs syncronously.
The latest version of DWB comes with PostScript support, and it seems
better to me than either what transcript or devPS did with their back
ends. So the only piece of devPS that was really of any use to me was the
filter "printer" that translated ordinary text files into Courier to use
the printer as a regular line printer, and it's only about 100 lines of C.
In spite of all the wonderful stuff transcript is supposed to do with
handshaking with the printer, just catting postscript onto it works fine,
if you remember to put a control D on the end. (If you forget the ^D,
amusing things happen. I'd troff a page and it comes out fine. The next
document I troffed came out postage stamp sized. The next one was about
the size of one character. The next one was a dot. Each time it was
reducing the size by a factor of 10. I don't know why the reduction, but
apparently the ^D resets things for the next document.)
I have a shell script called "enscript" which just does
pr *$ | printer | lp
and one called qroff which does
soelim $2 | grap | pic | tbl | eqn | troff -Tpost $1 - | dpost | lp
or some such thing, I'm not on that machine right now. soelim isn't on DWB,
so I brought it over from 4.2BSD, it's a Berkeleyism.
If worst comes to worst, you can print a file by sticking ".nf" at the top
and running it through troff. Maybe add a ".ft C" at the front as a
nicety. Troff is nice and fast with a 6386, and I expect it should be on
a Sun 3 or 4 as well.
Mark
------------------------------
Date: Mon, 11 Jul 88 14:59:26 EST
From: munnari!cluster.cs.su.oz.au!rex@uunet.uu.net
Subject: Re: Security hole in RCP/REX software (on program)
In v6n130 purtilo@flubber.cs.umd.edu (Jim Purtilo) said that root access
was necessary for this hole to be exploited. Actually, any user can
exploit this hole. It requires a simple patch to a copy of /usr/bin/on, so
that _geteuid returns the targeted uid, not the uid returned by the
kernel. This is a quite trivial 5 minute change and requires NO root
privileges (/usr/bin/on is publically readable as are most binaries, but I
won't start on that foolishness here).
------------------------------
Date: 12 Jul 88 02:46:15 GMT
From: woods@handies.ucar.edu (Greg Woods)
Subject: Re: 4.0 vs kill -HUP 1
In article <1988.06.28.15.55.26.255.17550@rice.edu> Sun-Spots@rice.edu writes:
>From: Jean-Francois Lamy <lamy@ai.toronto.edu>
>
>Repeat-by: edit /etc/ttytab, change your terminal entry to some other
>speed and kill -HUP 1. You should get kicked out.
I have never seen a UNIX system that does not behave like this. Any ports
whose tty entries have been changed since init started will have all
associated process group leaders sent hangup signals and a new getty
started on that port when init is sent a hangup. Init does not check to
see if what is being HUPed is a login session or just a getty.
--Greg
------------------------------
Date: Tue, 12 Jul 88 12:25:28 EDT
From: dpz@njin.rutgers.edu (David P. Zimmerman)
Subject: Re: cmdtool under OS 4.0
From: Harold Pomeranz <pomeranz@cs.swarthmore.edu>
Has anyone else running 4.0 noticed the distinct tendancy of cmdtool to
die?...
I've noticed this too, and this behavior royally loses. I don't use it
anymore, though, since I've got Chuck Musicano's "contool" program.
Although you can't type commands at it, it makes a MUCH better console
window tool.
David Zimmerman
Apprentice Wizard
Rutgers University
------------------------------
Date: 12 Jul 88 18:43 +0200
From: Dominique Petitpierre <petitp@cui.unige.ch>
Subject: mapst.c shar archive (again)
As <philipt@csta.uucp> reported to me, the second part of the mapst.shar
(mapst.c) archive unpacks improperly. A quick look at it showed me that
it was because somewhere on the mail route, lines longer than 80
characters were folded, and thus introduced newlines in the middle of
strings or between the * and / of an end of comment. Evidently this caused
problems at unpacking and compiling time. Here is a another shar archive
of mapst.c slightly changed to insure that no line is longer than 78
characters! Let's hope that this was the only problem! Sorry for the
trouble, Best regards, Dominique
Mr. Dominique Petitpierre |EAN, BITNET, EARN, MHS, X.400: petitp@cui.unige.ch
ISSCO, University of Geneva |UUCP: mcvax!cernvax!cui!petitp , petitp@cui.uucp
54 route des Acacias |JANET: petitp%cui.unige.ch@ean-relay.ac.uk
CH-1227 GENEVA (Switzerland)|CSNET, ARPA: petitp%cui.unige.ch@csnet-relay.csnet
Tel: 0041/22/20 93 33 extension 2117
[[ The mapst.shar file in the archives has been updated. It is now 17199
bytes. --wnl ]]
------------------------------
Date: Mon, 11 Jul 88 17:17:26 PDT
From: haynes@ucscc.ucsc.edu (99700000)
Subject: Terminal eyestrain
I've found it helpful not to have a wall right behind the terminal. I
moved my terminal so there is a wall with bookcaes about fifteen feet
behind it, so I can glance over the top of the terminal from time to time
and focus on the objects farther away.
------------------------------
Date: Mon, 11 Jul 88 17:21:16 PDT
From: haynes@ucscc.ucsc.edu (99700000)
Subject: Manual binders
I prefer a catalog rack over individual ring binders. These come in
arbitrary sizes with one or two inch wide binders.
------------------------------
Date: Tue, 12 Jul 88 09:33:13 -0200
From: "Gerd Woetzel" <unido!gmdzi!woetzel@uunet.uu.net>
Subject: Write errors after using yellow pages (SUN OS 3.4)
Some calls to the C-library (gethostbyname(), getpwuid(), getpwname()
...), which are using the "yellow pages" service change filedescriptors in
an unexpected way.
The following program shows the changed inode data causing a write error
in the child process (on SUN OS 3.4 using yellow pages).
Sorry, if this is a well known bug (or a feature ?). Perhaps someone can
tell me how to keep track of this hidden usage of filedescriptors (I have
no sources :-(, is it always fd 4 ?). How about OS 3.5, 4.0???
Thanks in advance,
Gerd Woetzel email: woetzel%gmdzi@unido.uucp
GMD / F3 phone: (++49 2241) 142648
Schloss Birlinghoven
D-5205 St.Augustin 1, FRG
-------%<---------- cut here, C-code follows ----------------------
#include <stdio.h>
#include <sys/types.h>
#include <netdb.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <sys/wait.h>
main() {
int pid;
/*
** I assume filedescriptors 0, 1, 2 are open.
** The fd's 3 and 4 should not be open here.
*/
(void) close(3); (void) close(4);
/*
** If the "yellow pages" are used, gethostbyname(3N)
** opens fd 4 but does not close it (the same holds for getpwuid(3)
** and getpwname(3)).
** Prstat() prints some inode data of fd 4 using fstat(2).
*/
if(!gethostbyname("localhost")) Bad("hostbyname");
prstat(4, "opened by gethostbyname");
/*
** Ok, some open fd hanging around in the dark background
** doesn't matter so much (we need no documentation ;-).
** But it has some hidden effect, if we close this fd
** and use it again in a child process.
**
** Let's see what happens in the child and parent processes.
** After a fork, and a wait in the parent, the same piece of
** code is executed both processees.
*/
if((pid = fork()) < 0) Bad("fork");
if(pid) while(pid != wait((union wait *)0));
(void) printf(pid? "\nParent:\n": "\nChild:\n");
(void) fflush(stdout);
/*
** We dup fd 4 from fd 1, just to close and use fd 4 again.
*/
if(dup2(1, 4) != 4) Bad("dup");
if(write(4, "write1 ok\n", 10) < 0) Bad("write1");
/*
** In the child process, after another gethostbyname(3N),
** the filedescriptor fd 4 is changed (closed and reopened??).
*/
prstat(4, "before gethostbyname");
if(!gethostbyname("localhost")) Bad("gethostbyname");
prstat(4, "after gethostbyname");
/*
** The follwing write to fd 4 fails in the child process.
** The errno returned was a BIG surprise to me :-(
**
** I think it's quite common, to do a
** "for(fd=3; fd<..; fd++) close(fd);"
** after a fork(), to get used filedescriptors free again.
**
*/
if(write(4, "write2 ok\n", 10) < 0) Bad("write2");
}
static prstat(fd, msg) int fd; char *msg; {
struct stat sb;
if(fstat(fd, &sb) != 0) {
(void) printf("fd %d is not open\n", fd);
(void) printf("Yellpow pages not used here?\n");
exit(0);
}
(void) printf("fstat(%d): %x %d %d <-- %s\n", fd,
sb.st_mode, sb.st_ino, sb.st_dev, msg);
(void) fflush(stdout);
}
static Bad(msg) char *msg; {
perror(msg);
exit(1);
}
/* Output (stdout, stderr mixed) :
fstat(4): 11b6 262792332 -1 <-- opened by gethostbyname
Child:
write1 ok
fstat(4): 21b6 146 1280 <-- before gethostbyname
fstat(4): 11b6 262788364 -1 <-- after gethostbyname
write2: Destination address required
Parent:
write1 ok
fstat(4): 21b6 146 1280 <-- before gethostbyname
fstat(4): 21b6 146 1280 <-- after gethostbyname
write2 ok
*/
------------------------------
Date: Mon, 11 Jul 88 10:33:05 EDT
From: Doug Wildes <steinmetz!wildes@uunet.uu.net>
Subject: Sun 3/E Eurocard boards: comments and questions
Does anyone have experience with Sun's family of 6U "Eurocard" boards?
The product line was announced in August '87, and includes the 3E/120 cpu,
3E/340 Ethernet + SCSI, 3E/450 monochrome video, and 3E/204 4MB memory.
All are sized to fit in a *standard* VME card cage.
We have been using the cpu and ethernet boards for a real-time,
multiprocessor development project. The Sun boards are running Unix and
appear as any other diskless workstation on our local network. Other
boards (from other vendors: Motorola, Heurikon) in the same VME rack are
running the pSOS real-time kernel from Software Components Group. SCG
provides a device driver and interface library to allow Unix processes to
interact with real-time tasks and access shared VMEbus memory.
Our experience with the Sun boards has been mixed. When they do what we
want, they are wonderful. Developing, downloading, and testing code has
been easy. Having Sun Unix and a real-time O/S in the same backplane is a
powerful combination: we acquire and process signals on the real-time
side, then pass results across the bus to the Sun, then via RPCs to a
remote workstation for storage and display.
On the down side, we've had a number of bad experiences and continuing
frustrations: Technical support for the boards has been extremely hard to
come by. Many (most?) of the people we've talked to at Sun have never
heard of the 3/E family. The only option for repairs is 30 days, return
to factory. Sun "recommends that you purchase an adequate supply of spare
boards in the event of failure."
Configuration options standard on VME boards from other manufacturers are
not configurable on the Sun 3/E: The 3/E runs only at bus requester level
3, with its memory at VME address 0. If it gets an interrupt with a
vector it doesn't recognize, it reboots. So since the 3/E ethernet/scsi
board uses IRQ3 & IRQ2, we can't, even if we use a different vector. We
have been told by Sun that a) we should not use any interrupts higher than
those the 3/E uses [this rules out IRQ 4-7, leaving only 0 and 1] and b)
preventing the reboots would require "hacking the kernel."
So far, our frustrations have been just that. Running into them and
working around them have cost us time, but not forced major changes in our
system design.
Has anyone else had experience with these boards? What are you using them
for, what problems have you had, what solutions have you found? Please
respond by mail; I will summarize to the net if there is interest.
------------------------------
Date: 11 Jul 88 18:21:50 GMT
From: Guy Middleton <gamiddleton@watmath.waterloo.edu>
Subject: MAX Groups Question
> Is there a hack I can install to make it a larger number?
>
> [[ No way. The upper bound is determined by an array in the user
> structure that is fixed at 8 entries. Impossible to fix in a binary, hard
> to fix in the source. --wnl ]]
It isn't really very hard to fix in source. When we were running 3.2, we
changed NGROUPS to 64 without much trouble. Unfortunately, you can only
pass 10 groups as part of NFS authentication.
[[ You're probably right. The hard part probably isn't changing the
kernel, the hard part is deciding which programs need to be recompiled!
--wnl ]]
------------------------------
Date: Mon, 11 Jul 88 13:55:07 pdt
From: rtech!llama!daveb@sun.com (Dave Brower)
Subject: LWP context switch for Sun/4?
I need to implement a lightweight process switch in assembler on a Sparc.
Has anyone already written such a beast that would be sharable?
Thanks,
-dB
------------------------------
End of SUN-Spots Digest
***********************