Sun-Spots Digest, v6n101
William LeFebvre
Sun-Spots-Request at RICE.EDU
Thu Jun 2 14:05:51 AEST 1988
SUN-SPOTS DIGEST Wednesday, 1 June 1988 Volume 6 : Issue 101
Today's Topics:
Re: Resolver based gethostby* in 4.0 (2)
Re: text table full (3)
Re: silly behaviour of dbx(tool)
Re: Is NFS "secure" in SunOS 4.0
printing tex dvi files on a sun laserwriter: psdf
User-level NFS daemon sources
Amiga NFS Security
Fig2tex needs a BIG BIG LaTeX
gammontool
date bizarreness
Help, need info on video board for Sun
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: Mon, 23 May 88 18:54:16 EDT
From: libes at cme-durer.arpa (Don Libes)
Subject: Re: Resolver based gethostby* in 4.0 (1)
[talk about going to 4.0 just for getting gethostby* that uses resolver.]
If that is the only reason you want 4.0, don't bother.
Sun has a version of gethostby* that uses the resolver running under 3.x.
This includes yp, sendmail (with MX), nslookup, and the appropriate
libraries. To get it, call Sun Tech Support and ask for the "nameserver
kit". It's free.
I only wish I didn't have to bang my head against the wall with the 3.x
version before I learned this.
We have been running it for a couple months now, and I'm quite happy with
the way it works - it is very robust.
About the only reason you wouldn't want it is that it is fairly lean on
documentation, and you really have to read between the lines. However, if
you have conquered sendmail without the resolver, you can probably conquer
this stuff.
Don Libes cme-durer.arpa ...!uunet!cme-durer!libes
------------------------------
Date: Tue, 24 May 88 18:17:29 EDT
From: Root Boy Jim <rbj at icst-cmr.arpa>
Subject: Re: Resolver based gethostby* in 4.0 (2)
We at NBS have a pre-release of the 4.0 name server stuff available for
anonymous ftp on a machine at internet address 129.6.80.33. We got it from
NNSC.NSF.NET so I believe it should be freely redistributable. It should
work on 3.4 and 3.5, possibly on 3.3. It includes an MX mailer as well. We
don't run YP here.
(Root Boy) Jim Cottrell <rbj at icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688
------------------------------
Date: Tue, 24 May 88 12:22:54 EDT
From: mcgrew at topaz.rutgers.edu (Charles)
Subject: Re: text table full (1)
Reference: v6n95
ufnmr!ufnmr_1!gareth at bikini (Gareth J. Barker) writes:
Can someone please tell me what the 'text' in the 'text: table
is full' message is. Is the size of the table definable in
the kernel configuration files...
... the relevant magic is MAXUSERS (in the kernel config file - see files
in /usr/sys/conf). This increases the size of the internal table for text
(programs) and the other things needed to run more processes. So
increasing MAXUSERS allows you to run more processes. We typically set
ours at 16. This grows the kernel slightly (table sizes increasing), but
beyond that, there's no drawbacks.
Charles
------------------------------
Date: Tue, 24 May 88 09:56:18 EDT
From: smb at research.att.com
Subject: Re: text table full (2)
The text table is used to keep track of re-entrant executables; if it's
full, you'll have stuff that isn't shared but could be, and hence increase
your swapping load. The size of the text table is in param.c in the
kernel.
------------------------------
Date: 26 May 88 05:00:21 GMT
From: tekbspa!tss!joe at uunet.uu.net (Joe Angelo)
Subject: Re: text table full (3)
Every unique a.out file (program) that runs requires a text table slot;
multiple occurances of the same program reside in the same text tabel
slot.
param.h defines the size of most system tables; but, as you'll see, almost
all of the tables are some number X MAXUSER. So the key is to increase the
"maxuser" line in the kernel config file and make a new kernel.
Tradeoffs? Well, dats hard to say, I actually can't see any (slowness) in
any of our systems since we increased maxuser. Our application machines
are all run with maxuser=12 for 4meg, 8meg, 16meg, and 20meg machines. Our
file servers run with maxuser=32 and they have 32meg main memory and
something like 58meg swap space. The larger MAXUSER is, the more memory
your tables will take. See the "using ....k buffers of main memory"
message after boot up. You'll see (if i remember properly) only a 100k
difference between maxuser=4 and maxuser=12 -- with megs of memory, what's
100k-200k? I also think that the kernel is ``smart'' enough to only take
such and such a cut of main store. Even if there is a nanosecond or so
performace decrease, it's worth being able to run more things
simultaneously.
maxuser=4 really doesn't leave you much room for any system and 8 is
cutting it close. I'd recommend maxuser=12 as a standard for w/s and
16->24 for fileservers. For development enviroment file servers (were
everyone rlogin's), try maxuser=32.
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: Sat, 23 Apr 88 10:37:55 CDT
From: vuse!ip0!hsc at uunet.uu.net (Hsuan Chang)
Subject: Re: silly behaviour of dbx(tool)
This is in reference to DAVIS' note in v6n95 on who-steps-on-who's-toes.
I had this nasty experiences also. Here is the story:
Once upon a time, in a far away place, a person found
himself lost in the Sun. He asked his local gurus for help
but none of them could find the answer to the problem.
In his long trip seeking for help he met this genius.
He taught him to manipulate a magic stick called dbxtool
and the power of which helped him to find that he was using
the name sketch_roi to define something but Sun woudn't take it.
"whatis" says that sketch_roi is a pointer to a pixrect structure
rather than what ever he had defined. He was so glad that he
solved the problem that he bought himself a new Sun (4).
Excitingly was he porting his stuff to the new baby when he
discovered that he once again stepped onto Sun's designer's
toes. This time, "whatis" says image (defined as unsigned short *)
is a "file image.o"!
He wonders if he should he start using obsolete names for his work and let
the master from Sun to consume the easy wordings... if he does, will his
boss fire him?
He sent this message.
H. Chang
hsc at vuse.vanderbilt.edu, !uunet!vuse!hsc
[[ Gee. That kind of sounds like the problems I had with the generic 4.2
line printer spooler package. It wanted to create a Unix domain socket.
Since an Internet domain socket is declared as "struct sockaddr_in sin",
the authors decided to use "struct sockaddr_un sun". Think about it.
--wnl ]]
------------------------------
Date: 25 May 1988 10:24 EDT
From: Charles Jerian <cpj at citi.umich.edu>
Subject: Re: Is NFS "secure" in SunOS 4.0
SunOS 4.0 uses 'Secure' RPC which uses DES encrypted timestamps, to
prevent forged packets or replays. It does NOT protect the data from
etherfind (as far as I know). It sets up a session between the user and
the server that is protected by a session key, used to DES encrypt the
timestamps using Diffie Hellman public key cryptography. THis form of
cryptography was broken at a conference by Adi Shamir with an apple II
computer, though maybe the key length is longer on the SUN scheme. The
uid issue goes away, since a user is identified by possession of a private
key that matches a public key held in the YP server. The private key is
encrypted under the users password and held in the YP server. An obvious
scheme would be to get the server and client to talk to a fradulent YP
server. I don't know if anything has been done to seriously secure YP
from such an attack.
------------------------------
Date: Tue, 24 May 88 18:02:59 EDT
From: Root Boy Jim <rbj at icst-cmr.arpa>
Subject: printing tex dvi files on a sun laserwriter: psdf
> From: lear at aramis.rutgers.edu (eliot lear)
> >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.
Its README file also describes its limitations. I once tried to print the
output from an elisp macro that generates the documentation from the GNU
emacs DOC file. It was 100 pages or so. I had to manually split it into
ten files of ten pages each before it would print correctly.
In all fairness, perhaps that particular document used lots of fonts, or
perhaps there is a newer dvi2ps that works better, or perhaps my laser
printer didn't have as much memory as newer ones, or perhaps the gods were
just angry that day. Just a note of caution folks.
(Root Boy) Jim Cottrell <rbj at icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688
------------------------------
Date: Wed, 25 May 88 11:48:45 EDT
From: rsalz at pineapple.bbn.com
Subject: User-level NFS daemon sources
A user-level NFS daemon was recently posted to comp.sources.unix
(gatewayed to the ARPA unix-sources mailing list).
Quoting from the README:
"This package implements a simple user level NFS server based on the
sunrpc3.9 package that was posted to the net a few months ago. The
current version only provides read access from the clients. It has
been tested between a VAX11/780 running 4.3BSD (the server) and several
diskful SUN3/60 running SunOS 3.4 (the clients) and on a diskless
SUN3/50 running SunOS 3.2 remounting its own root at a lower level of
its file hierarchy.
"Unlike SUN's NFS-servers, the file hierarchy exported by unfsd treats
mount points within an exports filesystem transparently; thus the
client sees the same file hierarchy as is seen from the server.
These programs may be freely distributed provided they retain my
copyright notices. They are provided as is, with no warranty
expressed or implied."
/rich $alz, moderator thereof
------------------------------
Date: Tue 24 May 1988 15:09:05 EST
From: Jim Evins <evins at nrl-radar.arpa>
Subject: Amiga NFS Security
Does anyone know how to limit the users who can mount an NFS filesystem
from the Amiga or any PC NFS product. The amiga does not require
passwords, and the Amiga-NFS lets you set your username and UID to
anything you wish. This means that you can mount the filesystem as anyone
you like, and gain full read/write access to that users files. I would
like to be able to limit who could mount a filesystem from a particular
machine, and then let that person worry about the physical security to
protect his files. We are currently running SunOS 3.2. Thanks for any
help.
-Jim Evins <evins at nrl-radar.arpa>
[[ I *knew* there was a really good reason to own an Amiga! :-) --wnl ]]
------------------------------
Date: Wed, 25 May 88 13:19:57 EDT
From: beck at svax.cs.cornell.edu (Micah Beck)
Subject: Fig2tex needs a BIG BIG LaTeX
In response to Michael Siegel's note about Fig2tex running LaTeX
out of memory:
1) PiCTeX takes up a huge amount of TeX internal memory, even
for simple figures. You need to get a C compiled version of
Tex (Web-to-C or Common TeX) and build it with a memory size
of at least 128K, preferably 256K or 512K. The Pascal version
cannot handle sizes larger than 64K.
2) The file pictex.tex is not the PiCTeX manual. It is the
PiCTeX macro file. The PiCTeX manual is not distributed free
with the macros, but must be purchased from the author
Michael Wichura (wichura at galton.uchicago.edu).
3) The TransFig package (which Fig2tex is part of) is distributed
with a manual which is a LaTeX document and which uses PiCTeX figures.
Since I don't usually read Sun Spots, you might want to mail further
questions about TransFig/Fig2tex to me directly.
Micah Beck beck at svax.cs.cornell.edu
Dept of CS
Cornell University
------------------------------
Date: Tue, 24 May 88 18:45:10 EDT
From: Root Boy Jim <rbj at icst-cmr.arpa>
Subject: gammontool
> [gammontool is] also incredibly stupid. I can remember one time
> when I had a single man left on the 1 point and it was my turn (i.e. it
> was theoretically impossible for me not to win on the next roll). I
> offered a double. It accepted!
So it is only marginally more stupid than your strategy. Never double when
you are assured of winning, unless you have no hope of scoring a
(back)gammon. In that case, you just shorten the game.
[[ I don't think he would do that in a *real* game. --wnl ]]
The old program was incredibly stupid. It would hit a blot no matter what,
not a good strategy to sacrifice one's inner table men to hit blots just
off the bar. A good strategy book is Backgammon for Blood, by an author I
forgot. Available at B. Dalton and probably Walden.
[[ Which is why I claim that backgammon was either seriously reworked or
not used at all in gammontool, because gammontool doesn't do that. --wnl ]]
The new one sure seems to cheat, but I like to assume otherwise.
(Root Boy) Jim Cottrell <rbj at icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688
------------------------------
Date: Wed, 25 May 88 16:20:50 CDT
From: vuse!backup!drl at uunet.uu.net (David R. Linn)
Subject: date bizarreness
I have seen a loss of a month and a day on two SUN3's recently. Both had
been powered down and restarted when the odd date was noticed. The
machines are a 3/110 running 3.4 and a 3/50 running 3.5; both SunOS's have
the clock fix for leap years.
Anyone else seen this?
David
David Linn
System Manager, Vanderbilt University School of Engineering
INET: drl at vuse.vanderbilt.edu [129.59.100.1]
UUCP: ...!uunet!vuse!drl CSNET: drl at vanderbilt.csnet
AT&T: (615)322-7924 BITNET: linndr at vuengvax
USPS: P.O. Box 1824, Vanderbilt University, Nashville, TN, USA, 37235
------------------------------
Date: Sat, 23 Apr 88 10:16:16 CDT
From: vuse!ip0!hsc at uunet.uu.net (Hsuan Chang)
Subject: Help, need info on video board for Sun
Need to copy screen video from Sun color monitor to standard NTSC VCR
recorder. How about a composite video board add-on to the Sun 3/260.
-Gary
grm at vuse.vanderbilt.edu -OR- !uunet!vuse!grm
P.S. please send info direct to me, thanks.
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list