Sun-Spots-Request@RICE.EDU (William LeFebvre) (05/09/88)
SUN-SPOTS DIGEST Sunday, 8 May 1988 Volume 6 : Issue 77
Today's Topics:
Re: Yp problem. "server not responding..."
Re: Experience with DECNET
Re: Detecting suntool invocation?
Re: gdbtool wanted (2)
Changes coming with 4.0
noisy machines
tty vs text windows: an update
newfs -N
gammontool
Verstec printer problems
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: Sun, 01 May 88 14:55:36 PDT
From: Craig Leres <leres%lbl-helios@lbl-rtsg.arpa>
Subject: Re: Yp problem. "server not responding..."
The problem has to do with figuring out who the ypmaster is. I think this
has something to do with a bug that causes sunrpc broadcast packets to be
sent to the gateway that the "default" route points to instead of being
broadcast. I didn't take the time to track this down. Instead, I modified
ypbind to never throw away the ypmaster. My version just patiently waits
for him to wake up. Since your ypmaster doesn't change every day and since
it's usually necessary to reboot the clients when it does, this works just
fine.
Appended is a context diff to /usr/src/etc/ypbind.c. I think I started
with a 3.3 source, but (except for the sccs date string) this it appears
to be identical to 3.5.
Craig
------
RCS file: RCS/ypbind.c,v
retrieving revision 1.1
diff -c -r1.1 ypbind.c
*** /tmp/,RCSt1a03710 Sun May 1 14:33:05 1988
--- ypbind.c Fri Jul 17 18:37:37 1987
***************
*** 1,4 ****
--- 1,6 ----
#ifndef lint
+ static char rcsid[] =
+ "@(#) $Header: ypbind.c,v 1.2 87/07/17 18:37:02 leres Exp $ (LBL)";
static char sccsid[] = "@(#)ypbind.c 1.1 86/09/24 Copyr 1985 Sun Micro";
#endif
***************
*** 451,457 ****
FILE *f;
if ((f = fopen("/dev/console", "w")) != NULL) {
! (void) fprintf(f, "%s.\n", s);
(void) fclose(f);
}
--- 453,459 ----
FILE *f;
if ((f = fopen("/dev/console", "w")) != NULL) {
! (void) fprintf(f, "%s.\r\n", s);
(void) fclose(f);
}
***************
*** 650,658 ****
--- 652,671 ----
}
if ((clnt_stat = (enum clnt_stat) clnt_call(pdom->ping_clnt,
YPPROC_NULL, xdr_void, 0, xdr_void, 0, timeout)) != RPC_SUCCESS) {
+ #ifdef notdef
pdom->dom_boundp = FALSE;
clnt_destroy(pdom->ping_clnt);
pdom->ping_clnt = (CLIENT *)NULL;
+ #else
+ {
+ char outstring[YPMAXDOMAIN + 256];
+
+ (void) sprintf(outstring,
+ "yp: server not responding for domain \"%s\"; still pinging",
+ pdom->dom_name);
+ writeit(outstring);
+ }
+ #endif
}
}
------------------------------
Date: Mon, 2 May 88 09:02:33 EDT
From: gfr%wolfgang@gateway.mitre.org (Glenn Roberts)
Subject: Re: Experience with DECNET
Cc: jipping@frodo.cs.hope.edu
Reference: v6n65
> We are considering getting DECNET for our network. I'm interested in
> experience others of you have had. We are interested in DECNET
> compatilibity for (a) faster/easier/more flexible mail delivery and file
> transfer, (b) better connections BOTH directions (SET HOST from the VAX ->
> Sun, as well as Sun -> VAX), and (c) wider access of peripherals BOTH
> directions (Sun users using VAX printers; VAX users using the Sun UUCP or
> laser printer).
The SunLink DNI product meets some (but not all) of your needs. With
regard to (a), there is no e-mail support. File transfer is implemented
on the Sun side with the dnacp command, unfortunately you will have to
type your password each time you copy to the VAX. Since the VAX world has
RMS, and Unix considers files to be simply byte streams, there is a file
format conversion problem. DNI gives you the -v switch to help handle
this problem; it allows you to copy binary files 'verbatim'. There is
also a dnals command for obtaining a directory listing off the remote VAX.
>From the VAX side, the Sun looks just like any other DECnet node.
Logging on to systems either way is straightforward. From the VAX you
simply set host ... From the Sun you simply dnalogin ... Users of vi on
our Suns have had a few problems when they log in from the VAX. It seems
that our VAX's LAT servers interpret <ctrl-f> as an attention key (to
start a new LAT session), so one has to learn to use <ctrl-d> to page down
in vi. Alternatively you could change the attention key on the LAT's.
With regard to peripheral sharing, the DNI product does not really give
you any utilities for doing this (it would have been nice, for example, if
Sun had provided a device driver to allow a VAX printer to simply look
like the sun's lp - I know of no way to do this, short of writing your own
device driver using the routines they provide). We have had some success
in approximating this capability using the dnacp command, for example my
printscreen capability is implemented as:
screendump -f /dev/bwtwo0 | lasersun | /usr/sunlink/dna/dnacp - 'mtr780::laser'
(where lasersun is a Sun raster to LN03 sixel conversion filter I have
written). I have also implemented a 'print' command on the Sun by putting
the following alias in my .cshrc:
alias print 'dnacp \!* "mtr780::lp:"'
Unfortunately, in both cases above we're logging in anonymously, so the
print flag page reads "GUEST" instead of the user's name. The only ways
around this are to enter your password each time, or embed it in the
script file, neither of which is acceptable.
This product is a bit disappointing in terms of breadth of capabilities.
I have worked with DEC's DECnet DOS (for the PC), and feel that it offers
a much nicer set of capabilites, including sending E-mail, copying and
submitting batch files, and disk and printer peripheral sharing. I was
surprised and disappointed that Sun did not offer at least an equivalent
set of functions with DNI. Of course, they do include a programmer's
guide and several complete examples (including the venerable TELL
program), so if you're ambitious you could write these programs yourself I
suppose.
Glenn F. Roberts
The MITRE Corporation
McLean, VA
gfr%wolfgang@gateway.mitre.org
------------------------------
Date: Mon, 2 May 88 12:29:35 edt
From: mp@allegra.att.com
Subject: Re: Detecting suntool invocation?
I'd like to ask a similar question - is there a way to tell if a program
is being invoked either on the console or under suntools, in other words,
that the program is being invoked from the Sun console?
Here's why: in some cases, an owner of a Sun needs to be user root or
group kmem to do certain things such as run halt, reboot, toolplaces,
rdate, or kill other users' runaway processes. But we'd like to reduce
the need for people to know the root password on their systems (too many
incidents of accidental YP spoofing and intentional NFS userid spoofing),
and the best suggestion seems to be to have a setuid root program that
will perform the above duties to anyone who's at the Sun console.
However, a way of reliably determining that a program has been invoked on
the console, in the face of a publically writable /etc/utmp and the
TIOCNOTTY ioctl, seems to have eluded us.
Mark Plotnick
allegra!mp
mp%allegra.att.com@att.arpa
[[ How about this: check to see if the user running the program (obtained
with a "getuid") is the same user that is logged on the console. The
latter would have to be obtained in a reliable manner, by finding the
console's login process and obtaining the ownership of that process (in a
manner similar to the way "ps" obtains its information). Or for that
matter, see if the console's login process is an ancestor of the current
process. That would work in almost all situations (the user could
intentionally orphan a tool---my remote login shell script does that).
All these solutions require mucking around in /dev/kmem, but there is
probably no other way to *reliably* do this. --wnl ]]
------------------------------
Date: Mon, 2 May 88 19:14:34 EDT
From: tower@bu-it.bu.edu (Leonard H. Tower Jr.)
To: jonathan@vax.cs.pittsburgh.edu
Cc: Sun-Spots@rice.edu
Subject: Re: gdbtool wanted (1)
Release 18.50 of GNU Emacs comes with a gdb-mode in lisp/gdb.el.
Release 2.5 of gdb (included with the above release of GNU Emacs) can be
built to run under X as xgdb. The X build needs updating to X11R2. Note
someone has just posted diffs to do this on comp.windows.x. Its,
obviously, not widely tested yet.
Your time would benenfit many more people if you worked on enhancing and
testing the two above gdb user interfaces, rather than hacking a gdbtool,
which can only be used by Sun users.
enjoy -len (aka a GNU hacker)
[[ Can *only* be used by Sun users? I guess that means we should all stop
writing any sort of tool to run under SunView. After all, Sun machines
aren't very common, are they? Neither gdb-mode nor the X version of gdb
can take full advantage of the SunView windowing interface. And let's not
get into a war about which window environment is better. That's not the
point. --wnl ]]
------------------------------
Date: Mon, 2 May 88 18:03:23 edt
From: umix!oxtrap!rich@rutgers.edu (K. Richard Magill)
Subject: Re: gdbtool wanted (2)
Why? Try gdb mode from emacs-18.50.
------------------------------
Date: Mon, 2 May 88 09:23:05 PDT
From: Stuart Cracraft <cracraft@hyper-sun1.jpl.nasa.gov>
Subject: Changes coming with 4.0
Many readers of this list may have heard of the upcoming release of a
major SUN operating system titled 4.0 -- but many may not have heard about
the many fundamental changes in Unix that are coming along with it.
It all looks very good, though there are some concerns, primarily related
to the filesystem reorganization mentioned below. This is paraphrased from
a release report.
There will be a massive filesystem reorganization. /usr/spool and
/usr/adm are gone -- instead there's /etc/spool and /etc/adm. (Those
of you who know how fast /usr/spool grows will see the implication of
placing this on the root filesystem.)
Also, /bin no longer exists! Its contents live in /usr/bin. Also,
/lib no longer exists. Its contents have been moved to /usr/lib.
Executables from /etc are in /usr/etc. Also, /usr is to be mounted
read-only.
Executables from the root directory reside in /single.
Comments anyone?
Stuart
[[ What are they going to do with executables like "cp" and "sh"? Put a
copy in both "/single" and "/usr/bin"? Or will we have to replace "/bin"
on our path with "/single"? The former sounds like a waste of disk space
and the latter seems to have no advantage. --wnl ]]
------------------------------
Date: Sun, 1 May 88 12:47:32 BST
From: Dr R M Damerell (RHBNC) <damerell@nss.cs.ucl.ac.uk>
Subject: noisy machines
1. I believe that individual machines of the same model differ a lot in
the amount of noise they make; and the same machine that sounds OK in a
crowded exhibition will be quite different in your office when you are
trying to work. Subject to the above I believe the SUN 3/60 is not
significantly different from the /260.
2. My question is: I am very anxious to move the machine into another
room. What is the greatest length of cable I can have between CPU and
(monochrome) monitor? Please could anybody give advice on cables (e.g.
Belden number)? Many thanks. Mark
------------------------------
Date: Mon, 2 May 88 13:57:41 EDT
From: Nathan H. Hillery <nhh@cs.duke.edu>
Subject: tty vs text windows: an update
Ahhh! What wonders one can discover by (really) reading the manual!
In answer to my own questions a few weeks ago, I have the following
information. In Defaults_edit under the Text category, there is an option
entitled "Edit_back_char" that has a default value of "\^?" (DELETE).
Simply by changing the value of this to "\^H", one's backspace character
in ALL text windows becomes CONTROL-H. (Well, to be more precise, you must
change it, save the new set of defaults, and re-run suntools)
Also, in my search to make text windows more like tty windows (especially
in regard to cut and paste) I have made some headway. The function keys
allow one to do many operations (and aren't as cumbersome as I thought).
Additionally, by setting "Initial_selection" to "Last_selection" (under
Defaults_edit category Menu) you can get essentially the same
mouse-directed cut_and_paste functionality you have in tty windows.
With this change, you will have to "prime the pump" by initially doing the
first put_then_get yourself. After that, a single mouse-key click will
get the text that was previously grabbed.
If any of this makes sense to you seek professional help :-) If not, the
read "Window and Window Based Tools: Beginner's Guide". The function keys
are well documented there (pages 65-90). If what I say still doesn't make
sense then you can mail to me.
Nate.
P.S. Thanks to all that sent personal replies, they are much appreciated.
Nathan H. Hillery PHONE: (919) 684-5721
Dept. of Computer Science CSNET: nhh@duke
Duke University UUCP: decvax!duke!nhh
Durham NC 27706-2591 USA ARPA: nhh@cs.duke.edu
------------------------------
Date: Mon, 2 May 88 14:47:16 EDT
From: ames!srs!matt@ut-sally.UUCP (Matt Goheen)
Subject: newfs -N
Sun OS 3.2
The documentation for the -N option to "newfs" says:
-N Print out the file system parameters without actually
creating the file system.
Although it doesn't actually create the file system, it DOES try to run
"fsirand" and this can cause NFS clients to begin reporting "stale NFS
file handle" on the file system fsck was run on. You eventually have to
reboot ALL the clients.
I don't know exactly what's going on (my guess is that fsirand puts a new
filesystem ID in the superblock, which causes clients to think that the
file system has been changed), but I highly recommend NOT using "newfs -N"
on ANY file system that you want to keep. Note that we broke out of newfs
as soon as we saw that it was actually running fsirand and it still had
time to do it's dirty work.
In case anyone wonders why anyone would want to run "newfs -N" on a file
system they cared about, we have a file system that was created smaller
than the physical partition and were wondering how much bigger it would be
if it used the whole thing. Running "newfs -N" should be an easy way to
do this...
uucp: {rutgers,ames}!rochester!srs!matt Matt Goheen
maybe-nets: matt@srs.uucp OR matt%srs.uucp@harvard.harvard.edu
------------------------------
Date: Mon, 2 May 88 17:37:25 BST
From: Aled Morris <aledm%cvaxa.sussex.ac.uk@nss.cs.ucl.ac.uk>
Subject: gammontool
Does gammontool cheat?
[[ Sure seems like it does, huh? In tight spots, it almost always manages
to get the roll it needs and I always manage to get the worst possible
roll I could get. --wnl ]]
Aled Morris
Janet/Arpa: aledm@uk.ac.sussex.cvaxa | School of Cognitive Science
uucp: ..!mcvax!ukc!cvaxa!aledm | University of Sussex
talk: +44-(0)273-606755 e2372 | Falmer, Brighton, England
------------------------------
Date: Sun, 1 May 88 12:32:50 PDT
From: Al Conrad <conrad@jupiter.ucsc.edu>
Subject: Verstec printer problems
Has anyone seen the following symptoms using a versatec printer on a Sun
3/280: any attempt to open results in the driver bombing out of lpcmd()
with the error messages
printer off line
printer out of paper
and then going into an infinite loop that requires killing the process
from another terminal.
We've been through three controllers and an equal number of Versatec FEs
and everybody is stumped.
Thanks in advance,
Al Conrad
conrad@saturn.ucsc.edu
------------------------------
End of SUN-Spots Digest
***********************