Sun-Spots Digest, v6n164
William LeFebvre
Sun-Spots-Request at RICE.EDU
Fri Aug 5 14:57:02 AEST 1988
SUN-SPOTS DIGEST Wednesday, 3 August 1988 Volume 6 : Issue 164
Today's Topics:
Re: Security hole in RCP/REX software (on program)
Re: How do I make an IBM readable tape on a SUN
login problem when NFS server crashes
#of NFS/BIOD daemons && Hard Vs. Soft
Problems with SCSI drives in 3/160
4.0 problem: SunView key bindings change randomly
Custom SCSI devices for Suns?
Here is mactorf.c, a simple MacPaint to Rasterfile converter
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: Fri, 22 Jul 88 08:14:23 MDT
From: lee at unmvax.unm.edu (Lee Ward)
Subject: Re: Security hole in RCP/REX software (on program)
Reference: v6n147
>From: munnari!cluster.cs.su.oz.au!rex at uunet.uu.net
>
>In v6n130 purtilo at 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...
>requires NO root privileges (/usr/bin/on is publically readable as are
>most binaries...
In order to "patch" a file write access OR root is needed.
--Lee
------------------------------
Date: Mon, 11 Jul 88 16:30:32 PDT
From: Stan Uno <ut-sally!pyramid!!ttidca.tti.com!uno at cs.utexas.edu>
Subject: Re: How do I make an IBM readable tape on a SUN
> I have a hunk of C code that I want to port (sort of) to an IBM
> mainframe. (Yeah, I know, why would I want to do that anyway? :-)) My
> only method of transportation is 9-track tape. The files I want to move
> are all c source (hence ascii text). I think the IBM can handle the
> ASCII-EBCDIC conversion, but if I can preconvert on the sun that would
> make me more confident. I've heard rumors that this can be done using 'dd'
> but don't know the details.
>
> Anybody know how to do this?
. . .
> [[ A good place to start would be the manual page for "dd". Look for the
> description of the option "-conv=ebcdic". --wnl ]]
Beware that the EBCDIC to ASCII mapping used in the old (circa 4.1BSD) dd
was not IBM EBCDIC. For this you need to hack the translation tables in
dd. Don't know if this descrepancy has been changed in later versions of
the code, or exactly what machine's EBCDIC the author's were writing for
(ANSI EBCDIC?). This should minimally affect you, as it is more of a
problem when coming from EBCDIC -> ASCII.
[[ What *IS* IBM EBCDIC? Last time I looked, there were at least several
different interpretations for some of the less-used codes. It all
depended on what "print train" the printer was using. --wnl ]]
If you have sources and a valid translation table it's a trivial exercise
to add it as a new option (we did it back in 4.1BSD days), or just replace
the supplied mapping.
I'd use the conversion option on the IBM side and eyeball the results.
It'll be real obvious if there are problems, and fixing them is just a
matter of doing a few global changes using your favorite (<:) IBM editor.
You might also take a look at ibmtape or ansitape for more information
(public domain standard tape label utilities).
Stan Uno
Citicorp/TTI
3100 Ocean Park Blvd.
Santa Monica, CA 90405
(213) 452-9191 ext 3807
Arpanet: {pyramid!ttidca,tsunami!dads}!uno at sun.arpa
Usenet direct: !{{csun,mtxinu,philabs,psivax,pyramid,rdlvax,retix}!ttidca,sun!tsunami!dads}!uno
uunet direct: uunet!{{mtxinu,philabs,psivax,pyramid}!ttidca,sun!tsunami!dads}!uno
Usenet mapped: uno at tti.com
------------------------------
Date: Fri, 22 Jul 88 11:51:03 EDT
From: dupuy at columbia.edu (Alexander Dupuy)
Subject: login problem when NFS server crashes
While William LeFebvre's comments are completely accurate, and a good
exposition of a problem with NFS, I don't think this is the cause of the
problem which Tom Vijlbrief describes, since he is soft-mounting the other
server's filesystems. He says this is a problem when logging in (but
doesn't mention starting a new shell (in a window for example). And
anyone whose home directory is / would not have any problems with getwd(),
but he only mentions root being able to login quickly.
I would guess that the problem is that he is running quotas on his 3/160
(and perhaps on the 3/260 as well). When login runs, before it exec's the
shell, it runs /usr/ucb/quota to determine whether the user is over quota.
This will do an RPC to the quota daemon on any machines from which
filesystems have been mounted. If the server is down, this can take quite
some time.
The workaround/fix for this is to move /usr/ucb/quota to /usr/ucb/quota-,
and to make /usr/ucb/quota a link to /bin/true. This makes login faster
even if all servers are up. To notify users if they are over quota, write
a script to be run each night from cron which runs /usr/ucb/quota- for
each user, and if they are over quota, mails the output from the program
to them.
@alex
------------------------------
Date: 22 Jul 88 21:28:25 GMT
From: tekbspa!tss!joe at uunet.uu.net (Joe Angelo)
Subject: #of NFS/BIOD daemons && Hard Vs. Soft
Here is something Linda, a very "with-it" person, sent me over the course
of a "fine tuning" service order ...
__________
Mount(8) options--
retrans = the number of times a request is sent to the NFS server before
the request times out.
timeo = the time to wait *BETWEEN* retransmissions of a request, before
sending another request. This value is used for all retries specified by
retrans. If the filesystem is hard-mounted, then this value is backed-off
by a factor of 2 (up to a maximum of 30 seconds) before the next set of
'retrans' requests. See the picture below.
intr = allow keyboard interrupt (like ^C) on a hard mount *AFTER* you have
sent all the requests that retrans specifies, and before you start the
'send request' sequence all over again. This is also the point at which a
soft mount would give up.
Here's a picture of how these things interact on an rpc call, with a hard
mount vs soft mount. All this stuff is happening on the 'client', but the
requests are going to the 'server' side.
==================================================================
CLIENT SIDE SERVER SIDE
rpc call "lookup"
--->> callrpc ----send request---->
| \
| timeo = n tenths of second
| /
| retrans= ----send request---->
| how many \
> | times the timeo
| same request /
hard ^ is sent before----send request---->
mount | timing out \
> path | timeo
| /
| ----send request---->
|
<<-request times out---- <<intr possible (only time intr can happen)
| (have sent 'retrans' number of requests)
> | If hard mount, then: timeo=MAX(timeo << 2, 300)
soft v
mount |
path -->>ETIMEOUT
> Note that as timeo grows, it takes longer for intr to take effect. At the
> maximum backed-off timeout, it could take up to two minutes for an
> interrupt to be noticed.
Some general discussion for reference--------
usually, one gages how many biod's and nfsd's by how many nfs mounts you
have and how many file systems you are exporting, respectively. for the
most part, 4 biod's are good since on a client, (e.g. your workstation),
you are probably not doing so many things in parallel that you'd need
more, though running more than 7 makes no sense since you'd end up with
one or more of them paged out of context. now for nfsd's, this depends on
how many other machines are mounting your filesystem's. again, more than 7
makes little sense for there are only 8 context registers of which one is
reserved for the kernel. anyway, morenfsd's will not make any single nfs
request any faster, but it will allow for more requests to be queued up so
that more throughput is possible. how much 'power' is consumed? like what
percentage over an avarge hour is spent on behalf of that process? this
is hard to quantify. as the cpu power goes up, the overhead of nfs goes
down. perhaps bob lyon might have a magic number for this. 4.0 with its
better memory management and systems with more memory for block caching
now will help nfs throughput.
[Courtesy Sun]
Joe Angelo -- Senior Systems Engineer/Systems Manager
at Teknekron Software Systems, Palo Alto 415-325-1025
joe at tss.com - uunet!tekbspa!joe - tekbspa!joe at uunet.uu.net
------------------------------
Date: Fri, 22 Jul 88 11:41:05 EDT
From: droms at BKNLVMS.BITNET
Subject: Problems with SCSI drives in 3/160
I'm trying to use a Maxtor 3380 drive (which includes an integral SCSI
controller) on a 3/160. The standalone diagnostic doesn't work with
either the Adaptec or Emulex adapter specified (I know ... I don't have
either of those). Unix gives me the following error at boot time:
scsi: chk on sense: invalid
scsi: cannot get sense 2
scsi: chk on sense: invalid
scsi: cannot get sense 2
I don't know if I have a bad drive, if I need to fix some jumper settings
on the drive or if the Maxtor SCSI interface is incompatible with the
3/160 SCSI interface.
Any helpful insights into this problem would be greatly appreciated...
- Ralph Droms
Bucknell University
Lewisburg, PA 17837
droms at bknlvms.bitnet
(717) 524-1145
------------------------------
Date: 22 Jul 88 21:15:41 GMT
From: wasg at rice.edu (Eric Salituro)
Subject: 4.0 problem: SunView key bindings change randomly
I am running SunOS 4.0 on a standalone Sun 3/60. Occasionally, the R2, R8,
and R14 keys will map to the letters s, s, and g respectively, instead of
their normal codes. By running "/usr/old/setkeys sun3 reset" the keys
return to normal.
Why would this happen? Is running an obsolete program the only solution?
Is this peculiar to 4.0?
By the way, I set up the defaults to use the SunView keys and to map the
arrow keys to cursor movement control codes instead of functions.
------------------------------
Date: 22 Jul 88 08:33:54 CDT (Fri)
From: geowhiz!ben at spool.cs.wisc.edu
Subject: Custom SCSI devices for Suns?
Here at the Department of Geology & Geophysics we have a need to interface
different scsi devices to a sun 3/50, running OS 3.4.
We would like to interface a "Bernouli Box" to a 3/50 and would like to
know if anyone out there has done so. The bernouli box has a peculiarity
of having 256 byte blocks.
We need to know the specifics of the sun scsi port in order to write our
own driver if neccessary.
Questions:
Is the scsi command status register cleared if it is read?
Has any one interfaced a bernouli box to the imbedded sun scsi port?
Places to find documentation on the sun 3/50 scsi port.
Thanks in advance for any information you might be able to furnish.
Ben Abernathy: Site and System Manager
Department of Geology & Geophysics UW - Madison
1215 West Dayton Street Madison, WI 53706
BELL: (608) 262 9698
ARPA: ben%geowhiz.uucp at spool.cs.wisc.edu
UUCP: {seismo, topaz, harvard, ihnp4}!uwvax!geowhiz!ben
BITNET: ben%geowhiz.uucp%spool.cs.wisc.edu at vms3.macc.wisc.edu
------------------------------
Date: Tue, 12 Jul 88 16:13:11 PDT
From: hoptoad.UUCP!gnu at cgl.ucsf.edu (John Gilmore)
Subject: Here is mactorf.c, a simple MacPaint to Rasterfile converter
This little program converts a MacPaint file to a Sun rasterfile. It
does not handle MacDraw or the newer Mac image formats such as TIFF.
My efforts in this program are in the public domain; it was based on an
earlier program called "decode.c" that was posted to net.sources.mac
without copyright on 21 March 1985, as message <913 at cbdkc1.UUCP> from
cbosgd!cbdkc1!gwe (George Erhart). Thanks George!
Compile with: cc $(CFLAGS) -o mactorf mactorf.c -lpixrect .
John Gilmore
/*
* Turn a MacPaint image file into a rasterfile.
*
* John Gilmore, 11 Jan 1986
*
* Based on "decode.c", a MacPaint to "blit twid" format decoder
* by George Erhart of Bell Labs (cbosgd!cbdkc1!gwe).
*
* Here's a description of the MacPaint format:
*
For those interested, here is a description of the format of MACpaint files.
This format is the common interchange format for full-page bitmap images on
the MACintosh.
The first 512 bytes of the file are the header. The first four bytes comprise
the version number, followed by 38*8 = 304 bytes of patterns. The remaining
204 bytes of the header are reserved for future expansion. If the version
number is zero, the patterns are ignored. Hence, programs that wish to create
files to be read into MACpaint can just write out 512 bytes of zero as the
header.
Following the header are 720 compressed scanlines of data which form the 576
wide by 720 tall bitmap. The bitmap is compressed as follows ;
Any run of three or more equal bytes is compressed into a count byte and a
single data byte. Runs of unequal bytes are passed on literally, preceded also
by a count byte. I.E.
<count byte> <data byte> count = -1..-127 --> replicate byte 2..128 times
<count byte> <n data bytes> count = 0.. 127 --> copy 1..128 bytes uncompressed
count = -128 ignored for backward compatibility
That's it. A nice simple scheme. Thanks to Bill Atkinson for providing this
info.
*
* One thing he forgets to mention is that when the files are uploaded
* by binhex, hexbin, or whatever damn thing, up to a block of junk is
* appended to the end. We take care to stop decoding the input stream
* as soon as we have a full MacPaint picture.
*/
#include <stdio.h>
#include <pixrect/pixrect_hs.h>
main()
{
unsigned char head[512];
register int byte;
register int tag;
register unsigned char x;
register int index;
struct rasterfile rfh;
register int total;
/* read MacPaint header ... skip it */
for (index = 0 ; index < 512 ; index ++) {
if ((tag = getchar()) == EOF)
exit( 1 );
head[index] = (unsigned char) tag;
}
/* Set outgoing pixrect header */
rfh.ras_magic = RAS_MAGIC;
rfh.ras_width = 576;
rfh.ras_height = 720;
rfh.ras_depth = 1;
rfh.ras_length = rfh.ras_height *
mpr_linebytes(rfh.ras_width, rfh.ras_depth);
rfh.ras_type = RT_STANDARD;
rfh.ras_maptype = RMT_NONE;
rfh.ras_maplength = 0;
if (pr_dump_header(stdout, &rfh, (colormap_t *)NULL)) {
perror("Error writing rasterfile header");
exit(2);
}
/* expand the scan data */
total = 0;
/* get a count byte */
while ((tag = getchar()) != EOF) {
x = tag;
if (x >= 0x81) {
/* expand a compressed byte to proper size */
byte = getchar();
total += 257 - x; /* 1 + abs(signed x) */
for (index = 257 - x; index > 0; index--) {
putchar(byte);
}
} else if (x == 0x80) {
/* skip -128 counts ... they are obsolete */
;
} else {
/* read raw uncompressed bytes */
total += x + 1;
for (index = x + 1; index > 0; index--)
putchar(getchar());
}
if (total >= rfh.ras_length)
break;
}
if (total != rfh.ras_length) {
fprintf(stderr,
"Warning, total length is %d bytes, should be %d\n",
total, rfh.ras_length);
exit(3);
}
}
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list