Re: [zones-discuss] non global zone memory allocation enquiry
rcapstat(1M). On Thu, Aug 21, 2008 at 1:29 AM, Gauss Tang - Sun Microsystems [EMAIL PROTECTED] wrote: Dear Expert, We can check the zone memory allocation via command zonecfg -z zonename info capped-memory: physical: 256M But how to check this info after longin the zone? -- --JeffV ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [smf-discuss] 6725004 - installing single-user-mode patches automatically
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. Historically, I believe the only things running in single-user mode are init and the shell. There's more than that now, but it's still pretty limited. The reason that the system needs to be quiet is that (for instance) a patch might install new versions of two kernel modules. If one of them was currently loaded and the other was not, activity on the system might cause the new one to be loaded. If it's not compatible with the already-loaded old version, bad things might happen. By convention, all non-system services would be (strongly) recommended to depend upon this service. This would also make application specific services more rubust. I've seen a couple of examples where SMFs would, depend upon filesystem/local and network/physical, but fail if the user configured the application to use an NFS mountpoint, for instance. This would also facilitate the introduction of additional services which are a requirement for all applications in the general case. In the current context, this milestone (and the requirement for all user apps to depend upon it) would provide a way to make sure patching is done at the right time. I believe that the point you describe pretty much corresponds to milestone/multi-user. I don't have a strong opinion on whether non-system services should be encouraged to wait for such a milestone. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [smf-discuss] 6725004 - installing single-user-mode patches automatically
[ 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 that resulted in the fix that brought us here. Can you offer any insight into why that change was rejected? ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [smf-discuss] 6725004 - installing single-user-mode patches automatically
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 apparently considered and rejected as the answer for the patchadd problem that resulted in the fix that brought us here. Can you offer any insight into why that change was rejected? I assume you are targeting this change for s10. The single-user milestone is intended to mimic the traditional unix run-level 1 (S?) This is typically where an admin would run stuff like fsck (on filesystems that are not yet mounted). I don't think it is ok to change this behavior in a patch. I'm not sure I understand all the details of the problem you are trying to solve. For example, I thought it was desired that the patch service run during a boot to all, but then I saw following mail stating that the patch service should not run in this case, and something about the user explicitly booting to single user. I don't think I know what the use cases are. You may want to draft a brief ARC fastrack describing the desired behavior(s), and the issues, and perhaps proposed solutions. Getting it all on one page will faciliate a solution. -Steve L. ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [smf-discuss] 6725004 - installing single-user-mode patches automatically
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 are not yet mounted). It is also where we tell people to install many patches that touch key parts of the system. Zones and patching collided to break that use case, by making it (potentially) necessary to mount secondary file systems in order to apply patches. I don't think it is ok to change this behavior in a patch. Something's got to give. I'm not sure I understand all the details of the problem you are trying to solve. For example, I thought it was desired that the patch service run during a boot to all, but then I saw following mail stating that the patch service should not run in this case, and something about the user explicitly booting to single user. I don't think I know what the use cases are. There's been a lot of variations flying around and it's tough to keep them all straight. One key incorrect assumption that we (the patch automation teams) had been making was that we could catch system startup at the right point and do our work, as was possible in pre-SMF systems. That would suggest having a patch service that ran on the way to all. However, on an SMF system that's not a valid assumption: if the target is all, services might be started at any point, including before milestone/single-user, if their dependencies are met. It now appears clear that we must limit the system to some appropriate milestone, to limit the services that are started. You may want to draft a brief ARC fastrack describing the desired behavior(s), and the issues, and perhaps proposed solutions. Getting it all on one page will facilitate a solution. I agree that an ARC case is needed, if only to formally record the agreed-upon solution. However, since we don't yet have a complete solution to propose, I think it's premature at the moment. Getting it all on one page would, I agree, be helpful. (Is there an externally-visible wiki where such a writeup could be posted and maintained?) --- 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? It is when we start to look at solutions that the problem becomes more difficult. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [smf-discuss] 6725004 - installing single-user-mode patches automatically
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
Re: [zones-discuss] [smf-discuss] 6725004 - installing single-user-mode patches automatically
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 patchadd. 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 zones-discuss@opensolaris.org
Re: [zones-discuss] [smf-discuss] 6725004 - installing single-user-mode patches automatically
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 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. That seems completely unsupportable, but ok. Admins are used to getting away with not following the patch README or suggested procedure. (A) could be dropped without much impact to the solution. 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. Your final comment addresses this. Post filesystem/local, it is safe for SMF services to call patchadd. 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. 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. Definately get some console messages out of the patch-service so folks don't think their boot is hung and freak out. :) My favorite approach is, approximately: 1) Move system/filesystem/local into milestone/single-user. Note that this alone addresses the issues for interactive patchadd. 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. Or just set the boot milestone if patching deferred to next reboot. 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. I'm sure you could write the old boot milestone down somewhere. If the admin modifies the milestone after the patch tool sets it to milestone-patching, the patch-on-next-boot will just get clobbered. I suppose the patch-service could then re-instate it on the next boot, and hope to get it on the subsequent boot. I suppose being inside the bounds of SMF also makes the implementation vulnerable to other admins manimpulating SMF. The above issue is basically by design. b) How do the patching services *avoid* running when the system is coming up normally - even if they have work to do? Probably
