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
