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. Apologie
Liane Praza wrote:
> 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
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 mo
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.
In rcS.d/Swhatever, do:
if (we want to do-single-user-patchs)
assert(we are currently booting to single-user m
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
confu
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 mid-mil
> 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 t
Steve Lawrence wrote:
> 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.
That would be my initial pl
> >It should be ok to issue smf commands from an smf service, as long as they
> >do not try to do any synchronous operations (-s).
>
> Seems a little convoluted, but might be workable.
I can't see any straightforward way to interrupt boot without changing the
milestone. You could make lots of se
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 real
> 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 t
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 possi
[ 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 t
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
> ap
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 th
> 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 usi
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.
I
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 pat
Steve Lawrence wrote:
> Call this requirement (no login prompt) out in your use case. I assume
> the patch service will patch, set the boot milestone, and reboot before
> the patch milestone is actually met, avoiding the maint prompt.
Yes.
> Definately get some console messages out of the patch-
21 matches
Mail list logo
