Sun-Spots Digest, v6n117
William LeFebvre
Sun-Spots-Request at RICE.EDU
Mon Jun 20 12:07:19 AEST 1988
SUN-SPOTS DIGEST Sunday, 19 June 1988 Volume 6 : Issue 117
Today's Topics:
Re: $un / AT$T have got us now (4.0 unbundled software)
Re: NFS security
Re: Doing the unexpected
Re: Postscript for Sun Manual Binder Labels
Quote w/o comment: Arbitrator Favors Sun Micro in Dispute
Problems with SUN-Link X.25
Displaying characters above ASCII 127 on a Sun?
Re: SunOS 4.0: Shared Library Comment (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: Sat, 11 Jun 88 21:14:17 PDT
From: tsunami!nswed5!efb at sun.com
Subject: Re: $un / AT$T have got us now (4.0 unbundled software)
Reference: v6n105
Thanks bpowell at sun.com (Brad Powell/Corporate Sales Tech Support)
We wish we could have gotten such a forthright answer from you (Sun) or
AT$T on the NEW_UNIX. As I maintain System V systems, I bought $55K of
Source License via my SysV vendor. Then I learned I needed to BUY the
manual pages.
I thought DEC was bad, that took the cake. Then to check my worst nightmare,
I called your Mr Mitchell, near Mr Cage's office. Who prefered not to return
my call after hearing of my concern. I had this very bad dream that AT$T and
its clones were getting ready to disassemble the once valuable Unix packager.
Voila, and says Steve Simmons: 1) Unbundled s/w means you'd better get the
stuff ordered now (i.e. NeWS, lisp, f77vms, etc).
So, SUN and other resellers of AT$T .. YOU believed in the newly found
business smarts of those folks .. MAYBE we the users, especially the tax
supported ones, would be real smart to stick with old versions of *nix
until Pub_nix is available.
There are a long list of hardcore expressions which well describe my
feelings toward the new *nix attitude, all unfit for retransmission.
I don't speak for my employers .. include disclaimer.h ..
Everett F. Batey II } {UUCP: sun!tsunami!nswed5!efb
USNSWSES - Code 4V33 } {ARPA: efbatey at NSWSES.ARPA
Blg 1214 } { efbatey at NOBBS.UCSB.EDU
Port Hueneme,CA 93043-5007 } {DDD: 805/982-5881 983-1220(ans)
SoCalif SUN Local User Group - Vta-SantaBarbara-SanLuisObispo DECUS
------------------------------
Date: Sat, 11 Jun 88 23:43:46 EST
From: treese at athena.mit.edu
Subject: Re: NFS security
MIT's Project Athena has implemented a user ID mapping scheme for NFS that
maps a pair {client IP address, uid} onto a uid on the server. The
mappings are established at mount time and are authenticated using
Athena's Kerberos authentication system. With such a server, an Amiga (or
any other NFS machine) can't access private files simply by changing the
uid in the request.
More information about the Kerberos authentication system can be obtained
by mailing to kerberos at athena.mit.edu.
Win Treese
DEC/Project Athena
treese at athena.mit.edu
------------------------------
Date: Sat, 11 Jun 88 12:15:42 EDT
From: jsol at bu-it.bu.edu
Subject: Re: Doing the unexpected
Reference: v6n107
From: woods at handies.ucar.edu (Greg Woods)
I don't understand what is happening. If I attempt to start a second
sendmail daemon on any machine I've ever used, including Sun-3's and 4's,
I get "bind: address already in use". I didn't think it was possible for
two daemons to bind to the same port. Am I missing something?
--Greg (woods at ncar.ucar.edu)
[[ That's what I think, too. But I wasn't sure enough about it to say
something out loud. As far as I know, you can't have more than one
process "listening" to the same port....can you? --wnl ]]
No, you can't. Try setting up two telnetd's you'll get the same problem.
------------------------------
Date: Sat, 11 Jun 88 16:46:33 CDT
From: Farrell Gerbode <farrell at trinity.rice.edu>
Subject: Re: Postscript for Sun Manual Binder Labels
Reference: v6n109
The PostScript file referenced above was seriously damaged in transfer.
Several lines of "ljustify" were truncated and all "{" characters were
changed to something that neither vi nor od could grok while all "}"
characters were changed to "^G". The file should probably be placed on
the archive server for retrieval.
Farrell
[[ Well, phooey! I didn't look at it very closely, did I? Farrell kindly
cleaned up the file and made sure it worked. Rather than put it in
another digest, I'm just placing it in the archives as
"sun-source/sunlabels.ps". It is 5428 bytes. It can be retrieved via
anonymous FTP from the host "titan.rice.edu" or via the archive server
with the request "send sun-source sunlabels.ps". For more information
about the archive server, send a mail message containing the word "help"
to the address "archive-server at rice.edu". My thanks also to the many
others who pointed this put, including the original poster. His mail goes
through an ebcdic machine and the file must have gotten munged in the
ebcdic to ascii translation (not an uncommon occurence). If you have the
old file, the changes are straightforward: change "$" to "{", "^G"
(it's a control-G in the file) to "}", and look for truncated lines---they
are all supposed to end with "ljustify". --wnl ]]
------------------------------
Date: Fri, 10 Jun 88 07:34:30 PDT
From: cgl.ucsf.edu!hoptoad!cfcl!rdm at sun.com (Rich Morin)
Subject: Quote w/o comment: Arbitrator Favors Sun Micro in Dispute
Arbitrator Favors Sun Micro in Dispute
by Don Clark, Chronicle Staff Writer (S.F. Chronicle, 6/10/1988)
An arbitrator yesterday ruled that two small Silicon Valley firms stole
trade secrets from Mountain View-based Sun Microsystems Inc. to make
"clone" memory boards for Sun's workstations.
Arbitrator Thomas Schatzel ordered LCF International to pay Sun $856,288
in damages, plus additional attorney's fees. Custom Memory Systems, an
affiliated firm that also sold the memory boards, was ordered to pay Sun
$203,281.
The dispute stems from a November 1986 suit by Sun in Santa Clara County
Superior Court that was later referred to arbitration. Defendants in the
suit also included Qubix Graphics Systems of San Jose, which later agreed
to a settlement that included paying royalties to Sun.
According to Schatzel's findings, Qubix in 1984 had been seeking a cheaper
source of memory boards for the Sun-2 workstations that the San Jose
company uses. A Qubix employee and two other men illegally used a copy of
a Sun manual in Qubix's possession to help copy a Sun board. LCF and
Custom Memory were then formed to make and market copies, the arbitrator
found.
The two companies sold more than $1 million worth of boards, Schatzel found.
"Our assumption is that every sale they made is one we didn't make," said
Michael Morris, Sun's general counsel. "We wanted to make absolutely
certain that we come down hard on any misappropriation of Sun's
technology."
An attorney for LCF and Custom Memory could not be reached for comment.
------------------------------
Date: 11 Jun 88 16:08:34 GMT
From: unido!infoac.rmi.de!rmohr at uunet.uu.net (Rupert Mohr)
Subject: Problems with SUN-Link X.25
We are running SUN-Link X.25 on a 3/50 here and it seems to us that there
is much missing with this packet:
1. If running 'x.29' (host-server):
There is nothing available in the shell we desparately need:
a) Where are the X.25 User date (no shellvariable),
b) Where is the calling DTE (utmp, ok),
c) Where is the called DTE (need it for recognition of Sub-address).
The file x29authorization is very nice, but unsufficient:
It should allow to check userdate, calling and called DTE,
facilities (reverse charge!), and be able to set environment
variables for later use. Best thing would be a shell script
and/or c-program (user made) doing all this things.
There seems to be no possibility to set the remote X.3/X.29
parameters. This is necessary fo instance to allow remote users
to use screen oriented programs (line 'news') and set their
parameters accordingly before starting the application and also
switch off the remote echo (2:0).
We are also missing the possibilty to get accounting information
on the running connection from within the running login-shell.
Especially when allowing reverse charge calls there should be a
way to get the required information (packets, time of connect etc.).
The logfiles in /tmp are
a) at the wrong location there and
b) lacking sufficient information (user, uid, pid, etc.).
Passwords at login are echoed. Very bad.
2. Running the x25manager
leaves a connection between the two 'networks' (here two suns)
running all the time ( 60 sec * 60 min * 24 hours * 30 days * $$$ +
pckt.cnt * $$$ = $^$ !!).
This is a costly and not very elegant solution.
The documentation of the X25 package concerning internetwork
routing via X.25 is wrong.
3. pad
using ^P<CR> does not always result in the expected prompt. There
is also a 'rset' command missing to send Q-Bit data to the remote
Host/computer/pc/pad.
Accounting information missing.
4. Host setting parameters of callers
When called by a user via X.25 the SUN Link X.25 package sets
the parameters of the caller to a strange 3:54. This is very
unusual and some commercial PAD's just stop working after
connecting to a sun.
5. Strange behavior when calling from a sun:
If you use the command 'pad <host>' you get connected
immediately, but the remote host gets some characters
first. This unwanted transmission is very annoying.
Is there anybody out there knowing about this effects I wrote about?
Rupert
------------------------------
Date: Sat, 11 Jun 88 22:46:34 EDT
From: Kibo <USERFE0N%mts.rpi.edu at itsgw.rpi.edu>
Subject: Displaying characters above ASCII 127 on a Sun?
Please, please, please, does anyone out there know a way to show the top
half of the character set under NeWS or (most preferably) SunTools?
- James "Kibo" Parry userfe0n%mts.rpi.edu at itsgw.rpi.edy
userfe0n at rpitsmts.bitnet
------------------------------
Date: Sun, 12 Jun 88 00:57:54 EDT
From: hedrick at aramis.rutgers.edu (Charles Hedrick)
Subject: Re: SunOS 4.0: Shared Library Comment (LONG)
Reference: v6n108
I see another user has already run into the same problem we did: we need
to replace gethostbyname in the sharable library (in order to put in one
that uses the resolver), but sharable libraries are not in a format that
allows you to replace one entry. I did manage to do it, and thought I'd
say how. This is only for the desperate, but anyone in the Internet
community is likely to be desperate to get a library that uses the
resolver. (I note that one person said Sun could send you libraries that
include the resolver. All attempts to get them to do so have failed. I
have talked to our salesman, placed an official service call with
USA-4SUN, and even talked to one of Sun's TCP developers.)
[[ Come on SUN. WAKE UP! Static host tables are out: the Internet
community no longer uses them. There a tons of new host names that are
not in the tables. We NEED the name resolver in the gethostby* routines.
That is not "want", that is "NEED" as in requirement. --wnl ]]
OK, here goes: libc.so (I'm going to omit the .1.1 or whatever -- assume
any file names ending in .so or .sa have appropriate version numbers
tacked on) is an executable. It's built by ld, and has the same magic
number as a normal program. I still haven't figured out how the system
tells the difference between an executable and a sharable library -- maybe
there isn't any. You can't just replace one module in it. So you have
two choices: build a new one, or make another sharable library that points
to it. In fact you have to do both. It's very easy to build a new
sharable library:
ld -o foo.so a.o b.o c.o
will build a sharable library called foo.so, containing a,b, and c.
Ideally, a, b, and c should be compiled with -pic, but things will work
even if they aren't. (Starting the program will be slightly slower, and
multiple users of the libraries will each end up with their own copy, so
many of the advantages won't be there, but it will work.) So to get
existing programs to use the resolver, you do the following:
ld -o libc.so a.o b.o c.o -Bdynamic -ld
This causes a new library to be built containing a.o, b.o, and c.o, which
we assume are the resolver routines. (You'll have to modify the makefile
for the resolver so it uses -pic, and also just have modules compiled
using -c -pic. The original makefile uses a procedure that links each one
with -x -r and renames it. You won't want this for these purposes.)
Because of the -ld, this library contains a link to /usr/lib/libd.so,
which is to be used for any routines not in this library. Now, rename
/usr/lib/libc.so and libc.sa to /usr/lib/libd.so and libd.sa, and existing
programs will use the resolver. If you do
ldd /usr/ucb/telnet
it will show that telnet now depends upon both libc and libd. (Don't
forget that if you increment the version numbers of the .so and .sa files,
you'll need to run /etc/ldconfig. to make them take effect.)
Unfortunately, this doesn't solve the problem of building new programs.
While the runtime ld.so will follow the link from libc to libd, the normal
ld will not. So when you try to load new programs, you'll get undefined
symbol errors for any libc routine that isn't in the resolver library
(which is now called libc.so). The only solution I could come up with is
to build an complete, merged libc.so, containing the original libc
routines, with the resolver routines in place of the original
gethostent.o. But, you say, if I could do that, why did I bother with the
libc to libd kludge? Well, the problem is that although I can build a new
sharable libc.so with all the right code, to do so I have to use libc.a.
The routines in there are not compiled -pic, so the resulting sharable
library -- although it works -- isn't really sharable. So I go ahead and
build that version, but use it only for resolving symbols when loading
programs. For actual execution, I use the libc/libd pair. So I have to
give you two instructions:
1) how to build this merged libc.so
2) how to make ld search this version, but have the libc/libd pair
used at runtime
Building the library is fairly easy. You just pull apart libc.a into its
pieces, remove gethostent.o, put in the resolver routines, and then put it
back into a sharable library. In effect:
ar x /usr/lib/libc.a
rm gethostent.o
cp /usr/src/resolver/*.o .
ld -o libc.so *.o
There are some additional details, among them a couple of files whose
names have the .o truncated from them that have to be renamed from
rpc-somethingorother. to rpc-somethingorother.o. But you get the idea.
You will also need a libc.sa to use with this libc.so. For it, use the
original /usr/lib/libc.sa, but add to it one module that declares the
exported interfaces for the resolver. This is simply
struct state _res;
int h_errno;
as I recall. (According to the documentation, you don't have to put
things in the .sa file unless they are initialized, but h_errno doesn't
always work unless you put it into the .sa file. I note that errno is in
Sun's .sa file, so obviously there's more going on here than the manual
tells us.) That is, assuming this stuff (with the necessary #includes) is
put into res_exports.c, do more or less
cc -c -pic res_exports.c
cp /usr/lib/libd.sa libc.sa
ar q libc.sa res_exports.o
ranlib libc.sa
Now you have libc.so and libc.sa. The question is where to put them.
What I did was to create a new directory, /xlb. I put those files in that
directory. Then I edited ld in emacs, and found all the places (about two
of them) where the list of libraries searched by ld occurs. The list
includes both /lib and /usr/lib. /lib is now redundant, since it is a
pointer to /usr/lib. Indeed the runtime version, ld.so, doesn't include
/lib, so it is probably even a bug that ld does. Using Emacs, I simply
replaced /lib with /xlb. Since it's at the beginning of the list, this
means that libc.so that we just put in /xlb is used in loading programs.
But since /xlb is not mentioned in ld.so, at runtime, the libc/libd pair
from /usr/lib is used when the program runs. It is crucial to make sure
that /lib is replaced with another name having the same number of
characters, and that you don't do anything else when you edit the file.
The whole concept of using a text editor on an executable is a bit wierd,
but if you are very careful, it does work (at least with Gnu Emacs -- I
make no guarantees about vi or other editors [[ we have done similar
tricks with Unipress emacs; the editor *must* handle full eight-bit data
correctly and I believe "vi" does not. --wnl ]]).
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list