Re: [zones-discuss] How to enable a service of a zone that is not running...
AFAIK the upgrade script is not an stable interface. IMHO it's better to create an rc script in the zone with the svcadm enable command which removes itself after executing the svcadm command. regards Bernd Mike Gerdts wrote: On Sun, Sep 27, 2009 at 10:50 AM, Brad Diggs bradley.di...@sun.com wrote: I would like to svcadm enable a service of a non-global zone who's state is not 'running'. Is that possible? If so, how? Thanks in advance, Brad Brad Diggs Principal Field Technologist You can cause it to become enabled on the next boot with: echo svcadm enable $fmri $zonepath/root/var/svc/profile/upgrade This will get processed when manifest-import runs early in the zone boot process. I'm not so sure that this is considered to be an interface, so it may break at any time. It is probably best to ask on smf-discuss if you care about the stability of this mechanism. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org -- Bernd Schemmer, Frankfurt am Main, Germany http://bnsmb.de/ M s temprano que tarde el mundo cambiar . Fidel Castro ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Ancestor filesystems writable by zone admin - by design?
Le 27 sept. 09 à 12:55, Miles Benson a écrit : Hi All, I'm not sure what I'm seeing is by design or by misconfiguration. I created a filesystem tank/zones to hold some zones, then created a specific zone filesystem tank/zones/basezone. Then built a zone, setting zonepath=/tank/zones/basezone. If I zlogin to basezone, and do zfs list, it shows the ancestors to basezone tank tank/zones tank/zones/basezone tank/zones/basezone/ROOT tank/zones/basezone/ROOT/zbe This in itself is not ideal - if a zone become compromised then it's revealing something about the underlying pool and filesystems. I can live with it. However, if I become root in the zone then the ancestor filesystem is *writable*. I can write a file in /tank/zones! So if I delegate root access to a zone to someone, all of a sudden they can write to the entire pool? Am I doing something wrong? Any and all suggestions welcome! AFAIK, you shouldn't see all these in your zone. Are you in S10 or on OS ? Did you delegate any dataset or set the zoned flag on ZFS ? Nicolas ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] updating zones question
Will Fiveash wrote: This is in the FAQ. http://www.opensolaris.org/os/community/zones/faq/#os I wish the info was more detailed/explicit. How do I use zones attach/detach to do an image-update on the zone exactly? # zoneadm -z myzone foo detach # zoneadm -z myzone foo attach -u Also I don't see anything in there on what I need to do if I want to snapshot an existing zone in case I want to rollback the zone to the state it was in prior to the image-update. When you image-update the system that will happen automatically. When you go back to an earlier global zone BE, then the earlier zone BEs will automatically be used. If you want to do something like this independently of the global zone, then you have to roll your own stuff. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Ancestor filesystems writable by zone admin - by design?
Miles Benson wrote: Hi All, I'm not sure what I'm seeing is by design or by misconfiguration. I created a filesystem tank/zones to hold some zones, then created a specific zone filesystem tank/zones/basezone. Then built a zone, setting zonepath=/tank/zones/basezone. If I zlogin to basezone, and do zfs list, it shows the ancestors to basezone tank tank/zones tank/zones/basezone tank/zones/basezone/ROOT tank/zones/basezone/ROOT/zbe This in itself is not ideal - if a zone become compromised then it's revealing something about the underlying pool and filesystems. I can live with it. However, if I become root in the zone then the ancestor filesystem is *writable*. I can write a file in /tank/zones! So if I delegate root access to a zone to someone, all of a sudden they can write to the entire pool? Am I doing something wrong? Any and all suggestions welcome! So how do the higher datasets appear in the namespace of the zone? That is, you're implying that somehow /tank/zones is mounted inside the zone. Is that true? I can't reproduce this on my opensolaris system running b123. Can you provide more details on your zone configuration and what you did to make /tank/zones visible inside the zone. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] How to enable a service of a zone that is not running...
It should be possible to do it since the integration of PSARC 2008/015 svccfg refresh subcommand in nevada. eg. # svccfg svc: repository zonepath/etc/svc/repository.db svc: select instance_FMRI svc: setprop general/enabled = true svc: refresh svc: exit I've never tried it though and I'm not sure you can manipulate the 'general' property group offline. Btw, to be able to do it, the NGZ must be running the same OS as the Global Zone otherwise you could corrupt the repository. -- Renaud Bernd Schemmer wrote: AFAIK the upgrade script is not an stable interface. IMHO it's better to create an rc script in the zone with the svcadm enable command which removes itself after executing the svcadm command. regards Bernd Mike Gerdts wrote: On Sun, Sep 27, 2009 at 10:50 AM, Brad Diggs bradley.di...@sun.com wrote: I would like to svcadm enable a service of a non-global zone who's state is not 'running'. Is that possible? If so, how? Thanks in advance, Brad Brad Diggs Principal Field Technologist You can cause it to become enabled on the next boot with: echo svcadm enable $fmri $zonepath/root/var/svc/profile/upgrade This will get processed when manifest-import runs early in the zone boot process. I'm not so sure that this is considered to be an interface, so it may break at any time. It is probably best to ask on smf-discuss if you care about the stability of this mechanism. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Ancestor filesystems writable by zone admin - by design?
Thanks for getting back. Anyway, I've done some more digging. It seems to be related to having delegated a dataset to a zone. I have two zones 'basezone' and 'paulzone'. Forget the fact that I used the example of basezone above for a moment. basezone has no delegated dataset and when you zlogin you can do r...@muttley:~# zlogin basezone [Connected to zone 'basezone' pts/2] Last login: Mon Sep 28 19:29:31 on pts/2 Sun Microsystems Inc. SunOS 5.11 snv_111bNovember 2008 r...@basezone:~# zfs list NAME USED AVAIL REFER MOUNTPOINT tank 93.8G 2.57T 53.6K /tank tank/zones1.12G 2.57T 41.1K /tank/zones tank/zones/basezone314M 2.57T 37.5K /tank/zones/basezone tank/zones/basezone/ROOT 314M 2.57T 34.0K legacy tank/zones/basezone/ROOT/zbe 314M 2.57T 309M legacy r...@basezone:~# touch /tank/zones/foobar touch: cannot create /tank/zones/foobar: No such file or directory r...@basezone:~# so all's well and good. paulzone on the other hand was cloned from basezone and then I created a new filesystem /tank/zones/pauldata and delegated it: r...@muttley:~# zonecfg -z paulzone info zonename: paulzone zonepath: /tank/zones/paulzone brand: ipkg autoboot: true bootargs: pool: limitpriv: scheduling-class: ip-type: shared hostid: net: address: 192.168.246.249/29 physical: e1000g0 defrouter: 192.168.246.254 dataset: name: tank/zones/pauldata r...@muttley:~# so if we zlogin to that zone... r...@muttley:~# zlogin paulzone [Connected to zone 'paulzone' pts/2] Last login: Mon Sep 28 19:30:10 on pts/2 Sun Microsystems Inc. SunOS 5.11 snv_111bNovember 2008 r...@oberon:~# zfs list NAMEUSED AVAIL REFER MOUNTPOINT tank 93.8G 2.57T 53.6K /tank tank/zones 1.12G 2.57T 41.1K /tank/zones tank/zones/pauldata 390M 19.6G 390M /tank/zones/pauldata tank/zones/pauldata/svnrepository 105K 19.6G 105K /tank/zones/pauldata/svnrepository tank/zones/paulzone 404M 4.61G 37.5K /tank/zones/paulzone tank/zones/paulzone/ROOT404M 4.61G 34.0K legacy tank/zones/paulzone/ROOT/zbe404M 4.61G 701M legacy r...@oberon:~# touch /tank/zones/foobar r...@oberon:~# ls -l /tank/zones/foobar -rw-r--r-- 1 root root 0 Sep 28 19:38 /tank/zones/foobar r...@oberon:~# not so good. This is an opensolaris machine, r...@muttley:~# uname -a SunOS muttley 5.11 snv_111b i86pc i386 i86pc Solaris I pretty much followed the instructions in, er, your book to set all this up :-) but I've probably missed a step somewhere. Thanks Miles -- This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Can't set up AutoInstall in a non-global zone with exclusive IP
On a related topic, is there a reason you can't snoop -d /dev/igb1 in the non-global zone, where igb1 is the NIC dedicated to the zone? That should work fine (well, snoop -d igb1 should). -- meem ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Ancestor filesystems writable by zone admin - by design?
Miles Benson wrote: Hi Jerry, Ok, that makes sense. And I've checked and you're right, it's all in the non-global zone. My mistake and I'm glad I was wrong. However, I think the thing which set me off on the wrong track in the first place was the zfs list output showing the available space. Which quota is that data space coming out of? The zone's filesystem has a 5G quota and the data filesystem has a 20G quota. zfs list shows these as I'd expect but it shows /tank/zones having the full run of the 2.5T main pool. I'd guess that it's in the 5G basic zone filesystem and that zfs list is just a bit confused? I can't really answer this without seeing the quota's you have set on each dataset. However, the output you sent earlier, which I've included here, seems to show the correct quotas on the two datasets that are actually available inside the zone. This matches up to what you've said above (20GB and 5GB). r...@oberon:~# zfs list NAMEUSED AVAIL REFER MOUNTPOINT tank 93.8G 2.57T 53.6K /tank tank/zones 1.12G 2.57T 41.1K /tank/zones tank/zones/pauldata 390M 19.6G 390M /tank/zones/pauldata tank/zones/pauldata/svnrepository 105K 19.6G 105K /tank/zones/pauldata/svnrepository tank/zones/paulzone 404M 4.61G 37.5K /tank/zones/paulzone tank/zones/paulzone/ROOT404M 4.61G 34.0K legacy tank/zones/paulzone/ROOT/zbe404M 4.61G 701M legacy I'm unclear why the size of the datasets that aren't available inside the zone is a concern, other than that you'd prefer those to not be visible at all. That's really not a zone's issue and would be more appropriate to discuss over on the zfs alias. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
Edward Pilatowicz wrote: hey jerry, do you have an updated ws+webrev where the s10 files were created using hg cp? (i'm waiting for that before doing a review.) also, when were you planning to integrate? (so i can avoid a last minute rush.) Ed, I wasn't aware that this was holding you up. I haven't done anything on it yet. I'll work on regenerating the webrevs by tomorrow and send out an announcement. We are targeting b127 so it would be good to get any comments this week so that there is time to respond and test any changes. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
On Mon, Sep 28, 2009 at 03:06:00PM -0600, Jerry Jelinek wrote: Edward Pilatowicz wrote: hey jerry, do you have an updated ws+webrev where the s10 files were created using hg cp? (i'm waiting for that before doing a review.) also, when were you planning to integrate? (so i can avoid a last minute rush.) Ed, I wasn't aware that this was holding you up. I haven't done anything on it yet. I'll work on regenerating the webrevs by tomorrow and send out an announcement. We are targeting b127 so it would be good to get any comments this week so that there is time to respond and test any changes. ah. yeah. i was waiting because i wanted to use the hg cp' workspace to generate a webrev using daneks copy of webrev. (since that would show just the delta to all the copied files, there by greatly reducing the amount of code to review.) ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] updating zones question
Will Fiveash wrote: On Mon, Sep 28, 2009 at 12:20:53PM -0600, Jerry Jelinek wrote: Will Fiveash wrote: This is in the FAQ. http://www.opensolaris.org/os/community/zones/faq/#os I wish the info was more detailed/explicit. How do I use zones attach/detach to do an image-update on the zone exactly? # zoneadm -z myzone foo detach # zoneadm -z myzone foo attach -u The man page for zoneadm does not describe the -u flag for attach. It is also unclear to me which zoneadm parameter foo represents. Sorry, I mistyped the example. It should have been: # zoneadm -z myzone detach # zoneadm -z myzone attach -u The string foo should not have been in the example. The -u flag is not in the zoneadm man page because it is a brand specific option. Not all brands support -u (e.g. lx does not). There is no man page for the ipkg brand yet but you can read about this option on the native(5) man page. Given I created and updated a BE by doing: beadm create opensolaris_123 beadm mount opensolaris_123 /mnt pkg -R /mnt image-update and I have a non-local zone called master, can you provide the exact commands I should have run in order for the master zone to be updated to snv_123 when I boot the opensolaris_123 BE and still have be able to access a master zone at snv_111 when I boot the opensolaris_111 BE? Is this what I should have done: beadm create opensolaris_123 beadm mount opensolaris_123 /mnt zoneadm -z master detach pkg -R /mnt image-update zoneadm -z master attach -u More like: beadm create opensolaris_123 beadm mount opensolaris_123 /mnt pkg -R /mnt image-update zoneadm -R /mnt -z master detach zoneadm -R /mnt -z master attach -u Although I haven't tested that to see if the ipkg brand will handle the zone update correctly on an alternate root. If not, thats a bug in the brand. I do know that booting the opensolaris_123 BE then detaching/attaching the zone will properly update the zone. We're still working on getting IPS and zones to work properly together so that the zones get updated when you image-update the global zone. ? Do I need to recreate the opensolaris_123 BE and do the above in order to get the master zone properly updated? No, if you're running opensolaris_123, just detach the zone then attach -u and the right thing should happen. If the zone is already up-to-date, then the zone will simply be attached. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
