Sun-Spots Digest, v6n9

William LeFebvre Sun-Spots-Request at RICE.EDU
Mon Feb 1 13:19:01 AEST 1988


SUN-SPOTS DIGEST         Friday, 29 January 1988        Volume 6 : Issue 9

Today's Topics:
                     Re: Trouble with ditroff on Suns
            Re: Strange failure of bind(2) on diskless clients
                Re: Adding a node to a server-based system
                        Re: EPSON Printer Problems
              Thanks & Summary (sun.com problem in sendmail)
                            New Sun Disk Drive
                            newstool for Suns
            HP Laserjet filters:  Oops, I forgot the printcap
                     Program to help keep utmp clean
                         "iebark" errors on Sun 3
               Which sun to use with a Telebit Trailblazer?
                   COMPARING apollo and sun WORKSATIONS
                      XDR on Cray COS and IBM VM/CMS

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

Date:    Tue, 19 Jan 88 20:52:53 EST
From:    Preston Mullen <mullen at nrl-css.arpa>
Subject: Re: Trouble with ditroff on Suns

The .tl primitive breaks when ditroff is compiled under SunOS 3.3.  This
causes the misbehavior of the header macros in -me.

The problem disappears when you make ditroff under SunOS 3.4 using the
SunPro version of the compiler and loader.  (We attributed it to some
unknown compiler or loader bug fixed in the SunPro version.)

We never tried compiling it using the non-SunPro 3.4 compiler and loader.
Offhand, I don't know whether these programs changed from 3.3 to 3.4 (or
from 3.2 to 3.3, for that matter).

You might look to see whether SunPro has been installed on your machine.
SunPro is not installed by default when you upgrade to 3.4; you must cd to
/usr/sunpro and then run the installation script.  On a diskful machine
that is not a server, you must either fix the script first or perform the
installation manually as indicated in the Read This First document.

(If you install SunPro, watch out for possible inconsistencies in the
semantics of the old Make and the SunPro Make; don't be surprised if one
or two old Makefiles break.)

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

Date:    Tue, 19 Jan 88 18:24:08 -0800
From:    Sam Horrocks <sam at ics.uci.edu>
Subject: Re: Strange failure of bind(2) on diskless clients

Talk was crashing for us on some 3/50's, exiting with an EADDRNOTAVAIL
returned from bind.  It turns out bind fails because it can't find an
interface with the address you are trying to bind to.  I've sent a bug
report to sun, but haven't gotten a reply yet.  Following is pretty much
what I reported:

The problem appears to be in the list of interfaces (_ifnet).  In the
sockaddr for le0 (_ifnet->sockaddr), the last 8 bytes, which should be
zero for an internet address, are being trashed.  When _ifnet is searched
during a bind, all 14 bytes are checked with a bcmp.  This causes the
interface not to be found.

My workaround is to do an ioctl(SIOCSIFADDR) call on the interface
periodically to reset the last 8 bytes of the sockaddr in the entry for
the le0 interface.

This problem seems to appear on some machines and not others, and there
seems to be no correlation between the boot files or the daemons running
on the machines.  All the 3/50's use "/etc/ifconfig le0 <hostname>
-trailers up" in their boot file.

We are currently using release 3.2.

Here's my program, fixif, to clear out the last eight bytes.  It should be
run as "fixif le0".  Talk is currently running this every time it starts up
until a better fix comes along.

----------

#include <sys/types.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <netinet/in.h>
#include <net/if.h>
#include <stdio.h>


main(argc, argv)
    char **argv;
    {
    register i, c;
    struct ifreq ifr;
    struct sockaddr_in addr_in;
    int sockt;

    if (argc < 2) {
	fprintf(stderr, "usage: fixif ifname\n");
	exit(1);
    }

    sockt = socket(AF_INET, SOCK_DGRAM, 0);

    if (sockt < 0) {
	perror("socket");
	exit(1);
    }

    strncpy(ifr.ifr_name, argv[1], sizeof(ifr.ifr_name));

    if (ioctl(sockt, SIOCGIFADDR, (caddr_t)&ifr) < 0) {
	perror("ioctl: get interface addr");
	exit(1);
    }

    bzero(((struct sockaddr_in *)(&ifr.ifr_addr))->sin_zero,
	  sizeof(addr_in.sin_zero));

    if (ioctl(sockt, SIOCSIFADDR, (caddr_t)&ifr) < 0) {
	perror("ioctl: set interface addr");
	exit(1);
    }

    exit(1);

    } /* main */

