Re: [zones-discuss] [osol-discuss] solaris 8 container installation failed
Hello Asif, Saturday, August 9, 2008, 5:32:26 AM, you wrote: AI So I can take a ufsdump of the whole system and then give that to zoneadm as AI a image of the solaris 8 container? Cool I will give that a try next There is yet another option, quite useful sometimes. Export your file systems via nfs with anon=0, mount them as RO on target system - then install a zone using -d parameter as from local file system. -- Best regards, Robert Milkowskimailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [smf-discuss] 6725004 - installing single-user-mode patches automatically
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. Apologies for the crosspost.) It may just be morning, but I'm currently having a hard time finding that argument too compelling on its own -- it seems there must have been something more specific. Creating a patch milestone has previously been my preferred direction (as it requires actual definition and design of what the patching frameworks need, rather than just hoping that single user is appropriate), but I'm no longer certain this is a sensible investment, as my understanding of IPS is that they're sticking to their guns and there will be no live patching of the OS that leads us to these types of scenarios. Thankfully. Given that, I wonder if a different option is to confirm that system/filesystem/local is idempotent (and not already running), and then have patchadd just run its method directly. 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. But, again, I think the zones team explored many of these options in the first round and would like to make sure they have a chance to weigh in. liane (in theory, on vacation today.) Renaud Manus wrote: A solution could be to move system/filesystem/local in the single-user milestone. -- Renaud Jordan Brown wrote: Could some SMFers please weigh in on 6725004 and give some opinions on how best to address it? Here's a summary of the problem: Sun Update Connection Enterprise attempts to install single-user patches using an rcS.d script. This has historically been a problem, since zone roots may not have been mounted yet. Patchadd was recently changed to partially work around this problem, by enabling system/filesystem/local, but when that mechanism is triggered from an rcS.d script (or, presumably, from a service on which milestone/single-user depends), it yields a deadlock - system/filesystem/local can't be run, because milestone/single-user hasn't been reached. (This is, I believe, in addition to the technical issues surrounding performing SMF operations from an rcS.d script.) I believe that the most truly correct way to address this problem is to have a deferred patching service that depends on system/filesystem/local, and on which all other later services depend. However, I think the only way to implement such a service would be to modify the dependencies of those later services, and that seems awkward. (One could also rename system/filesystem/local, retain the original name as something of a milestone, and insert the deferred patching service as a new service between the renamed s/f/l and the original s/f/l, but that seems quite ugly.) ___ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [smf-discuss] 6725004 - installing single-user-mode patches automatically
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. The underlying problem there is that there's a hidden dependency built into the way /usr/bin/ld (in SUNWtoo) is constructed. It depends on a private version of libld.so.4 (in SUNWcsr) -- one that gets incremented occasionally. Thus, if you upgrade SUNWcsr, you must also upgrade SUNWtoo, even if you didn't want to, and even though the package dependency runs the other direction (SUNWtoo depends on SUNWcsr, not vice-versa). Since SUNWcsr is one of the common packages on which everyone depends, it's at high risk of being upgraded frequently. It'll be upgraded when someone installs a new package, or when someone upgrades an existing one, because it's a dependency. But the system doesn't seem to know that SUNWtoo is tightly bound to a special library version and must be upgraded as well. It's really a mutual dependency. I don't think we know how many of these sorts of special dependencies exist in ON. Except for the controlled environment of patches, we've always assumed synchronous delivery of everything built in ON as part of our design. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ 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] [smf-discuss] 6725004 - installing single-user-mode patches automatically
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 confusing. I like the elegance of that solution as it relies less on what works now in favor of a defined environment which presumably would get better coverage for zones and zfs [zone]root. And further refinement would only impact patching rather than the booting process as a whole. 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. reboot -- -m milestone=patchinstall seems elegantly simple. Bob ___ 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
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-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). This approach is also good because an explicit boot to single user WILL NOT attempt to install pending patches. Disabling the patch-test and patch-install services will disable the automatic installation of pending patches on reboot. Thoughts? -Steve L. On Tue, Aug 19, 2008 at 01:03:55PM -0700, Jordan Brown wrote: 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 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [smf-discuss] 6725004 - installing single-user-mode patches automatically
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 the patch-test and patch-install services, but want to safely install patches manually when they have zones on local filesystems. -Steve L. On Tue, Aug 19, 2008 at 01:03:55PM -0700, Jordan Brown wrote: 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 ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] how to configure port listening in a zone?
I have a glassfish webserver running in my Solaris 10 zone. It will not respond to remote jmxrmi requests on port 8686. If I connect locally with (for instance) jconsole it works fine. I believe it is somehow related to being in a zone. Because snoop -p 8686 from my zone... tells me, no network interface devices found. [EMAIL PROTECTED]: ifconfig -a lo0:1: flags=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL mtu 8232 index 1 inet 127.0.0.1 netmask ff00 bge0:1: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500 index 2 inet 10.5.185.103 netmask fc00 broadcast 10.5.187.255 Is there something I can configure to do this? Thanks, Russ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] how to configure port listening in a zone?
also: [EMAIL PROTECTED]: netstat -a | grep 8686 *.8686 *.*0 0 49152 0 LISTEN Russ Petruzzelli wrote: I have a glassfish webserver running in my Solaris 10 zone. It will not respond to remote jmxrmi requests on port 8686. If I connect locally with (for instance) jconsole it works fine. I believe it is somehow related to being in a zone. Because snoop -p 8686 from my zone... tells me, no network interface devices found. [EMAIL PROTECTED]: ifconfig -a lo0:1: flags=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL mtu 8232 index 1 inet 127.0.0.1 netmask ff00 bge0:1: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500 index 2 inet 10.5.185.103 netmask fc00 broadcast 10.5.187.255 Is there something I can configure to do this? Thanks, Russ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] how to configure port listening in a zone?
By default, a zone does not have privilege to snoop: http://blogs.sun.com/JeffV/entry/snoop_zoney_zone Could just be a network config/routing issue. Can you ping 10.5.185.103? Can you access other network services, like ssh? -Steve L. On Tue, Aug 19, 2008 at 03:01:37PM -0700, Russ Petruzzelli wrote: I have a glassfish webserver running in my Solaris 10 zone. It will not respond to remote jmxrmi requests on port 8686. If I connect locally with (for instance) jconsole it works fine. I believe it is somehow related to being in a zone. Because snoop -p 8686 from my zone... tells me, no network interface devices found. [EMAIL PROTECTED]: ifconfig -a lo0:1: flags=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL mtu 8232 index 1 inet 127.0.0.1 netmask ff00 bge0:1: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500 index 2 inet 10.5.185.103 netmask fc00 broadcast 10.5.187.255 Is there something I can configure to do this? Thanks, Russ ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] how to configure port listening in a zone?
I snooped from the global zone and could see a request and response. I can ping. I can ssh into the zone. Just a sec ... I found the problem. It is not a zones issue... In my domain.xml for the webserver, I had security-enabled set to true. It works with false jmx-connector accept-all=true address=0.0.0.0 auth-realm-name=admin-realm enabled=true name=system port=8686 protocol=rmi_jrmp security-enabled=false Thanks, Russ Steve Lawrence wrote: By default, a zone does not have privilege to snoop: http://blogs.sun.com/JeffV/entry/snoop_zoney_zone Could just be a network config/routing issue. Can you ping 10.5.185.103? Can you access other network services, like ssh? -Steve L. On Tue, Aug 19, 2008 at 03:01:37PM -0700, Russ Petruzzelli wrote: I have a glassfish webserver running in my Solaris 10 zone. It will not respond to remote jmxrmi requests on port 8686. If I connect locally with (for instance) jconsole it works fine. I believe it is somehow related to being in a zone. Because snoop -p 8686 from my zone... tells me, no network interface devices found. [EMAIL PROTECTED]: ifconfig -a lo0:1: flags=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL mtu 8232 index 1 inet 127.0.0.1 netmask ff00 bge0:1: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500 index 2 inet 10.5.185.103 netmask fc00 broadcast 10.5.187.255 Is there something I can configure to do this? Thanks, Russ ___ 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 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
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.
Argh again. Currently startd hard codes the allowable milestones. My
proposal would require patching startd :(
static int
dgraph_set_milestone(const char *fmri, scf_handle_t *h, boolean_t norepository)
{
const char *cfmri, *fs;
graph_vertex_t *nm, *v;
int ret = 0, r;
scf_instance_t *inst;
boolean_t isall, isnone, rebound = B_FALSE;
/* Validate fmri */
isall = (strcmp(fmri, all) == 0);
isnone = (strcmp(fmri, none) == 0);
if (!isall !isnone) {
if (fmri_canonify(fmri, (char **)cfmri, B_FALSE) == EINVAL)
goto reject;
if (strcmp(cfmri, single_user_fmri) != 0
strcmp(cfmri, multi_user_fmri) != 0
strcmp(cfmri, multi_user_svr_fmri) != 0) {
startd_free((void *)cfmri, max_scf_fmri_size);
reject:
log_framework(LOG_WARNING,
Rejecting request for invalid milestone \%s\.\n,
fmri);
return (EINVAL);
}
}
-Steve L.
___
zones-discuss mailing list
zones-discuss@opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org
