Nils Goroll wrote:
I suggest to introduce an additional milestone (e.g. milestone/ready)
with optional dependencies on all system services, roughly matching
the time when rc3 is run.
That's much later than is desirable for these patches. The goal is to
have the system as quiet as possible.
[ Which brain-dead mail client turns all of the spaces in the Subject
into tabs? ]
Zones folks: the current proposed answers to this problem involve
moving system/filesystem/local into milestone/single-user. That was
apparently considered and rejected as the answer for the patchadd
problem
On Thu, Aug 21, 2008 at 12:54:14PM -0700, Jordan Brown wrote:
[ Which brain-dead mail client turns all of the spaces in the Subject
into tabs? ]
Zones folks: the current proposed answers to this problem involve
moving system/filesystem/local into milestone/single-user. That was
Steve Lawrence wrote:
I assume you are targeting this change for s10.
Yes.
The single-user milestone is intended to mimic the traditional unix
run-level 1 (S?)
Nit: Run level 1 is slightly different from S.
This is typically where an admin would run stuff like
fsck (on filesystems that
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
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
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
I believe the original concern about making system/filesystem/local part
of single-user was that it changes the definition of single-user. The
zones team was involved in that discussion, and I've just tried to
re-involve them in the resolution discussions. (And have cc'ed them
here.
Enda O'Connor ( Sun Micro Systems Ireland) writes:
alternate BE ), I have seen issues with compilers failing due to SUNWcsr and
SUNWtoo
getting out of sync, because user updated the live system.
I think I understand that problem, and I don't think it has anything
to do with a live update.
Liane Praza wrote:
It leaves a bad taste
in my mouth, but then again so does the fact that we've got two
different patching systems which require the system to be in different
states when they run.
Three :-)
Well, sort of.
All of them agree that the system should be in single user mode.
On Tue, 2008-08-19 at 11:36 -0700, Steve Lawrence wrote:
Add a new service do-single-user-patch, make it depend on filesystem-local.
This service is typically disabled. This service will add the patch(es)
and reboot.
The same could be done with a custom milestone which might be less
Bob Netherton wrote:
And further
refinement would only impact patching rather than the booting process
as a whole.
Hmm. I don't know how to have a service that runs when a particular
milestone is selected, that *doesn't* run when all is selected.
(Other than by dynamically enabling and
So you want to be able to interrupt any boot to any milestone, and instead do
the patch processing if a patch is pending. You basically want to interrupt
the current milestone, and instead just boot to filesystem-local and do the
patching.
The question is, can the smf milestone be changed
2. Create patch-install-milestone, which depends on patch-install-service
below.
The patch-install-milestone could also depend on single-user and
filesystem-local so that it is generally useful for admins manually
installing patches as well, even if they don't have
Steve Lawrence wrote:
I can't see any straightforward way to interrupt boot without changing the
milestone. You could make lots of services dependent on a patching
service, but that will have a maintenance burden. It also may not play well
with 3rd party services.
Yep.
Hmm. I just
The only way that you can get *that* guarantee is by using the
milestone mechanism to limit the system to a particular milestone, as
you suggest.
In fact, argh. This problem affects even your proposed scheme. By the
time that your patch-test-service is running, there could (in
16 matches
Mail list logo