----------

Sam Horrocks
ICS Support Group
UC Irvine

sam at ics.uci.edu
...!ucbvax!ucivax!sam

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

Date:    Wed, 20 Jan 88 00:39:11 EST
From:    bzs%bu-cs.bu.edu at bu-it.bu.edu (Barry Shein)
Subject: Re: Adding a node to a server-based system

>Did I just screw up?  Does everyone make extra partitions "in case" they
>get new nodes?  And, most importantly, is there a better way?  It would
>seem to me that just a few files need to be modified (e.g.,
>"/etc/nd.local"), and some initialization should take place.  Clue me in!

[READ EVERYTHING -- YOU MAY NOT WANT TO TRY THIS! - B]

You -might- have screwed up, it depends. Do you have a spare partition to
put the extra diskless root/swap in or room in your current partition?
(you don't need a techie -- you need sales :-)

If you do have the space then careful examination of the /etc/nd.local
file should tell you how to set this up, I doubt I could give you complete
directions right here and it will depend a little on how clear the model
in your head of how all this works is but I assume you did notice that
(for example):

user buit2.bu.edu 0 /dev/xy1e 0 16080 0
user buit2.bu.edu 1 /dev/xy1e 16080 41540 -1

means that buit2's root is /dev/nd0 and is allocated on /dev/xy1e and
starts at block 0 with length 16080 (~8MB.) Then the swap/page partition
comes right after that starting on 16080 and using about 20MB. Of course
pub and /tftpboot and /etc/ethers and /etc/hosts has to be set up right
(just follow the others), and /etc/yp/make should be run (I also think,
before you boot, you'll need to poke in the new host into the arp table
with /etc/arp, maybe that will just happen.)

Then you have to get the root newfs'd and put a suitable root on there.
The easiest way to do this is to shut down a diskless client, mount its
ndl? partition on the server (please, mount it read-only, otherwise you'll
make me nervous, or at least back it up first) and just use 'dd' to copy
the whole mess to the new client's ndl? partiton (remember to re-run
'/etc/nd - < /etc/nd.local' first so the changes take effect.) Then fsck
the fresh ndl? partition and mount it and edit the requisite files
(/etc/rc.boot, /etc/hosts) so it takes on its new identity.

Of course, you'll need the spare space to put it on. *BE CAREFUL* if your
nd partitions refer only to the c partition (xy0c,xy1c) you almost
certainly cannot just extend it as the 'c' partition maps the whole disk,
you could overlap a following disk partition and you'll be sorry you tried
(you'll crunch the partition fatally.) You can use /etc/dkinfo to verify
this, but you better know how to interpret the results. If you allocate an
already existing partition for this make sure you never mount it again as
a regular disk partition (remove it from /etc/fstab.)

I can understand why the Sun support person gave the advice s/he did, it's
more than mildly fraught with peril and details, but we've done it here
more than a few times. I'll guarantee you I forgot something in the above
description, or wasn't very clear somewhere.

I would agree that there should some procedure for adding new nd clients
(at least when) using a fresh disk partition.

-Barry Shein, Boston University

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

Date:    Tue, 19 Jan 88 12:30:02 EST
From:    Mike Jipping <jipping at frodo.cs.hope.edu>
Subject: Re: EPSON Printer Problems

>...The bug is this:
>
>    a) Occasionally, the print is skewed, almost like italics, and
>    seemingly at random.
>
>    b) When I try to send a screendump to the printer, the first few
>   'lines' of output look O.K. (e.g Namestripes from windows come out
>    alright,icons at the top of the screen, etc.) but then the printer
>    mysteriously jumps into an odd mode and prints garbage ( e.g. strange
>    looking escape sequences and other oddities).

