Sun-Spots-Request@RICE.EDU (William LeFebvre) (04/27/88)
SUN-SPOTS DIGEST Tuesday, 26 April 1988 Volume 6 : Issue 66
Today's Topics:
Re: how to tell if you're running under suntools
Default route problem
Sendmail.cf talking to itself
I have a DECnet mailer
Magic on sun4
bug in OS 3.5
deskside Suns and acceptable noise levels
fsck clears unref'd inodes, files still there
Yp problem. "server not responding..."
problems with VMS fortran
macro assembler for Suns?
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: 18 Apr 88 19:05:22 GMT
From: mkhaw@teknowledge-vaxc.arpa (Mike Khaw)
Subject: Re: how to tell if you're running under suntools
> Does anybody know how to have a .login know whether it is being
> executed
> a) from console .login
> versus
> b) from suntools window creation
>
> I have commands I wish executed in one case, but not the other.
(a) .login only runs when you login, not when you start a shell/cmdtool in
suntools. However, If you want to find out from .login if you are on the
console so that you can decide if it's ok to run suntools, do something
like
if (`tty` == /dev/console) then
suntools
endif
[[ Isn't that what *I* said? --wnl ]]
(b) According to Sun s/w support, the env. variable WINDOW_PARENT is
always set if you're running under suntools, so you could
if ($?WINDOW_PARENT) then
echo "running under suntools"
endif
Mike Khaw
internet: mkhaw@teknowledge-vaxc.arpa
usenet: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa
USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
------------------------------
Date: Mon, 18 Apr 88 11:02:26 PST
From: jimc@math.ucla.edu
Subject: Default route problem
Serial number 628c0890, 3-180 running SunOS v3.4.2 (unhacked).
A site has a second Ethernet board (ie1) which is connected to nowhere and
has not been activated with /etc/ifconfig. Its /etc/rc.local executes
"/usr/etc/route add default 128.97.64.16 3" (yes, 3 hops to the ARPAnet).
By matching the internet address on the board (0.0.0.0) with the address
on the destination (default = 0.0.0.0), /usr/etc/route finds a perfect
match and sends the default packets off to nowhere via ie1.
A successful workaround was to do "/etc/ifconfig ie1 128.97.64.21 down".
First, the matching should be on the gateway address, not the final
destination. Second, we have at least one pair of machines (gateways)
that can communicate over two networks, and we care which is used, so it
would be best if /usr/etc/route could be told which interface to use.
We are not using route-daemon because other groups on our net have a
different definition of "default" (i.e. everything not on our net) and,
therefore, a lower hop count. They then offer to gateway our ARPA
traffic, which we don't need. The problem seems to be in the definition
of "default". A possible workaround is to agree on a fixed, large hop
count for "default", like 16, except for the gateway, so only the real
gateway will be used to "default". This requires a cooperative gateway;
ours doesn't even HAVE "routed".
Vahe Sarkissian of UCLA-Mathnet found what was causing the "route" bug.
See <net/routes.h>.
James F. Carter (213) 825-2897
UCLA-Mathnet; 6608B MSA; 405 Hilgard Ave.; Los Angeles, CA 90024-1555
UUCP:...!{ihnp4,ucbvax,sdcrdcf,{hao!cepu}}!ucla-cs!math.ucla.edu!jimc
ARPA: jimc@math.ucla.edu BITNET: jimc%math.ucla.edu@INTERBIT
------------------------------
Date: Mon, 18 Apr 88 11:38:14 PST
From: jimc@math.ucla.edu
Subject: Sendmail.cf talking to itself
> From: Doug Moran <moran@ai.sri.com>
----- Transcript of session follows -----
>>> HELO pebble
<<< 553 pebble I refuse to talk to myself
554 <random@[192.12.5.67]>... Service unavailable
> ... Whatever the cause, the
> remote mailer sends the message to "pebble" with an address of
> "random@[192.12.5.67]" on the envelope. "pebble" then attempts to deliver
> the mail to host address 192.12.5.67 (itself), and detects a potential loop.
In our sendmail.cf (by Dorab Patel <dorab@cs.ucla.edu>) we have a line to
canonicalize the recipient's address using the nameserver, whereby pebble
would have translated [192.12.5.67] into pebble, recognized it, and
delivered the mail locally. Unfortunately it doesn't work on the
Sun-issue sendmail (SunOS v3.4.2); it does work on the 4.3BSD sendmail.
The UCLA CS department has hacked their Sun sendmail, and there is a
possibility of support for Suns in the next Berkeley release of sendmail,
soon to be available for anonymous FTP from ucbarpa.berkeley.edu. Here is
the line, at the very beginning of ruleset zero:
R$*<@[$+]>$* $:$1<@$[[$2]$]>$3 try conversion to name
James F. Carter (213) 825-2897
UCLA-Mathnet; 6608B MSA; 405 Hilgard Ave.; Los Angeles, CA 90024-1555
UUCP:...!{ihnp4,ucbvax,sdcrdcf,{hao!cepu}}!ucla-cs!math.ucla.edu!jimc
ARPA: jimc@math.ucla.edu BITNET: jimc%math.ucla.edu@INTERBIT
------------------------------
Date: 18 Apr 88 18:57:49 GMT
From: laic!darin@decwrl.dec.com (Darin Johnson)
Subject: I have a DECnet mailer
In regards to sending mail between suns with Sunlink/DNI and VAX/VMS, I
have written such a monster. It has not been thoroughly tested, but I
have not seen any 'real' problems with it. It started out as work with
the 'dnamail' program, but essentially rewritten (since I lost the
original), and is much more usable. In essence, it interfaces to
sendmail, so you don't have to use an explicit command to send mail to the
VAX, and your Sun can act as a gateway. It also receives mail from the
VAX (which sendmail can forward to UUCP, etc.).
The only problem I have had is with the sendmail configuration. What I
wanted to do was to have 'simple' changes to sendmail.cf to do everything.
The problem was that I wanted to say "vaxnode::user" and have everything
work. Turns out that there are quite a few nodes out there that will muck
up an address like "a!b!c!d!vax::user" (it gets turned into vax..user).
Instead I recommend "vaxnode.decnet!user" to my users. The "::" works
fine locally, so I still use it. I have had mail forwarded from the Suns
to my VAX account for some time now with no problems (and vice-versa for
some Sun users).
I will post this sometime soon when I get documentation/etc finished. I
will probably post to comp.sources.misc since I feel that is more
accessible than the Rice archive server (I can probably put the stuff
there also).
(If anybody is ambitious and/or has Sun source, I have a rudimentary print
filter that prints to VMS systems - such as cheap band-printers/etc. It
really needs work and I don't know that much about UNIX print queues. If
anyone wants to work on this, let me know and I will send you the sources
(and exec for VMS side if you don't have Bliss compiler))
Darin Johnson (...lll-lcc.arpa!leadsv!laic!darin)
(...ucbvax!sun!sunncal!leadsv!laic!darin)
All aboard the DOOMED express!
------------------------------
Date: Mon, 18 Apr 88 15:00:00 EDT
From: Jack V. Briner <jvb@cs.duke.edu>
Subject: Magic on sun4
We have attempted a port of magic (a VLSI layout tool from Berkeley). We
were pretty successful except that it has trouble with plow.
Berkeley no longer supports magic. Is there anyone out there that has
made a sun4 port of magic? (Does plow work?)
Thanks,
Jack
jvb@cs.duke.edu
------------------------------
Date: Mon, 18 Apr 88 14:59:24 MDT
From: lee@turing.unm.edu (Lee Ward)
Subject: bug in OS 3.5
Ever try putting a second disk on the controller and NOT configuring it
into the kernel? While this isn't very useful it probably should return
ENODEV (or whatever) when you access it, instead of crashing.
--Lee
p.s. Where does one mail bugs with suns "officially"? Here?
[[ Officially? No, not here. Sun-Spots is not affiliated in any way with
Sun Microsystems (except for a mutual interest in their products). Try
"sunbugs@sun.com". --wnl ]]
------------------------------
Date: Mon, 18 Apr 88 14:58:41 PDT
From: Doug Moran <moran@ai.sri.com>
Subject: deskside Suns and acceptable noise levels
This is simply an FYI item (and call to arms) for those who might be
concerned with this issue. I do NOT want to start a discussion in this
newgroup and I especially do not want to get a lot of messages back!!!!!!
Anyone who has similar concerns should express them directly to Sun, e.g.,
through their sales representatives.
FLAME ON.
Remember, this is a marketing issue not a technical one, so the
relevant factor will be the quantity and intensity of the response,
rather than the quality of the opinions expressed.
FLAME OFF
BACKGROUND:
-----------
Almost everyone I know regards the Sun-x/160 and Sun-x/260 packages
(deskside cabinet on wheels) as far too noisy to put in an office. The
few such system that we have have been put in computers rooms with
consoles in people's offices (cabling such system has been discussed in
previous issues of Sun-Spots digest). When we need more
slots/cooling/power than is provided by the 110/140/150 packaging, we
prefer to buy the 180/280 (rack-mounted) packaging over the 160/260
packaging and add a monitor. Since the CPU will be going in a computer
room anyway, rack-mounting has multiple advantages for us: better use of
floor space, better protection of cabling, easier access to SMD disks,
cheaper mounting hardware for SMD disks (the second (disk) cabinet in a
160/260 is quite expensive).
PROBLEM:
--------
In my discussions with various people at Sun, I have repeatedly
encountered the belief that these packages are suitable office systems,
and that the objections to the noise levels that I report are not
widespread. Consequently, the 180/280 packaging is regarded by Sun as for
servers only. This has the following side-effects:
-- monitors are not offered as part of packages on a 180/280 system
and thus addding a monitor to a 180/280 costs more than a comparable
160/260 system. For example, adding a HM monitor to a 280 costs $4K
(list), but a 260HM package costs only $3K more than a 260S package
(in addition to a 180/280S costing $1K more than a 160/260S).
-- only large-capacity, high-performance disks are offered in packages
with the 180/280 systems. Disks reasonable for a single-user
workstation will be offered only with 160/260 configurations.
-- Sun will continue to ignore the problem of extending the console
cables. The next generation of monitors and keyboards may well be
significantly harder and/or more expensive to operate at a distance.
Part of the problem is apparently due to the 160/260 and the 180/280 being
handled by different groups in marketing.
Doug Moran
AI Center, SRI International
------------------------------
Date: Mon, 18 Apr 88 18:29:13 MDT
From: dbd@benden.lanl.gov (Dan Davison)
Subject: fsck clears unref'd inodes, files still there
Along with the accompanying note about problems with ypbind, we also have
a problem when rebooting after one of the ypbind-inspired crashes. On the
server, the fsck after reboot occasionally says that inode x is
unreferenced and clears it. On clients, once this cleared inode was
/etc/services. So, since then I check all the inodes it reports it
cleared.
Now for the strange part: the vast majority of the time *on clients*, fsck
lies. It claims the inode is cleared, but when I go looking it exists and
the contents of the file or directory pointed to are fine.
Anyone have any idea why? I thought fsck on clients only looked at /,
/etc, and (maybe) /pub. Files in / and /etc certainly can go away, but
frequently the inode numbers are in remote-mounted file systems! Even
when they are *not*, the file is usually intact.
Thanks in advance,
dan davison theoretical biology t-10 ms k710 los alamos national
laboratory los alamos, nm 87545 dd@lanl.gov ...cmcl2!lanl!dd
------------------------------
Date: Mon, 18 Apr 88 18:26:50 MDT
From: dbd@benden.lanl.gov (Dan Davison)
Subject: Yp problem. "server not responding..."
We've been having an intermittent but annoying problem with yellow pages
that the folks at Sun have not been able to solve. The problem: the error
message
"yp: server not responding for domain biocomp, still trying".
When the message comes it's bad news for the server(s) or client(s) it
appears on because within 5 minutes no one can log in and commands like
"ls" are not executed. The *only* way to get out of this is to reboot the
afflicted machine(s).
Background:
We have 2 Sun-3/280s, one with 2 ALM-1s, 4 Fujitsu 2333s and 1 2344 run
off of Xylogics 451 controllers. The OS is 3.4.2; we can't trust Sun
enough to upgrade (Also, some of our device drivers are for 3.4 only). We
are also running with subnetting, and there is assorted bric-a-brak on the
backplanes (Tek color printer board, frame buffer).The clients are all
ndiskless 3/50s. One server is the master yellow pages server with the
other as a slave. If the master goes down for any reason, the "yp: server
not..." message comes up almost immediately (within 3 minutes) on the yp
slave. Doing a "ypset 128.165.24.xxx" (where xxx is the IP address of the
slave server) does not help. Sometimes the slave server can run for
several hours but people cannot log in.
The clients also have this problem, but there is no obvious pattern: the
client which has the "yp: server..." message varies. It has never been
the same one twice in a row. Nor have more than two clients hung (in
sympathy for their servers?) simultaneously. The client also does not
correspond to its NFS server, i.e. one of Genome's (the yp master) clients
will hang with the yp bug when Life (the yp slave) goes south, not one of
Life's clients.
Digging around on a hung system has revealed that there are *two* ypbinds
running, one low numbered (started at boot time) and another high
numbered, as if started recently. Even more strangely, if you watch (via
ps -aux | grep yp) the new ypbind dies *and a new one is created*.
My suspicion at this point is that some other process is creating ypbind
processes when the ypmaster goes away. These new ypbind processes look
around, realize they aren't bound to anything, print an error message, and
die. A few seconds later a new one is created, and on it goes. It
appears that the average lifetime of a new ypbind process is ~30 seconds,
and it takes 10-60 seconds for another to take its place.
I have two questions: (1) Has anyone else had this problem? (2) does
anyone know what daemon might be creating the extra ypbind processes & how
to stop it? Is every program that requests a yp service creating a new
ypbind? Why?
This has become very disruptive of our work--this problem happens 2-4
times per week--and the management, as they say, ain't pleased about this.
Thanks to all (and to wnl for his work moderating the list).
dan davison theoretical biology t-10 ms k710 los alamos national
laboratory los alamos, nm 87545 dd@lanl.gov ...cmcl2!lanl!dd
------------------------------
Date: Mon, 18 Apr 88 16:44:31 PDT
From: danq%sag4.ssl.Berkeley.EDU@jade.berkeley.edu (Daniel Quinlan)
Subject: problems with VMS fortran
We ordered the new unbundled VMS-compatible Fortran from Sun in December,
and were promised delivery by February 1. The product has still not
arrived, despite weekly inquiries. However, I was told today that the
delay was because I had ordered both a Sun 3 and a Sun 2 version. It
seems the Sun 2 version is not ready, and will not be for several months.
Meanwhile Sun has had it on the pricelist at least since October 5, with
no clue that it was not available. We were one of the early purchasers of
Sun equipment, and consequently we still have more Sun 2's than Sun 3's.
We try to maintain compatibility of the various machines by always
generating Sun 2 code. I think Sun needs to show more responsibility by
not marketing vaporware and by supporting the Sun 2 line.
Daniel Quinlan
Space Sciences Laboratory
UC Berkeley
------------------------------
Date: Mon, 18 Apr 88 13:16:06 EDT
From: ning@alaya.nyu.edu
Subject: macro assembler for Suns?
Could some one out there direct me to a good assembler with macros for Suns ?
------------------------------
End of SUN-Spots Digest
***********************