lianep at eng.sun.com wrote: > Darren J Moffat writes: >> lianep at eng.sun.com wrote: >>> This doesn't work for the zones model. /usr/lib is (by default) shared >>> between all zones, and services need to have a location where they may not >>> be. >> I don't see where the problem is with zones so I must be missing >> something. Here's my thinking: >> >> We don't support different versions of the same Solaris WOS package in >> different zones. >> >> Zones can't have a different set of packages installed from the global >> zone either. > > Where'd you get this information? All the zones docs say you can use > pkgadd in a local zone. If I'm confused about this, the docs are too. > :)
I didn't say you couldn't use pkgadd. The Zone creation tools don't let you choose what Solaris packages you get for your zone, full or sparse. You always get the same packages as you already have in the global zone. At least today. >> The files aren't editable anyway so the admin can't arrange for the >> contents of the Solaris manifests to be different between zones. >> >> Given that the files in /var/svc/manifest are always the same for all >> zones, right ? So what am I missing ? > > That's what you're missing. You could pkgadd, say, sendmail into > just one local zone. It delivers a manifest. It needs to put the > manifest in a location that's per-zone by default. True, I was forgetting about the case of adding WOS packages to a Zone where they didn't already exist in the global zone. However I believe that really only works if you have a full root zone or your packages don't touch /usr. So I believe it would already need to be able to write into /usr/lib/svc/ it has to write into /usr/lib to put sendmail in place anyway for that example. Surprising I didn't catch that one since I've actually done that myself to have a minimized global zone with a less minimal full root local zone :-) > Zones design, I think, sticks us with a problem of having to split > packages. (Or, put another way, the packaging tools do -- split root > and usr packages are an artifact of package/install implementation, not > necessarily the way things needed to be done.) Agreed, a little bit of both me thinks. It would be nice if our package tools could just be told "this file is a root one, this is a usr one". >>> I've been cooking up a plan in conjunction with the profiles project to >>> move the default manifest and profiles location to /etc. It needs a little >>> refinement first as some details are tricky, but I'll post it here, probabl >> y >>> mid-July, for comment. >> Whats the rationale for the move from /var/svc to somewhere under /etc ? >> What problem is that solving ? I know it doesn't change my situation >> since /var and /etc are both root filesystem package locations. > > Early boot services, and we can manifest-import *much* earlier and get > rid of a lot of grungy scenarios. You're right that it doesn't solve > your request. Cool that seems well worth it. The late mounting of /var is a problem! > You also said: >> My request was ONLY for the Solaris WOS provided manifests not ones from >> unbundled products or ones written locally; those would still live in >> /var/svc/manifest (or in /etc/ somewhere depending on Liane's proposal). > > Plenty of WOS provided manifests couldn't do this based on the zones > requirement to allow installation in a shared-/usr local zone. Are you > sure your service could? My service in this case is pretty simple. It just has a start method that calls a modified /usr/bin/mixerctl to set the volume back to what it was on shutdown (since lots of hardware doesn't remember that). -- Darren J Moffat