Check your settings in "/etc/printcap".  I run an Epson FX-86e off of my
Sun 3/50.  When I first set it up, I had the identical problems -- the
random italics REALLY confused me.  The problem was that the spooler was
spooling with parity -- which the Epson, which was set to ignore parity,
interpreted as accessing characters >127 ASCII, i.e., the italics
character set.  Thus, characters with the parity bit on (for even or odd
parity) were printed in italics!

I added a "fc#0300" and "xc#40"  to the printcap entry to shut off all 
possible parity conflicts.

[[ Ummm....Don't you mean "fs#0300", which would set "any parity"?  And
"xs#040", which would set LITOUT mode?  (The leading 0 tells printcap that
it's an octal value.)  Actually, turning on LITOUT *should* force no
parity, regardless of the settings for EVEN and ODD.  Out of curiosity,
what would turning off both EVEN and ODD parity mean?  It's quite possible
that either one will work.  --wnl ]]

Good Luck.

-- Mike Jipping
Department of Computer Science
Hope College
jipping at cs.hope.edu

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

Date:    20 Jan 88 07:23:34 GMT
From: tombre at crin.crin.fr (Karl Tombre)
Subject: Thanks & Summary (sun.com problem in sendmail)

Many thanks to the people who answered with hints and advices.  Other
people had the same problem and asked for feedback so here is a summary.

1) It was not
   - an old sendmail.fc superseding the sendmail.new cf
   - a CDsun and DUcom somewhere in the sendmail.cf

Our sendmail.cf has nothing to do with the original one coming with the
Suns. It is an adaptation of a sendmail.cf written by rd at lri.lri.fr here
in France for domain addressing.

2) It was a strange interference of the YP "domainname", in spite of the
fact that "man domainname" on the Sun says that domainname is not used
anywhere else than in the yellowpages !!! John Gilmore (gnu at hoptoad) and
Steve Alexander (stevea at laidback) both pointed out the problem. Many
thanks for them. Here are parts of John Gilmore's answer. He also named
one person at Sun who took ths decision - I don't know if the latter would
be pleased to be named publicly, so I call him XX in this copy of gnu's
mail. But I would be glad if he or some other people at Sun explained why
the things are laid out this way:

-------
This bug occurs if you use a networked /usr/lib/aliases file (via the
yellow pages) and you have names in it that are not fully qualified with a
hostname.  It adds the YP "domainname" as the hostname.  I tried to tell
XX that tying YP domainnames to mailer domainnames was a horrible idea but
he didn't see it that way.  To see if this is the problem, try running
"domainname" on your suns and see if it says "sun.com".  If so, that's the
problem.

You might be able to talk XX into fixing it -- send him mail at [address
deleted].  If not, you can circumvent the problem by putting your full
address, including hostname, into the aliases files.

(I used to maintain sendmail at Sun.)

	John Gilmore

-------

Our YP domainname is sun!!! From John Gilmore's answer, there are 2 ways
of circumventing the problem :

   - change the domainname to name a REAL machine on OUR network
   - put full adresses (i.e. tombre at crin.crin.fr for instance) in the
aliases. That's what we are doing right now.

Steve Alexander gave a third solution: simply use a synonym in /etc/hosts.
Here is parts of his mail:

-----
What is the name of your YP domain?  When I worked at NCSA, our YP domain
was "planets".  Every once in a while, an error return would be sent to
winckler at planets.  I think that this turned out to be fixable by adding
planets as a synonym for the the server machine (newton) in /etc/hosts and
remaking YP.  So, if your YP domain is "Sun.COM" (which seems very
unlikely), this may be that problem.

-------

NB : it was not sun.COM but sun ; the .COM was added on its way back with
an error message, when the local message had traveled to California, to
the real "sun" machine (half ;-)

