Sun-Spots-Request@RICE.EDU (William LeFebvre) (08/25/88)
SUN-SPOTS DIGEST Tuesday, 23 August 1988 Volume 6 : Issue 195
Today's Topics:
Re: Proxy arp
Re: Manual Binders for the Sun
Re: troff to postscript
Announcement: Fig 1.4.FS and TransFig 1.4 Release 3
OS 4.0 lpd problem
lpr -s /tmp/file fails on 4.0 clients (with fix)
pwd: getwd: can't open ..
Problem with biff and pseudo terminal ownership
passwd matching across YP domains?
printcap vs. XON/XOF (SunOS4.0)?
troff leaders?
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: Thu, 18 Aug 88 13:25:11 EDT
From: bob@allosaur.cis.ohio-state.edu (Bob Sutterfield)
Subject: Re: Proxy arp
Reference: v6n187
In article <1988.08.17.16.00.05.763.10323@rice.edu> Barry Shein <bzs@bu-cs.bu.edu> writes:
>I wrote a proxy arp based upon Sun's rarpd server which has been in
>production here at BU for over a year.
and which we've been using for several months. Thanks!
>...My Proxyd kind of got out there by accident when someone mentioned
>I had given them a copy on one of the major lists.
Oops - sorry (red face :-). I hope I'm not stealing Haavard Eidnes'
thunder by mentioning this here, but since he did provide it:
>...
>B) Haavard Eidnes claims to have completely written a new Proxyd from
>scratch based on my basic design (not the Sun sources) and I assume
>will make all sources available...
>You should probably wait for B) to become available and that will
>solve all sorts of problems.
Mr Eidnes asked us to provide a distribution point on this side of the
pond. You can get his proxyd via:
(a) anonymous FTP to tut.cis.ohio-state.edu in proxyarp/proxyarpd.shar.Z
(b) anonymous UUCP to osu-cis in /u/public/proxyarp/proxyarp.sharZ
Option (b) works like everything else we redistribute. If you don't have
instructions, drop me a line.
We haven't had a chance to try out this new Proxy ARP daemon. If you get
it from us, and have problems with it, please send mail to the author,
Haavard Eidnes (he@idt.unit.no).
---
Bob Sutterfield, Department of Computer and Information Science
The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277
bob@cis.ohio-state.edu or ...!{att,pyramid,killer}!cis.ohio-state.edu!bob
------------------------------
Date: 18 Aug 88 17:52:26 GMT
From: ehrlich@blitz.cs.psu.edu (Dan Ehrlich)
Subject: Re: Manual Binders for the Sun
At Penn State we order them direct from the manufacturer. There may be
more than one company that makes these, but here are the particulars on
the one we use:
Buchan Industries
Clifton Heights, PA 19018
+1 215 622 3500
Call them up and ask for the current price list and catalogs. It seems to
take two of the eleven inch racks to hold the entire set of SUN OS 3.5
manuals. Each rack was about $US 65. Haven't tried putting the SUN OS 4
manuals in yet.
Dan Ehrlich <ehrlich@blitz.cs.psu.edu>
The Pennsylvania State University
Department of Computer Science
University Park, PA 16802
------------------------------
Date: Mon, 15 Aug 88 15:38:02 EDT
From: suneast!rahthum!ppk@sun.com (Pravin Kumar)
Subject: Re: troff to postscript
>From: Paul Hudson <mcvax!moncam!paul@uunet.uu.net>
>
>I don't know of a PD filter, but a quick and dirty (And slow) one
>shouldn't take too long. If there's any demand, I'll knock one up.
Under SunOS 4.0, you can do "troff -t | lpr -t" to do troff to PostScript.
Read the SunOS 4.0 Change Notes (page 29, Section 2.7 Utilities) for more
information.
pk
[[ Although the Change Notes really do say something to that effect, I
strongly suspect that you still need to have the "Transcript" software
installed in order for it to work. You also need to have your default
printer (or whatever printer is specified in your PRINTER environment
variable) set up correctly in /etc/printcap. I think that the Change
Notes were pointing out that "lpr -t" now worked with Transcript, making
"ptroff" obsolete. I don't think they intended to imply that Transcript
comes with 4.0. But, I have occasionally been wrong. --wnl ]]
------------------------------
Date: Thu, 18 Aug 88 10:21:18 EDT
From: beck@cs.cornell.edu (Micah Beck)
Subject: Announcement: Fig 1.4.FS and TransFig 1.4 Release 3
Announcing availability of two software components: Fig 1.4.FS and
TransFig Version 1.4 Release 3:
* Fig 1.4.FS is an enhanced version of Fig 1.4 Release 2.
Some bugs are fixed, the user interface is enhanced, and
some new graphics features are supported.
* TransFig 1.4 Release 3 includes Fig code translators which
implement the extension to Fig code needed by Fig 1.4.FS
to implement new graphics features.
New graphics features include setable text font and size, and area fill.
Both Fig 1.4.FS and TransFig Release 3 use an extension to the definition
of Fig code. This extension maintains compatibility with standard Fig code.
Fig 1.4.FS was developed by Frank Schmuck at Cornell University. It is no
sense an "official" version of Fig. The features added to Release 2 are
summarized below:
1. New operation: zoom
2. New operation: change object properties
3. New modes: LaTeX line and vector
4. Search uses real mouse position rather than magnet-rounded coordinates
5. Centered and right justified text is drawn correctly.
6. Displays current file and directory on window label
Frank Schmuck has left Cornell and I now support Fig 1.4.FS. It is available
for anonymous FTP from svax.cs.cornell.edu as ~ftp/pub/fig/fig-fs.tar.Z.
TransFig Release 3 is available as ~ftp/pub/fig/transfig.tar.Z. [[ Be
sure to use "image" transfer type for compressed files (use the FTP
command "binary" before transferring). --wnl ]]
Some technical notes:
* Fig 1.4.FS is different enough from Release 2 that it was not possible
to automatically generate patch files for the bug fixes. Sorry.
* In a recent posting, Ken Yap of Rochester U. suggested that Fig hacking
be done on Xfig, his generalized Fig which runs under both Suntools and
X11. Unfortunately, Fig 1.4.FS was developed in parallel to Xfig, and
thus some work will be required to merge the two.
* If you picked up a version of Fig 1.4.FS or TransFig Release 3 before
reading this note, then you may have to apply this fix: line 121 of read.c
should be
tfx_flag = !strncmp(buf, "#FIG 1.4-TFX", 11); /* check for TFX */
Micah Beck
beck@svax.cs.cornell.edu
Cornell Dept of Computer Science
------------------------------
Date: Thu, 18 Aug 88 12:16:55 EDT
From: ileaf!io!jaguar!dbjag@eddie.mit.edu (David Benjamin)
Subject: OS 4.0 lpd problem
We've run into a problem with the Sun OS 4.0 lpd (line printer daemon) in
which some printing jobs queued up with the "lpr -s" command disappear for
no apparent reason. The problem, apparently, is that lpd4.0 does not like
"lpr -s" queueing when the file to be printed resides on an NFS
filesystem. Our particular case was an OS4.0 system queueing files on a
remote printer running OS3.2, but the problem also happens when the
printer server is running OS3.4, as well as 4.0. In all cases the NFS
mounted filesystem was from server machine running 3.4, I'm not sure if
NFS mounting from an OS4.0 machine will produce the same effect.
Presently (8/18/88) Sun considers the bug (#1007641) closed, but this may
change since their only suggested workaround ("don't use lpr -s") does not
offer a method to print files of over a megabyte in size. We've found
that substituting the lpd4.0 with a copy of lpd3.4 seems to alleviate the
problem, although we're not sure of what other side effects this may have.
Also, there seems to be a new line in the /usr/spool/*/cf* file called the
"S" line which contains two numerical arguments. I don't know what it
means yet, but it may have something to do with the NFS-drop problem since
the arguments turn strange on the files that get dropped.
[[ The "S" line has always been in the control file specifications. It is
used to hold "stat info" for symbolic link protection. The two numbers
are the device and inode numbers of (I think) the original file. I
believe this exists to handle the "-s" option and has nothing to do with
NFS. --wnl ]]
I hope that this info will save someone else from going through the
hassles I went through before makeing the NFS-lpr connection. This way I
can indirectly pay back SunSpots for all the information I've gleaned from
this group!
Thanks.
Dave Benjamin
Interleaf
Cambridge, MA
[[ To quote the lpr(1) manual page: "Note: the -s option only works on
the local host (files sent to remote printer hosts are copied anyway), and
only with named data files - it doesn't work if lpr is at the end of a
pipeline." But there's also a problem with "lpr -s" and NFS. See the
next message. --wnl ]]
------------------------------
Date: Thu, 18 Aug 88 17:19:52 CDT
From: aydt%guitar.cs.uiuc.edu@a.cs.uiuc.edu (Ruth Aydt)
Subject: lpr -s /tmp/file fails on 4.0 clients (with fix)
There is a problem with lpr/lpd on 4.0 clients when you try to print a
file with the -s option (use symlink to file rather than copying it into
the spool area).
lpr writes the device number as returned from stat to the control file
with the S tag using printf %d format. However, this is a short and with
the nfs-mounted filesystems it gets written as -32256 or some such number.
When lpd then checks the S line in the cf file to make sure the device and
inode numbers match those of the "current" file before printing the match
fails and the job is rejected.
The solution is to change lpr to use only relevant bits when building the
cf file:
(void) sprintf(buf, "%d %d", statb.st_dev&0xffff, statb.st_ino);
For us this first turned up when some text-processing scripts submitted
jobs that were rejected by lpd. The lpr -s was "hidden" within the
scripts.
Ruth Aydt
Department of Computer Science
University of Illinois at Urbana-Champaign
------------------------------
Date: 18 Aug 88 14:08:41 GMT
From: oliveb!stpstn!aad@ames.arc.nasa.gov (Anthony A. Datri)
Subject: pwd: getwd: can't open ..
For the past week, I've had the following problem:
<=>26<=>cd /usr/spool/uucp
<=>27<=>pwd
pwd: getwd: can't open ..
It comes an goes. In the past, I've had problems with diskless clients
doing that with NFS mounts, and it seemed to go away when I made the
underlying mount point 777.
We're running 3.2 on these machines.
Any ideas? Almost everything works find -- cd works, but UNIPRESS Emacs
complains when I try to run it out of there. I doubt that it's NFS
related, especially since everything's up and it's still happening.
--
Anthony A. Datri,SysAdmin,StepstoneCorporation,stpstn!aad
[[ It is completely related to the permissions on the directories between
the current one and the root. Try this experiment. "cd; mkdir foo; cd
foo; mkdir bar; cd; chmod 111 foo; cd foo/bar; pwd" You will get
"pwd: getwd: can't open ..". Why? Because "~/foo" is only scanable and
not readable. You can cd to a subdirectory of "foo" because you
explicitly named it ("x" permission on a directory means that you can
access a file in that directory provided you know the name). So cd-ing
there worked, but "pwd" needs to read all the directories back to the
root. And it can't read "~/foo". Now do "cd; chmod 700 foo; rmdir
foo/bar; rmdir foo" then go eat a grilled peanut butter sandwich. After
you wash your hands and face, check the permissions on "/usr" and
"/usr/spool" (and "/" too if you want). I don't know why it would "come
and go" unless some evil daemon process keeps changing the permissions on
you. Unipress Emacs has problems because it does the equivalent of a
"pwd" (the library call "getwd") when it starts up. For more information
on how "pwd" does its dirty work, look at v6n143 where it is discussed in
the context of an NFS server crash. --wnl ]]
------------------------------
Date: Thu, 18 Aug 88 10:03:17 EDT
From: ufnmr!ufnmr_1!gareth@bikini.cis.ufl.edu (Gareth J. Barker)
Subject: Problem with biff and pseudo terminal ownership
There's been a lot in Sun-Spots recently about ownership modes of pseudo
terminals and problems with incorrect modes. I recently discovered that
the 'biff' mail notification program doesn't work correctly under Suntools
- typing 'biff' alone gives the response 'is y' or 'is n' (as it should),
but trying to set biff (with 'biff y', for example) produces
'/dev/ttyp3: Not owner' or similar. An 'ls' shows that /dev/ttyp3 is
'crw-rw-rw- 1 root reebok' - is this correct, and why does 'biff' need to
know who owns the terminal anyway?
This is not a big problem, as setting biff in '.login' makes everything
work as expected (with mail notification going to the 'console' window
under Suntools) and the shell mail/MAIL variables can be used if
notification to other windows is needed, but I'd like to know what's going
on.
Thanks for any information,
[[ This last paragraph was sent in a little later: --wnl ]]
A correction to my last note - I'm not sure that setting the mail/MAIL
variable in a Suntools window has any effect. A quick test has just shown
no obvious response when I send mail either to myself or to 'root' (just
an idea, seeing as root owns the window ...).
Gareth J. Barker,
University of Florida,
Department of Radiology.
BITNET : GJBARKER@UFFSC.BITNET
INTERNET : ufnmr!gareth@BIKINI.CIS.UFL.EDU
UUCP : ...gatech!uflorida!ufnmr!gareth
[[ Didn't I explain this before? Oh well. When mail arrives for user X,
the mail daemon checks all the terminals to see where X is logged in (I'm
not sure if it checks /etc/utmp or just tty ownerships). If the owner
execute bit is set (that is, mode 722 or "crwx..."), then notification is
written to that terminal. Biff does its job by changing the permission
bits. But since biff is not setuid, it can't change the permission bits
if the user running biff doesn't own the terminal. This is the case for
the pseudo ttys used by shelltools and cmdtools. Try using "mesg" to
"turn messages off" in one of your windows. Same result for similar
reasons. As for the cshell "mail" variable: it is more of a periodic
synchrnous check which is completely separate from the asynchronous mailer
daemon notification. That just tells the cshell to check for mail before
it prompts you for another command. Read the csh(1) manual page for more
information about that. --wnl ]]
------------------------------
Date: Thu, 18 Aug 88 18:52 GMT
From: Royd Whittington <GEW%DLGM.DARESBURY.AC.UK@cunyvm.cuny.edu>
Subject: passwd matching across YP domains?
I want to have an entry in my /etc/passwd file that refers to a netgroup.
The thing is, I want that netgroup to have a different domainname entry
from my machine's domain in order to pick up the passwd entry from the
other domain.
At the moment it just ignores the entry in /etc/passwd. For example,
/etc/passwd /etc/netgroup
.
.
+@test_group
|
----------> test_group (,,different_domain)
Has anyone made this work?
Thanks for any help!
Royd Whittington, SERC Daresbury Laboratory, Warrington, UK.
(Running SunOS 3.5)
------------------------------
Date: Thu, 18 Aug 88 07:49:05 HST
From: Bob Cunningham <bob@kahala.hig.hawaii.edu>
Subject: printcap vs. XON/XOF (SunOS4.0)?
Could somebody please show me an example /etc/printcap entry for a simple
serial port printer that actually works using XON/XOFF under SunOS4.0?
The obvious DOESN'T seem to work; this drops the ends of even
moderately-sized files:
oki|local okidata printer:\
:lp=/dev/ttya:sd=/var/spool/oki:\
:br#9600:\
:ms=evenp,ixon,-echo:\
:lf=/var/adm/lpd-errs:
------------------------------
Date: Thu, 18 Aug 88 09:45:37 EDT
From: ufnmr!ufnmr_1!mike@bikini.cis.ufl.edu (Michael D. Cockman)
Subject: troff leaders?
Could anyone tell us if the leader function ( \a ) in troff is functioning
as shown in the 'Tabs, Leaders, and Fields' section of the troff manual ?
If there is no software bug in troff, could someone show us how to use the
leader function correctly ??
Reply to:
Username: ufnmr!mike
Node: bikini.cis.ufl.edu
------------------------------
End of SUN-Spots Digest
***********************