Sun-Spots Digest, v6n86
William LeFebvre
Sun-Spots-Request at RICE.EDU
Sun May 15 11:32:18 AEST 1988
SUN-SPOTS DIGEST Friday, 13 May 1988 Volume 6 : Issue 86
Today's Topics:
OS4.0 experience
File system reorganization under 4.0 (5)
Re: SunOS 4.0 "features"
Re: SLIP for Sun
This issue is almost entirely dedicated to messages about SunOS 4.0.
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: Wed, 11 May 88 08:59:37 CDT
From: edsr!neptune!jcn at texsun.UUCP (Jim Niemann)
Subject: OS4.0 experience
We have been a beta site for OS4.0 for 3 months, but now that we are one
of the first customers to have received the FCS version, I can comment.
1) /usr/spool and /usr/adm were not moved to /etc. Sun created
a new directory called /var where high volume files reside.
neptune 37) ls /var
adm crash log preserve spool tmp yp
The idea being that /var can be a seperate partition.
1.5) Copies of hostname, ifconfig, init, mount, and sh reside in /single.
They also reside in /usr/bin, so there is no need to change paths.
2) The goal was to move all executables out of anyplace that was not
in the /usr directory structure, to make administration of providing
executables to clients easier. As a systems administrator, I like
it much better, because all clients dont their own private copy anymore.
(Saves disk space).
3) It is true, ND is gone. But there are a lot of new directories on
servers. /export/exec is where the /usr partitions for hetergenous
clients are placed. This machine is a sun4 serving both sun3 and sun4
clients.
edsr 27) ls -als /export/exec
2 drwxr-xr-x 38 root 2048 Apr 28 13:14 sun3
1 lrwxrwxrwx 1 root 4 Jan 20 22:07 sun4 -> /usr
/export/root is the directory where clients root file system reside
/export/swap is the directory where clients swap files reside.
Even though you can really but clients swap spaces anywhere, SUN
recommends them in a seperate disk partition (so they can be
excluded easily from backup procedures).
/home is SUNs new standard for user work space.
4) SUN did attempt to move most files that require configuration to
/etc. (/usr/lib/aliases and /usr/lib/sendmail.cf both have moved
to /etc). uucp control file (L.sys, etc) have moved to /var/spool/uucp/sys.
(Unfortunately, they forgot to tell beta sites, I hope this move got
into the documentation).
5) /etc/servers changed to /etc/inetd.conf
6) The maximum number of fds have been expanded to 64. Special macros are
required to manipulate them. Old source still works, unless you
reference some old suntool structures that have converted to use the new
FD_SET stuff.
7) Shared libraries live. Binaries are much smaller, especially the windowing
system libraries. Example:
A program that uses sunview, has 4 panels bunches of buttons, when
linked statically is 1097728 bytes. When linked with shared
libraries, it is 106496.
Ah, but you get nothing for free. Administration is more difficult.
Now you have to insure that the proper version of the shared library
exist. Sun has introduced a two tier version system for shared
libraries. Currently SUN distributes these libraries as shared:
libc.so.1.1
libkvm.so.0.2
libpixrect.so.2.2
libsuntool.so.0.28
libsunwindow.so.0.25
That first number after the 'so' is the major version number. It must
be the same as when the binary was linked, or the binary will not run.
The second number is a version control. The theory is that the major
version number should change when any interface to routines change.
When upgrading between releases, save the old version of the .so
libraries. It you (after upgrading) install them in /usr/lib and run
ldconfig, old applications will work. (In the beta distribution, libc
was libc.so.0.7 (ARG!)).
All in all, we have been quite pleased with OS4.0. But it is a major
change for all system administrators. (A change for the better I think).
It will definitely take some getting used to.
------------------------------
Date: 11 May 88 14:59:46 EDT (Wed)
From: mark at cblpf.att.com (Mark Horton)
Subject: File system reorganization under 4.0 (1)
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.
I trust there will be symbolic links in place so that old software and
files will continue to work? Everyone knows that /bin/mail gets you mail
delivery everywhere, for example. Lots of software knows about
/usr/spool. And people's PATHs would break. I think System V requires
that mail go in /usr/mail, which I guess should also be symlinked to
/etc/spool/mail.
Mark
[[ Ahh, but well-written programs shoudl have all of those definitions
collected together in a common place (such as a local.h file). A major
change in the operating system justifies recompilation of most everything
anyway, so it will only be just a little more work to change the
configurations of all your local software while you're at it. Simple,
right? Oh, am I dreaming again? --wnl ]]
------------------------------
Date: Tue, 10 May 88 15:48:40 EDT
From: reg%lti.UUCP at bu-it.bu.edu (Rick Genter x18)
Subject: File system reorganization under 4.0 (2)
/usr/spool and /usr/adm are symbolic links to /private/usr/spool and
/private/usr/adm, so they are already on the root filesystem. (SunOS 3.X)
- reg
------------------------------
Date: 11 May 88 18:26:56 GMT
From: laic!darin at decwrl.dec.com (Darin Johnson)
Subject: File system reorganization under 4.0 (3)
> /usr/spool and /usr/adm are gone...
Actually, mine are on the root system. They come that why by default.
Yours might not be if you are not running clients.
> Also, /usr is to be mounted read-only.
My /usr is mounted read-only from the clients by default. The only hangup
I've run across is that you can't play hack from clients...
>Comments anyone?
OK, here they are.. Looks like what Sun is trying to do is to get rid of
all the stuff that used to reside in the nd disk and put it somewhere
else. The spool and adm stuff are moved back onto the nd disk (or however
they are going to do it) since they were really links to there anyway.
This will result in LOTS less disk space taken up (I have nearly three
quarters of a disk taken up by client root and swap space) since nearly
all this stuff are duplicates. Personally, I would like to see nothing at
all in the root partition for clients except for symbolic links to the
private stuff needed (/tmp and rc stuff - /tmp can be linked to
/usr/tmp/client_name, etc.). Of course, in order to reorganization like
this, Sun has to resort to messing with your interpretation what what a
UNIX hierarchy looks like.
Darin Johnson (...lll-lcc.arpa!leadsv!laic!darin)
(...ucbvax!sun!sunncal!leadsv!laic!darin)
------------------------------
Date: Wed, 11 May 88 22:50:42 EDT
From: Stephen J. Roznowski <sjr at mimsy.umd.edu>
Subject: File system reorganization under 4.0 (4)
I'm doing this from memory (my 4.0 documentation is at home and I'm not),
so I may be slightly incorrect.
Your reorganization is slightly incorrect. Specifically:
> /usr/spool and /usr/adm are gone -- instead there's /etc/spool and /etc/adm.
/usr/spool and /usr/adm are being moved to /var. The implications are
that if you want, /var can be a separate file system.
> Also, /bin no longer exists! Its contents live in /usr/bin. Also,
> /lib no longer exists. Its contents have been moved to /usr/lib.
But, /bin is a symbolic link to /usr/bin and /lib is a symbolic link to
/usr/lib.
> Executables from /etc are in /usr/etc. Also, /usr is to be mounted
> read-only.
/usr will be available during a single user boot, just like the diskless
clients mount / and /pub. /etc/rc.boot and been changed to fsck both /
and /usr.
> Executables from the root directory reside in /single.
There are only seven executables in the root file system (/ and /single).
They are: vmunix hostname fsck mount ifconfig sync echo. [These are the
files needed to "execute" rc.boot]. The root file system is now only
about 1 Meg.
>[[ 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 ]]
I believe that there will still be a "hidden" copy of sh on the root file
systems (something like /pub/bin/sh).
4.0 changes the default location of home directories (file systems) from
/usr/<hostname> to /home/<hostname>.
Setup no longer supports a bitmapped interface. It is now "vt100"
capable. [i.e. it uses curses....]
Of course 4.0 is where ND goes away and netdisk becomes available. So
there is also a /exports/roots, and a /exports/swaps for diskless clients
(not sure of the locations, but you get the idea). I believe that swap
grows (and shrinks?) automatically as needed, so you can set aside a chunk
of your file system for swap spaces, and users who need alot can get it,
while the ones who don't, don't "waste" theirs.
I guess that my big concern is that I now need two good sections of disk
to be able to boot my sun, if /usr is corrupted, I need to boot miniroot
off tape to uncorrupt /usr. Also, it is nearly impossible to have a
backup root (since I also now need a backup /usr), but going to the tape
is not all that painful.
Apart from the file system reorganization, 4.0 looks like it is a step in
the right direction. Some of the better things that I remember off the
top of my head is:
A capapability to do (more) auditing of users. [Big Brother
finally arrives in unix land]
Auto mounting and dismounting of NFS file systems (through
automount)
The ability to run individual (diskless) workstations at
different release levels [you can upgrade 1 workstation
to release 4.1 to see how you like it without
disturbing the others]
One of the not so better things is that there are now dozen of symbolic
links scattered all over the place. [And just when I figured out where the
executables were, they move them on me :-) ]
I'm sure that I forgot some of the more important items in 4.0, but it
will soon be out for everyone to see.
Stephen J. Roznowski sjr at mimsy.umd.edu
P.S. I'm dreading the upgrade to 4.0; how does the rest of the net feel?
[[ Any major operating system upgrade is a royal pain for system managers.
SunOS 2.0 and 3.0 were, as was 4.2BSD, 4.3BSD, and VMS 4.0 (and probably
VMS 3.0 and 2.0 as well---but I wasn't involved with Vaxes way back then).
--wnl ]]
------------------------------
Date: Wed, 11 May 88 11:43:11 PDT
From: bvs%shadrak at sun.com (Bruce Schwartz)
Subject: File system reorganization under 4.0 (5)
[[ Mr. Schwartz also cleared up some of the reorganization questions (as
Mr. Roznowski did). Here are Mr. Schwartz personal comments: --wnl ]]
>Comments anyone?
There are quite a few other changes in 4.0. Most file system changes have
to do with cleanung up the directory and making heterogeneous environments
work better. In 4.0 it is easy to have diskless clients that are running
different architectures and releases than the server. It is much easier
to add and delete clients.
Hope that helps.
------------------------------
Date: Thu, 12 May 88 11:47:13 EDT
From: reg%lti.UUCP at bu-it.bu.edu (Rick Genter x18)
Subject: Re: SunOS 4.0 "features"
My understanding is that the integration of NeWS and X into a "generic"
window system (one where you choose which toolkit you want to use -- and
yes, SunView is YATK) will occur in SunOS release 4.1.
- reg
Rick Genter ...!buita!lti!reg
Language Technology, Inc. reg%lti.uucp at bu-it.bu.edu
27 Congress St., Salem, MA 01970 (617) 741-1507
------------------------------
Date: Thu, 12 May 88 11:16:10 PDT
From: Brent Chapman <capmkt!brent at cogsci.berkeley.edu>
Subject: Re: SLIP for Sun
Reference: v6n81
> You should also consider obtaining the latest release of the internet code
> from 4.3BSD. It contains a much improved SLIP driver, and is already set
> up for installation on binary-only Sun's.
>
> The complete source code was posted to comp.bug.4bsd.fixes, and is also
> available via ftp from ucbvax and uunet.
There are several parts to this upgrade kit (four, I believe). Only one
of those four parts (the TCP code, mostly by Van Jacobson of Lawrence
Berkeley Labs) is set up for installation on binary-only Suns. It is
doubtful that the other parts could be made to work, even with source; in
any case, it would probably be a lot of mostly unnecessary work, since
people at Sun have stated that the improvements in those kits have been
integrated into SunOS 4.0.
Specificly, the SLIP driver from the Berkeley kits will _not_ work on Suns
as-is; it assumes 4.3BSD networking code and structures, which SunOS 3.x
doesn't have. Have hope, however... David Comay has already modified
that SLIP driver for Suns, and it is already in the Sun-Spots archive on
titan.rice.edu (though I'm not sure of the exact name). It works just
fine.
One further note, for those who are interested... I just recieved PC-NFS
3.0 today from Sun. It includes a SLIP driver (basicly the older, but
perfectly usable, SLIP stuff from Rick Adams and Mark Weiser that was on
the 1987 Sun User Group tape) for both the Sun and the PC, and several
programs to do dialup SLIP (apparently derived from work by Greg Whitehead
of UC Davis).
It looks like at least _one_ division of Sun (whoever it is that handles
PC-NFS) is living up to Sun's claim of "delivering what the market
wants"... Now, if only they'd ship SLIP as part of SunOS, which is what
we _really_ want...
-Brent
Brent Chapman Capital Market Technology, Inc.
Senior Programmer/Analyst 1995 University Ave., Suite 390
brent at capmkt.com Berkeley, CA 94704
{lll-tis,uunet}!capmkt!brent Phone: 415/540-6400
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list