Archive-name: Solaris2/FAQ Version: 1.44 Last-Modified: 1995/01/26 17:01:16 Maintained-by: Casper Dik <casper@fwi.uva.nl>The following is a list of questions that are frequently asked about Solaris 2.x. You can help make it an even better-quality FAQ by writing a short contribution or update and sending it BY EMAIL ONLY to me. Thanks!
The latest Solaris 2 FAQ, including an HTML version, and some other goodies can be obtained through ftp from ftp.fwi.uva.nl:/pub/solaris.
The HTML (URL: ftp://ftp.fwi.uva.nl/pub/solaris/solaris2.html) version of the FAQ contains references to most FTP sites and files mentioned in the FAQ. The references to ftp sites are always to either HTML files or directories, never to binary files.
I've added an index of questions and marked changed(*) and added questions(+). The FAQ is being reorganized, time permitting. The index is generated automatically, so there may be errors there. Not all questions are in the section they belong in. Suggestions on how best to subdivide/order the FAQ are welcome.
Solaris(tm) is Sun's name for their UNIX-based user environment, including the UNIX(tm) operating system, window system (X11-based), and other stuff too. Solaris 1.x is a retroactive (marketing?) name for SunOS4.1.x (x>=1), a version of UNIX that is BSD-like with some SVR4 features, along with OpenWindows 3.0. Solaris 2.x (which is what most everybody means by "Solaris") includes SunOS5.x, which is an SVR4-derived UNIX, along with OpenWindows 3.x, tooltalk, and other stuff. (See 1.5 for a chart with more info)
Solaris 2 is more compatible with the rest of the UNIX industry. Other major UNIX vendors including IBM, HP, SGI, SCO, and others are based on System V rather than on BSD (though some of them are on SVR3, not SVR4). All but one commercial PC-based UNIXes are System V based (and mostly SVR4); the only commercial exception is from a small but interesting firm called BSDI. Solaris 2 is where Sun has been putting almost all its development for the last few years now. There will be no new development on SunOS4; already much of Sun's add-on software is only available for Solaris 2. Solaris 2 is the only supported MP OS on all but the old 4/6x0-1x0 w/ Ross 605 modules. Most Sun software is being released first for Solaris 2.x. Solaris 2.3 features a standard X11R5 release of The X Window System, a benefit for those who didn't like NeWS or the V2/V3 OpenWindows server. (It's still called OpenWindows, but it is the X11R5 server with Adobe DPS added in). It is as fast or faster than MIT R5 (depending on the platform) and supports all Sun graphics hardware. Solaris 2 is more standards-compliant than Solaris 1/SunOS 4.
That depends - on you, your situation, your application mix, etc. Some year SunOS4.1.x will go the way of the 3/50 - it'll still be around, but Sun will no longer support it. You don't have to upgrade immediately, but you should be planning your upgrade path by now.
Solaris 2 is an "operating environment" that includes the SunOS 5.x operating system and the OpenWindows 3.x window environment. SunOS 5.x are based on USL's SVR4.0. SVR4.0, in turn, was developed jointly by AT&T and Sun while Sun was developing 4.1.0, which is why things like RFS, STREAMS, shared memory, etc., are in SunOS 4.1.x, and why things like vnodes, NFS and XView are in SVR4.0. (RFS, by the way, is being dropped effective with Solaris 2.3).
Solaris 2.0 only ran on desktop SPARCstations and a few other Sun machines. Solaris 2.1 and 2.4 and later come in two flavors, SPARC and "x86". Solaris 2.1 (and 2.2, ...) for SPARC run on all SPARCstations and clones, as well as all models of the Sun-4 family. The old FPU on the 4/110 and 260/280 is not supported, so floating point will be SLOW, but it does work. A Solaris port for the PowerPC is underway. It is expected to be completed first half '95. IBM will be selling systems with Solaris pre-installed and shrink-wrapped for people who bought a different OS with their PowerPC. The first systems are expected to be 66MHz 601s and 603s. (SunExpert 11/94) Solaris 2.1 and 2.4 for x86 has been released to end users. It runs on a wide range of high-end PC-architecture machines. "High-end" means: 16MB of RAM and an 80486 (or 33MHz or faster 80386DX). It will not run on your 4 MB 16MHz 386SX, so don't bother trying! Also, floating point hardware (80387-style) is absolutely required in 2.1. Starting with Solaris 2.4 for x86, a fp CO-processor is no-longer required, though still recommended. All three buses are supported: ISA, EISA, MCA. Some PCI devices are supported, though full bus nexus support for PCI is not there. See also 3.30. To summarize all this, Jim Prescott gave this chart, which I've updated: Solaris SunOS OpenWin Comments 1.0 4.1.1B 2.0 4.1.1_U1 2.0 sun3 EOL release (not named Solaris) 1.0.1 4.1.2 2.0 6[379]0-1[24]0 MP 1.1 4.1.3 3.0 SP Viking support 1.1C 4.1.3C 3.0 Classic/LX 1.1.1 4.1.3_U1 3.0_U1 4.1.3 + fixes + Classic/LX support 1.1.1 B 4.1.3_U1B 3.0_U1 1.1.1B + SS5/SS20 support 1.1.2 4.1.4 3_414 The "final" 4.x release (SS20 HS11) 2.0 5.0 3.0.1 sun4c only 2.1SPARC 5.1 3.1 Dec '92 2.1 x86 5.1 3.1 May '93 2.2SPARC 5.2 3.2 May '93 2.3SPARC 5.3 3.3 Nov '93 OpenWin 3.3 is X11R5 based: Display PostScript instead of NeWS, no SunView. It is still primarily OPEN LOOK. The Spring 1995 OpenWin will be Motif and COSE-based. 2.3 edition II SPARC Special Solaris 2.3 distribution for Voyager and SparcStation 5 2.3 hardware 5/94 SPARC ?? 2.3 hardware 8/94 SPARC Supports S24 (24 bits color for SS5), POSIX 1003.2, Energy Start power management and SunFastEthernet + patches. 2.4 5.4 3.4 From this moment on, the SPARC and x86 releases are in sync. Q3 '94 Adds motif runtime and headers (not mwm).
There is quite a bit of support in SunOS 5.x for running 4.1.x binaries in an emulation mode called "Binary Compatibility" (BCP). This works by dynamically linking the 4.1.x binaries with a shared library that emulates the 4.1.x binary interface on top of 5.x, so there is some overhead. Programs will only work if they were dynamically linked (statically linked binaries run in 2.3, but with some extra restrictions), and if they meet certain other criteria. Best bet: try it and see. Be aware, though, that Sun WILL drop the binary compatibility package some year. Try to wean yourself and your users from depending on it, even if it means beating on your software vendors to offer "native" Solaris2 applications.
As with SPARC, there is an emulation mode that should run the majority of well-behaved SVR3 and Xenix binaries. Most SVR3 stuff appears to work under Solaris 2.4. Applications from any other vendor's standards-conforming 386/486 SVR4 should also run. However, some vendors have made incompatible changes to their SVR4 release and programs linked on those versions may not work. Future versions of Solaris 2.x for Intel will address some/most of those incompatibilities. Unixware is one of the offenders.
There are too many of these changes to include in this FAQ, but here are some key ones: a. locations are often different hostid /usr/ucb/hostid whoami /usr/ucb/whoami hostname /usr/ucb/hostname (or use uname -n) b. some old commands don't exist or have replacements 4.1.X Solaris 2.X pstat -s swap -s (how much swap space?) dkinfo /usr/sbin/prtvtoc raw_dev_name trace truss mount -a mountall exportfs share bar cpio -H bar (read only) This information can be found in the Solaris 2.x Transition Guide - Appendix A (commands), Appendix B (system calls), Appendix C (files). This guide has undergone some changes from 2.0 -> 2.1 and beyond. Several manuals have ended up being combined into this single manual. This manual discusses administrative transition and developer transition issues. The command "whatnow" (for Solaris 2.x) is included in the "Admigration Toolkit" package (see below). The Admigration toolkit can be obtained from: opcom.sun.ca:/pub/AMToolkit-2.2a.* Sample output: % whatnow hostname hostname 4.x command only hostname /usr/ucb/hostname part of SCP package hostname /usr/bin/uname -n alternate command The whatnow command is limited in that it may point to one command which may only implement a subset of the old command (e.g., pstat points to sar, while pstat -s is identical to swap -s)
You can't do a SunInstall "upgrade" from 4.1.x to Solaris2. You can use the Admigration toolkit (q.v.) to help you move from SunOS 4.1.x (Solaris 1, actually) to Solaris 2. If you're moving from Solaris 2.1 to 2.2, or 2.2 to 2.3, ..., then you can use "upgrade" to preserve your existing partitions and local changes (including pkgadd!!), though it runs very slowly (about 1.5-2x the time for a reinstall) and does require that you have enough free space in / and /usr - make these big when you first install! If you run out of space in one of your partitions, you can always remove some components. Those will not be upgraded and can be installed elsewhere after initial upgrade (e.g., you can remove OW, Xil, Dxlib, manual pages, etc) There is no need to backout patches before upgrading. In 2.2, the system would back them out for you, in 2.3 it won't back out the patches but removes them without a trace. The upgrade doesn't work as well as a full install. E.g., the upgrade from 2.x (x<3) to 2.3 will leave aliases for all your ptys in /devices/pseudo.
The consensus seems to be that yes, it is, for many applications and most users. Your mileage may vary. Binary compatibility was much improved in 2.3. That will help transition somewhat. The performance of 2.3 is adequate, though some parts of the system are still slower than SunOS 4.1.x. Solaris 2.3 is much more stable on MP machines than 2.2. The Solaris 2.3 version of OpenWindows is much faster and much more stable than the versions shipped with SunOS 4.1.x. Solaris 2.1 and earlier should really be avoided. Solaris 2.2 should be avoided too, but some people need to stick to it until some applications get ported (2.2 is the last release with NeWS) Solaris 2.3 still has some problems on high-end MP systems with large numbers of interactive users. Solaris 2.4 promises much more scalable multi-processing.
There is a number of reasons why people dislike Solaris.
1) Change. In general people dislike change. Change requires
re-learning and retraining. Old system administration practices
no longer work. Commands have been replaced by other commands,
some commands behave differently. And they ask why the change was
necessary. SunOS 4.x worked for them.
2) Lack of migration support. Sun did not provide a lot of
tools to ease migration. Many applications wouldn't run in the
binary compatibility mode. The source compatibility mode was
probably compatible with some OS, but it certainly wasn't SunOS.
Lot of public domain and third party stuff needed wasn't
immediately available for Solaris. NIS+, buggy, resource hungry
and instable replaced NIS in incompatible ways.
3) Missing functionality. When people migrate, they at first
don't tend to notice new functionality. Instead, they stumble
upon missing functionality such as screenblank, clear_colormap
and the like (but see 3.17).
4) Slow and buggy. The initial Solaris releases didn't perform
at all well and were extremely instable. This is improving
rapidly, but SuperSPARC MP machines need a heavily patched 2.3
to work reliably.
There are improvements in Solaris 2.x.
1) OpenWindows 3.3 (in Solaris 2.3). Includes X11R5 and
Display PostScript.
2) ANSI-C and POSIX development environment.
3) Multi-threaded kernel and real threads.
4) True multi-processing.
5) Goodies: vold, admintool and Wabi.
"RTFM" is an old saying: Read The "Fine" Manual. Sun still
sell printed manuals, but doesn't automatically distribute
them. As with all real UNIX systems, you do get a full set of
online "man" pages. A smaller, lighter, bookshelf-friendly :-)
CD-ROM called "The AnswerBook"(tm) contains all the printed
documents in machine-readable (PostScript) form, with hypertext
capabilities and a keyword search engine. 90% of your
introductory questions are answered therein!
In Solaris 2.x the Answerbook set gets increasingly more
divided into pieces. It is currently (2.3) split over 4 CDs
Solaris 2.x CD:
Solaris 2.x User AnswerBook
Solaris 2.x administrator answerbook
Solaris 2.x System Administrator AnswerBook
Solaris 2.x on Sun Hardware AnswerBook
Solaris 2.x Reference Manual AnswerBook
Solaris 2.x Software Developer Kit
All programming manuals.
Solaris 2.x Driver Developer Kit
Device driver developer manuals.
There is some overlap between CDs.
As distributed with 2.1 and 2.2, the Answerbook search engine
runs only with the OpenWindows ("xnews") server, not with MIT
X11. This changed in 2.3. If you are using the MIT server
instead of what Sun provides, you'll have to use one of several
"answerbook workaround" scripts that are in circulation. The
AnswerBook distributed with 2.3 and later runs with the OW3.3
X11R5+DPS server, so it should display on any X11+DPS server,
such as on DEC, IBM and SGI workstations.
You should buy (or print from within Answerbook) at least the
reference manual and the System and Network Administration
books, because if your system becomes disabled you won't be
able to run the Answerbook to find out how to fix it...
Solaris man uses a manual page index file called "windex" in place of the old "whatis" file. You can build this index with cd <man-page-directory>; catman -w -M . But, in 2.1, this will result in numerous "line too long" messages and a bogus windex file in /usr/share/man, and a core dump in /usr/openwin/man. (In 2.2, catman works in /usr/share/man, but says "line too long" in /usr/openwin/man). To add injury to insult, "man" normally won't show you a man page if it can't find the windex entry, even though the man page exists. There's a "makewhatis" script in /usr/openwin/man that works better than catman. But watch it - by default it searches files in /usr/man, not in openwin, and it only looks in some predefined man subdirectories. Try changing its "for ..." command to "for i in man*", then use it like this: cd /usr/share/man; /usr/openwin/man/makewhatis . cd /usr/openwin/man; /usr/openwin/man/makewhatis . Still (!), the openwin windex file is somewhat hosed (try "man answerbook" :-(. You can always delete the bogus lines manually... or, you can alias man to "man -F", forcing it to look for the bloody file like you asked. But wait, there's more! To see the read(2) man page, you can't just type "man 2 read" anymore - it has to be "man -s 2 read". Or, alias man to this little script: #!/bin/sh if [ $# -gt 1 -a "$1" -gt "0" ]; then /bin/man -F -s $* else /bin/man -F $* fi
Most commercial software that ran on 4.x either will run in BCP mode, or is available for Solaris 2.x, or is being ported now. Solaris 2.3 BCP mode finally supports statically-linked executables. You can obtain a list of official 3rd party porting commitments, maintained by Sun's "Solaris Demand Center" (whatever that is), by sending electronic mail to "sparc_products@thegift.sun.com" -- this is an automatic reply server. The list shows what third party applications are currently available for Solaris, and lists expected dates for many more. A list of freeware (some "public domain", but mostly copyright- but-freely-distributable) [as well as commercial software??] that has been ported to Solaris 2.x is posted monthly to the newsgroup comp.unix.solaris by ric@updike.sri.com (Richard Steinberger). Look for this: Subject: Solaris SW list. Monthly Post. If you can't wait, the list is also available via anonymous FTP from updike.sri.com.
www.sun.com Sun's own WWW site, contains pointers to Sunsites, patches and has lots of info, press releases etc, etc. SunSites - Sun sponsored sites. Lots of good stuff here: SunSITE USA at UNC - Chapel Hill (sunsite.unc.edu) SunSITE Japan at Science University - Tokyo (sunsite.sut.ac.jp) SunSITE North Europe at Imperial College - London (www.doc.ic.ac.uk) Sun SITE Russia at Moscow State University - Moscow Sun SITE Singapore at National University of Singapore - Singapore Sun SITE South Africa at University of the Witwatersrand - Johannesburg Solaris at UMBC (http://umbc8.umbc.edu/~vijay/solaris/solaris.html) Solaris tips & tricks by Vijay Gill ftp.x.org - the master X11 site camus.quintus.com:/pub/GNU - GNU binaries ftp.uu.net - UuNet communication archives (mirrors abovementioned GNU binaries in systems/gnu/solaris2.3) OpCom. (opcom.sun.ca) - run by Sun Microsystems' OpCom group - lots of stuff. Here is some of the stuff that's online: pub/AMToolkit.* - the Administration Migration (4.1.x to Solaris 2) Toolkit pub/binaries - binaries/man pages for Solaris 2.0 native binaries. pub/newsletter - issues of the monthly OpCom newsletter. pub/docs - assorted documentation, papers, and other information. - all of the RFCs pub/drivers - information related to device driver writing under under Solaris 2.0 as well as a skeleton SCSI driver. ls-lR.Z - compressed recursive listing of files available on the server. pub/tars - compressed tars. pub/tmp - place for uploading things to the server. pub/R5 - the unadultered MIT x11r5 distribution. pub/x11r5 - port of X11r5 to Solaris 2.0, binaries, libraries and headers. A compressed tar of this tree can be found in tars. prep.ai.mit.edu and the GNU mirrors pub/gnu/sparc-sun-solaris2 - recent gcc binaries for SPARC pub/gnu/i486-sun-solaris2 - recent gcc binaries for i486 ftp.fwi.uva.nl pub/solaris - where the Solaris FAQ is kept, including an html version. Accompanied by versions of the wabi1.0 FAQ and x86 hw-config as send out by Sun's autoreply daemons. pub/solaris/auto-install - fully automated auto-install scripts, including an explanation of exactly what a machine needs when booting the installation, automated patch installation and even post-install updates from your install tree, which gives you an easy way to keep all your Solaris machines in sync.
All of them :-). But in particular you should see these FAQ's:
1) Sun Computer Administration Frequently Asked Questions
2) The "Solaris 2 Porting FAQ"
3) comp.windows.open-look - Anything related to OpenWindows or the
OPEN LOOK Graphical User Interface.
4) The Sun-Managers mailing list (see below) has its own FAQ,
maintained by John DiMarco <jdd@cdf.toronto.edu>.
FTP from ra.mcs.anl.gov in the sun-managers directory.
5) See also the "Solaris SW list. Monthly Post" above and the
"whatlist" file.
First, read all the USENET newsgroups with "sun" in their name :-)
1) The Florida SunFlash is a "closed" mailing list for Sun owners.
It contains mostly press releases from Sun and third-party
vendors. This list contains information on conferences such as
the Solaris Developer's Conference as well. It is normally
distributed regionally - to find out about a mail point in your
area, or for other information send mail to info-sunflash@Sun.COM.
Subscription requests should be sent to sunflash-request@Sun.COM.
Archives are on solar.nova.edu, ftp.uu.net, sunsite.unc.edu,
src.doc.ic.ac.uk and ftp.adelaide.edu.au
2) The Sun Managers list is an unmoderated mailing list for
emergency-only requests. Subscribe and listen for a while,
and read the regularly-posted Policy statement BEFORE sending
mail to it, and to get a feel for what kinds of traffic it carries.
Write to sun-managers-request@eecs.nwu.edu.
O'Reilly & Associates specializes in UNIX books. Their "UNIX In A Nutshell" has been updated for SVR4 and Solaris 2.0. Get their catalog by calling 800-998-9938 (1-707-829-0515) 7AM to 5PM PST. SunSoft Press carries books specific to Solaris 2. Look for the inset with your End User Media Kit that lists the most relevant ones. Prentice-Hall has reprints of much of the AT&T documentation. I'm not sure how much of this you need - a lot of the same material is in the Answerbook (see above).
The complete and often updated list Solaris x86 hardware options can be obtained by sending an email message without subject/body to: x86hcl@sun.com (ascii) x86hcl.ps@sun.com (postscript) or x86-hwconfig@Cypress.West.Sun.Com This address currently sends out info on Solaris 2.4.
Wabi is Sun's new MS-Windows-under-unix emulator. The Wabi faqs can be obtained by sending an empty message to: wabi1.0-questions@East.Sun.com wabi1.1-questions@East.Sun.com The list of current Wabi (and future :-) apps can be obtained by mailing: wabi1.0-apps@East.Sun.COM wabi1.1-apps@East.Sun.COM wabi2.0-apps@East.Sun.COM Applications that execute a lot of X86 code, run fastest on Solaris 2.x_86, as no x86 emulation needs to be done. Applications that are more windows intensive will run better on machines with faster graphics hardware. The currently shipping version of Wabi is Wabi 1.1, 2.0 is just around the corner. Wabi will not be made available for SunOS 4.1.x.
A full install of 2.2 is supposed to be 164 MB, but that doesn't include swap. Here is a net exchange between Casper Dik and Gil Tene: In article <1993Apr2.083549.19177@fwi.uva.nl>, Casper writes: |> >How much disc space does SOLARIS take up ? That is should we buy a |> >424MB disc or get a 1Gb disc to put it on :-) |> |> Solaris 2.x takes about as much diskspace as SunOS 4.x: |> |> Partition/Slice Solaris SunOS |> / 10MB 8MB |> /usr 78MB 90MB |> /var 10MB 10MB |> /usr/openwin 83MB 83MB |> Gil replies: On my system, with a full Solaris installation (EVERYTHING selected) + gnu's binary stuff for solaris (off of the Catalyst CD) installed in /opt I see a similar situation to the above plus : 16852 /opt/SUNWabe 19 /opt/SUNWcg12 7968 /opt/SUNWdiag 721 /opt/SUNWgt 7740 /opt/SUNWits 14609 /opt/cygnus-sol2-1.0 (output from "du -k -s /du/*") - SUNWabe is the end user answerbook stuff. (vi, mail, Deskset tools etc, etc) - SUNWcg12 is (obviously) cg12 support. - SUNWdiag is obvious too. - SUNWgt is support for gt boards. - SUNWits is the xgl3.0 library (it has libPEX5.so.1 in there too). - cygnus-sol2-1.0 is the gcc2.0+tools stuff. I have gcc2.3.3 on another partition and that takes about the same space as 2.0 does. Another important note : The full Solaris 2.1 answerbook takes up 164MB on disk. I highly recommend installing it and not using it off the CDROM drive. It's much more usable (faster) this way. And it always stays around -- even when you have something else in the CDROm drive.
1) Do it by hand. You did document every single change and
check it into RCS, didn't you?
2) Automate it, using the AMToolkit (Administration Migration
Toolkit) from the OpCom FTP server (q.v.)!
A SVR4 mechanism for "standardizing" the installation of optional software. Most vendors are expected to use this format for distributing add-on software for Solaris 2.x. Packages can be installed/deinstalled with pkgadd/pkgrm which are standard SVR4 items, or with swm (CRT) or swmtool (GUI-based) which are provided only in Solaris 2. Note that the "pkg" system keeps lots of files in /var/sadm/install, and in particular the file "contents", which is hundreds of KB, and that there are two copies of it while pkgadd is running, so you needs lots of free space where /var is, typically the root. This file must be kept around if you want, for example, to use pkgrm to remove a package, or pkgchk to verify months later that all of a a package's files are still intact. Summary of pkg* commands: pkginfo <pkg> - test for presents of package. pkgadd -d /<cdrom>/Solaris_2.3 <pkg ...> - add missing packages pkgrm <pkg ...> - remove packages. pkgchk -q <pkg> - test for existance of package pkgchk <options> [pkg] - check installed packages for integrity.
This is a common one! SunOS is delivered with the "automounter" enabled. The automounter is designed for NFS sites, to simplify maintenance of the list of filesystems that need mounting. However it is a burden for standalone sites. The automounter takes over /home and in effect becomes the NFS server for it, so it no longer behaves like a normal directory. This is normally a Good Thing as it simplifies administration if everybody's home directory is /home/<username>. To kill it off for standalone or small networks, you can comment out the three lines in /etc/init.d/nfs.client that start "if" (from the if to the fi!!), and reboot (Solaris 2.2) or remove the file /etc/rc2.d/S73autofs (Solaris 2.3). You can always relink that file with /etc/init.d/autofs if you change your mind. To learn about it, read the O'Reilly book "Managing NFS and NIS", or ftp the white paper 'The Art of Automounting". from sunsite.unc.edu in the directory /pub/sun-info/white-papers.
Solaris 2.2 introduces a new scheme for automatically mounting removable media. It consists of a program "vold" (volume daemon) which sits around watching for insertions of floppies and CD's, handles ejects, talks to the file manager, and invokes a second program called "rmmount" (removable media mounter) to mount the disk. Note that on most SPARCstations, you must run "volcheck" whenever you insert a floppy, as the floppy hardware doesn't tell SunOS that a floppy was inserted. Advantages of this scheme: - no longer need root; users can mount and unmount at will. - can do neat tricks like automagically start "workman" or other Audio CD player when audio CD inserted. - extensible - developers can write their own actions Drawbacks: - can no longer access /dev/rfd0 to get at floppy; must use longer name like /vol/dev/rdsk/floppy0 - similarly, CD's get mounted on /cdrom/VOLNAME/SLICE, e.g., /cdrom/solaris_2_2/s0 is slice 0 of the Solaris 2 CD (nice that it does mount all the partitions, though!). To read or write a non-filesystem floppy (tar, cpio, etc), put in the diskette and run "volcheck" from the commandline or click "Check for Floppy" in the filemgr to get it noticed; then access /vol/dev/rfd0/unlabeled (e.g. "tar tvf /vol/dev/rfd0/unlabeled"). [Solaris 2.3: /vol/dev/rdiskette0/unlabeled, or /vol/dev/aliases/floppy0.] If you want the old behavior, it's been suggested that you can comment out the vold startup in /etc/init.d/volmgt and then reboot; an easier way is # /etc/init.d/volmgt stop.
System V Release 4 includes a feature called "shadow passwords". The encrypted passwords are moved out into a shadow password file (called /etc/shadow in this release) that is NOT publicly readable. The passwd file has always been readable so that, for example, ls -l could figure out who owns what. But having the passwd encryptions readable is a security risk (they can't be decrypted but the bad guy can encrypt common words and names &c and compare them with the encryptions). The Shadow Password feature is mostly transparent, but if you do any passwd hacking you have to know about it! And DO make sure that /etc/shadow is not publicly readable!
>... when I try to rlogin as root ...
>it gives me the message "Not on system console
>Connection closed.". What have I left out?
Solaris 2 comes out of the box a heck of a lot more secure than
Solaris 1. There is no '+' in the hosts.equiv. root logins are not
allowed anywhere except the console. All accounts require passwords.
In order to allow root logins over the net, you need to edit the
/etc/default/login file and comment out or otherwise change the
CONSOLE= line.
/etc/hosts.equiv is still supported, but there is no default.
This file's CONSOLE entry can actually be used in a variety of ways:
1) CONSOLE=/dev/console (default) - direct root logins only on console
2) CONSOLE=/dev/ttya - direct root logins only on /dev/ttya
3) CONSOLE= - direct root logins disallowed everywhere
4) #CONSOLE (or delete the line) - root logins allowed everywhere
There are basically two ways to achieve this: Edit /etc/default/login and comment out PASSREQ=YES or change it to PASSREQ=NO. The second way is to give a particular use no password with the following entry in /etc/shadow: user::9092:9999:9999::::
If you need help, ftp the file "solaris2.ftpsetup" from ftp.cs.toronto.edu:/pub/darwin/solaris2. ftpd(1M) is nearly complete when it comes to setting up anonymous ftp. It only leaves out /etc/nsswitch.conf. [S2.3]
Hmmm, the lp system is totally different than what you're used to. The System V Line Printer System is a lot more, well, flexible. A cynic might say "complicated". Here's a very quick guide -- see the man pages for each of these commands for the details. Let's say your Solaris2 workstation is called "sol" and the 4.1.x server is called "bertha" and you want the printer name to be "printer" (imaginative, eh?). sol# lpsystem -t bsd bertha # says bertha is a bsd system sol# lpadmin -p printer -s bertha # creates "printer" on "sol" # to be printed on "bertha" sol# accept printer # allow queuing sol# enable printer # allow printing sol# lpstat -t # check the status Finally, if that's your only printer, make it the default: sol# lpadmin -d printer On some systems you may have to turn on the port monitor. I did that. Why does it now complain about invalid content types? I said it was complicated! For better or for worse, you need to know about printer content types. See the man page for "lpadmin". To get transparent mode, try this: lpadmin -I any -p printer Isn't there any easier way? The GUI-based Admintool has a Printer Manager that is supposed to be able to do all this and more. Try it; Sun hopes you'll like it. Now my jobs print but they stay in the queue after!? It's a known bug, and probably get fixed in 2.3. There's also a number of lpsched patches out for Solaris: 101025-xx (2.2) and 101317-xx (2.3). Make sure you install those.
The 4.3BSD-reno lpr system for Solaris 2, file lpr-sol2-p3.tar.gz or lpr-sol2-p3.tar.Z is available from the following FTP site: get ftp.nus.sg:/pub/NUS/ISCS/misc/lpr-sol2-p3.tar.gz And don't despair. Someday the System V print spooler will be replaced by something new. (See the Solaris 2.3/2.4 Open Issues & Late Breaking News For System Administrators)
Device drivers are linked in dynamically. When you add new devices, just shutdown the system and do boot -r # use drive spec if not default disk to rebuild the /devices and /dev directories. If you're just adding a SCSI disk, you don't need to reboot. Run the following script (as root): #!/bin/sh # # add-disk # # Runs the commands to make Solaris locate a new disk that # has been plugged in after the system was booted. # /usr/sbin/drvconfig /usr/sbin/devlinks /usr/sbin/disks # or /usr/sbin/tapes for tapes /usr/ucb/ucblinks # Compatibility links exit 0 Note that this only works if you already have at least one SCSI disk on the system. (This is because the above just makes symbolic links and things, it does not load up the SCSI driver kernel modules, etc.)
They're now fragmented into 12 million tiny little pieces. Look in
the following files to get oriented:
/etc/inittab - starting point for init
/sbin/rcS, /etc/rcS.d/* - booting stuff
/sbin/rc2, /etc/rc2.d/*,
/sbin/rc3, /etc/rc3.d/* - stuff for multi-user startup.
Note that all files in /etc/rc*.d/* are hardlinked from
/etc/init.d (with better names), so you should grep in there.
There are many "run levels" to the System V init; the run
level 3 is normally used for "multi user with networking."
I can't understand that stuff; can't I have /etc/rc.local back?
I just want to keep all my local changes in one place.
No. You can never have rc.local back the way it was. But then, it
never really was purely a "local" rc file. To have a real
"local" rc file with just your changes in it, copy this file
into /etc/init.d/rc.local, and ln it to /etc/rc3.d/S99rc.local.
Put your startup stuff in the "start" section.
----- Cut here -----
# /etc/init.d/rc.local - to be linked into /etc/rc3.d as
# S99rc.local -- a place to hang local startup stuff.
# started after everything else when going multi-user.
# Ian Darwin, Toronto, November, 1992
# As with all system changes, use at own risk!
case "$1" in
'start')
echo "Starting local services...\c"
if [ -f /usr/sbin/mydaemon ]; then
/usr/sbin/mydaemon 1>/dev/console 2>&1
fi
echo ""
;;
'stop')
echo "$0: Not stopping any services."
;;
*)
echo "Usage: $0 { start | stop }"
;;
esac
------ End of Cut Here -----
SVR4 (hence SunOS 5.x) tries to make everybody happy. The traditional (slow) System V "shutdown" runs all the rc?.d/* shell scripts with "stop" as the argument; many of them run ps(!) to look for processes to kill. The UCB "shutdown" tells init to kill all non-single-user processes, which is about two orders of magnitude faster. Unfortunately, the UCB version does everything it should except actually halt or reboot in SunOS5.1 (and some other SVR4 implementations). This is fixed in Solaris 2.3. If you run a database (like oracle) or INN, you should install a special /etc/rc?.d/K* script and make sure you always shutdown the long way.
Getty should be easy and was reportedly done at a number of sites. The port monitor isn't everyones favorite. But given that you can do much more with the SVR4 init, why would you want to change back? It would be much more trouble than it's worth.
I was hoping you wouldn't ask. PMadm stands for Port Monitor Admin,
and it's part of a ridiculously complicated bit of software
over-engineering that is destined to make everybody an expert.
Best advice for workstations: don't touch it! It works out of the box.
For servers, you'll have to read the manual.
This should be in admintool in Solaris2.3.
For now, here are some basic instructions from Davy Curry.
"Not guaranteed, but they worked for me."
To add a terminal to a Solaris system:
1. Do a "pmadm -l" to see what's running. The serial ports on the
CPU board are probably already being monitored by "zsmon".
PMTAG PMTYPE SVCTAG FLGS ID <PMSPECIFIC>
zsmon ttymon ttya u root \
/dev/term/a I - /usr/bin/login - 9600 ldterm,ttcompat ttya \
login: - tvi925 y #
2. If the port you want is not being monitored, you need to create a
new port monitor with the command
sacadm -a -p PMTAG -t ttymon -c /usr/lib/saf/ttymon -v VERSION
where PMTAG is the name of the port monitor, e.g. "zsmon" or "alm1mon",
and VERSION is the output of "ttyadm -V".
3. If the port you want is already being monitored, and you want to
change something, you need to delete the current instance of the port
monitor. To do this, use the command
pmadm -r -p PMTAG -s SVCTAG
where PMTAG and SVCTAG are as given in the output from "pmadm -l". Note
that if the "I" is present in the <PMSPECIFIC> field (as it is above),
you need to get rid of it.
4. Now, to create a specific instance of ttymon for a port, issue the
command:
pmadm -a -p PMTAG -s SVCTAG -i root -fu -v 1 -m \
"`ttyadm -m ldterm,ttcompat -p 'PROMPT' -S YORN -T TERMTYPE \
-d DEVICE -l TTYID -s /usr/bin/login`"
Note the assorted quotes; Bourne shell (sh) and Korn (ksh) users
leave off the second backslash!
In the above:
PMTAG is the port monitor name you made with "sacadm", e.g. "zsmon".
SVCTAG is the service tag, which can be the name of the port, e.g.,
"ttya" or "tty21".
PROMPT is the prompt you want to print, e.g. "login: ".
YORN is "y" to turn software carrier on (you want this for directly
connected terminals" and "n" to leave it off (you want this
for modems).
TERMTYPE is the value you want in $TERM.
DEVICE is the name of the device, e.g. "/dev/term/a" or "/dev/term/21".
TTYID is the line you want from /etc/ttydefs that sets the baud rate
and stuff. I suggest you use one of the "contty" ones for
directly connected terminals.
5. To disable ("turn off") a terminal, run
pmadm -d -p PMTAG -s SVCTAG
To enable ("turn on") a terminal, run
pmadm -e -p PMTAG -s SVCTAG
Ports are enabled by default when you "create" them as above.
For more details, see the article:
SUMMARY: Solaris modem/terminal how-to: Rev xx.xx.xx
posted periodically to comp.unix.solaris by
celeste@xs.com (Celeste Stokely).
Under 4.1.x you invoke screenblank in /etc/rc.local, but there's no screenblank in Solaris 2.1. Sun recommends that you have everybody put `xset s on' in their .xinitrc, but this may be hard to police, and in any event it won't work when nobody is logged in. The simplest workaround is to copy /usr/bin/screenblank from 4.1.x and run it in binary compatibility mode. See ``What happened to /etc/rc and /etc/rc.local?'' for how to invoke it. Another possibility is to use xdm, but you'll have to use your own, since the xdm shipped with Solaris 2.1 doesn't work. The 4.1.x screenblank didn't work for us; We use Jef Poskanzer's freeware screenblank. His version is available from ftp.netcom.com:/pub/jef/screenblank_21dec93.tar.Z. Because of a bug in Solaris 2.3, you'll need to specify -DHAVE_POLL=0 when compiling this version.
You can FTP Jef's screenload, screendump, etc., if you need that functionality, and for free you get a pixrect (clone) library. Get one of these: ftp.netcom.com:/pub/jef/raster-pixrect_30dec93.tar.Z ee.lbl.gov:/raster-pixrect_30dec93.tar.Z The 4.1.x versions of these programs will not run under Solaris 2.2 or later. The pixrect BCP library is no longer supported.
There is a replacement for etherfind, but it has changed name; in fact it's a whole new program. It IS better. To find it, though, you would have to realize that network snooping is not really Ethernet-specific. To end the suspense :-), here it is: % man -k snoop snoop snoop (1m) - capture network packets and inspect them % It works differently - it has an immediate mode, a capture-to-disk mode, and a playback-from-disk mode. Read the man page for details.
The Classic, LX and the single processor models of the SS20 are still supported under some version of SunOS 4.1.x. A lot of people wanted these machines but only if they ran SunOS 4.1.x. When the Classic/LX came out, clone manufacturers were able to provide SunOS 4.1.x with it, Sun came out with SunOS 4.1.3C some time later. The Classic, LX and SS5 and SS20 are supported in the most recent Solaris 1.x release, SunOS 4.1.3_U1 rev B (Solaris 1.1.1B). The Classic and LX are supported since 4.1.3C (release for LX & Classic only), the SS20/SS5 since release 4.1.3_U1 rev B (Solaris 1.1.1B). Note that none of these OS versions support SuperSPARC MP or any of the new graphics hardware (ZX, SX, S24). The Voyager is not supported under SunOS 4.1.x, too many new device drivers have been added plus the suspend resume feature. The XDbus machines SS1000/SC2000 are also not supported under SunOS 4.1.x. Support for the kernel architecture and XDBus is missing in 4.x.
Yes! Actually, messages like find : cannot open /: No such file or directory. are due to a bug in the tree walking function (nftw(3)). Fixed in 2.4 and in the 2.3 kernel jumbo patch 101318 (-41 or later)
Try using UUCP. The Solaris 2.x sparc serial driver has trouble receiving data at or above 9600 bps. Symptoms include sluggish response, `NOTICE: zs0: silo overflow' console messages, sending spurious control-Gs to the serial port, and applications that cannot be killed even with `kill -9'. This problem surfaces in many applications, including Kermit and tip. UUCP seems immune, though, because its protocol throttles input sufficiently.
Root's shell is /sbin/sh, which is statically linked. Don't just insert a 'c' before "sh" as previously, as that would look for /sbin/csh, which doesn't exist. Don't just change it to /bin/csh, since that's really /usr/bin/csh, which is dynamically linked, because: a) /usr may not be mounted initially, and then you're in deep (the shared libraries are in /usr!), and b) There is code in the startup scripts that assumes that everything critical is in /etc/lib, not /usr/lib. Approach with caution! Safer bet - have an alternate root account, like "rootcsh", with uid 0, and /bin/csh as its shell. Put it after root's entry in the passwd file. Only drawback: you now have to remember to change all of root's passwords at the same time. Third bet - in root's .profile, check if /usr is mounted and, if so, exec /bin/ksh or whatever.
The other machine (an NFS server) is running 4.1.x and needs a patch from Sun to update its network lock daemon (lockd). If you don't install the patch on the server, file locking will not work on files mounted from "thathost". The lockd jumbo patch fixes a bunch of other lock manager problems, so it may be a Good Thing To Get; however, it may also cause the machine on which the patch is installed to have trouble talking to servers with no patch or older patches, so Be Warned. The lockd patches are: 100075 (now 4.1.3 only), 101817 (4.1-4.1.2) and 101784 (4.1.3_U1), 100518 (for Online: Disksuite).
Append this line to /etc/system and reboot: set scsi_options & ~0x80 This turns off Command Queuing, which upsets the Toshiba and some other drives.
As with any hardware addition, first try the obvious (boot -r after installing and power-cycling everything). The adaptec is no longer supported; man -s7 sd no longer even lists it! So I guess they go over the cliff. Either that, or take the drives out and put them on a PC, where ST506 MFM drives are still supported. The MD21 should work, though some people report that SCSI doesn't work in 4/260 boxes (bug-id #11187521).
Solaris 2.x releases are essentially frozen TWO months before their general release date. During the early access/beta test period bugs are found both in the beta and in the previous release. That's why at the moment a new release comes out a number of patches is ready. Some of those are on the Solaris 2.x CD. Others were released almost at the same time as 2.x, or even before 2.x becomes generally available. Some bugs are found in the previous release that can't be fixed in the time for the next release. And bugs get added to new code.
The mandatory patches weren't mandatory, so they've been relabeled. They're now called ``recommended'' patches. The recommended patches are those patches Sun recommends for trouble free system operation. With those patches installed, your chances on trouble free operation are higher. That doesn't mean you will run into trouble without them. These recommended patches can be anonymously ftp'ed from official Sun ftp sites.
thor.ece.uc.edu:/pub/sun-faq/Solaris2.[123]-patches. (SunOS 4.1.x patches in: /pub/sun-faq/SunOS4.1.x.Patches) ugle.unit.no:/pub/unix/sun-fixes SunSites (carry recommended and security patches): sunsite.unc.edu:/pub/sun-info/sun-patches sunsite.sut.ac.jp:/pub/sun-info/sun-us/sun-patches sunsite.doc.ic.ac.uk:/sun/sunsite-sun-info/sun-patches Sunsolve: sunsolve1.sun.com:/pub/patches http://sunsolve1.sun.com/ This Sun's own site, it has the recommended patches up for anonymous ftp, packaged as one huge 2.x_Recommended.tar.Z file and as individual patches. Starting with SunSolve CD 2.1.2 ALL Sun patches are shipped on the SunSolve CD. Contract customers can get all patches by ftp from Sunsolve or via e-mail and query one of the online sunsolve-databases on the internet.
The Solaris x86 driver updates can be obtained by anonymous ftp from: ftp.uu.net:/vendor/sun/sun-doc/x-86-driver
All the files that are replaced by a patch are stored under /var/sadm/patch/<patch-id>/save so the patch can be backed out safely. You can remove the <patchdir>/save directory provided you also remove the <patchdir>/.oldfilessaved file. Alternatively, you can install a patch w/o saving the old files by using the "-d" flag to installpatch.
No, unless otherwise stated in the patch README. If the previous patch installation saved the old files, you may want to reclaim that space. Patches can be backed out with: /var/sadm/patch/<patch-id>/backoutpatch <patch-id> Backoutpatch can take an awful long time, especially when the patch contained a lot of files.
Edit /etc/system and add the following line: * System V pseudo terminals set pt_cnt = <num> * BSD pseudo ttys set npty = <num> Halt the system and boot -r.
Prior to Solaris 2.4, the OS didn't do the bookkeeping necessary to obtain these values. In Solaris 2.4 the code was added to kernel and ps can now show these values.
After installation, run the command /usr/sbin/rtc -z $TZ, where $TZ is your timezone. The default root crontab runs /usr/sbin/rtc -c once everyday. That way your clock will give the proper time whether you boot Solaris or DOS/Windows.
In 2.3 in earlier this requires poking the kernel. In Solaris 2.4, this can be accomplished by adding the following lines to /etc/system: * set hard limit on filedescriptors set rlim_fd_max = 4096 * set soft limit on filedescriptors set rlim_fd_cur = 1024
Under SunOS 4.1 it was next to impossible to run DNS name resolution without either a kludge fix or the NIS (V2 I guess). Under Solaris 2.1 it is incredibly simple, but you must ignore what the manual (SunOS 5.1 Administering NIS+ and DNS) says (the manual is fixed in Solaris 2.2). All that is required to make a non-NIS host use the DNS for name resolution is to change the host: line in the /etc/nsswitch.conf file to the following: hosts: files dns (i.e., when looking for hosts, look in /etc/hosts first, if not found there, try DNS, if still not found then give up) and set up a correct version of /etc/resolv.conf to tell the resolver routines (like gethostbyname) how to contact the DNS nameserver. You must have the names of machines which are somehow contacted during boot in the files in /etc and files must appear first in the hosts: line, otherwise the machine will hang during boot (at least ours did). Make sure that /etc/netconfig is using switch.so. (It does from the factory.)
An idea whose time has come (it came to Ultrix a few years ago). You can control which of the "resolver" services are read from NIS (formerly YP), which from NIS+, which from the files in /etc, and which are from DNS (but only "hosts" can come from DNS). A common example would be: hosts: nis files which means ask NIS for host info and, if it's not found, try the local machine's host table as a fall back. Advice: if you're not using NIS or DNS, SunInstall probably put the right version in. If you are, ensure that hosts and passwd come from the network. However, many of the other services seldom if ever change. When was that last time you added a line in /etc/protocols? If your workstation has a local disk, it may be better to have programs on your machine look up these services locally, so use "files". Terminology: Sun worried over the term "resolver", which technically means any "get info" routine (getpwent(3), gethostbyname(3), etc), but is also specifically attached to the DNS resolver. Therefore they used the term "source" to mean the things after the colon (files/DNS/NIS/NIS+) and "database" to mean the thing before the colon (passwd/group/hosts/services/netgroup etc). A complete discussion can be found in nsswitch.conf(4).
Type "man nsswitch.conf" for more info. There is too much detail to summarize here. Briefly, [NOTFOUND=return] means that the name service whose entry it follows should be considered authoritative (so that if it's up and it says such a name doesn't exist, believe it and return instead of continuing to hunt for an answer).
Yes, you need the Solaris network transition kit available from Sun. However, his kit does not include the securenets patch. Path 100363-03 fixes this, but breaks all TCP NIS calls. (Such as ypcat)
Sort of, with the NIS+ server implementation for Solaris 1.x that comes on the Solaris 2.x CD. This is a server side only implementation and requires NIS+ to run in YP compatibility mode.
Nis+ clients do not hard bind to nis+ servers in the same way that nis clients bind to nis servers. The clients have a list of nis+ servers within the cold-start file. When they need to do a lookup they do a type of broadcast called a "manycast" and talk to the first server that responds. This way they can be sure to use the lightest loaded server for the request.
Yes, that is a known problem. The only operations allowed from a NIS client side on the netgroup table are the ypmatches, but not ypcat (i.e. no support for yp_first(), yp_next() or yp_all() calls). The netgroup table is kind of unique in this. The reason for this is that the netgroup table format changed quite significantly in NIS+ and the NIS+ server would take a big performance hit in converting the netgroups table to YP (key-value) format.
The good news is that it's not memory OR swap space you're being shown by 'ps'. Instead it's showing you the process ADDRESS space which includes 256 MB of address space reserved for the NIS+ transaction log. Given the cost of moving things around in memory and the fact that we have 4 GB of address space to play with it, this is a good idea. You've just got to stop thinking small. THINK BIG. It's only 1/16th of the total process address space being used. And if you ever exceed the 256 MB size of the transaction log you're doing something VERY wrong.
Ps counts the mappings for the framebuffer as memory. Especially on the SX where a number of different mappings of the device address space is used to optimize access this can cause large amounts of memory, but not physical memory, to be mapped and shown by ps.
Start rpc.nisd with the -B switch. This can be done editing the server's /etc/init.d/rpc file and change 'EMULYP="-Y"' to EMULYP="-Y -B"
This is a bug in openwindows. Using xhost + or starting openwin -noauth works around this problem. This is only recommended for stand-alone machines with no dial-in users. [ S 2.3 ]
This is a symptom of a bug in filemgr in Solaris 2.3 Either apply patch #101514 or run the following commands at system start-up: mkdir /tmp/.removable chmod a+rwxt /tmp/.removable
That's a bug in libdps. Sun compiles and links its software
with its own compilers. The isinf() function is shipped with
the SunPRO compilers, but not defined in any Solaris 2.x library.
A workaround exists, and consists of adding the following to
your program:
#include <ieeefp.h>
int isinf(double x) { return !finite(x) && x==x; }
The PPP shipped with Solaris 2.3 doesn't interoperate with other PPP implementations. Patch #101425 fixes this.
You need patch #101448.
You're using gcc without properly installing the gcc fixed include files. Or you ran fixincludes after installing gcc w/o moving the gcc supplied varargs.h and stdarg.h files out of the way and moving them back again later. This often happens when people install gcc from a binary distribution. If there's a tmp directory in gcc's include directory, fixincludes didn't complete. This can happen when you run fixincludes in the background w/o redirecting I/O. Another possible cause is using ``gcc -I/usr/include.''
When the system boots, the first invocation of ps will try to recreate /tmp/ps_data. To this end ps scans the /dev tree. Under some circumstances, a loop exists in /dev and ps will run forever. Most of the time this loop is caused by the symbolic link /dev/bd.off. While this link usually points to /dev/term/b, it sometimes get truncated and points to /dev instead. Fix: rm -f /dev/bd.off; ln -s /dev/term/b /dev/bd.off Use truss(1) to determine whether this is real the cause of your problem.
Make sure you have /usr/ccs/bin/m4 installed. It's in package SUNWbtool. Other causes are bugs in Solaris 2.3 and various revisions of patches. E.g., syslogd is broken in all 101318 patches between level -42 and -50. It works again in 101318-54.
Some vendors still ship a version of RPC/NFS that allows at most 8 groups in the client credentials. Root on Solaris is by default in 10 groups. As a result, the Solaris 2.x mount command will send AUTH_UNIX credentials that are too big to cope with for the remote mount daemon resulting in the ``Invalid client credential'' error. Workaround: put root and all your users in 8 or less groups. NOTE: You must logout and login again for changes in the number of groups to take effect. (or exit root's shell and re-su)
Boot with -as. The kernel will ask you all sorts of questions, including the name of the system file. Use the previous /etc/system file or specify /dev/null.
Boot with -a and specify /dev/null as path_to_inst file.
The tcp/ip abort interval in Solaris 2.x is too short, the default value is 2 minutes. The result is that when an ACK isn't received in 2 minutes, the connection is closed. This is most often seen by sendmail, which will log sendmail: SYSERR: collect: read timeout on connection from ... You can fix this by running following command which increases the timeout to 8 minutes (unit is millisec), which is the Solaris 2.4 (and patched 2.3 default) /usr/sbin/ndd -set /dev/tcp tcp_ip_abort_interval 480000 This command should be placed in a script rc2.d script. (See 3.13) (See 5.13 for another possible cause)
Solaris 2.x sets the don't fragment bit on all packets it send as part of MTU path discovery. The Solaris 2.x implementation is RFC compliant, but the MTU path discovery protocol will fail when there are broken routers in the path. Typical symptom is not being able to connect from a Solaris 2.x hosts but having no trouble from other hosts or being able to start a TCP/IP connection but not move any significant amount of data. /usr/sbin/ndd -set /dev/ip ip_path_mtu_discovery 0 (See also 5.12)
Solaris 2.x uses the "Content-Length:" header to tell the MUAs where messages should be split. Unfortunately, no-one else understands this convention. Instead, the old convention, ``split on "From " lines'' is used most of the time. Those mail readers expect extra lines with "From" to be escaped with ">". Workaround: add "E" to the mailerflags of the local mailer. Edit /etc/mail/sendmail.cf on your Solaris machines, add E to F= on the line that reads: Mlocal, P=/bin/mail, F=flsSDFMmnP, S=10, R=20, A=mail -d $u so that it becomes: Mlocal, P=/bin/mail, F=EflsSDFMmnP, S=10, R=20, A=mail -d $u
In the shadow table/file/map there is a field that indicates how long an account may be inactive before it is expired. On login, the entry in /var/adm/lastlog, the inactive expire time and the current date are compared. If the system determines that the user is expired, he will get "Login incorrect", indiscernible from a normal incorrect login. The fix is changing the user's shadow entry.
Remote, but unshared filesystems, such as /, /var, /var/adm, etc should be mounted with the llock option. Solaris 2.x does this automatically for remote /, but not for remote /var or /var/adm. If you don't specify llock, the system will hang when it tries to do stuff to the *[wu]tmp files, early in the boot process. Workaround: Add the (undocumented) llock option to the mount options for /var and/or /var/adm. (It should be fixed in /etc/rcS.d/S70buildmnttab.sh)
Vacation was moved from /usr/ucb (in SunOS 4.x) to /usr/bin. Unfortunately, the full pathname must be specified in your .forward. Workaround: add a link to /usr/ucb/vacation in /usr/bin on SunOS 4 machines, and add a link to /usr/bin/vacation in /usr/ucb on SunOS 5 machines.
In Solaris 2.3 (and presumably earlier) there is a bug in the pseudo tty modules that makes them hang in close. This causes processes to hang forever while exiting. Fix: Apply patch 101415-02 (for 2.3).
You need to increase the number of pseudo ttys. If you also have a lot of <defunct> processes, you may be hit by a bug in the OS. (See 5.18)
You probably use a Cray as fileserver. It doesn't support all NFS operations ld want to perform. Install the folowing patch: 101409-04: SunOS 5.3: Jumbo linker patch [ Solaris 2.3 ]
Su won't run under a shell compiled under SunOS 4.1.x. Recompile your shell (tcsh/bash) under Solaris 2.x.
Several changes were made to the "sd" driver between 2.3 and 2.4. In particular, the code that resets the drive to the 512 blocksize is no longer called in the case of a data overrun. Accordingly, it is not currently possible to install 2.4 from a local non- Sun CDROM drive. Your best bet for the short term may be to either borrow a SunCD (locally or maybe from your Sun Rep) or to mount the CD remotely on a machine that is already up and running and can handle your non-Sun CD-ROM, and perform a network installation
Where have you been? :-) Sun has dropped their old K&R C
compiler, supposedly to create a market for multiple compiler
suppliers to provide better performance and features. Here
are some of the contenders:
1) SunPro C:
SunPro, SMCC, and various distributors sell a new
ANSI-standard C compiler on the unbundled (extra cost)
SPARCcompiler/SPARCworks CD-ROM. There are some other nice
tools there too, like a "make tool" and a visual diff
(interactive diff).
You have to license and pay per concurrent user.
2) Cygnus GCC:
Cygnus Support and the Free Software Foundation make the GNU C
compiler for Solaris, a free software product. Source code
and ready-to-run binaries can be installed from the CDware CD
(Volume 4 or 5).
Like all GNU software, there are no restrictions on who can
use it, how many people can use it at a time, what machines it
can be run on, or how many copies you can install, run, give
away, or sell.
Cygnus sells technical support for these tools, under annual
support contracts.
The Cygnus distribution includes:
gcc (ansi C compiler), gdb (good debugger), byacc (yacc repl),
flex (lex repl), gprof, makeinfo, texindex, info, patch,
cc (a link to gcc)
The Cygnus compiler on uunet is starting to show its age a
bit. If you want to compile X11R5, you can get the latest
version of GCC in source code, from the usual places
(prep.ai.mit.edu or one of the many mirrored copies of it).
Build and install that compiler using the Cygnus gcc binaries.
Or get tech support from Cygnus; they produce a new version
for their customers every three months, and will fix any
bug you find.
3) Gcc.
Gcc is available from the GNU archives in source and binary
form. Look in a directory called sparc-sun-solaris2 for
binaries. You need gcc 2.3.3 or later. You should not use
GNU as or GNU ld. Make sure you run just-fixinc if you use
a binary distribution. Better is to get a binary version and
use that to bootstrap gcc from source.
GNU software is available from:
prep.ai.mit.edu:/pub/gnu
gatekeeper.dec.com:/pub/GNU
ftp.uu.net:/systems/gnu
wuarchive.wustl.edu:/mirrors/gnu
nic.funet.fi:/pub/gnu
4) Info on Apogee, Lucid C, etc will be added if you send us some.
Solaris ships with everything you need, except for the compiler. All this stuff lives in /usr/ccs/bin and /usr/ccs/lib. If you still can't find it, make sure you have the following packages installed on your system: for tools (sccs, lex, yacc, make, nm, truss, ld, as): SUNWbtool, SUNWsprot, SUNWtoo for libraries & headers: SUNWhea, SUNWarc, SUNWlibm, SUNWlibms for ucb compat: SUNWsra, SUNWsrh
There are several "patch kits" for X11R5 under Solaris 2.1. Most of them require gcc 2.3.3 or later and you must have run "fixincludes" when you install the gcc software. The recommended patchkit is R5.SunOS5.patch.tar.Z available from ftp.x.org:/R5contrib. It works with gcc (2.3.3 or later) and SunPRO C. X11R6 compiles out-of-the-box on Solaris 2.3.
There are several possible problems when compiling X11R6 on Solaris 2.4: The compilation of xc/programs/Xserver/Xext/shm.c will fail with a redefinition of shmat(). Comment out the offending defintion from shmc. If you use SC 2.0, you'll have to add -D__sparc to the StandardDefines in sun.cf line 146. See also 6.5
Some changes in libc.so and libthread.so break the way libthread is linked with libX11.so. Apply the following patch and rebuild libX11.so. *** xc/config/cf/sunLib.tmpl.org Sat Apr 9 01:15:25 1994 --- xc/config/cf/sunLib.tmpl Wed Jan 11 10:59:03 1995 *************** *** 37,44 **** --- 37,46 ---- #else /* else it's Solaris */ + #if OSMinorVersion < 4 #if ThreadedX #define SharedX11Reqs -lthread + #endif #endif #define SharedXmuReqs $(LDPRELIB) $(XTOOLLIB) $(XLIB) #define FixupLibReferences() /**/
Solaris 2.2 doesn't have the full thread support required by X11R6. Compile R6 without multi-thread support or upgrade to 2.3 or later.
Run Configure, and use the solaris_2_0 hints, don't use the solaris_2_1 hints and don't use the config.sh you may already have. First you must make sure Configure and make don't find /usr/ucb/cc. (It must use gcc or the native C compiler: /opt/SUNWspro/bin/cc) Some questions need a special answer. Are your system (especially dbm) libraries compiled with gcc? [y] y yes: gcc 2.3.3 or later uses the standard calling conventions, same as Sun's C. Any additional cc flags? [ -traditional -Dvolatile=__volatile__ -I/usr/ucbinclude] -traditional -Dvolatile=__volatile__ Remove /usr/ucbinclude. Any additional libraries? [-lsocket -lnsl -ldbm -lmalloc -lm -lucb] -lsocket -lnsl -lm Don't include -ldbm, -lmalloc and -lucb. Perl 5 compiled out of the box.
Some of the socket constants have changed. E.g., SOCK_STREAM now has a value of 2, whereas SunOS 4.x uses a value of 1.
The MH config file for Solaris that comes with MH 6.8.3 should work OK, but there's some other problems: One of the Solaris 2.x headers conflicts with mhn.c and inc doesn't know how to seperate messages based on the Content-Length header. A fix for both problems can be found in: ftp.fwi.uva.nl:/pub/solaris/mh-6.8.3-diff
You need to get xv-3.x from ftp.cis.upenn.edu:/pub/xv. Don't use xv-3.01 from ftp.x.org. The latest version, xv-3.10, compiles fine w/o any of the ucb stuff.
See man page DLPI(7). Try NFSWATCH 4.1 for sample code using DLPI.
It is available by ftp from:
harbor.ecn.purdue.edu:/pub/davy/nfswatch4.1.tar.Z
and
gatekeeper.dec.com:/pub/net/ip/nfs/nfswatch4.1.tar.Z
Better yet, FTP the paper "How to Use DLPI in Solaris 2.x" by
Neal Nuckolls of Sun Internet Engineering. Look in
these FTP directories:
opcom.sun.ca:/pub/drivers/dlpi
ftp.ui.org:/pub/osi/{dlpi,npi,tpi}.ps
[ It appears that this site no longer exists, where did it move to? ]
[ someone has found these, ill put a reference in later ]
The C library has exploded. The manual page may give an indication where to find a specific function. Those libraries are essentially split over two directories: /usr/lib /usr/ccs/lib. Important libraries: /usr/lib: libsocket - socket functions libnsl - network services library /usr/ccs/lib: libgen - regular expression functions libcurses - the SysVR4 curses/terminfo library. See Intro(3) for more details.
They are in /usr/ucblib/libucb.so. The b* functions are replaced with the ANSI-C equivalents. Look in the Solaris porting FAQ for more details.
Not really. The Source code compatibility package is compatible with BSD 4.2, not SunOS 4.1.x. The consensus is that the library is broken beyond usability. If you use libucb to pick up some functions you need, it is often best to specify it after all other libraries and after libc with: -lc -L/usr/ucblib -R/usr/ucblib -lucb or preferrably: -lc /usr/ucblib/libucb.a
You're probably linking with libucb and didn't read question 6.14. (Readdir in libucb.so wants you to include sys/dir.h, but many SunOS 4.1.x programs included <dirent.h>, consequently, you're mixing native <dirent.h> struct dirent with libucb readdir(). The symptom of this mixup is that the first two characters of each filename are missing. Make sure you use the native compiler (default /opt/SUNWspro/bin/cc, which may not be in your PATH), and not /usr/ucb/cc.
It is easy to mixup the BSD libcurses and the SVR4 libcurses. One lives in /usr/ucblib, the other in /usr/ccs/lib, when you've installed SUNWarc. Note that when you specify: -L/usr/ucblib -lucb -L/usr/ccs/lib -lcurses you will pick the ucb version of libcurses, not the SVR4 version. If you always put libucb last, as recommended in the previous question, you will have no such problem.
Most of this material is either written by me or sent to me directly. Some of it is cribbed shamelessly from USENET postings in several groups. Thanks to all people who contributed to this FAQ, you know who you are. The list is too long to be included in this FAQ. --- End of Solaris 2.x FAQ -- Maintained by Casper Dik <casper@fwi.uva.nl> ---