> 2. Create patch-install-milestone, which depends on patch-install-service > below.
The patch-install-milestone could also depend on single-user and filesystem-local so that it is generally useful for admins manually installing patches as well, even if they don't have the patch-test and patch-install services, but want to safely install patches manually when they have zones on local filesystems. -Steve L. > > On Tue, Aug 19, 2008 at 01:03:55PM -0700, Jordan Brown wrote: > > Bob Netherton wrote: > > > And further > > > refinement would only impact patching rather than the booting process > > > as a whole. > > > > Hmm. I don't know how to have a service that runs when a particular > > milestone is selected, that *doesn't* run when "all" is selected. > > (Other than by dynamically enabling and disabling it.) > > > > > rc scripts doing things with SMF seem a permanent solution to a > > > temporary problem. In my virtual universe there are no rc scripts :) > > > And then the alarm clock goes off and I return to reality. But it does > > > promote rc hackery rather than fixing the problem in SMF where it > > > belongs. > > > > Agreed. Besides, I believe that SMF is locked while rc scripts are > > running, and that any attempt to manipulate it deadlocks. > > > > There are related schemes that could work, but the problem is getting > > them properly sequenced into system startup. > > > > > reboot -- -m milestone=patchinstall seems elegantly simple. > > > > Plausible, though it doesn't exactly fit the current application usage > > model. At the moment, the reboot might or might not be triggered by the > > patching application. The patching application leaves the system set up > > to do the patching at the next shutdown/reboot, whenever that might be. > > (For SunUC-S's shutdown-time processing, it's require that that reboot > > be via the "clean" mechanisms - init, shutdown - so that the processing > > gets done.) > > > > This scheme would require either > > > > 1) having the patch application set the default milestone, and then > > having the startup-time processing set it back, or > > 2) having the patch application do the reboot. > > > > There's still the issue with how to keep this service from running when > > you boot to "all". > > > > Hmm. How does single-user-mode login work? What stops it from running > > on a normal boot? Is it a special case? > > > > --- > > > > BTW: I'm not in a position to commit the patch applications. I'm in > > the middle here because I'm relatively familiar with all of the players > > and the issues, but in my day job I'm not responsible for *any* of them. > > _______________________________________________ > > zones-discuss mailing list > > firstname.lastname@example.org > _______________________________________________ > zones-discuss mailing list > email@example.com _______________________________________________ zones-discuss mailing list firstname.lastname@example.org