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