Sun-Spots-Request@Rice.edu (William LeFebvre) (10/24/88)
SUN-SPOTS DIGEST Sunday, 23 October 1988 Volume 6 : Issue 270
Today's Topics:
Re: M*cAPP file open tool
Re: mounting remote tape drives
Re: DEC LANBRIDGE 100/Sun 4 problems (2)
Multi-user SUN enquiry
Kernel paramters for streams?
SunView and System Console drivers?
Request: network layout help
Re: How do I translate x@y to y!x if y is a uucp neighbor (LONG)
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: Tue, 18 Oct 88 10:24:37 CDT
From: Jim Knutson <knutson%sw.MCC.COM@mcc.com>
Subject: Re: M*cAPP file open tool
Try getfile. It's a directory browser for Sunview and was announced in
Sun-Spots V5n13. The person who posted it was:
Bob Brown
RIACS
Mail Stop 230-5
NASA Ames Research Center
Moffett Field, CA 94035
rlb@riacs.edu
...!decwrl!riacs!rlb
and the sources were available from icarus.riacs.edu but no longer seem to
be there. I have a copy that I fiddled with to add a few more features so
I'll send it in for the archive.
Jim Knutson
knutson@mcc.com
cs.utexas.edu!milano!knutson
------------------------------
Date: Tue, 18 Oct 88 12:56:04 EDT
From: Bennett Todd <bet@bent.mc.duke.edu>
Subject: Re: mounting remote tape drives
MAKEDEV won't help. The device inodes contain major and minor device
numbers which are used as indices into tables in the locally-running UNIX
kernel -- there is no way for them to get translated into network
connection requests. There are a few choices for how to get around the
problem. I always use "rsh". So,
thismachine% tar cf - * | rsh othermachine dd of=/dev/rmt8 obs=10k
thismachine% rsh othermachine -n dd if=/dev/rmt8 ibs=10k | tar xf -
This isn't a very high-performance solution, but it is simple to
implement. If you are using dump such shenanighans shouldn't be necessary,
as dump(8) knows about the rmt(8) protocol, and so should be able to refer
to tape drives on other machines as "machinename:devicename" so:
thismachine% dump 0f othermachine:/dev/rmt8 /dev/xy0a
and that should be quicker. If you want to write your own command to
interface with it, you should be able to talk to an rmt(8) server on the
other machine. If you are using off-the-shelf software and it doesn't know
rmt(8) (dump/restore are the only ones I know which do) then the rsh(1)
solution is the only way I know.
Hope this helps!
-Bennett
P.S. NFS can't hope to do this for largely the same reason nothing else in
the BSD networking suite makes this transparently available: device I/O
characteristics are just about the least portable characteristic
system-to-system, and the BSD networking offerings as well as NFS are
reasonably portable. AT&T's RFS would allow you to mount another machine's
/dev and refer to devices in it correctly. As far as I know, RFS isn't
capable of spanning the breadth of inhomogeneous architectures that NFS
routinely connects. Also (and I think it is an independant issue, not
related to the device I/O) AT&T's RFS is a stateful server protocol
whereas NFS is a stateless server protocol. RFS fans claim it doesn't make
a difference. I claim that we just moved a Sun across the room; he
provides /usr/local for the network via NFS. The only people who noticed
that we had him shut down for a bit were the folks who tried to access
/usr/local in that time; everyone else continued business as usual, and
when we brought him back up folks could get to /usr/local again -- no
resetting required on the clients.
P.P.S. Actually there is an extremely obscure case where NFS can make a
magtape available over the network directly, though I haven't heard of
anyone exercising the required parts of the system in years, and they
might have decomposed into a puddle of disfunctional bits in the interim.
In principle, you can build a filesystem on disk, dd the raw partition
containing the filesystem onto a magtape, and then mount the magtape
filesystem readonly using the block device, something like
mount -o ro /dev/mt8 /mnt
It would be impressively slow, of course, probably worse even than DECTape
(which is designed to be accessible as a random-access block device). If
you did this, then you could export the mounted filesystem via NFS. Maybe
I'll have to try that just to see if that capability actually still
works....
------------------------------
Date: Tue, 18 Oct 88 15:23:03 EDT
From: hoffman@vax.cs.pittsburgh.edu (Bob Hoffman)
Subject: Re: DEC LANBRIDGE 100/Sun 4 problems (1)
In Sun-Spots Digest v6n256, Tom Arons of UC Davis reported a problem with
broadcast packets not being forwarded by DEC LANBridge 100s. We have
observed the same behaviour with the LANBridges, but not necessarily with
Sun-4s. Some combination of events, as yet untraced by us, will cause a
LANBridge to stop forwarding broadcast packets in one direction only.
This occurs with LANBridge firmware revision E. Older LANBridges with
revision D firmware do not exhibit this problem. DEC is aware of the
problem here at Pitt and is attempting to resolve it with new firmware
revisions. I suggest that Mr. Arons contact DEC as well.
Bob Hoffman, N3CVL {allegra, bellcore, cadre, idis, psuvax1}!pitt!hoffman
Pitt Computer Science hoffman@vax.cs.pittsburgh.edu
------------------------------
Date: Wed, 19 Oct 88 08:08:48 EDT
From: dunigan@msr.epm.ornl.gov (Tom Dunigan 576-2522)
Subject: Re: DEC LANBRIDGE 100/Sun 4 problems (2)
Newer models of DEC's LANBRIDGE 100 apparently will "learn" the broadcast
address if there is a sick engine on the Ether that emits packets with a
source addresss of all 1's (broadcast). Having stashed the broadcast
address in its filter table, the LANBRIDGE will no longer pass broadcast
packets, so engines behind the LANBRIDGE that require broadcast (e.g. ARP)
no longer work! (We had a sick microvax 2000 that would issue the bogus
packets with broadcast source address occasionally and gum up three or
four of our LAN100s) Older LAN 100s survive. I think DEC may have a ROM
patch or some such, but the only recourse is to restart the LAN100 (can be
done remotely however)
AND, of course, see if you can "catch" the engine that is sending packets
with a broadcast source address -- a challenge!
------------------------------
Date: Mon, 17 Oct 88 16:01:36 EST
From: levison@QUCIS.BITNET
Subject: Multi-user SUN enquiry
We already operate a network comprising 40 to 50 SUN3s. We are now
considering the installation of additional SUNs to provide for first year
undergraduates. The new facility must support about 30 alphanumeric
terminals, and have 600+ MB of disk. The job mix is very predictable. At
peak times, most of the users (say, 24-25) will be engaged in full-screen
editing, and a few (say, 5-6) in compiling short programs with a high-
speed compiler (probably Modula-2 or Turing). The cpu time for running the
compiled programs is negligable.
A similar facility, which has been in use for the last two years by upper
year students, consists of two 8MB 3/160s, each its own SuperEagle disk
and 16-port ALM. We could simply duplicate this (with newer disks), but a
single 3/260 or 4/260 would be cheaper.
My question: does any reader have experience in using a single 3/260 or
4/260 for 30 users (especially users of this kind)? What size of memory do
you have? Will a single large disk (700 or 890 MB drive) do the job, or
would two smaller drives be better?
Please reply by mail to either of:
levison@qucis.bitnet
levison@qucis.queensu.ca
------------------------------
Date: 18 Oct 88 17:15:34 GMT
From: ehrlich@shire.cs.psu.edu (Dan Ehrlich)
Subject: Kernel paramters for streams?
Yesterday the console on our Sun 4/260 started to spit out
stropen: out of streams
everytime someone tried logging in. At the time there were 20 people
logged in over the net and 8 logged in through an ALM-II. 'netstat -m'
reported 183 'stream allocation falures', etc, etc.
After poking around a bit and looking at /sys/conf.common/param.c we came
across the following:
/* @(#)param.c 2.34 88/02/08 SMI; from UCB 6.1 83/07/29 */
[text deleted]
/*
* Stream data structures.
* XXX - should be dynamically allocated.
*/
#define NBLK4096 0
#define NBLK2048 32
#define NBLK1024 12
#define NBLK512 8
#define NBLK256 32
#define NBLK128 96
#define NBLK64 240
#define NBLK16 400
#define NBLK4 128
#define NBLK (NBLK4096 + NBLK2048 + NBLK1024 + NBLK512 + NBLK256 + NBLK128 + \
NBLK64 + NBLK16 + NBLK4)
#define NSTREAM 32
#define NMUXLINK 87
#define NSTRPUSH 9
#define NSTREVENT 256
#define MAXSEPGCNT 1
#define STRLOFRAC 80
#define STRMEDFRAC 90
#define STRMSGSZ 4096
#define STRCTLSZ 1024
/*
* Number of STREAMs queue pairs to allocate:
* initial amount and subsequent increment(s).
*/
#ifndef QUEUE_INIT
#define QUEUE_INIT 100
#endif QUEUE_INIT
#ifndef QUEUE_INCR
#define QUEUE_INCR 10
#endif QUEUE_INCR
int queue_init = QUEUE_INIT;
int queue_incr = QUEUE_INCR;
struct stdata streams[NSTREAM];
struct stdata *streamsNSTREAMS = &streams[NSTREAM];
[text deleted]
It appears that not only is the number of streams NOT dependent on
MAXUSERS, number of pseudo-ttys, or anything else. In order to get around
the current problem we just upped NSTREAM to 48, until we can figure out
what a reasonable formula for it should be.
Has anyone else seen this happen? What if anything was done to fix it?
Can anyone at Sun explain why NSTREAM is fixed at 32?
Dan Ehrlich <ehrlich@psuvax1.{psu.edu,bitnet,uucp}>
The Pennsylvania State University, Department of Computer Science
333 Whitmore Laboratory, University Park, PA 16802
+1 814 863 1142 or +1 814 865 9723
------------------------------
Date: 18 Oct 88 19:21:24 GMT
From: uvm-gen!matrox!rob@uunet.uu.net (Robert Keller)
Subject: SunView and System Console drivers?
In my application, I require that a custom video controller become the
system console. I realize that during the 'power on' diagnostics this may
very well be impossible, but once the workstation is executing vmunix this
should be possible. Therefore, I need information regarding how to making
an arbitrary display controller the system console (i.e. how do I write a
system console device driver?) in a Sun-3, Sun-4, or 386i.
If the above is too tall an order, I would at least be able to run SunView
on the custom video controller. Since I already have a pixrect driver
this should not be too difficult, according to Appendix A of the Pixrect
Reference manual. However, the paragraph on page 70 fails to describe the
steps needed to redirect SunView programs to my pixrect driver. I've
searched through all the related manuals I have, and still no luck...
To recap:
How do I write a console device driver for a Sun-3, Sun-4, 386i?
How do I get SunView to run on an arbitrary Pixrect driver?
many thanks for any help/pointers,
Robert Keller (514) 685-2630 x318
Matrox Electronic Systems uunet!uvm-gen!matrox!rob
Moores, N.Y. 12958 onfcanim!matrox!rob
------------------------------
Date: Tue, 18 Oct 88 09:24:55 edt
From: harvard!ulowell!cg-atla!duane@cs.utexas.edu (Andrew Duane)
Subject: Request: network layout help
I am about to undertake a large scale reorganization of our lab full of
Suns. We have about 60 Suns, mostly clients hanging off of 5 servers. Our
problem is that the current topology sort of "evolved" randomly as new
people would get workstations, and would just grab some cable to connect
them. This is no longer acceptable, as some servers are S-L-O-W and some
zip right along. Disk space is also becoming a factor.
What I am looking for are some heuristics (or *heuristics) to determine
optimal client configuration given:
1) Impact of number of clients on a server
2) Impact of number of NFS mounts of server file systems
3) Impact of being a gateway
4) Number of disks to hang on a server.
In other words, we know that ND traffic slows down a server, and so does
NFS traffic. How do we balance the two to "even out" the load on a server.
Some of our NFS filesystems are exported to *EVERY* machine in the lab;
some are just exported to clients.
The information from programs like netstat and nfsstat are inadequate for
our needs. If someone has better programs, or has already derived numbers
for the various traffic patterns, I would be grateful.
Side note about increasing NTEXT in a kernel. The "proper" way to do it is
to edit the local param.c file for the specific kernel you want to change.
If you want to change them all, edit conf/param.c which then gets copied
to each private kernel directory. This is the way we do it, and it leaves
traces, unlike ADB patches to the kernel executable.
Andrew L. Duane (JOT-7) w:(508)-658-5600 X5993 h:(603)-434-7934
Compugraphic Corp. decvax!cg-atla!duane
200 Ballardvale St. ulowell/ \laidback
Wilmington, Mass. 01887 cbosgd!ima/ \cgeuro
Mail Stop 200II-3-5S ism780c/ \wizvax
------------------------------
Date: Tue, 18 Oct 88 00:52:39 PDT
From: Mark D. Baushke <mdb@silvlis.com>
Subject: Re: How do I translate x@y to y!x if y is a uucp neighbor (LONG)
> From: lai@vedge.UUCP (David Lai)
>
> Another problem I have is that sending mail to 'foo@bar' returns the
> message:
>
> bar - host unknown
>
> whereas bar is the name of a uucp neighbor. Can I tell sendmail to look
> at the output of uuname and translate foo@bar to bar!foo?
There are a number of ways to do this.
Using the "standard" sunos 3.5 sendmail.main.cf an address foo@bar.uucp is
equivalent to bar!foo so putting the address into the uucp domain will do
what you want. However, if you really do want to be lazy, you should be
able to modify your sendmail.main.cf by doing the following.
1) Add the following lines to your sendmail.main.cf file. They should
go near the top of the file where the lines defining the relay host
appear. For example:
# major relay host
DRsun
CRsun
# This assumes that no-one is adding uucp hosts to the list very
# often since $=R will only get updated when sendmail is started.
# Class $=R now contains the list of all direct uucp connections we have.
FR|/usr/bin/uuname
2) Then down in ruleset 0 ("S0") you should see a line that looks like:
# Explicitly specified names in our domain -- that we've never heard of
R$*<@$*.LOCAL>$* $#error $:Never heard of host $2 in domain $D.$U
Move this to be *after* the "# resolve UUCP domain" block and change the
UUCP domain block to look something like the following. Do NOT use the
$@pyramid unless you really talk to that machine. This was just an example
of how you might have more than one mail relay machine.
# resolve UUCP domain
#Note: These next two rules are handled after the domain check.
#R<@$-.uucp>:$+ $#uucp $@$1 $:$2 @host.uucp:...
#R$+<@$-.uucp> $#uucp $@$2 $:$1 user@host.uucp
R<@$=R.uucp>:$+ $#uucp $@$1 $:$2 @host.uucp:...
R$+<@$=R.uucp> $#uucp $@$2 $:$1 user@host.uucp
# The following two rules allow addresses of the form user@uucpname
# where uucpname is not in the host table. This is for those folks
# that are too lazy to user user@uucpname. or user@uucpname.uucp .
R<@$=R>:$+ $#uucp $@$1 $:$2 @uucphost:...
R$+<@$=R> $#uucp $@$2 $:$1 user@uucphost
# Explicitly specified names in our domain -- that we've never heard of
R$*<@$*.LOCAL>$* $#error $:Never heard of host $2 in domain $D.$U
# Pass other uucp names to the smart mailer on pyramid
R$+<@$-.uucp> $#uucp $@pyramid $:$2!$1 user@host.uucp
# If the domain is pyramid.com, use pyramid as our relay, not $R (sun)
R$*<@$*pyramid.com>$* $#uucp $@pyramid $:$1<@$2pyramid.com>$3
Note that in the above the machine "pyramid" may be replaced by $R.
Our site is connected to both pyramid and sun and have found that
pyramid finds uucp sites much better.
3) test out the resulting sendmail.main.cf using the -bt "test" switch
for sendmail. Where bar is a real uucp machine name from uuname.
% /usr/lib/sendmail -bt -Cnew.cf
> 0 foo@bar
> 0 bar!foo
> 0 foo@bar.uucp
> ^D
Enjoy!
Mark D. Baushke Internet: mdb%silvlis.com@sun.com
Silvar-Lisco, Inc. Nameservers: mdb@silvlis.com
1080 Marsh Road Usenet: {pyramid,sun}!silvlis!mdb
Menlo Park, CA 94025-1053 Telephone: +1 415 853-6411 / +1 415 969-8328
------------------------------
End of SUN-Spots Digest
***********************