Re: [zones-discuss] Zone Statistics: monitoring resource use of zones
Mike Gerdts wrote: > When really important features are released as new > packages "genesis patches" are delivered to deliver the feature. Sometimes, but not always. In fact, I'd have to say "usually not". The Genesis technique is not without its problems, and is considered controversial. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Programming for zones
Nick Kew wrote: >> (Note, incidentally, that the picture might be different for a Java >> server, where the Java byte code for the application and a bunch of >> overhead objects might well fall into that sharable bucket.) > > Would that apply to similar bytecode like Python, which is commonly > run in-process in Apache? Don't know, maybe. It would depend on how much of the memory is common between the various servers. Looking again at my comment, the effect I'm imagining would depend a great deal on whether they're all using the same application, and then on whether you know that (and initialize the application) before you fork the servers. It would also depend on how memory happens to be laid out - if it happens that sharable (read-only after initialization) and unsharable (written after initialization) data get interleaved, you might end up with few pages shared. If you initialize the application and *then* fork, I'd expect a great deal of sharability, for any development environment. If, on the other hand, you fork and then initialize the application, probably none of it will be sharable. (Environments that precompile the program and save it in a file might end up sharing that part, but not data or dynamically compiled code.) It should be possible to determine this sharability today, if you're already forking new processes for each customer. The zone_enter() won't affect that. Unfortunately, I don't know how to ask the virtual memory subsystem how much COW memory is shared between two processes. Sorry, that's a little rambling. I'm still asleep :-) ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Programming for zones
Nicolas Williams wrote: > On Fri, Oct 03, 2008 at 02:37:28PM -0700, Jordan Brown wrote: >> Nick is trying to isolate virtual systems, not users. I've seen this > > That was, obviously, not the impression tat I got. It's trivial to > separate virtual systems by just running them in zones. But if I > misread what Nick was asking, then you're right, we should respond with > documentation on how to setup zones and so on (that documentation > exists, of course, and can easily be found online; I suspect Google > knows all about it). My interpretation (and hopefully Nick will jump in here soon and clarify) is that he's trying to get some additional cross-zone sharing, over simply running a fresh Apache in each zone. > I think the mention of zone_enter() is what made me think take Nick's > question quite literally. That is, I assumed that zones newbie would > not have known about zone_enter(), therefore I assumed Nick is not a > newbie. Remember that "user" is a relative term. The "user" of a hosting company is the hosting customer, *not* the guy behind the web browser. Note also that (with no disrespect meant to Nick) a common newbie behavior is to latch onto some random interface and attempt to bend it to solve the problem at hand, whether or not it's the intended way to solve that problem. >> It's quite possible that the IP address alone is enough to determine >> which zone the server should run in, in which case you could probably do >> the zone_enter before the listen(). Even without that, the host name >> (HTTP "Host:" header) is enough, so you could do the zone_enter() early >> in HTTP processing. > > My wife's web sites (she used to seel clothing and now sells editing > services) all run on separate addresses. Her hosting provider obviously > gets it right. Maybe, maybe not. Those IP addresses might well all lead to the same server and the same UIDs. Remember that a single Apache is perfectly happy to serve multiple addresses. > Note: the domainname used by the client in its HTTP request is available > ONLY with HTTP/1.1. IIUC HTTP/1.0 still must be supported (die, > HTTP/1.0, die!). I don't know what the HTTP/1.0 deployment picture is like these days, but I'm pretty sure that an HTTP/1.0 browser can't get to my personal web pages, because I don't have dedicated IP addresses. Host: is the only way to tell my URLs from the next guy's. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Programming for zones
You and Dan both talked about user authentication and therefore the need for the zone_enter to happen "late", but I don't think that's part of the picture here at all. Nick is trying to isolate virtual systems, not users. I've seen this problem on my personal hosting providers - my CGI scripts run as the same user as everybody else's, in the same file system. We'd better all trust each other. That's OK for cheesy little personal sites, but not so good for real businesses. It's quite possible that the IP address alone is enough to determine which zone the server should run in, in which case you could probably do the zone_enter before the listen(). Even without that, the host name (HTTP "Host:" header) is enough, so you could do the zone_enter() early in HTTP processing. I agree with Dan that the savings here are questionable over simply running separate Apaches in each zone. You'd save on all-zone-global data (which might be COW pages that never get written) but that's about it. (Note, incidentally, that the picture might be different for a Java server, where the Java byte code for the application and a bunch of overhead objects might well fall into that sharable bucket.) ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [smf-discuss] Possible solution to automated installation of "single user" patches
Narendra Kumar S.S wrote: > Is there any particular reason, why you are not proposing to move > filesystem/local to single-user milestone. That was option #1 in my list. However, there were those who objected to changing the definition of single-user mode in this way. In addition, there are these late-breaking issues with Sun Cluster et al. > That looks very simple fix Yes. > and will solve all the problems. No. It would address the particular breakage that we're seeing today, but would not address the systemic problem that there is no agreement on when and how these services should be run. Re-read the proposal. It describes the issues and constraints. I believe that today (even without this most recent patchadd issue) there are a number of cases where we are avoid problems only because we've been lucky, and because we've worked around the problems in a few cases. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Possible solution to automated installation of "single user" patches
Jordan Brown wrote: > Proposal 2: > - Make the new patching service depend on system/filesystem/local. > - Modify patchadd to temporarily enable system/filesystem/local before > patching, and disable it afterward, *if* it is offline. Note that when > the patching service runs, system/filesystem/local will be online and so > patchadd will not need to manipulate it. I added part of this late and it's a little misleading. It suggests that patchadd wouldn't need to manipulate s/f/l, and that's not quite right. *When invoked from the patch service*, patchadd wouldn't need to manipulate s/f/l. When invoked interactively (from milestone/single-user), in this scenario patchadd would still have to enable s/f/l. ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Possible solution to automated installation of "single user" patches
We had a meeting this morning to further discuss this issue, but
unfortunately a number of key people were not able to make it. SMF and
Zones people: Please take a look at the following and see if you can
shoot any holes in it.
---
There is an important assumption that today's automated patching tools
have made in their attempts to solve this problem: that system startup
and shutdown are sequential and that it is possible to intercept them at
a point where the system is in a state equivalent to "single user mode".
This assumption is false. It is part of the design of SMF that if the
system is booting to full operation, services are started when their
dependencies are satisfied, whether or not any particular milestone has
been reached. A service that is started only when the system is headed
for full operation may well come up at the very beginning of startup, if
it has no dependencies. Similarly, that service may well persist until
the very end during shutdown, since (again) it has no dependencies.
This means that the *only* way on an SMF system to get the system into
the desired quiescent state is to set the system to a limited milestone
like milestone/single-user.
Milestone/single-user is not suitable for use as that milestone, because
an unknowable set of services are starting in parallel to reach that
milestone. It is not possible to place an automated patching service in
that set and ensure that it executes after all of the other services
have reached a quiescent state.
Thus, it seems necessary to introduce a new patching milestone. That
milestone should be dependent on a new patching service (or services)
that does the actual work. The patching service must depend on
milestone/single-user, so that single-user services are known to be
running and quiescent.
Other constraints:
Patches may use SMF operations, and some SMF operations are blocked
during execution of rc*.d scripts.
We tell users to install these patches "in single user mode". This
means that "boot -s" or equivalent operations must yield an environment
where patchadd can apply these patches.
Patching requires the file system mounts implemented by
system/filesystem/local.
There is a legacy that "single user mode" does not mount all file
systems. This brings with it the possibility that a user might expect
that file systems will not be mounted.
Now I think we've set the stage for a concrete set of proposals.
Common elements:
- Define a new milestone, say "milestone/patching".
- Create a new service (or, more likely, two, one for UCE and one for
UCS). Set this service to depend on milestone/single-user and
system/filesystem/local, and be depended upon by milestone/patching.
- Have the application queue up patches to be installed, and then boot
the system to milestone/patching.
- Once the patches have been applied, the patching service should either
allow the system to come up (by changing its target milestone) or reboot
it, depending on the requirements of the patches.
Proposal 1:
- Move system/filesystem/local under milestone/single-user.
Upside: Really simple (other than common elements).
Downside: Violates the user assumption that only key file systems are
mounted.
Proposal 2:
- Make the new patching service depend on system/filesystem/local.
- Modify patchadd to temporarily enable system/filesystem/local before
patching, and disable it afterward, *if* it is offline. Note that when
the patching service runs, system/filesystem/local will be online and so
patchadd will not need to manipulate it.
Upside: Relatively simple and modular.
Downside: Patchadd mounting and unmounting file systems may be unexpected.
Proposal 3:
- Modify patchadd to execute system/filesystem/local's start method
before patching, and its stop method after, if it is offline.
Upside: avoiding SMF manipulations in patchadd avoids the possibility
of SMF-related deadlocks.
Downside: patchadd has unholy knowledge of system/filesystem/local, or
requires unpleasant examination of s/f/l's SMF data. Patchadd mounting
and unmounting file systems may be unexpected.
Common issues:
- How do we avoid starting the patching service when the system is
coming up to "all" (and so the system may not be quiescent when the
service runs)? One possibility might be to have the service disabled
when there are no patches queued, but that might lead to problems if the
user explicitly selects "all" in some way. Another possibility might be
to have the service inspect the current target milestone, and do nothing
if it is not "milestone/patching".
- How does the application boot the system into milestone/patching?
Using a temporary milestone ("reboot -- -m milestone/patching") requires
that the application initiates the reboot, rather than allowing the user
to reboot at leisure. Using a permanent milestone setting requires that
the application stash away the original target milestone to be restored
after t
Re: [zones-discuss] file system access from global zone
Jerry Jelinek wrote:
> Jordan Brown wrote:
>> bart(1M) says about its -R option:
>>
>> Note - The root file system of any non-global zones
>> must not be referenced with the -R option. Doing
>> so might damage the global zone's file system,
>> might compromise the security of the global
>> zone, and might damage the non-global zone's
>> file system. See zones(5).
>>
>> Why?
>
>
> Accessing a ngz fs from the gz is always dangerous since
> a hostile ngz root admin can make changes which
> refer to the gz, if you are looking at the fs from the
> gz. If you are only reading and don't care
> if you are reading the wrong stuff, it is not a
> big deal. You should never write and attempt to
> change anything when running in the gz and reaching
> into the ngz hierarchy. E.g. editing {zonepath}/etc/passwd
> could be made to refer to gz /etc/passwd with a simple
> symlink.
That makes sense, but the statement in the man page seems far too strong
for this situation... how many zones configurations involve potentially
malicious local zone administrators? I know mine never do.
The caveats that you suggest seem along the lines of the usual caveats
about administrators working with files that are not trusted, applicable
in almost any environment.
Thanks for the info.
___
zones-discuss mailing list
zones-discuss@opensolaris.org
[zones-discuss] file system access from global zone
bart(1M) says about its -R option: Note - The root file system of any non-global zones must not be referenced with the -R option. Doing so might damage the global zone's file system, might compromise the security of the global zone, and might damage the non-global zone's file system. See zones(5). Why? ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [smf-discuss] 6725004 - installing single-user-mode patches automatically
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-service so folks don't > think their boot is hung and freak out. :) I believe they're already there. >> 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. Hmm. I was concerned about that, but also about the possibility that we'd overwrite the admin's subsequent selection with the value that we remembered. I guess that can't really happen, since we won't do the overwriting if the milestone isn't set to our magic one. (Well, except for truly perverse sequences like "we remember A, set it to P, user sets it to B, user boots to P, we reset it to A".) > 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 like that plan. > 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. Sure. It'd just be nice to have a scheme that was both within the bounds *and* didn't offer the user any ways to break it :-) >> 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. > > That makes sense. It would have to do-nothing-succeed to work with > milestone "all". Do-nothing-fail would also work - it would just result in a message and putting the service into Maintenance, just like any other miscellaneous failing service. If the patching service has work to do, and isn't able to do it because the system isn't booting the right way, that might be the rightest answer. >> 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. > > Right. Just make the patch-service depend on filesystem-local. If > then patchadds issued by patch-service enable filesystem-local, it will > be a no-op. No need. The enable done by patchadd will be sufficient. We should represent the dependency on filesystem/local in exactly one place, either in patchadd itself or in the dependency list for milestone/single-user. > Another approach is to just modify patchadd to exec > /lib/svc/method/fs-local if called from SMF context. patchadd also stops > filesystem-local when done, but the stop method for that service is :true, > so stopping it is a no-op. patchadd should really verify fs/local's > dependencies are online before doing this.Patchadd is already parsing > the output of the svcprop command as it is. It could certainly read > start/exec property and whatever else. This would fix both smpatch and > UCE, and whoever else may depend on patchadd working from rcS.d. rcS.d doesn't really work, because of the SMF deadlock issue. (Some SMF operations deadlock when run from rcS.d scripts. Some patches use those SMF operations.) This is kind of unfortunate, because rcS.d is the only way (other than a new milestone) to catch the system in the right state. rcS.d scripts are not the Way Of The Future. It's also just gross :-) However, if we can make it work and everybody can agree that it's THE way to solve the problem, it's OK with me. I like the "new milestone" answer above, plus either moving filesystem/local or enabling it from patchadd, better. --- I know this has looked like wandering in circles, but I think it's been quite helpful - I think we're getting pretty close to a reasonable answer. Thanks. ___ zones-discuss mailing list zones-discuss@opensolari
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
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
[ 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
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
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 realized a flaw in my mental model of an SMF system. In a traditional rc-based system, everything runs in sequence. When you get to the "single user" point, it doesn't matter whether your target was to get to "single user" mode or to get to "multi user" mode - in either case, the system is in the same state. In an SMF system, on the other hand, you could have a service that is intended for "multi user" mode that doesn't have any dependencies. It could come up instantly, even before the system has reached milestone/single-user. I had previously thought that milestone/single-user was equivalent to the legacy end-of-rcS / beginning-of-rc2 point, but that's not true. Although milestone/single-user guarantees that a particular set of services is running, it *does not* guarantee that other services are *not* running! 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 theory) be all kinds of services running that didn't happen to depend on anything. Maybe in practice we could ignore that possibility, but it's still bothersome. Argh. Not quite back to Square One, but that certainly tosses a wrench into most of my theories on how to solve this problem. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [smf-discuss] 6725004 - installing single-user-mode patches automatically
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 plan, at least roughly. I wouldn't think of it in terms of going to a different milestone, per se, but rather that there is a point in system startup where we look to see if there are any patches pending. If not, we continue; if so, we apply them. If they require reboot, we reboot, else we let the system continue to come up. That point needs to be early enough so that the system is quiescent, but late enough so that the services needed by the patches tools (e.g. local file systems) and the patches themselves are present. > The question is, can the smf milestone be changed mid-milestone? > > My test shows that it can. How about: > > 1. Create patch-test-service, on which single-user depends. This will >"svcadm milestone patch-install-milestone" if a patch needs to be >installed. This service is always enabled. > > 2. Create patch-install-milestone, which depends on patch-install-service >below. > > 3. Create patch-install service, which depends on: > single-user > filesystem-local > >This service is always enabled. It will install a patch if it is pending, >otherwise, do nothing. If the service fails, it might need to: > > # svcadm milestone single-user > >So that a maintenance prompt will be appear on the console. This might >not be necessary. you might get this anyway, as console-login is not >reached. > > 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. patch-install-service might need to ms=`svcprop -p options/milestone svc:/system/svc/restarter:default` svcadm milestone "$ms" if the patches installed don't need a reboot. > This approach is also good because an explicit boot to single user WILL NOT > attempt to install pending patches. That would be very nice, but are you sure? It seems like patch-test-service would override the milestone specified at boot time, and the system would continue up to the patch installation milestone. > Disabling the patch-test and patch-install services will disable the > automatic installation of pending patches on reboot. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [smf-discuss] 6725004 - installing single-user-mode patches automatically
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 disabling it.) > rc scripts doing things with SMF seem a permanent solution to a > temporary problem. In my virtual universe there are no rc scripts :) > And then the alarm clock goes off and I return to reality. But it does > promote rc hackery rather than fixing the problem in SMF where it > belongs. Agreed. Besides, I believe that SMF is locked while rc scripts are running, and that any attempt to manipulate it deadlocks. There are related schemes that could work, but the problem is getting them properly sequenced into system startup. > reboot -- -m milestone=patchinstall seems elegantly simple. Plausible, though it doesn't exactly fit the current application usage model. At the moment, the reboot might or might not be triggered by the patching application. The patching application leaves the system set up to do the patching at the next shutdown/reboot, whenever that might be. (For SunUC-S's shutdown-time processing, it's require that that reboot be via the "clean" mechanisms - init, shutdown - so that the processing gets done.) This scheme would require either 1) having the patch application set the default milestone, and then having the startup-time processing set it back, or 2) having the patch application do the reboot. There's still the issue with how to keep this service from running when you boot to "all". Hmm. How does single-user-mode login work? What stops it from running on a normal boot? Is it a special case? --- BTW: I'm not in a position to commit the patch applications. I'm in the middle here because I'm relatively familiar with all of the players and the issues, but in my day job I'm not responsible for *any* of them. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [smf-discuss] 6725004 - installing single-user-mode patches automatically
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". The difference is how you get there, and *exactly* what it means. The legacy is that it means interactive, shell-prompt single-user mode. We're trying to implement (or, rather keep supporting) automatic installation of these patches, and interactive shell prompt single-user mode isn't reasonable for automatic installation. (There are one or two really gross ways to do it - boot the system to single user mode, including a service that runs before single user mode, puts itself in the background, and waits for SMF to reach milestone/single-user, then *while the interactive single-user login is available* do the patch installs in the background and reboot the system.) The two automatic schemes attempt to install patches at a system state that is epsilon different from interactive single-user mode. (Either epsilon earlier than interactive or epsilon later than single-user would be OK, with epsilon earlier being easier to implement and epsilon later being slightly more desirable.) One, UCE, does this by running its automatic mechanism from a high-numbered rcS.d script. The other, SunUC-S (a.k.a. smpatch or Update Manager) does it by running its automatic mechanism from a SMF service that runs during system shutdown at a point intended to be equivalent to single-user mode. (The reason that SunUC-S does its work during shutdown rather than startup is that most of these patches require a subsequent reboot, and doing the patching during shutdown means that there's only one reboot. This is better in theory than in practice, because system shutdown is not as well controlled as system startup and many services are left running until the bitter end.) Anyhow, the goal here is to find at least one strategy for automatic installation of these patches that everybody can agree to support. Of course, my slight preference is that it be installation during shutdown (because that reduces the number of reboots), but my expectation is that it will involve installation epsilon from interactive single-user mode, with a subsequent reboot required. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Creating users and SMF services in SVR4 packages with zones
James Carlson wrote: > Jordan Brown writes: >> Before diving too far down this rathole... aren't the package scripts >> run in the context of the zone? > > Yes, for the specific issue of running a script in a zone, but in > general, you can't chroot to $BASEDIR and expect any good to come of > it. Agreed, chroot is essentially never appropriate. > The same script will fail miserably when 'pkgadd' is pointed at > an alternate boot environment, or when invoked during a custom > install. Ah, indeed. Whether that's an issue or not depends on the requirements for the particular package. For packages in the Solaris distribution it's a requirement ... for others, it might or might not be. > That's why I'm discouraging its use, and instead pointing folks to CR > 6387333. There's a missing feature here, and trying to paint around > it just risks causing new problems. Yes. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Creating users and SMF services in SVR4 packages with zones
Before diving too far down this rathole... aren't the package scripts
run in the context of the zone?
James Carlson wrote:
> Ralf Weber writes:
>> or your zone path when the package gets created inside a zone. So I
>> would rewrite your scripts as:
> [...]
>> ${BASEDIR}/usr/sbin/chroot ${BASEDIR} /usr/sbin/groupadd -g 27 mysql
>> ${BASEDIR}/usr/sbin/chroot ${BASEDIR} /usr/sbin/useradd -u 27 -d /var/
>> lib/mysql -s /bin/false -G mysql mysql
>
> I wouldn't. There's no guarantee at all that $BASEDIR refers to an
> instance of the OS that can run at all with the current running
> kernel.
>
> In more detail: when you use chroot, the system reads *everything*
> from the given base directory, including the system libraries. That
> means you'll load up $BASEDIR/usr/sbin/groupadd and try to link in
> $BASEDIR/lib/libc.so.1 (among many other things). That library makes
> undocumented system calls that in turn depend on the exact rev of the
> kernel.
>
> What happens when you do that is arbitrary. It may work, as the
> system call interface usually changes slowly, but it may not. It all
> depends on the calls made by the application and the nature of the
> user/kernel flag days that have passed between these two images.
>
> (Note that Sun's ABI guarantee applies at the ABI level -- meaning the
> documented system library interfaces -- and not at the system call
> level.)
>
> What you're suggesting isn't supported and can't be supported.
> Instead of that, I'd suggest using nawk for now, and adding a call
> record to CR 6387333. useradd/groupadd should know how to deal with
> alternate roots.
>
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] Making zoneadm more like the other adms...
Darren Reed wrote: > Hmmm, I think I prefer the bottom one, but I can't see why > either precludes the other as I'm pretty confident no sane > person will ever want a zone name that matches a uuid and > code could easily be written to cover this. Are zones required to have names? If so, one case where a sane person might want a zone name that matches a uuid is if they really don't care about the name - they just need another zone that doesn't conflict with any existing zones. An automated test framework might want such a thing, for instance - build a zone, run a test, tear down the zone. I've considered using uuids in a variety of places where human-readable tags are more usual, simply because uuids have no intrinsic meaning. My current project is derived from about five previous projects, and so our directory and package names are all over the map... in some ways, it's be better if we'd used uuids for all of the names. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Script run from global zone into local zones - to shut them down
Depends on whether you want to take the zone down *now* or want the
gradual shutdown behavior of shutdown. Granted, -g0 is pretty abrupt.
Sean McGrath - Sun Microsystems Ireland wrote:
>
> surely use zoneadm halt instead of zlogin ?
>along with zoneadm list -p and grep for running zones..
>
> for z in `zoneadmn list -p | grep running | grep -v global | awk -F: '{print
> $2}'`
> do
>zoneadm halt $z
> done
>
> Regards,
> Sean.
> .
> Craig Cory stated:
> < Anne,
> <
> < Something like this should work for you:
> <
> < ===
> < #!/bin/sh
> <
> < for z in `zoneadm list`
> < do
> < if [ "$z" = "global" ]; then continue
> < fi
> < zlogin $z shutdown -y -g0 -i0
> < done
> <
> <
> <
> < Regards,
> <
> < Craig
> <
> <
> < In response to Anne Moore, who said:
> < > All
> < >
> < > I'm trying to write a script that will shutdown all zones from the local
> < > zone. I'm not terribly good with scripting (yet), but thought many of you
> < > would be.
> < >
> < > I need to run the command "zoneadm list" and then output each line to a
> < > different variable to run this command:
> < >
> < > zlogin $zonename1 shutdown -y -g0 -i0
> < >
> < > Does anyone know how one would do something like this?
> < >
> < > Thank you for all of your help!
> < >
> < > Anne
> < >
> < >
> < > ___
> < > zones-discuss mailing list
> < > zones-discuss@opensolaris.org
> <
> <
> < Craig Cory
> < Senior Instructor :: ExitCertified
> < : Sun Certified System Administrator
> < : Sun Certified Network Administrator
> < : Sun Certified Security Administrator
> < : Veritas Certified Instructor
> <
> < 8950 Cal Center Drive
> < Bldg 1, Suite 110
> < Sacramento, California 95826
> < [e] [EMAIL PROTECTED]
> < [p] 916.669.3970
> < [f] 916.669.3977
> < [w] WWW.EXITCERTIFIED.COM
> < +-+
> < SAN FRANCISCO | VANCOUVER | REGINA | WINNIPEG | TORONTO
> < ___
> < zones-discuss mailing list
> < zones-discuss@opensolaris.org
> ___
> zones-discuss mailing list
> zones-discuss@opensolaris.org
>
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] Script run from global zone into local zones - to shut them down
Anne Moore wrote: > All > > I'm trying to write a script that will shutdown all zones from the local > zone. I'm not terribly good with scripting (yet), but thought many of > you would be. > > I need to run the command "zoneadm list" and then output each line to a > different variable to run this command: > > zlogin $zonename1 shutdown -y -g0 -i0 > > Does anyone know how one would do something like this? > > Thank you for all of your help! something like for z in `zoneadm list` do zlogin $z shutdown -y -g0 -i0 done though a bit better might be for z in `zoneadm list` do if [ $z != global ] then zlogin $z shutdown -y -g0 -i0 fi done ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Setting up SMC on a zone - possible?
Anne Moore wrote: > Okay, that's good information. I can then install it manually and things > should work. I'll try in the morning. You could perhaps install all of the contents of that package (plus any other packages that are required and similarly situated), and that might well work. I'm pretty sure that you could _not_ install the package. The SUNW_PKG_ALLZONES and SUNW_PKG_HOLLOW markings on it will, I believe, cause it to be rejected on local zones. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Setting up SMC on a zone - possible?
Jordan Brown (Sun) wrote: > You could perhaps install all of the contents of that package (plus any > other packages that are required and similarly situated), and that might > well work. ... but it would of course not be a supported configuration. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Setting up SMC on a zone - possible?
Anne Moore wrote: > Thanks for the reply. I am talking about the Solaris Management Console. I > have a whole-root zone and those two services are running. However, there is > no /usr/sbin/smc in my whole-root zone. It's like the whole-root > installation didn't even install it. Very odd. SUNWmcc, which is the package that includes /usr/sbin/smc, is for some reason marked "hollow", that its contents should be installed only on the global zone, but the package should appear for bookkeeping purposes in local zones. Why this is I could not tell you, but it does explain why /usr/sbin/smc is not installed in your zone. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] new option - cpu-dedicated
Mike Gerdts wrote: > Does updatemanager use patchadd -M under the covers? No. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Patches via Live Upgrade with 2 zones on Solaris 10 Update 4 failed
Renaud Manus wrote: > Jordan Brown wrote: >> luupgrade -p does essentially that same set of operations. >> lumount+pca+luumount should be OK. > > But we (Sun) don't support it. True (which is why I said we'd prefer you used smpatch), but I believe that lumount + patchadd -R + luumount *is* supported, and that's basically what the PCA sequence does. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Patches via Live Upgrade with 2 zones on Solaris 10 Update 4 failed
[ Sorry if this is a repeat. I tried to abort it during the original send and haven't gotten my own copy, so I think something went a bit weird. ] Renaud Manus wrote: > Eric Ham wrote: >> I then ran the following Live Upgrade and PCA commands with no errors. >> >> lumake -s sol10-2007-08 -n d2 >> lumount d2 >> ./pca -R /.alt.d2 --install >> luumount d2 >> lurename -e d2 -n sol10p-20080229 >> luactivate sol10p-20080229 >> init 6 >> > > live-upgrade patching should be done with "luupgrade -p", not with pca. luupgrade -p does essentially that same set of operations. lumount+pca+luumount should be OK. (Of course, we'd really rather that you use smpatch update -b instead of pca, but that's a different question.) ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Boot state completion?
Christine Tran wrote: > who -r still works in a zone. > > [EMAIL PROTECTED]> zonename > zone1 > [EMAIL PROTECTED]> who -r > . run-level 3 Jan 24 14:53 3 0 S Yes, but apropos of our earlier discussion around milestone/multi-user-server, run level 3 doesn't mean "all services up". ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] dbus in local zones
Glenn Faden wrote: >> I understood that. What I didn't understand was why there wasn't a >> completely separate instance of the dbus-daemon running in each zone, >> with its own rendezvous file for communicating with clients in that >> zone. Why would you expect there to be cross-zone communication here? > Some kind of zone-awareness needs to be integrated into HAL and/or dbus > to deliver notification events (like hot plugging) to appropriate > consumers. I don't have a proposal at this point. Hmm. I didn't read enough of the D-Bus materials to see the kernel interaction; I only read the part about "inter-process communications". Still, it seems like the two should be mostly separable, that the IPC aspects should be straightforward to support in local zones. Kernel communications might not be available without zone support, but presumably there is a significant class of applications that would still be interesting - notably probably including the text editor that was the start of the conversation. (Disclaimer: I'm speaking entirely from a 100K-foot view, with almost no knowledge of how D-bus is implemented or used.) ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] dbus in local zones
Glenn Faden wrote: > I thought I answered that. The dbus-daemon is using a UNIX domain > rendezvous file in /tmp in the global zone. The non-global zones have > their own instances of /tmp, so the rendezvous file does not exist in > their namespace. Even if it did, there would be other problems because > the devices that get reported to HAL by the dbus-daemon don't exist in > the non-global zones. HAL isn't zone-aware. I understood that. What I didn't understand was why there wasn't a completely separate instance of the dbus-daemon running in each zone, with its own rendezvous file for communicating with clients in that zone. Why would you expect there to be cross-zone communication here? ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] dbus in local zones
>> dbus-daemon cannot be run in non-global zones Sure sounds like the question is "why not?". ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] sharing "terminal server ports" to non-global zone
Paul Davis wrote: > > Sounds like they want to access the local zone's console directly from a > terminal server? I don't believe there is a concept of that in the zones > model (of course, the local zone's console is normally started with > "zlogin -C zonename" from the global zone). Sure sounds like they have a bunch of serial-attach devices that they multiplex onto the network using a terminal concentrator and demultiplex in software at the computer, and they want to make some or all of those serial connections available to applications running in local zones. > Christine Tran wrote: >> Jerry Jelinek wrote: >> >>> Christine Tran wrote: >>> A customer is unable to share something called the "terminal server ports" to non-global zone. I don't know what these are, but here's the description: "Serial sensor interfaces are fed to a patch panel and then received by a digital terminal server. Terminal server sends output to a switch, to which the host is connected. Terminal server port driver installs in global zone, creates /dev/dty/tt1, /dev/tty/tt2 ..." He tried adding the device by "set match = /dev/dty/*" but the device does not appear in the non-global zone. Any thoughts? >>> Is it /dev/dty or /dev/tty? The example shows both. What version are >>> they running? There is a known bug with wildcard matching in u4: >>> >>> 6632938 zonecfg fnmatch device matching interface seems to be broken >>> >>> >> >> Sorry, that's /dev/dty/* not /dev/tty/*, my typo. >> >> And thanks for the bug, this may be it. >> >> CT >> ___ >> zones-discuss mailing list >> zones-discuss@opensolaris.org >> > > > > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] netmask warning, misconfiguration
[EMAIL PROTECTED] wrote: > What does the "netmasks" entry in /etc/nsswitch.conf say? A common > issue is that a user changes their local /etc/netmasks file but their > the switch says to use something like "nis". Bingo! Thanks! >> (I also tried 172.20.0.0 on the theory that maybe it wanted me to set >> the netmask for the entire Class B, but no dice.) > > Actually, that's exactly what you should be using in your local > /etc/netmasks entry. I'm not sure, but reading netmasks(4) I don't think so. Note that it has an example entry: 128.32.27.16 255.255.255.240 and says that the system uses the longest prefix found. OTOH, I don't immediately understand how the example can work. It says that 128.32.*.* (except for the exclusions) gets a 24-bit netmask, but I don't see how that can be unambiguously determined. The example *seems* to want to explicitly specify a 28-bit netmask for several ranges and a 24-bit netmask for the rest, but how can it distinguish between requesting that 128.32.*.* is all 24-bit and requesting that 128.32.0.* is all 24-bit? (For that matter, why isn't it specifying that 128.001?.*.* is 24-bit?) > Although I do suggest that specifying the prefix > length (such as /24) via zonecfg(1M) is the best solution. Point-specifying a global value seems like the wrong answer. Normalization says that you should specify the global value in one place, not replicated across many. (Less abstractly, that you should specify the netmask in one place, not individually for each address that uses it.) ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] netmask warning, misconfiguration
Antonello Cruz wrote: > I would definitely run > > zonecfg -z int-sagent-1-z1 info > > to check what the zone thinks is the netmask. Doesn't display a netmask. > I suspect if you haven't defined the '/24' it will pick the default for > the address class. In this case, '/16' IIRC. > Sometimes documentation gets old... Sure seems like a bug. >>> Did you use, in zonecfg: >>> zonecfg:int-sagent-1-z1:net> set address=172.20.46.188/24 >>> ? >> >> No, no "/24". (I see how that could affect the picture, but it seems >> like /etc/netmasks should work too, and the message certainly suggests >> it.) Actually, I just remembered that I didn't specify the address this way. I used "set address=int-sagent-1-z1". (I don't like using IP addresses when I don't absolutely have to.) ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] netmask warning, misconfiguration
Antonello Cruz wrote: >> zoneadm: zone 'int-sagent-1-z1': WARNING: bge0:1: no matching subnet >> found in netmasks(4) for 172.20.46.188; using default of 255.255.0.0. > How did you setup the IP address for that zone? > > Did you use, in zonecfg: > zonecfg:int-sagent-1-z1:net> set address=172.20.46.188/24 > ? No, no "/24". (I see how that could affect the picture, but it seems like /etc/netmasks should work too, and the message certainly suggests it.) ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] netmask warning, misconfiguration
I get: zoneadm: zone 'int-sagent-1-z1': WARNING: bge0:1: no matching subnet found in netmasks(4) for 172.20.46.188; using default of 255.255.0.0. but my /etc/netmasks (on both the global and local zone) looks good: 172.20.46.0255.255.255.0 (I also tried 172.20.0.0 on the theory that maybe it wanted me to set the netmask for the entire Class B, but no dice.) I see many instances of this message in BugTraq and Google searches, but I don't immediately see any resolutions. ___ zones-discuss mailing list zones-discuss@opensolaris.org
