Casper.Dik at sun.com wrote: > >Do you mean replacing "root"'s login shell in /etc/passwd with any shell > >? Where is this documented (AFAIK the recommentation over all the years > >was "... don't do that. Never. Don't touch it or your system will > >explode (sooner or later) ...") ? > > No, there was no documentation stipulating that fact.
I think you will still get that answer when you ask in news:comp.unix.solaris (e.g. this knowledge doesn't seem to be well-known outside Sun...) ... ;-( > The only potential problem was for those people stupid enough to > split / & /usr; well, the *real* problem was people changing > /sbin/sh to /sbin/csh which, of course, does not work. Uhm... I do not think it is "stupid" to split "/" and "/usr" - sometimes it is usefull to do it for performance or other reasons (like using seperate physical disks for "/" and "/usr") ... > But we've addressed that issue. > > This is somewhat of a rehash of the argument against no longer > shipping a statically linked "/sbin/sh", which the external folks > may have missed. > > In the end, having /sbin/sh dynamically linked adds about 10 files > to the list of 100s of files needed to successfully boot to single > user mode so the whole statically linked issue was declared moot. Why doesn't apply the same argumentation to "libshell in the root filesystem", too ? [snip] > This is relevant, how? > Root's shell needs to be POSIX compliant because? I was thinking more about having a (near-) POSIX-conformant shell around at startup time and single-user mode, something which is easy to use, doesn't have the habit to turn the life of admins into a living hell in emergencies, can be used in jumpstart, pkgadd/pkgrm preinstall/postinstall/precheck/preremove/postremove scripts, boot time scripts and allow a high amount of "portability" between operating systems. > >It is still the default configuration in the installer to create a > >seperate "/usr" filesystem (and still needed for diskless client setups > >or when /usr should live on ZFS/QFS or simply another physical disk). > >And you forgot the jumpstart case (like I did... and I usually try to > >forget this immediately again because it is usually a pain to deal with > >/sbin/sh when you write POSIX-like shell scripts most of the time) ... > > If that's the case the installer is broken (and it probably is, I > don't doubt that). Why should the installer be "broken" when it uses this choice by default ? It is a valid choice in Unix to have "/" and "/usr" on seperate filesystems and it is AFAIK still needed for diskless client support and zones (please correct me if I am wrong). > ><blink><marquee>DEFINATELY NO</marquee></blink>. At some point we will > >have followup projects and many of them (like SMF) simply need libshell > >in the root filesystem because the consumers live there, too. Moving > >libshell or any of the libraries needed by it to /usr/lib would kill > >most of the follow-up projects. And this would neither help programmers, > >users, admins or writers of jumpstart/startup scripts. > > Why? Why do we want to burden these programs with libshell? Why not ? > All the tools which currently use command line editing use > libtecla; it is installed in /usr/lib so it is clear that replacing > such functionality does not require a library in /lib. I wasn't only thinking about "command line editing". For zones and SMF I have some nice ideas in the queue to add features like event-driven scripting (for example send SMS to the admin when a service goes down) or simply "conditional execution" (e.g. the usual if...else...fi machinery would be very usefull, including keeping the current status of a SMF service in variables maintained by discipline functions (for example $ echo ${SMF.service.status["svc:/network/telnet:default"]} # could return "online" (the "trick" is to define a "get" discipline function for "SMF.service.status"))). > I see no follow-on projects listed in the ARC case so I would > like to know what these are. They are not listed because we have only rougth drafts and some prototype code for some of them - but it doesn't make sense to spend more time on such items unless we're sure that the basis - this ARC case and putback - has a chanche to succeed (and the current resistance makes me think there isn't much a chanche it will succeed without being crippled to death). To satisfy your curiosiy a little bit: - |libc::wordexp()| currently uses the old Solaris /usr/bin/ksh but should use "ksh93" in the future. Since libc sits in "/lib" it may be nice to have a copy of ksh93 in the root filesystem, too - otherwise |libc::wordexp()| will only work when "/usr" is mounted - Replace some of the standalone commands with the libshell builtins (low-hanging fruits include "sleep", "pwd", "test" etc.) - Think about { SMF, zone adminstration tool } which can be scripted (and do event-driven+conditional tasks) using shell functions and scripts (similar how dtksh/tksh can run shell functions as callback hooks) > The ARC has traditionally resisted "frameworks" which did not > have consumers; I see no concrete examples of such consumers. ksh93 has no "concrete consumers" either right now, too - using this kind of argumentation we could cancel this effort completely. > And what is preventing these followon projects to move the library? It needs to be ARC'ed - again. Based on the current resistance we will either get libshell in /lib now or simply forget such projects completely because in a second/third/etc. attempt we will face the same argumentation+resistance. It's IMO useless to start projects or even consider them when there is little chanche of success. > What is the relevance of jumpstart here? Think about pkg preinstall/postinstall/precheck/preremove/postremove scripts or custom install scripts which need to be run before "/usr" gets mounted... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
