> 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
> > zones-discuss@opensolaris.org
> _______________________________________________
> zones-discuss mailing list
> zones-discuss@opensolaris.org
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
