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: > > I think the most often use case (at least for my servers) are sparse zones. T > hus /sbin, /usr, /platform and /lib are inherited read-only. For several reas > ons 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. B > ut now one has a major problem, since /lib/svc/method is read-only, services > can not be installed correctly anymore. > > A dirty workaround for SUNW packages might be to relocate the package (-a non > e). However, this usually doesn't work, since pathes are "hardcoded" into the > manifest (e.g. /usr/share/man , /lib/svc/method aka do not honor BASEDIR) [b > eside the fact, that "relocatable" usually describes the missing / in the pkg > map entries, but real relocation was probably never on the plan of the packag > er]. SUNWsndmr might be sufficient for a case study. > > So actually I can't see, what problems are solved by putting the so called "i > nit.d" scripts into /lib/svc/methods/, but I see, that this artificiallly cre > ates a lot of problems and actually makes managing zones a lot harder than it > could be and even requires package maintainers to create more complex instal > l scripts (error prone) than usually required. > > RFE: So would you mind to consider /etc/svc/method as the primary place for s > tartup scripts (which IMHO shouldn't break anything, if /lib/svc/method becom > es a link to /etc/svc/method) ?
As a beginning note, there's nothing in the SMF architecture or implementation which requires methods be put into /lib/svc/method. I suspect you already recognized this, but wanted to be explicit before continuing the discussion. A method is wherever the manifest defines it to be. /lib was chosen because it is available before /usr is mounted, and IIRC the Solaris rules (per filesystem(5)) say that /etc is for configuration, not executables. But, it's late and I may be misremembering. I'm not sure I fully understand your use case right now, so let me try to clarify. SUNWsndmu installs the sendmail binary into a read-only location, /usr/lib/sendmail. So, you've installed SUNWsndmu into the global zone/ all zones? And, the package you're trying to control is SUNWsndmr, which you want to avoid installing in all local zones? So you're OK with having the service binaries in the zones, and you just don't want the service to run except on zones you specifically select? If I've misinterpreted your use case, please help me clarify it. :) thanks, liane -- Liane Praza, Solaris Kernel Development liane.praza at sun.com - http://blogs.sun.com/lianep
