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