--- Karl Tombre @ CRIN (Centre de Recherche en Informatique de Nancy)
EMAIL : tombre at crin.crin.fr  --   tombre at crin.UUCP
POST  : Karl Tombre, CRIN, B.P. 239, 54506 VANDOEUVRE CEDEX, France
PHONE : +33  83.91.21.25

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

Date:    20 Jan 88 15:51:34 GMT
From:    km at emory.UUCP (Ken Mandelberg)
Subject: New Sun Disk Drive

Sun just announced a 892 Meg, 9 inch SMD drive. Does anyone
know the manufacturer and model number?

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

[[ I have received a press release announcing the product, but it doesn't
answer your question.  Oh well.  --wnl ]]

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

Date:    Wed, 20 Jan 88 12:52:22 GMT
From:    bowen%prg.oxford.ac.uk at nss.cs.ucl.ac.uk
Subject: newstool for Suns

Here is a "newstool" shell script to run "rn" in a SunView window.  Two
icons are also supplied to indicate "news" and "no news", in a similar way
to the Sun "mailtool". Feel free to distribute and/or archive this if you
think this is appropriate.

Jonathan Bowen
Programming Research Group
Oxford University
England
JANET: bowen at uk.ac.oxford.prg
ARPA:  bowen%prg.oxford.ac.uk at nss.cs.ucl.ac.uk
UUCP:  ...!uunet!mcvax!ukc!ox-prg!bowen

[[ It has been placed in the archives as "sun-source/newstool.shar".  It
can be retrieved via anonymous FTP from the host "TITAN.RICE.EDU" or via
the archive server with the request "send sun-source newstool.shar".  For
more information about the archive server, send a mail message containing
the word "help" to the address "archive-server at rice.edu".  -wnl ]]

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

Date:    Thu, 21 Jan 88 09:26:47 CST
From:    blu at sc.msc.umn.edu
Subject: HP Laserjet filters:  Oops, I forgot the printcap

What can I say, Oopps.   I forgot the printcap file like I promised.
Anyway, this is the full distribution.

---- end apology
---- start corrected file

Here are all the files that I use with our HP LaserJet Series II.  This
includes the printcap file, two nroff files (one for the banner, one for
accounting) and a rasterfile filter.  The latter is great with the
dumpregion utility.  I wrote the above filters, so if there are any
suggested enhancements, or any bug reports, please let me know.

Brian Utterback     |UUCP:{ihnp4!cray,sun!tundra}!hall!blu | Think of it as
Cray Research Inc.  |ARPA:blu%hall.cray.com at uc.msc.umn.edu |  evolution in
One Tara Blvd. #301 |                                      |     action
Nashua NH. 03062    |Tele:(603) 888-3083                   |

[[ The copy in the archives has been updated.  It is stored as
"sun-source/hp-filters.shar" (honest).  Archive server users can retrieve
it with the command "send sun-source hp-filters.shar".  --wnl ]]

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

Date:    Wed, 20 Jan 88 11:37:51 EST
From:    Graham Campbell <gc at bnl-ewok.arpa>
Subject: Program to help keep utmp clean

Since the question of cleaning out the pseudo-tty entries from utmp has
arisen again (Sun-Spots v6n5),  I will contribute a small program that I
run from my .logout that does this.

Graham
---------------------------------------------------------------------------
#include <utmp.h>
#include <sys/file.h>
#include <stdio.h>
char    master[11] = "/dev/pty??";

main()
{
    struct utmp ut;
    int     utmp, pty;
    long    posn;

    utmp = open("/etc/utmp", O_RDWR);
    if (utmp == -1)
    {
        perror("Cannot open utmp");
        exit (1);
    }
    while (posn = lseek(utmp, 0L, L_INCR), read(utmp, &ut, sizeof(ut)) != 0)
    {
        if (ut.ut_name[0] == 0)
            continue;
        if (strncmp(ut.ut_line, "tty", 3) == 0 && (ut.ut_line[3] == 'p' ||
                           ut.ut_line[3] == 'q' || ut.ut_line[3] == 'r'))
        {
            master[8] = ut.ut_line[3];
            master[9] = ut.ut_line[4];
            pty = open(master, O_RDWR);
            if (pty >= 0)
            {
                close(pty);
                lseek(utmp, posn, L_SET);
                ut.ut_name[0] = 0;
                ut.ut_host[0] = 0;
                write(utmp, &ut, sizeof(ut));
            }
        }
    }
}

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

