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

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

Reply via email to