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-
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:
> 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
> 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:
> 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
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
[ 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
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
> 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
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
> >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:
> 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
> 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
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
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
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
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
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
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:
> 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
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
21 matches
Mail list logo