Date:    Tue, 19 Jan 88 12:36:57 EST
From:    Christopher Byrnes <cb at mitre-bedford.arpa>
Subject: "iebark" errors on Sun 3

We are a Sun 3 installation which has recently had major problems with a
new Sun 3/280 we have connected to our network.  This Sun 3/280 will
occasionally output system console messages of the form "iebark: ...",
resulting in all the other Suns on the network being unable to communicate
with the 3/280.  The 3/280 continues to run as if nothing has happened.
The problem at first appeared to be stress-related, the surest way to
cause this "iebark" error was to have one user logged onto the 3/280 and
running a large process (such as an Ada compiler) while another user on
another Sun tried another large process which had to access files on the
3/280's disks.

Things seem to be getting worse and worse.  Repeated visits by Sun
(resulting in almost every board on the 3/280 being replaced) have not
solved the problem.  Now other things are starting to break (such as `ls'
always dumping "core").  Has anyone else seen this problem and (hopefully)
know of a solution?  Christopher Byrnes The MITRE Corporation Burlington
Road M/S A156 Bedford, Mass. 01730

cb at Mitre-Bedford.ARPA
...!decvax!linus!mbunix!cb.UUCP

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

Date:    20 Jan 88 22:09:17 GMT
From:    Randy Hammel <rsh at mimsy.umd.edu>
Subject: Which sun to use with a Telebit Trailblazer?

We at the SRC are looking at joining UUNET.  We would like to use the
Telebit Trailblazer connected to one of our Suns.  Does anybody have
experience as to which of the following would be best?

	- A sun 3/140 (4MB) dedicated to using the Trailblazer 
	  connected to the serial port.  Data would be to an NFS
	  file system on the fileserver (see below)

	- A sun 3/280s (16MB) This server serves user home directories and
	  spool areas for ~5 little suns.  The Trailblazer could use either
	  the default serial port or a port on the ALM.

We expect to use UUNET as a news feed, and for a little bit of mail.  Due
to the current moving at Univ. of Maryland please respond directly to
both:

	rsh at mimsy.umd.edu   &   rsh at super.org

We'll post the consensus to the group at a later time.

Randy Hammel
IDA Supercomputing
Research Center

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

Date:    20 Jan 88 21:46:40 GMT
From:    ut-emx!jezebel at ut-sally.UUCP (Jim Delaney)
Subject: COMPARING apollo and sun WORKSATIONS

Ladies & Gentlemen,

I would like to know if someone has published a detailed listing of
graphics and other software available for the APOLLO & Sun workstations.
Aside from merely name listings, I would also be interested in finding out
about the details of the software.

REASON: we are planning to buy a workstation. The machines in
consideration are the APOLLO and the Sun 3. Any further information that
you feel is relevant is welcome.

Any idea about the possibility of 3D graphics capacities of these
workstations ?

Thanks for the information,
Jim

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

Date:    Tue, 19 Jan 88 17:08:24 MST
From:    davis at groucho.ucar.edu (Glenn P. Davis)
Subject: XDR on Cray COS and IBM VM/CMS

Hi. We are working on file format for scientific data that will be
transportable across machine architectures and operating systems.  This
simply uses tagged data types and XDR. (eXternal Data Representation)

In order for this to be accepted in our in environment, We have to make it
work on Cray COS (not unicos) and IBM VM/CMS. 

If anyone has attempted to port XDR to either of these systems, I would
like to hear from you.

Thanks.

Glenn P. Davis		davis at groucho.ucar.edu (128.116.40.3), hao!davis
UCAR / Unidata
PO Box 3000                   1685 38th St.
Boulder, CO 80307-3000        Boulder, CO  80303

(303) 497 8643

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

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



More information about the Comp.sys.sun mailing list