Sun-Spots Digest, v6n108
William LeFebvre
Sun-Spots-Request at RICE.EDU
Sat Jun 11 04:57:54 AEST 1988
SUN-SPOTS DIGEST Friday, 10 June 1988 Volume 6 : Issue 108
Today's Topics:
Re: Resolver based gethostby* in 4.0
Re: Is NFS "secure" in SunOS 4.0 (2)
Re: slip on Suns
Re: 16" Sony Trinitron
SunOS 4.0: Gethostbyname Prob and Shared Library Comment
Porting Hypercard to the Suns?
A questoin about the SunOS License
SUN's rebooting themselves?
The fictitious address "shell.com"
raster image to DEC sixel format 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, 3 Jun 88 14:32:31 EDT
From: libes at cme-durer.arpa (Don Libes)
Subject: Re: Resolver based gethostby* in 4.0
I mentioned previously that upon request Sun will give you a new sendmail
(with MX), new yp, and appropriate libraries all using the resolver.
Several people have asked me if they supply new binaries for ftp, telnet,
etc. The answer is no, because you don't need new binaries. Since all
these programs go through yp, and yp uses the resolver they automatically
see the new host names. [[ provided you have yp configured correctly
--wnl ]]
I don't understand the mechanism, but somehow yp knows to handle hosts
differently than everything else. Unfortunately, it was never designed to
handle funky things like MX records, so sendmail bypasses yp entirely,
which is why they give you a new sendmail.
The only drawback of all this is that if you don't run yp, this isn't a
solution for you.
Don Libes cme-durer.arpa ...!uunet!cme-durer!libes
------------------------------
Date: Fri, 3 Jun 88 10:01:20 PDT
From: david at sun.com (David DiGiacomo)
Subject: Re: Is NFS "secure" in SunOS 4.0 (1)
Reference: v6n101
>From: Charles Jerian <cpj at citi.umich.edu>
>... using Diffie Hellman public key cryptography. THis form of
>cryptography was broken at a conference by Adi Shamir with an apple II
>computer...
Wrong. It was a knapsack scheme that was broken. Factoring is still
thought to be difficult.
------------------------------
Date: Sun, 5 Jun 88 01:00:06 PDT
From: tli%sargas.usc.edu at oberon.usc.edu (Tony Li)
Subject: Re: Is NFS "secure" in SunOS 4.0 (2)
Secure RPC uses DES cryptography. It uses DES as part of a Diffie-Hellman
scheme for public signature verification. Prof. Len Adleman cracked a
Knapsack encryption algorithm using an Apple II. Whether or not DES has
been cracked is a question that the NSA won't answer.
Tony Li - USC University Computing Services - Dain Bramaged.
Uucp: oberon!tli
Bitnet: tli at kylara, tli at ramoth
Internet: tli at sargas.usc.edu
------------------------------
Date: Fri, 3 Jun 88 10:18:35 EDT
From: dpk at morgan.com (Douglas P. Kingston)
Subject: Re: slip on Suns
You need to be very careful exactly what you specify as the gateway
address. In particular, I have found that for SunOS 3.x, I had to specify
the remote hosts own slip address as the gateway address.
I.E. Server -------- Remote (via slip)
ether 192.0.0.42
slip 192.0.1.2 192.0.1.1
ifconfig sl0 192.0.1.1 up
dstaddr sl0 192.0.1.2
route add 0 192.0.1.1 3 (my gut says this should
be 192.0.1.2, but this works, the other
doesn't; I go with what works...)
You will also need to make sure that there is a routed running on the
Server so it will tell the rest of the world about the new network
(192.0.1). It will tak a couple of minutes for that information to
propogate. Routed will not use the slip line (I believe) because its not
marked as broadcast and generally the slip line is not activated when the
routing daemon is started, so it never sees sl0 as an interface to begin
with. Routed does not appear to deal too well with dynamic interfaces...
On a related topic, I am still anxiously looking for a SunOS 4.0 port of
the SLIP driver. We like dialup SLIP (with appropriate access controls).
-Doug-
------------------------------
Date: Sun, 5 Jun 88 13:26:39 CDT
From: drl%backup at uunet.uu.net (David R. Linn)
Subject: Re: 16" Sony Trinitron
>Sony Trinitron(16") is an INCREDIBLY sharp picture reminiscant of Sony's
>usual quality....
This is the monitor used in a RoadRunner (386i) demo here at Camp
Wondermite and I'll second the "INCREDIBLY sharp" evaluation. Since Sun
sells this for a 386i, you can probably buy one from Sun and have it be
covered under your Sun maintenance (if that's important).
David
------------------------------
Date: 4 Jun 88 04:53:04 GMT
From: emory!km at gatech.edu (Ken Mandelberg)
Subject: SunOS 4.0: Gethostbyname Prob and Shared Library Comment
Gethostbyname:
We just installed SunOS 4.0FCS on a Sun 3/50 and ran into an immediate
problem. With ypbind running, gethostbyname does not work. With a little
probing using etherfind, we see the yp requests going to the server are
corrupted and naturally do not get good answers. The domain and database
part of the packet look good, but the actual host string has been
corrupted. Gethostbyname works fine with ypbind off (when it goes right
to the hosts file), and other related yp services are ok (like ypmatch).
To check things out a little closer, we compiled some test programs with a
3.X version of gethostbyname and it is fine in both modes (using ND or
not). The same test programs fail with ND if we link against either the
dynamic or static libc version supplied on the tape.
The evidence seems to point to a bad Gethostbyname slipping onto the
distribution. I say this with a little reluctance. The first symptom of
this is the multiuser boot failing at the first daemon that does a
gethostbyname (sendmail in our case). It sure seems that Sun would have
noticed this.
Shared Libraries:
Well, our first reaction to this was that we had a perfect application of
the new Shared Library feature of 4.0. After all we had source to a
working gethostbyname. All we needed to do was substitute it for the "bad"
one in libc.so.0.10, and every dynamically linked program would be fixed.
However, after an hour of scanning the doc, and hunting through the
filesystem we found ourselves at a dead end. A shared library (a
libXXX.so) is not an archive, it is an a.out built by ld. There is no
apparent way of replacing a routine in one, short of rebuilding it from
the original .o files.
Sun does not appear to supply the .o files that were used to build
libc.so. The .o files in libc.a are not useable since the were not
compiled with the -pic flag, and are not position independent.
The version number scheme does not help with this problem either. There
is no mixing of .so files. ld.so will use the highest version that matches
and only that version. If not all routines can be resolved, it will not
use a lower numbered version to complete the link. So it does not do any
good to just make a new higher numberd .so with replacement routines.
Unless we are missing something, this is a real disappointing aspect of
Shared Libraries.
Ken Mandelberg | {decvax,sun!sunatl,gatech}!emory!km UUCP
Emory University | km at emory BITNET
Dept of Math and CS | km at emory.ARPA ARPA,CSNET
Atlanta, GA 30322 | Phone: (404) 727-7963
------------------------------
Date: Fri, 3 Jun 88 16:21 EDT
From: DAVIS%blue.sdr.slb.com at relay.cs.net
Subject: Porting Hypercard to the Suns?
Ok, Ok, its a wild one, but is anyone thinking of, or has anyone thought
about, trying to port HyperCard to the Sun ? I have no idea of the issues
involved, bar that the code is about 80% pascal (!!) and 20% assembler. I
can think of no great technical reasons for this being *very* difficult,
assuming that the original is a well-modularised piece of code. But I
don't even know if the author would allow it.... Imagine all that easy
power and wonderful naive-user interface running on X. Because of the
assembler, this is initially a Sun issue, rather than one for X, although
a C version could then be ported easily to other machines...
So how about it? Any takers ? I'll glady throw in what I have to offer,
which is not much, but first: where do we start ?
Paul Davis
Schlumberger Cambridge Research
Cambridge, UK
davis%blue.sdr.slb.com at relay.cs.net
[[ Check into the legalities, first. Apple loves to sue these days
(oops, was that slanderous?) --wnl ]]
------------------------------
Date: 3 Jun 88 21:34:07 GMT
From: cyrus at hi.unm.edu (Tait Cyrus)
Subject: A questoin about the SunOS License
Question:
if I develop a software package on a Sun that has a University
SunOS license, am I restricted in what I can do with that package?
That is to say can I sell this package (or rather can the
University sale it) or am I restricted to just charging a
distribution fee.
The reason I ask is because I heard, indirectly from Sun, that ANY
software written on a University licensed Sun was PD. The only fee that
could be charged would be a distribution fee.
Before I start my software project, I would like this answered. If I am
forced to do so, I will reluctantly develop in on a Vax or buy my own Sun.
Any help on this legel issue will be greatly appreciated.
Tait Cyrus (505) 277-0806
University of New Mexico
Dept of Electrical & Computer Engineering
Albuquerque, New Mexico 87131
e-mail:
cyrus at hi.unm.edu or
cyrus%hi.unm.edu at ariel.unm.edu
[[ Developing it on a VAX might not get around the problem, unless the VAX
is running VMS. I believe that this restriction is not Sun's doing, but
is part of the original AT&T Unix license for universities (which must be
signed before getting a "university" version of any Unix derivative).
Someone please correct me if I am wrong. --wnl ]]
------------------------------
Date: Fri, 3 Jun 88 09:55:08 PDT
From: Stuart Cracraft <cracraft at hyper-sun1.jpl.nasa.gov>
Subject: SUN's rebooting themselves?
On a SUN-160, running Sun OS 3.2, with NFS, I've observed an occasional
automatic reboot.
Does anyone know what causes this?
Stuart
[[ Bad source of power? Plug not in all the way? --wnl ]]
------------------------------
Date: Wed, 4 May 88 11:13:26 CDT
From: stan at shell.UUCP (Stan Hanks)
Subject: The fictitious address "shell.com"
In a recent Sun-Spots, Jim Marselea asks:
>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'm the postmaster here [[ at shell ]], so I'll answer for you:
shell.com is *not* an official address that the internet community knows
about. The address that you should use is
rgh%shell.uucp at sun.com or
rgh%shell.uucp at rice.edu
which is pretty much guaranteed to work. I am working towards a solution
which will hopefully mail into the shell.com domain to actually work as
expected. In the meantime, I appologize for any inconvenience that this
may have caused you or anyone else attempting to respond to Richard's
request.
Stan Hanks
Research Computer Scientist, (and Postmaster!)
Shell Development Company, Bellaire Research Center (713) 663-2385
...!{sun,psuvax,soma,rice,decwrl,ut-sally,ihnp4}!shell!stan stan at rice.edu
------------------------------
Date: Thu, 2 Jun 88 20:05:06 EDT
From: gfr%wolfgang at gateway.mitre.org (Glenn Roberts)
Subject: raster image to DEC sixel format converter
There was some interest shown in my program to convert Sun raster files
into DEC sixel files (printable on the LN03 and other DEC printers), after
I mentioned it in sun-spots a while back. I am submitting it here for
anyone who is interested.
Admittedly, it was written primarily to do screen dumps on our VAX's LN03
(via DNI), but with minor modifications could be made more generalized to
print different size raster images and to support different printers.
I invoke the screen dump via an entry in .rootmenu :
"Print Screen" /usr/local/bin/printscreen
where the script in /usr/local/bin/printscreen contains:
sleep 2
screendump -f /dev/bwtwo0 | pix2six | dnacp - 'vax::laser'
(Substitute your VAX's DECnet node name for 'vax'. 'laser' is a VMS
logical pointing to the spooled printer device, in our case "LTA1:".) The
program handles only monochrome images, so pipe color images through
rasfilter8t01 before printing.
Glenn Roberts, MITRE, McLean VA, 703-883-6820
gfr%wolfgang at gateway.mitre.org
---------------- cut here ------------------
/*
** pix2six
**
** converts standard raster image file from Sun format
** (read from stdin) to DEC "sixel" graphics format,
** printable on an LN03. Output written to stdout.
**
**
** usage: pix2six <infile >outfile
**
** Author: Dr. Glenn F. Roberts
** MITRE corp., Mail Stop W335
** 7525 Colshire Drive, McLean, VA, 22102
** gfr%wolfgang at gateway.mitre.org
**
** Last revision:
** 1.0 March 30, 1987
**
** Use this script to print screen via SunLink DNI (also add entry
** in /usr/lib/rootmenu to point to this script):
**
** sleep 2
** screendump -f /dev/bwtwo0 | pix2six | dnacp - 'vax::laser'
**
**
*/
#include <stdio.h>
#include <rasterfile.h>
/*
** defaults to describe nice layout for full screen print
*/
#define OUT_LINE_LEN 1152
#define LINE_LEN OUT_LINE_LEN/8
#define H_OFFSET 286
#define V_OFFSET 345
#define PIX_SIZE 2
char scan_line[LINE_LEN];
char output_line[OUT_LINE_LEN];
struct rasterfile hdr;
main (argc, argv)
int argc;
char *argv[];
{
int i, j, row, char_count;
char this_char, last_char;
/*
** read header
*/
if (fread(&hdr, sizeof(hdr), 1, stdin) == 0) {
fprintf(stderr, "Error reading pixrect header\n");
exit(1);
}
/*
** validate header data
*/
if (hdr.ras_magic != RAS_MAGIC) {
fprintf(stderr, "Not a raster image file !\n");
exit(1);
}
if (hdr.ras_type != RT_STANDARD) {
fprintf(stderr, "Raster type is %d\n", hdr.ras_type);
fprintf(stderr, "Only RT_STANDARD (type %d) is supported!\n",
RT_STANDARD);
exit(1);
}
if (hdr.ras_depth != 1) {
fprintf(stderr, "Pixel depth is %d\n", hdr.ras_depth);
fprintf(stderr, "Only monochrome images are supported!\n");
exit(1);
}
if (hdr.ras_width > OUT_LINE_LEN) {
fprintf(stderr, "Image is too wide\n");
fprintf(stderr, "Maximum supported width is %d\n", OUT_LINE_LEN);
exit(1);
}
/*
** set up LN03
*/
printf("\033[?21 J"); /* landscape mode (PFS) */
printf("\033[7 I"); /* pixels are 1/300th (SSU) */
printf("\033[11h"); /* move by pixels (PUM) */
printf("\033[%da", H_OFFSET); /* move relative right (HPR) */
printf("\033[%de", V_OFFSET); /* move relative down (VPR) */
/*
** introduce sixel stream
*/
printf("\033P0;0;%dq\"100;100", PIX_SIZE);
/*
** loop over scan lines in groups of 6
*/
for (row=0; row<(hdr.ras_height/6); row++) {
for (i=0; i<OUT_LINE_LEN; i++)
output_line[i] = '\0';
for (i=0; i<6; i++) {
fread(scan_line, (hdr.ras_width>>3), 1, stdin);
store_line(scan_line, (hdr.ras_width>>3), i);
}
/*
** six rows complete; convert line to sixel data
** (run length encode repeats of more than 3 )
*/
last_char = '\0';
char_count = 0;
for (i=0; i<hdr.ras_width; i++) {
this_char = output_line[i] + '\077';
if (this_char != last_char) {
output(last_char, char_count);
last_char = this_char;
char_count = 1;
}
else
char_count++;
}
/*
** flush unprinted characters, then graphic new-line
*/
output(last_char, char_count);
printf("-\n");
}
/*
** terminate the sixel stream with an ST
*/
printf("\033\\\n");
}
/*
** output -- output one or more characters.
** Use run length encoding for repeats of more
** than three characters.
*/
output(c, n)
char c;
int n;
{
int j;
if (n > 3)
printf("!%d%c", n, c);
else
for (j=0; j<n; j++)
putchar(c);
}
/*
** store_line -- convert row-oriented scan line data
** to column oriented sixel data. r is the sixel row
** (from 0 to 5).
*/
store_line(line, length, r)
char *line;
int length, r;
{
int i, j, col, mask;
char ich;
mask = 1 << r;
/* loop over bytes per line */
for (col=0,i=0; i<length; i++) {
ich = line[i];
/* loop over 8 bits per byte */
for (j=col+7; j>=col; j--) {
if (ich & 1)
output_line[j] |= mask;
ich = ich >> 1;
}
col += 8;
}
}
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list