The document below describes some minor changes I've planned for the
Zones administrative utilities in order to support Zones upgrade
("Zulu").
Please send me any comments or requests for more time by Monday, June
12th, 2006, if possible. You may send the comments directly to me or
copy the list; your choice.
The documents referenced in the 'background' note (lu-icf-design.txt
and lumount-design.txt) aren't necessary in order to review these
changes, and they refer to code that hasn't been released yet, but if
you'd like to see a copy of them anyway, please contact me directly.
Copyright 2006 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
# ident "@(#)new-on-features.txt 1.2 06/06/04 SMI"
Background
----------
The changes described in lu-icf-design.txt and lumount-design.txt
assume a certain amount of functionality from within the Operating
System / Networking (ON) consolidation. Currently, these features
are not present in ON, and the Zulu project contains kludges to work
around these feature gaps. These kludges must be removed and
replaced with supported ON features, or the Install gate (and Zulu)
will be faced with complex dependencies on ON internal data
structures and file formats.
Features In Zonecfg
-------------------
-R <root>
As with the other zones-related utilities, zonecfg needs a "-R"
option to invoke zonecfg_set_root(). This is used in many of the
functions below, and is a generic feature. (It will likely also
be used to deliver the ipge/e1000g transition, so it should be
integrated separately from Zulu.)
One of the risks with this feature is that the zones configuration
files in the alternate root specified might not be the same
(private) version as the running system. The existing "-R"
option on zoneadm also has this issue. For this reason, the
new option should remain (contracted) private at this point.
In the future, though, administrative control over inactive boot
environments seems like a highly desirable and useful feature.
Having this feature (or something like it) become stable enough
for general customer use should be a goal.
set -f zonepath=<path>
This new flag (-f) allows lucopy to change the path of a zone
after performing the copy operation. Unlike the regular "set
zonepath" operation, it does not check the zone state; it "forces"
the operation. Unlike the existing "zoneadm move" command, the
actual data are not moved or copied, just the path recorded in the
database is changed.
This should be a private feature as it relies on actions (copying
zone data) that can't necessarily be supported in this manner.
The documented way to change a zone path is via the "zoneadm move"
option.
This is used only in the case zones that exist on shared file
systems. Zones on unshared file systems do not change in path
during LU operations. Thus, it will be limited to just the "-R"
case and won't allow the path on the running system to be altered.
It is expected that when ZFS is integrated into Install, Zones
using ZFS will have substantially different features (using
snapshot/clone operations) and will thus be able to avoid path
changes.
Features In Zoneadm
-------------------
zoneadm [-R path] -z zone state incomplete
This allows lucopy to mark damaged zones (those that cannot be
replicated properly) as 'incomplete'. It's probably a useful
feature in general for administrative software that uses Zones
under the covers, so making it public seems reasonable.
zoneadm [-u uuid-match] list
Two separate features are added to the "list" subfunction to
enable matching based on UUID (universally unique identifiers).
The zone UUID is used to ensure that the zone against which we're
synchronizing is the same one that we previously copied.
The separate identifier is needed because zones can be uninstalled
and reinstalled under the same name (with different contents), and
can be renamed (without changing contents). The zone name is thus
an unstable handle for the zone.
Note that because S10 shipped without UUIDs on zones, and because
of CR 6379341, inactive BEs may not necessarily have values to
match. Any running system with this new feature will
(necessarily) have the fix for those problems, and thus have
reliable UUIDs.
-u uuid-match
This feature enables matching based on the UUID. If the UUID
string to match is zero-length, then it is treated as though the
option were not present. (I.e., it has no effect.)
If both -u and -z are present, then the match is done based on
the UUID first. If a zone with the specified UUID is found, it
is used, and the -z parameter is ignored. If no zone is found
by UUID, then the system searches by zone name instead.
This matching logic is identical to the existing "/b" mount
logic in zoneadmd that provides access to the running zone from
within a scratch zone. It is possible for the user to go out of
his way to fool this logic, but the result can only be a false
match against an uninstalled zone (lacking a UUID), and no
synchronization is ever done (or possible) with an uninstalled
zone.
Note that the option preceeds the subcommand because the "-z"
option also preceeds the subcommand. Standard style would place
the option after the subcommand, but adding a new feature that's
logically similar but differing in usage would be more
confusing.
list
The UUID is added as the fifth field (after path) in the
"zoneadm list -p" output. It is not administratively
significant, and thus is not listed with "zoneadm list -v."
With one minor vplat simplification (creating a dummy
/etc/zones/index entry inside the zone), this fixes CR 6365741
as well, and thus should be publicly documented. The
implementation will do a zone_enter() and then open and write to
that file. No special handling (e.g., enforcing read-only via
lofs) is expected to be needed.
Note that there's no security issue in allowing root within the
zone to overwrite this file. Such a user can already use
LD_PRELOAD and other tricks to fake the contents of this file,
so having that user overwrite the file directly introduces no
new vulnerabilities. The UUID is not (and cannot be made)
"secure" within the zone, for the same reason that the hostid
isn't "secure" anywhere.
Issues
------
Should the list -p output default to omitting the UUID value, at
least in a patch release due to CR 6431731? If so, we'll need a
way ("list -pu"?) to enable it there.
--
James Carlson, KISS Network <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.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
