Sun-Spots Digest, v6n91
William LeFebvre
Sun-Spots-Request at RICE.EDU
Thu May 19 14:43:05 AEST 1988
SUN-SPOTS DIGEST Wednesday, 18 May 1988 Volume 6 : Issue 91
Today's Topics:
Re: ESTALE
Re: printing tex dvi files on a sun laserwriter: psdf
Re: MAXUSERS > 12 in SunOS 3.2 and 3.4
How to get TeXsun
Comments about XY451's and NEC2363's
Comments and questions about SunOS4.0
CAPS lock and RESET disabled
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: Fri, 13 May 88 17:57:33 PDT
From: sxn at sun.com (Stephen X. Nahm)
Subject: Re: ESTALE
>I have an application that consists of two parts....Since I'm using
>rename() on the server I expected the file to
>never be unavailable!
Remember: NFS semantics doesn't always match UNIX sematics.
>Can anyone offer suggestions for how I might avoid
>getting the ESTALE error?
I think you're getting tangled by the lookup cache. The client keeps a
cache of recently used filehandles so that it doesn't have to do a
complete lookup series each time a file is referenced.
[This is the way NFS lookups work: The "filehandle" is a cookie that the
NFS server hands the NFS client when a filesystem is mounted. (eg, a
mount of "/usr" may return a filehandle of "XXX".) When the NFS client
wants to access a file, say "/usr/sxn/bin/foo"), it performs a series of
"lookups", starting with the mount point's filehandle. (eg, the client
will say "lookup 'sxn' in filehandle 'XXX'. It gets back 'YYY'. Then the
client will say "lookup 'bin' in filehandle 'YYY', and so on until it gets
to the file to be accessed.]
The rename that you're doing is causing the filehandle of the file to
change (a filehandle in Sun implementations is based on the file's inode;
the new incarnation of this filename has a different inode). If the
cached filehandle is used at that point, you'll get an ESTALE.
I looked at the lookup code, and it appears that it's trying to guard
against this problem by checking the attributes of the directory that owns
the file being looked up. If the the directory has been changed, then the
cache is purged; *however*, this check is not made if the attributes of
the directory has been retrieved from the server very recently. I can
imagine scenarios where this "however" will get triggered in this
rename/stat sequence.
The "good news" is that an ESTALE will flush the cache, so the next time
you do a stat, you should not get an error.
You might consider using the network lock manager to coordinate the
rename/stat sequence. You could use a second file as a lock file and only
rename or stat the file when you (the client or server) owns the lock.
(Use flock, not fcntl.) Unfortunately, the lock manager is not known for
speeding up applications.
Steve Nahm sxn at sun.COM or sun!sxn
------------------------------
Date: Sat, 14 May 88 04:07:38 EDT
From: lear at aramis.rutgers.edu (eliot lear)
Subject: Re: printing tex dvi files on a sun laserwriter: psdf
Reference: v6n74
>From: cracraft at venera.isi.edu (Stuart Cracraft)
> Question for the newsgroup: is 'psdf' available? Is there something else
> that is needed to convert tex dvi files to be able to print on a sun
> laserwriter?
I suspect psdf is the least of your worries. The program to convert TeX
dvi to PostScript is called dvi2ps, hacked at a number of institutions.
It is relatively simple to compile, but it requires about 20 Meg of fonts
to work properly. I believe dvi2ps can be found at a number of
institutions, and is somewhere on the Washington TeX tape
(tex82/TeXdevices/mitdrivers?). Once you have dvi2ps and its fonts up,
the modification to psdf is simple. Add the following case statement to
psint.sh:
psdf) dvi2ps -q | $comm ;;
and remove psdf from the list of filters not found.
For more information, you might want to post to comp.text on how to set up
TeX on your system or mail me for more information. If there is a large
demand, I'll post to sun-spots about it...
Eliot Lear
[lear at rutgers.edu]
------------------------------
Date: 14 May 88 18:26:47 GMT
From: tekbspa!tss!joe at uunet.uu.net (Joe Angelo)
Subject: Re: MAXUSERS > 12 in SunOS 3.2 and 3.4
rrb%mathsun%jupiter.uucp at umix.cc.umich.edu (Robert Bruner) says:
> I've used MAXUSERS = 16 in both 3.2 and 3.4 with no problems. (Also in
> SunOS 3.5)
The problem appears on a 3/160 and 3/280, as far as I know.
Joe Angelo -- Senior Systems Engineer/Systems Manager
at Teknekron Software Systems, Palo Alto 415-325-1025
uunet!tekbspa!joe -OR- tekbspa!joe at uunet.uu.net
------------------------------
Date: Sun, 15 May 88 10:58:35 cdt
From: grunwald at m.cs.uiuc.edu (Dirk Grunwald)
Subject: How to get TeXsun
Office: 72 DCL (217) 333-1925
The current release of TeXsun can be picked up from the host a.cs.uiuc.edu
(10.3.0.37 or 192.5.69.1) via public FTP in the file pub/TeX/iptex.tar.Z.
This also includes a re-worked version of 'iptex', the Imagen printer
driver. The ``re-working'' was to make both TeXsun, Iptex and TeXx use the
save ``dvi driver code'' with only application specific routines, mainly
to reduce maintaince. Also, iptex & TeXsun take (roughly) the same command
line arguments for options which make sense to share.
Although I've not used DviTool much of late, and can't compare the two,
TeXsun has a reasonable interface. It uses whatever fonts you have &
shrinks them to fit (& can also use the 78 or 118 DPI fonts if you have
the disk space). The current version has: 1 or 2 ``leaves'' at a time, an
``overview'' and a ``detail view'' mode, limited menu support (to be
extended...), a greatly improved interface over the older TeXsun (don't
need to hold buttons down anymore), scroll bars in detail view,
``reloading'' of documents so you don't need to re-init the tool.
Also, a new feature is that when you go to detail view, the window size
changes to fit the document (or gets as big as your display), and when you
switch back to overview, it resizes again. There have also been some
recent hacks to attempt to reduce the amount of memory needed.
TeXsun, iptex and TeXx implement the `tpic' or `texpic' set of specials.
They also use any of pxl, gf or pk fonts.
Eventually, that same tar file will include the updated version of TeXx,
which is being changed to look more like TeXsun. However, that is
predicated on finishing other projects.
The portion of the software which I developed is copyrighted along the
lines of the FSF copyright. Chris Torek did the original DVI library, and
has copyrights on that portion of the software, but has indicated that he
doesn't care about redistribution.
I do not have the facilities or time to distribute TeXsun other than via
the arpanet. If someone wants to put it in some Usenet distribution point,
be my guest. I'll remember to post notices about updates.
Dirk Grunwald
Univ. of Illinois
grunwald at m.cs.uiuc.edu
------------------------------
Date: Sun, 15 May 88 15:46:06 +0100
From: Mark Riddoch <mark at cs.ucl.ac.uk>
Subject: Comments about XY451's and NEC2363's
Just to add my comments to the disccusion about putting multiple drives on
a 451, and to ask about a problem we have.
We've had a 451 running 3 drives (2 Eagles + 1 SuperEagle) for some time
now with no problems whatsoever. Recently, following problems with
another of our machines (a pyramid), we moved an NEC D2363 to this same
sun. The drive remained on the machine for a week, whilst we had the
other machine repaired, during this time we had no problems with any of
the four drives. Once our other machine was fixed we moved the drive back
to its orginal home. This drive is used for our backup system, hence it is
required to be "highly available", this is why we went to all the trouble
of moving it. Recently we decided to move our backup system from the
Pyramid to the Sun (due to the availability of an Exabyte drive on the
sun). This we did, however we currently run 3.4 on our suns, which does
not have "support" for NEC 2363's, this doesn't seem to be a problem,
since as far as I can tell (by looking at the 3.5 that we have) all that
is changed is that diag now knows of a drive called a 2363. We did not use
the definition as given in 3.5's diag, since it throws away cylinders at
the end of the drive, we used:
1022 cyls, 2 acyl, 27 heads, 67 sectors/track.
Now for the problem (at last I hear you say), the drive normally performs
fine, however sometimes when the sun reboots at night, it fails to read
the label form the drive. It does successfully probe for the drive, and
the drive can be brought back by spinning it down, and spinning it up
again. So the label is not getting corrupted in any way. We have a theory
that the problem is heat related, but we have no way to prove this. The
other possibility we have been considering is a marginal timing problem, a
drive reset may sometimes take a little longer perhaps, putting the drive
in a non-ready state when unix comes along to read the label. We are
currently run the drive with extra cooling, but since the problem is
intermittant we have no way to say definately that we have solved the
problem. The other NEC drives have not shown this problem, however they
are on a pyramid, which does not label drives in the same way as suns.
Has anybody else encountered such a problem with these drives, or any
other drives.
Mark.
------------------------------
Date: Mon, 16 May 88 15:29:12 +0200
From: jan at eik.ii.uib.no
Subject: Comments and questions about SunOS4.0
Well, it's nice to follow the discussion on the new 4.0 release. As a
'sysadm' one of the features that is highest on my 'want'-list is a
read-only /usr filesystem, that could be shared between a -lot- of
clients. If I understand the comments so far correctly, this will indeed
be the case under 4.0? If this is wrong, please tell me at once!
We are using a lot of small SCSI-disks (80/300MB) to boot 3/50's off, with
30MB+ for swap pr. client, so if we could reliably get /usr from a big
server, we could free up a lot of disk-space.
I am also curious to know what Sun have done with files like crontab,
sendmail.cf etc. Under the old ND-system they had to reside in /private?
(Sun very thoughtfully made no such provisions if you set up a file server
whithout ND-partitions, so we had to create them.)
I have also noted the references to 8-bit characters. Does this mean that
Sun now support an International character set, or do they just repeat
the standard ASCII-set, but with the 8th bit set? (Since I live in Europe,
I would really like to have something like or HP's or even IBM's
international character sets. We really use those funny looking
characters!)
Jan Berger Henriksen jan at eik.ii.uib.no
Institute of Informatics jan%eik.ii.uib.no at tor.nta.no
University of Bergen
Allegt. 55
N - 5007 Bergen,
Norway
PS. I have also seen requests for information on 3rd-party SCSI-disks.
We have some 20 CDC Wren-III & Wren-IV disks, and our norwegian
distributor is expecting to start shipping the new CDC 550MB disks in
June. We usually format them specifying the Adaptec option, but as far as
I know, you can use Emulex just as well. The disks are hanging off 3/50's
and 3/60's. Our experience with this system is that the disks are very
reliable, but they make up for a lot of work when the times come for major
upgrades ... If anybody is interested in more info, mail me directly and
I'll try to answer. DS.
------------------------------
Date: 15 May 88 14:05:05 GMT
From: Wim Mooij <mcvax!uva!wim at uunet.uu.net>
Subject: CAPS lock and RESET disabled
Organisation: Faculteit Wiskunde & Informatica, Universiteit van Amsterdam
Kruislaan 409, 1098 SJ Amsterdam, The Netherlands
Phone: +31 20 5925022
Telex: 10262 hef nl
The problem of the CAPS key button on the Sun console has been mentioned
before in this newsgroup. Of the the two standard CAPS keys the function
of the function key F1 can be modified with a .ttyswrc file entry. The
CAPS key button cannot be changed with this mechanism. Included is a
small program to disable the CAPS key by changing the translation tables
of the keyboard using some ioctl() calls to /dev/kbd All this is described
in the kbd(4) manual pages.
[[ I suspect that the original poster was complaining about the CAPS key,
since his complaint was about the lack of a visual indicator and using the
F1 key changes the title bar to include "CAPS". --wnl ]]
The 'normal' operation of the keyboard (with CAPS enabled) can be restored
with the command: "setkeys reset". see setkeys(1). The same mechanism
makes it possible to disable the reset sequence L1-A (or ESC-A on older
keyboards). Just map on of the keys that is part of the reset sequence to
a key code that cannot be generated from the keyboard. A program for
disabling the L1-A reset sequence is included as well.
The "setkeys reset" command doesn't restore the default action. In the
standard sun file organization /dev/kbd is crw-rw-rw- so everybody can
fool around with your keyboard translation tables! Imagine someone
remotely remapping your /dev/kdb return key to a reset sequence....
Surely, this will have changed in newer SunOs releases (we are running
3.4) You don't expect a security hole like this in SunOs 4.0
[[ Wim Mooij sent me a note later that said this last statement was in
error. Specifically: "Only two keys pressed down simultaneously can
generate a system reset. A shift or control key only forces a different
mapping and as such can not be used as part of a reset sequence. I am
sorry if i have confused anyone. You don't have to worry about hitting
return anymore! :-)" --wnl ]]
I have changed /dev/kbd to crw-r--r-- so only root may modify the keyboard
translation tables. Suntool still works fine, even the .ttyswrc commands
are executed. An ordinary user cannot execute the caps disable program
anymore unless it is made setuid root.
/*
* The CAPS key disable program.
*/
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sundev/kbd.h>
#include <sundev/kbio.h>
main()
{
struct kiockey key ;
int fd ;
int z,i ;
fd = open( "/dev/kbd", 1 ) ;
if( fd < 0 ) {
perror("Open") ;
exit( 1 ) ;
}
for(i =0 ; i<128 ; i++ ) {
key.kio_tablemask = 0 ;
key.kio_station = i ;
ioctl( fd, KIOCGETKEY, &key ) ; /* get normal keyboard map entry */
z = key.kio_entry ;
key.kio_tablemask = CAPSMASK ;
if( ioctl( fd, KIOCSETKEY, &key ) < 0 ) { /* change to normal map entry */
perror("Ioctl") ;
}
key.kio_entry = 0 ;
ioctl( fd, KIOCGETKEY, &key ) ; /* verify the change */
if( z != key.kio_entry ) {
printf("Not changed, %d, %d\n", z, key.kio_entry ) ;
}
}
}
/*
* The reset sequence disable program.
*/
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sundev/kbd.h>
#include <sundev/kbio.h>
main()
{
struct kiockey key ;
int fd ;
int z,i ;
fd = open( "/dev/kbd", 1 ) ;
if( fd < 0 ) {
perror("Open") ;
exit( 1 ) ;
}
key.kio_tablemask = KIOCABORT1 ;
ioctl( fd, KIOCGETKEY, &key ) ; /* read abort key entry */
if (key.kio_station == 0)
printf("L1-A reset sequence already disabled\n");
else if (key.kio_station == 1)
printf("L1-A reset sequence enabled\n");
key.kio_station = 0 ;
ioctl( fd, KIOCSETKEY, &key ) ; /* map it to a 'hole' in map */
ioctl( fd, KIOCGETKEY, &key ) ; /* verify the change */
if (key.kio_station == 0)
printf("L1-A reset sequence disabled\n");
else if (key.kio_station == 1)
printf("L1-A reset sequence still enabled\n");
}
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list