Mike Gerdts writes: > There are already annoying portability issues. I'm sure someone will > correct me if my fuzzy memory is wrong.
Indeed; if you step outside of just Solaris, the issues get even worse. However, the compatibility issues considered in the context of this particular "bug" were as I stated: the rc script interface exists for compatibility with old versions of Solaris, and those versions won't run the rc scripts with anything other than a Bourne shell (unless you drive out of your way by running 'exec'), so there's no point in trying to do otherwise. That old software either works with old Solaris, and will continue to do so, or doesn't work, and still won't. > > (I wouldn't bother with an enhancement like this, precisely because > > it's just a compatibility feature, and because nothing new should have > > these scripts.) > > I would expect that Sun's priority would be to make it so that there > is a tool (command line and gui) to easily add a service. If you apply this: s/Sun/the OpenSolaris community/ then we'll be in agreement. Otherwise, I think we've got a topic problem, because I don't think Sun's priorities aren't really open for debate, at least on this list. > svccfg in > its current form is not it. I've worked with some reasonably good > sysadmins and application admins that have not been able to make the > transition which is largely seen as extra work that is hard to do with > little or no benefit (that is immediately apparent to them). There > are several things about adding a service to SMF that are confusing: Great! I hope someone who cares this much about the problem will volunteer to address these things. > - No other part of Solaris has configuration files in /var. IMHO this is a > bug. Those aren't actually configuration files (you're not supposed to edit them, and nothing else does); they're simply a mechanism that links package upgrade to the SMF repository. And, for what it's worth, I think you're actually mistaken about the "no other part" of Solaris -- consider NIS. > For the trivial case of "start this in muti-user mode", SMF is way > hard to use. I understand the benefits of SMF and am quite capable of > and am (almost always) quite happy using it. I have, however, had > limited success in getting others to make use of it when adding new > services for the reasons I outline above. So, then, complaints are great, but let's see a proposal from someone to fix that. Mike Gerdts writes: > If I were running that on Solaris 10 or earlier I would expect: > > [[: command not found > > There are already incompatibilites going backwards. Generally this > has been accepted so long as old stuff doesn't break. Indeed. But that misses the point: > > The only reason I can see to support rc scripts is to allow for > > compatibility with older releases of Solaris (or perhaps even with > > other OSes). In that case, you _have to_ live with the constraints > > that those older releases continue to have -- which means that > > "#!/bin/ksh" just isn't going to work. The existing /etc/rc*.d stuff is there so that software that *must* run on older versions of Solaris (either because it was originally written there and never updated for S10 or newer, or because it's still supported on those old versions) can still run. Since that's the purpose, the constraints of S9 and older here are quite important for the discussion. And on S9, if you put "#!/bin/ksh" at the top of your rc script, it won't work. Never has, never will. Since the purpose is compatibility, and what you're proposing to allow wouldn't be compatible with S9, what's the point? > > An rc script should just start the service; it shouldn't be a magnum > > opus. Frankly, I think that if you're doing anything in an rc script > > that is so complicated that the difference between legacy Bourne shell > > and the newer Korn shells makes any real difference, then you're doing > > something deeply wrong. > > Agreed. However, many people that need to deliver a start script > don't know about these differences - many of which only exist in > Solaris. A script that works fine on RHEL, HP-UX, and likely others > will fail on Solaris. As a closely related example, when a certain > market-leading data warehousing company's software is installed on > Solaris it drops things like the following in /etc/profile: > > export VAR=val Sigh. > I've seen similar things in rc scripts many times, usually when they > are expecting the shebang to have the typical effect. This is quite > likely because Solaris is not the primary development platform. The > code works just fine everywhere else, so I can understand why someone > trying to deliver to Solaris as a non-primary platform will get > tripped up in their attempts to port to Solaris. There is no value in > not supporting such an enhancement. Are there really valid rc scripts that (a) require ksh and not Bourne shell and (b) that are expected to run on OpenSolaris plus other platforms but not Solaris 10 or older? Note that these supposed rc scripts could never have been run on S10 or anything older, because they won't work. So, they must have either never been tested on Solaris at all (in which case it's hard to see how they're supported), or they're specifically designed for OpenSolaris. But if they're specifically designed for OpenSolaris, then why they heck are they still doing rc scripts? After all, rc scripting details vary greatly among systems (as you rightly note), and SMF is the new standard for S10, OpenSolaris, and beyond. If the issue is "SMF is too hard," then putting lipstick on /etc/rc*.d isn't the right answer at all. It just encourages people to try to stumble around the problem rather than addressing the real issue. For what it's worth, if I were one of those software developers trying to make a universal rc script, I'd very much intentionally restrict myself to the tiniest subset of Bourne syntax possible, to make sure it would work everywhere. It'd just never occur to me to pepper the script with ksh-isms like '[[' any more than I'd attempt to use csh syntax. Am I the last careful designer left? :-< -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
