> The list of use cases is really pretty simple:
>
> 1) Administrator has in hand a patch that says "install in single user
> mode". What does this administrator do? The answer seems self-evident:
> take the system to single-user mode (either by booting the system in
> single-user mode using boot -s or boot -m milestone/single-user, or
> dropping the system to single-user mode using "init s" or "svcadm
> milestone milestone/single-user") and install the patch using patchadd.
>
> 2) An automated tool has in hand a patch that says "install in single
> user mode". What does it do?
How about:
A. Make patchadd verify that the system is in single user milestone when
installing a single-user patch.
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).
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.
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).
-Steve L.
>
> It is when we start to look at solutions that the problem becomes more
> difficult.
> _______________________________________________
> zones-discuss mailing list
> zones-discuss@opensolaris.org
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
