On Thu, Aug 21, 2008 at 04:01:43PM -0700, Jordan Brown wrote: > Steve Lawrence wrote: > > A. Make patchadd verify that the system is in single user milestone when > > installing a single-user patch. > > That's a non-starter. *Many* of our customers ignore our recommendation > to install patches in single-user mode, and will revolt if we attempt to > enforce it. > > In addition, for many patches the single-user mode recommendation is > only the first approximation, primarily intended for automata. If a > human is installing the patch, it may be acceptable to install it after > manually shutting down the affected services.
That seems completely unsupportable, but ok. Admins are used to getting away with not following the patch README or suggested procedure. (A) could be dropped without much impact to the solution. > > > B. If patchadd discovers that it needs to patch a zone, patchadd should > > first > > make sure the zone's zonepath is properly mounted. An overkill for this > > could be to issue a "svcadm enable -srt fileystem/local" IF patchadd is > > not being run from the context of an SMF service, otherwise, fail. > > (sorry, no patchadd from smf services or rc*.d scripts). > > "No patchadd from smf services or rc*.d scripts" means "no automated > installation of single-user patches". That's a non-starter. Your final comment addresses this. Post filesystem/local, it is safe for SMF services to call patchadd. > > > An alternate solution is to fail patchadd with a message stating that > > filesystem/local must be enabled to install the patch due to the > > installed zones. The admin could then do as instructed. > > Also a killer for automated installation. > > > C. (2) above will need to somehow set the milestone to single-user, wait > > until single user is reached, and then do the patchadd, which will do > > A and B. This automated tool could also do the: > > > > "svcadm enable -rt fileystem/local" > > > > If B fails do to the alternate solution. The automation tool could also > > enable filesystem/local in cases where the patchadd version the system > > does > > not have this functionality. For simplicity, perhaps just always > > enable filesystem/local in the automation tool after single-user is > > reached. > > > > I think to implement (2), at some point you are going to need to fork off > > some asyncronous process which changes the milestone, waits, and then > > addes the patch, potentially also enabling filesystem/local before patching > > if needed (or just always). > > I'm not happy with doing this stuff outside the bounds of SMF, or with > approaches where the user is offered a single-user login while the > automated tools are installing patches in the background and will > asynchronously reboot the system. I don't think either is necessary. Call this requirement (no login prompt) out in your use case. I assume the patch service will patch, set the boot milestone, and reboot before the patch milestone is actually met, avoiding the maint prompt. Definately get some console messages out of the patch-service so folks don't think their boot is hung and freak out. :) > > My favorite approach is, approximately: > > 1) Move system/filesystem/local into milestone/single-user. > > Note that this alone addresses the issues for interactive > patchadd. > > 2) Define milestone/patching, dependent on milestone/single-user. > 3) Define new a new patching service (or services), dependent on > milestone/single-user and depended on by milestone/patching. > 4) When patch automation needs to install a single-user patch, have it > boot the system to milestone/patching. Or just set the boot milestone if "patching deferred to next reboot". > 5) When the patch services are done with their work, have them let the > system come up to its default milestone, or reboot it to its default > milestone, as required. > > There are approximately two tricky parts to this puzzle: > a) How does the patch tool reboot the system to milestone/patching? It > could use "reboot -- -m milestone/patching", but that would mean that > the patching work wouldn't get done if the reboot was done through other > mechanisms. It could set the system default milestone, but then how > would it determine the milestone to set the system back to when patching > was complete? Neither answer is pretty, but either is workable. I'm sure you could write the old boot milestone down somewhere. If the admin modifies the milestone after the patch tool sets it to milestone-patching, the patch-on-next-boot will just get clobbered. I suppose the patch-service could then re-instate it on the next boot, and hope to get it on the subsequent boot. I suppose being "inside the bounds of SMF" also makes the implementation vulnerable to other admins manimpulating SMF. The above issue is basically by design. > b) How do the patching services *avoid* running when the system is > coming up normally - even if they have work to do? Probably the best > answer is for them to check the target milestone and fail (or succeed > without doing anything) if it's not milestone/patching. That makes sense. Id would have to do-nothing-succeed to work with milestone "all". > > > I understand your reluctance to add system/filesystem/local to > milestone/single-user. If there's consensus that that's an unacceptable > change, then instead: > > 1) Have patchadd mount zone roots if they are not already mounted. > 2-5) As above. > > Hmm. My initial thought was that patchadd could not use > system/filesystem/local to do these mounts because of deadlock issues. > However, since we've moved automated patching to slightly *after* > milestone/single-user, perhaps those deadlock issues do not exist. Right. Just make the patch-service depend on filesystem-local. If then patchadds issued by patch-service enable filesystem-local, it will be a no-op. Another approach is to just modify patchadd to exec /lib/svc/method/fs-local if called from SMF context. patchadd also stops filesystem-local when done, but the stop method for that service is :true, so stopping it is a no-op. patchadd should really verify fs/local's dependencies are online before doing this. Patchadd is already parsing the output of the svcprop command as it is. It could certainly read start/exec property and whatever else. This would fix both smpatch and UCE, and whoever else may depend on patchadd working from rcS.d. -Steve -Steve L. > _______________________________________________ > zones-discuss mailing list > zones-discuss@opensolaris.org _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
