Re: [zones-discuss] sysidcfg - root password
v wrote: SunOS Release 5.11 Version snv_111b 32-bit Copyright 1983-2009 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Hostname: zone1 Reading ZFS config: done. Mounting ZFS filesystems: (6/6) root_password=fto/dU8MKwQR Is this encrypted string missing a character? syntax error line 8 position 15 Creating new rsa public/private host key pair Creating new dsa public/private host key pair Configuring network interface addresses: vnic1 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] sysidcfg - root password
v wrote:
I don't think so... It looks like it works:
http://blogs.sun.com/observatory/en_US/entry/zones_and_crossbow1
I would validate with that blogger if that sysidcfg had actually
been validated. If you look a little lower in the blog, the sysidcfg
file failed to get get consumed by sysidtool when that zone booted:
Use is subject to license terms.
Hostname: myzone
Loading smf(5) service descriptions: 69/69
Reading ZFS config: done.
Mounting ZFS filesystems: (5/5)
network_interface=myzone0 {
myzone0 is not a valid network interface line 3 position 19
Creating new rsa public/private host key pair
Upon any syntax error, the entire sysidcfg file is thrown out, so
I don't see how the root_password would have even gotten processed
by sysidroot.
Anyway, for your case, why don't you just replace the encrypted
string with some other known good one.
-ethan
___
zones-discuss mailing list
zones-discuss@opensolaris.org
[zones-discuss] Code review for zones support in SNAP (updated)
Joe, Jean, Jerry, Thanks for providing your comments. We've built an incremental webrev with just the changes from your comments. This webrev also includes a couple of dev bugfixes that went in during the code review process - 3776, 3772 Any further comments are welcomed. http://cr.opensolaris.org/~equach/webrev.snap_zones.2 As a reference, we've also refreshed the overall webrev here: http://cr.opensolaris.org/~equach/webrev.3686 Thanks again for the review, -ethan ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Code review for zones support in SNAP (updated)
Joe, Thanks. We'll make that correction. -ethan Joseph J VLcek wrote: Ethan Quach wrote: Joe, Jean, Jerry, Thanks for providing your comments. We've built an incremental webrev with just the changes from your comments. This webrev also includes a couple of dev bugfixes that went in during the code review process - 3776, 3772 Any further comments are welcomed. http://cr.opensolaris.org/~equach/webrev.snap_zones.2 As a reference, we've also refreshed the overall webrev here: http://cr.opensolaris.org/~equach/webrev.3686 Thanks again for the review, -ethan This all looks good. I only found one small nit. Joe usr/src/lib/libbe/be_create.c +-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+ Issue: -- Typo-s in comment: Change from: 1004 * root dataset of the new BE. The uuid is use to set the parentbe 1005 * property for the new zones datasets. To: 1004 * root dataset of the new BE. The uuid is used to set the parent be 1005 * property for the new zones datasets. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Code review for zones support in SNAP
Comments, mostly on libbe ...
General comment - Since we don't yet support boot environments
within a zone, beadm should fail gracefully when run in a zone, like:
# beadm subcommand
beadm is not supported in a zone.
rather then trying to do something and failing miserably. Most of
the if(GLOBAL_ZONEID) checks we have in libbe now are really
just primers for when we build in that support.
usr/src/man/beadm.1m.txt
--
333 - SUNWinstall - SUNWbeadm
messages.py
126 - BE_ERR_NO_ACTIVE_ROOT should be in here.
be_activate.c
-
136 - initialize to { 0 }
169-199 - This whole chunk needs to be encapsulated inside a
if (GLOBAL) {
}
215-221, 241-245 - These two chunks seem like they could be
moved up into the if (GLOBAL) {} from 169.
With some refactoring, the zfs_promote() calls in set_canmount()
could probably be ripped out and replaced by calls to be_promote_zone_ds()
(renamed to something more generic like be_promote_ds() of course).
I never understood why the zfs_promote() calls were hidden in the
set_canmount() function anyway. If we don't get to this per the code
review changes, please file a bug to track this.
972-1023 - This whole chunk can be removed if you replace 1025-1026
with a direct call to the callback giving it the root dataset of the
zone BE.
i.e. replace 1025-1026 with:
if (be_promote_sub_ds_callback(z_zhp, NULL) != 0) {
1028 - remove subordinate
Rename the following functions to be more generic:
be_promote_zone_ds() -- be_promote_ds()
be_promote_sub_ds_callback() -- be_promote_ds_callback()
be_create.c:
---
1880 - future
1878-1883 - this comment needs to be removed. It doesn't apply to
this section of code.
1884 - within the context of this function - that is, code running in the
global zone that's processing non-global zones - this if() can be removed,
along with 1895.
1944 - A comment stating this is getting the uuid of the newly cloned
parent BE would be nice.
2772-2774 - Missing function block comment.
libbe.h:
-
117 - not - no
177 - Remove this line; its not used anywhere.
thanks,
-ethan
Evan Layton wrote:
Hello All,
We're down to the wire on the zone support changes to SNAP upgrade and are
looking for code review comments. We'll be taking comments up until COB
Tuesday
October 7th. Your comments are as always welcome and appreciated.
Defect 3686 is the blocker bug that was submitted to cover this work and the
webrev is available at:
http://cr.opensolaris.org/~equach/webrev.snap_zones/
Thank you in advance for your comments and help!
-evan
___
zones-discuss mailing list
zones-discuss@opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] [caiman-discuss] Code review for zones support in SNAP
Tim, Thanks for the review. All comments taken as is unless noted below... thanks, -ethan Tim Knitter wrote: be_mount.c: 53: Why not add this struct to libbe_priv.h where the other structs live? Because its only used privately in be_mount.c, not anywhere else. Nit: 294, 2208: The comment should spell out variable names (altroot) for clarity sake. I think altroot is pretty well understood. Its not even used as variable name at 2208, but I could change altroot - alternate root, if that's what you were intending. 546: failed to - failed to mount a actually, the failed to just needs to be nuked. 547: dataset mountpoint - dataset. Mountpoint given the removal of the failed to portion, the sentence makes sense as is. 575: boolean_t seems a better choice since this function only has 2 states to return. Also calls to this function then don't have to compare against an int. Actually, I think this method (along with 525), need to be changed to return be_errno_t so that a more accurate message can ultimately be displayed. I'll make this adjustment. 702: Spell out altroot in comment; alternate root Again, I think altroot is well understood, but sure, I can change this... 644,715,750... zone_mounted_here the here is ambiguous, suggest just zone_mounted here means we mounted it here in this function, so we know we need to unmount it before leaving, as a cleanup task. I think its more ambiguous without the here. IMO zone_mounted sounds more like a status that the zone is currently mounted. thanks, -ethan Thanks Tim Evan Layton wrote: Hello All, We're down to the wire on the zone support changes to SNAP upgrade and are looking for code review comments. We'll be taking comments up until COB Tuesday October 7th. Your comments are as always welcome and appreciated. Defect 3686 is the blocker bug that was submitted to cover this work and the webrev is available at: http://cr.opensolaris.org/~equach/webrev.snap_zones/ Thank you in advance for your comments and help! -evan ___ caiman-discuss mailing list [EMAIL PROTECTED] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss Evan, I will review this today, Monday October 6. Joe ___ caiman-discuss mailing list [EMAIL PROTECTED] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss ___ caiman-discuss mailing list [EMAIL PROTECTED] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [caiman-discuss] SNAP zones layout proposal.
Jerry Jelinek wrote: Evan Layton wrote: This is the same as what is done with /rpool/ROOT and ZFS boot, with ROOT being the confined area where we place BE's. An admin can still create things there but this is the only place that we look for BE's. Datasets outside this are not considered BE's but would be shared between BE's as is done in the global zone now. Evan, We can certainly call this .../ROOT instead of .../rpool, if that makes a difference. The extra level is what makes the difference, not the name. -ethan ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [caiman-discuss] SNAP zones layout proposal.
Jerry Jelinek wrote:
Ethan Quach wrote:
Ethan Quach wrote:
Jerry Jelinek wrote:
Evan Layton wrote:
This is the same as what is done with /rpool/ROOT and ZFS boot, with
ROOT being the confined area where we place BE's. An admin can
still
create things there but this is the only place that we look for BE's.
Datasets outside this are not considered BE's but would be shared
between BE's as is done in the global zone now.
Evan,
We can certainly call this .../ROOT instead of .../rpool, if that
makes a difference.
The extra level is what makes the difference, not the name.
Jerry,
Let me try to clarify (if I wasn't clear), the extra level would be
just an
organizational convenience, not something required for this to work.
Without ROOT, the zone BE root datasets would have zfs properties
and such to delineate them from random datasets that a zone admin could
have created under zonepath/rpool.
zonepath/rpool/ZBE1
zonepath/rpool/ZBE2
zonepath/rpool/foo
zonepath/rpool/foo/bar
zonepath/rpool/export
vs.
zonepath/rpool/ROOT/ZBE1
zonepath/rpool/ROOT/ZBE2
zonepath/rpool/foo
zonepath/rpool/foo/bar
zonepath/rpool/export
Yes, the zone admin could still create random datasets directly under
the
ROOT because we have nothing stopping them to, but it's documented to
be a special dataset that they shouldn't play around with.
Ethan,
I wasn't evinsioning that the {zonepath}/rpool dataset was a general
purpose dataset to put stuff in. We already have other mechanisms for
that.
In fact, rpool is a bad name, since it is not a pool. Calling this
{zonepath}/ROOT seems to be clearer.
Jerry,
If its not for general purpose, then yes, I agree zonepath/ROOT is
more clear. (And I also agree about the rpool name)
Regarding a general purpose dataset, IMO we need to always automatically
give this branded zone one of those since we're giving it the ability to
manipulate its own BEs. With BEs, zone admins will inevitably want a
place to store data shared by all of their BEs instead of having everything
cloned.
thanks,
-ethan
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] [caiman-discuss] SNAP zones layout proposal.
Hey Jerry,
I just thought about something regarding the zones dataset
namespace. Instead of creating the dataset for zone roots at:
rpool/export/zones/z1/rpool/ZBE1
Maybe we should insert the roped off ROOT container dataset
like we do in the global zone:
rpool/export/zones/z1/rpool/ROOT/ZBE1
so that we confine the place where we know boot environment roots
live. The reason we do this is in the global zone is so that we
don't have to troll through potentially thousands of datasets
(sorting out whatever's been created in the shared area) to find
BE roots. This same problem would occur in the zone BE namespace.
Thoughts?
thanks,
ethan
Jerry Jelinek wrote:
The final design is attached.
Thanks,
Jerry
---
Zones/SNAP Design
8/25/2008
I. Overview
This specification describes how ZFS datasets will be used with zones for
supporting software management operations with ipkg branded zones on
OpenSolaris. Software management includes tasks such as a SNAP upgrade or
installing/removing pkgs.
Issues are summarized in Part III.
One goal is that sw management behavior within the zone should be as similar
as possible to the behavior in the global zone. That is, when the zone admin
does sw management, the tools running within the zone should be able to take a
snapshot of the zone root, clone it, and the zone admin should be able to
roll-back if the sw installation was problematic. This implies that the zone
root itself must be a delegated dataset. Up to now, zones does not support
this, so we must extend zones to provide this capability.
(Note that these software management features within a zone are not a
requirement for the 2008.11 release, however, this proposal lays the
groundwork to enable that capability moving forward.)
There are some issues with delegating the zone root dataset to the zone. The
way zones work, it is fundamental that the zone root be mounted in the global
zone so that the system can set up the chrooted environment when the zone
boots or when a process enters the zone. However, the ZFS mountpoint property
cannot be interpreted from the global zone when a dataset is delegated,
since this could lead to security problems.
(Note that the zone root is {zonepath}/root as seen in the global zone}
To address this, the zones code must be enhanced to explicitly manage the zone
root mounts. This naturally falls out of the basic design described here.
There were two alternative proposal considered; a two-level zone layout and a
single-level zone layout. After much discussion, the single-level approach
was chosen. The two-level approach is not described further here.
II. Description
To support the management of boot environments (BEs) for zones within both the
global zone context as well as the non-global zone context, a nested,
two-level, BE dataset naming scheme is used so that there is a top-level
global zone BE namespace, as well as a zone-level BE namespace for the zone's
own use. Properties on the zone's datasets are used to manage which dataset
is active and which datasets are associated with a specific global zone BE.
There are two properties on a zone's datasets that are used to manage the
datasets; org.opensolaris.libbe:parentbe and org.opensolaris.libbe:active.
The org.opensolaris.libbe:parentbe property is set to the UUID of the global
zone BE that is active when the non-global zone BE is created. The
org.opensolaris.libbe:active property is set to on or off to indicate
that the dataset is the one that should be mounted.
We leave the org.opensolaris.libbe:active property set to on to
correspond with older, inactive global zone BEs, and use the combination of
this property, along with the matching org.opensolaris.libbe:parentbe to
determine which dataset to mount on the zone root. Thus, rolling back to an
earlier global zone BE would cause the last active zone BE to be mounted for
that global zone BE.
When a global zone BE is deleted, all corresponding zone-specific BEs with the
matching org.opensolaris.libbe:parentbe property should also be deleted.
When a non-global zone is deleted, all of zone-specific BEs with the
matching org.opensolaris.libbe:parentbe property for the current global zone
BE UUID should be deleted, however, any zone-specific BEs for other
global zone BEs must be preserved.
The following example illustrates the dataset layout and management for zone
z1 while the global zone is running BE1. The zones code must be enhanced to
automatically create these datasets when the zone is installed.
(For clarity, the global zone GBE string is used instead of the global zone
BE UUID in the following examples. Likewise, the ZBE string is used to for
the non-global zone BE name.)
The zone has zonepath: /export/zones/z1
The relevant dataset that exists before the zone is installed:
dataset mountpoint prop.
Re: [zones-discuss] [caiman-discuss] SNAP zones layout proposal.
Mike Gerdts wrote: On Tue, Aug 26, 2008 at 5:07 PM, Ethan Quach [EMAIL PROTECTED] wrote: Hey Jerry, I just thought about something regarding the zones dataset namespace. Instead of creating the dataset for zone roots at: rpool/export/zones/z1/rpool/ZBE1 Maybe we should insert the roped off ROOT container dataset like we do in the global zone: rpool/export/zones/z1/rpool/ROOT/ZBE1 so that we confine the place where we know boot environment roots live. The reason we do this is in the global zone is so that we don't have to troll through potentially thousands of datasets (sorting out whatever's been created in the shared area) to find BE roots. This same problem would occur in the zone BE namespace. Thoughts? rpool/ROOT seems to be redundant and it repeats itself. :) In the global zone, rpool/ROOT makes sense because there needs rpool and ROOT perform different duties. In a non-global zone, rpool/export/zones/z1 is equivalent to the global zone's rpool. To maximize synergies (and end abuse of /export - see filesystem(5)), I suggest: Sure, that's fine. That part isn't really relevant from what I was trying to convey though. This is the equivalent of the global zone's rpool. Or in an environment where there is a pool per zone, it may be z1pool. rpool/zones/z1 This is managed by zoneadm and beadm. If all goes well, they both use libzonecfg to minimize the chance of divergence. rpool/zones/z1/ROOT rpool/zones/z1/ROOT/be1 rpool/zones/z1/ROOT/be2 The rest are available for use within the zone and may be mounted other places rpool/zones/z1/* rpool/zones/z1 is the zonepath, and I don't know if we're planning on delegating that dataset to the zone (for zone reasons I suppose). Based on Jerry's proposal, the zonepath is not delegated. Hence the need for: rpool/zones/z1/pool/ROOT/ZBE1 The pool level is delegated, and that was what I was thinking the zone can use as its free-range area. thanks, -ethan ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [install-discuss] [storage-discuss] Using LiveUpgrade with Zones
Giovanni Schmid wrote: Ethan, my zonepaths aren't on that zfs. Have you confidence (or evidence) that in such scenario a simple BE duplication as provided by # lucreate -c bootenv1 -m /:c2d0s0:ufs -n bootenv2 will be sufficient ? That is, will Z2 in bootenv2 see /zfspool/users/home ? I've not done this exact scenario with the zones and the dedicated zfs file system, so I can't offer any hard evidence. -ethan Thanks/g.s zfs with live upgrade isn't properly supported yet, but a simple shared zfs file system shared across BEs does work without hickups. If your zonepaths aren't on that zfs file system, this should be a working scenario. -ethan ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [install-discuss] [storage-discuss] Using LiveUpgrade with Zones
Jeff Cheeney wrote: Maybe someone on the install or zones discussion lists can help answer this question. Giovanni Schmid wrote: I have read different articles/docs/posts about solaris zones and liveupgrade issues until now; however, I have some doubts about the right way to deploy liveupgrade boot environments in the following case. I have a system with two disks configured as mirrors (that is, the same fdisk partition and VTOC). On the primary disk, I installed Solaris 10 8/07 with two sparse root zones, say Z1 and Z2. Just two file systems were settled on the primary disk: an UFS mounted on /, and a ZFS pool mirroring slice 4 of the two disks and mounted on /zfspool on the 1st disk. The UFS is intended to contain all but user's homes. These are served through a ZFS, namely /zfspool/users/home. Only zone Z2 inherits this ZFS, via the add fs setting. All that premised, my questions are: What is the correct way of using Live Upgrade for this case ? Would something like: # lucreate -c bootenv1 -m /:c2d0s0:ufs -n bootenv2 be sufficient ? That is, will Z2 in bootenv2 see /zfspool/users/home ? zfs with live upgrade isn't properly supported yet, but a simple shared zfs file system shared across BEs does work without hickups. If your zonepaths aren't on that zfs file system, this should be a working scenario. -ethan Any help is appreciated ! g.s This message posted from opensolaris.org ___ storage-discuss mailing list [EMAIL PROTECTED] http://mail.opensolaris.org/mailman/listinfo/storage-discuss ___ install-discuss mailing list [EMAIL PROTECTED] http://mail.opensolaris.org/mailman/listinfo/install-discuss ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Detect pkgs installed with -G?
Two ways a pkg can be installed in the global zone only. a) SUNW_PKG_ALLZONES=false SUNW_PKG_THISZONE=true b) SUNW_PKG_ALLZONES=false SUNW_PKG_THISZONE=false # pkgadd was run with -G Trolling though the installed pkginfo files will give you (a), but not (b). What you're probably looking for is /var/sadm/install/gz-only-packages. That's a private interface though. -ethan Ihsan Zaghmouth wrote: Much appreciated Shawn. Shawn Ferry wrote: Jeff, Ihsan; You want the command pkgparam, examples below. Shawn On Sep 5, 2007, at 2:54 PM, Ihsan Zaghmouth wrote: Hi Jeff, Here is my 2 cents, after assuming that pkginfo should hold such an information post installation. The */var/sadm/pkg/pkgname/pkginfo* file lists among other info the *SUNW_PKG_ALLZONES*=true | false for the installed package. pkginfo should have an option to display that, I tried them all ... in vain ! pkgparam -v pkgname or pkgparam pkgname param e.g. pkgparam SUNWcsr SUNW_PKG_ALLZONES true pkgparam -v SUNWcsr CLASSES='none ttydefs initd renamenew preserve cronroot passwd tiservices inetdconf definit etcremote nsswitch netconfig deflogin defsu syslogconf ttysrch group inittab etcrpc etcprofile mailxrc shadow locallogin localprofile logadmconf logindevperm nscd fstypes pamconf services rbac renameold dhcpinittab policyconf pkcs11confbase defpasswd vfstab manifest hosts' BASEDIR='/' LANG='' TZ='GMT0' PATH='/sbin:/usr/sbin:/usr/bin:/usr/sadm/install/bin' OAMBASE='/usr/sadm/sysadm' PKG='SUNWcsr' NAME='Core Solaris, (Root)' ARCH='i386' VERSION='11.11,REV=2007.01.05.02.51' SUNW_PRODNAME='SunOS' SUNW_PRODVERS='5.11/snv_55' SUNW_PKGTYPE='root' MAXINST='1000' CATEGORY='system' DESC='core software for a specific instruction-set architecture' VENDOR='Sun Microsystems, Inc.' HOTLINE='Please contact your local service provider' EMAIL='' SUNW_PKGVERS='1.0' SUNW_PKG_ALLZONES='true' SUNW_PKG_HOLLOW='false' SUNW_PKG_THISZONE='false' PSTAMP='elpaso20070105025839' PKGINST='SUNWcsr' PKGSAV='/var/sadm/pkg/SUNWcsr/save' MODIFIED_AFTER_INSTALLED='' INSTDATE='Mar 23 2007 06:09' if you write a small script, you can display the /var/sadm/pkg/pkgname/pkginfo, you should be able to distinguish: : cat /var/sadm/pkg/pkgname/pkginfo* | *grep SUNW_PKG_ALLZONES, and if: 1. SUNW_PKG_ALLZONES=true ... Then installed on all Zones 2. SUNW_PKG_ALLZONES=false ... *Only Global -G* Ihsan Jeff Victor wrote: How can someone learn whether a package was installed in the global zone *with* -G - or without it? ___ zones-discuss mailing list zones-discuss@opensolaris.org -- C:\Sun\Presentation2.jpg C:\Sun\Presentation2.jpg ___ zones-discuss mailing list zones-discuss@opensolaris.org mailto:zones-discuss@opensolaris.org -- Shawn Ferry shawn.ferry at sun.com Senior Primary Systems Engineer Sun Managed Operations ___ zones-discuss mailing list zones-discuss@opensolaris.org -- ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
