Why does Solaris keep coming with bourne as the default root shell? I've spoken with numerous admins that tell me they change all the root shells to korn.
I would like to change all Solaris 10 boxes here at my company to have a root korn shell. Can someone tell me why I shouldn't do this?
It that intentional? I would like Sun to explain what use /sbin/su.static is without a staticly linked shell. After a few customers screw up /lib we may see Sun return to a staticly linked shell. Even though Sun has withdrawn the ability to easily recover from a shared library disaster, I still would not change shells unless /usr has been merged into the root filesystem. Those other shells continue to reside in /usr. If /usr cannot be mounted, most of us would prefer a root shell that resides entirely in the root filesystem.
it's the same binary as well. sun recommends to include the /usr in the root filesystem. Sun EIS (Enterprise Installation Standards) follows the doctrine of Adrian Cockroft in his book "Solaris Performance and Tuning" ie "all in one slice". In particular sun does not have separate slices for /usr, /opt or even /usr/openwin! There may be reasons to have /var in a separate slice on a server (such as constraining the system from filling up with historic log and message files), which i always do and recommend...
if you have an own /usr, you could copy the shell to e.g. /sbin, links go to /lib in root and not to /usr/lib, that should do the job..
but anyhow, true, there is no explanation why, in a case of emergency it would be better to have a "not linked" shell
Amazing info, pressy! You weren't kidding when you said "everything". There is not even a libc.a anywhere on the box! I retract my statement about the possibility of seeing a staticly linked shell. Sun has burned their bridges behind themselves too thoroughly for that.
For those that don't know the difference between static and dynamic libraries.
When using a static library, the linker finds the bits that the program modules need, and physically copies them into the executable output file that it generates. For shared libraries, it doesn't --- instead it leaves a note in the output saying `when this program is run, it will first have to load this library'. Obviously shared libraries tend to make for smaller executables; they also use less memory and mean that less disk space is used.
You can also make changes to the libraries without a need to re-link or recompile your code.
I took this from this page. It does a good job of explaining it.
With something like stdio, a single shared library serves all of the programs to use printf, getc, etc; and yes, that saves a lot of memory. But now consider a single program that needs, say, a square root function. With archive libraries, we can the square root function out of the math library and build the program. With shared libraries, we must load the entire shared library into memory. Routines like log(), cos(), atan2(), gamma(), etc get loaded whether you use them or not. This leads you down a different path and you design libraries differently. Instead of a math library, you really want algebra, trig, statistics, and calculus libraries. And rather than loading a library with features, you want them "lean and mean". With archive libraries, it was cool to have a hyperbolic cosine function. With shared libraries, I'm thinking "who needs those hyperbolic trig routines?" Libraries are now a place to put very commonly used routines. They are no longer collections of functions in a general sense.
I know this thread is a couple years old, but I am trying to get a definitive answer on the Solaris 10 root default shell question. It seem the only place I can find anyone drawing a line in the sand and saying it is ok to have BASH or KORN as the default root shell is in forums like this.
Has Sun published this anywhere? I tried looking in BigAdmin and found nothing. You'd think there would be more discussion regarding this. After all BASH is a very popular shell, and BOURNE can be a PIA.
Please post any links that may be relevant, here is one that Google keeps putting up top: