Sun-Spots Digest, v6n270

[William LeFebvre]

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 at y to y!x if y is a uucp neighbor (LONG)

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:    Tue, 18 Oct 88 10:24:37 CDT
From:    Jim Knutson <knutson%sw.MCC.COM at 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 at 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 at mcc.com
cs.utexas.edu!milano!knutson

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

Date:    Tue, 18 Oct 88 12:56:04 EDT
From:    Bennett Todd <bet at 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 at 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 at vax.cs.pittsburgh.edu

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

Date:    Wed, 19 Oct 88 08:08:48 EDT
From:    dunigan at 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 at 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 at qucis.bitnet
	levison at qucis.queensu.ca

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

Date:    18 Oct 88 17:15:34 GMT
From:    ehrlich at 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 at 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 at 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 at 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 at silvlis.com>
Subject: Re: How do I translate x at y to y!x if y is a uucp neighbor (LONG)

>  From:    lai at vedge.UUCP (David Lai)
>  
>  Another problem I have is that sending mail to 'foo at 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 at 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 at 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 at host.uucp
    R<@$=R.uucp>:$+	$#uucp  $@$1 $:$2		@host.uucp:...
    R$+<@$=R.uucp>	$#uucp  $@$2 $:$1		user at host.uucp
    # The following two rules allow addresses of the form user at uucpname
    # where uucpname is not in the host table. This is for those folks
    # that are too lazy to user user at uucpname. or user at uucpname.uucp .
    R<@$=R>:$+		$#uucp  $@$1 $:$2		@uucphost:...
    R$+<@$=R>		$#uucp  $@$2 $:$1		user at 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 at 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 at bar
	> 0 bar!foo
	> 0 foo at bar.uucp
	> ^D

Enjoy!

Mark D. Baushke                 Internet:    mdb%silvlis.com at sun.com
Silvar-Lisco, Inc.              Nameservers: mdb at 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
***********************