Jens Elkner writes: > Just evaluating zones and think, that putting the so called Sol N > (with N < 10) /etc/init.d scripts into /lib/svc/method is a major > design flaw. Why:
This looks like something that ought to be discussed on the SMF (smf-discuss at opensolaris.org) or Zones (zones-discuss at opensolaris.org) list. It doesn't look to me like an install-related issue. > I think the most often use case (at least for my servers) are sparse > zones. Thus /sbin, /usr, /platform and /lib are inherited > read-only. For several reasons one may choose to not install > software packages into the global zone (e.g. for security reasons > (e.g. suid progs)), but into one sparse zone, only. But now one has > a major problem, since /lib/svc/method is read-only, services can > not be installed correctly anymore. The intended administrative model is different from what I think you're suggesting. Instead of using package installation to enable or disable software, use the supplied svcadm command to turn services on or off where desired. There are also SMF profiles that allow you to turn groups of services on and off for particular usage cases. > RFE: So would you mind to consider /etc/svc/method as the primary > place for startup scripts (which IMHO shouldn't break anything, if > /lib/svc/method becomes a link to /etc/svc/method) ? Yes, I would mind that. There should be nothing executable delivered by the system located in /etc. (There are a few things still there, but they're problems rather than features.) -- James Carlson, KISS Network <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
