PSARC Questions Version 1.22 Approved Oct. 2008 (PSARC/2008/625) 1. What is the proposal being presented for review? * Give an overview of the project and its phase(s). Snap Boot Environment (BE) Management provides the mechanism to safely update system software by capturing system states and allowing previous system states to be re-enabled. It does this by creating a ZFS clone of the current system. The definition of a boot environment (also called a BE) is an instance of a bootable OpenSolaris environment consisting of a root file system and, optionally, other file systems mounted underneath it (e.g. /usr, /var). The root file system and all other file systems of the BE which contain system software must be zfs datasets. This project will allow a user to very quickly create a duplicate image of their running system or other inactive BE, which can then be updated and booted. * Describe the exposure (OpenSolaris), scope and type of review desired (overview, full case, etc.) Open. Full case. * Indicate the release binding requested by the project team. See: http://www.opensolaris.org/os/community/arc/policies/release-taxonomy/ Minor release binding * What are the project's deliverables? The CLI interface (SUNWbeadm) The man page for beadm (SUNWbeadm) underlying consolidation private library (SUNWinstall-libs) * How does this project align with existing or proposed ARC cases? This project will provide the BE management for the Image Packaging system: http://sac.sfbay/Archives/CaseLog/arc/PSARC/2008/190/ 2. Describe user interactions. * Are new user interfaces being proposed, or existing interfaces being changed? Yes. This project will provide a CLI (beadm) and library (libbe) interfaces for consumers to perform the following functions: - list BE's - This includes a BE's attributes. - create/destroy a BE - mount/unmount a BE - activate a BE - This makes the named BE the default BE on the next reboot. - rename a BE - rollback a BE - This rolls the BE's back to the state of a previous snapshot. * Explain the similarities in proposed interfaces with existing OS user interfaces (Solaris, Linux, Windows, etc.). There are some similarities between this project and Liveupgrade but only as far as the ability to create/destroy, mount/unmount, activate etc, a BE. Other than this the interface, subcommands and options are very diferent. * Are there any install time changes? This is used by the caiman installer (PSARC 2007/039 ) to create the initial empty BE that is then installed into. 3. What are the exported (defined by your project) and imported (defined by another project that your project then references) interfaces or protocols and their respective stability levels? See: http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ * Is there a versioning scheme in place? Yes. Standard library and packaging versioning. * Has the team secured interface contracts where necessary? We will be getting a contract with the ZFS team for the libzfs interfaces. * Use an ARC prescribed interface table format. _________________________________________________________ | Interfaces Exported | |_________________________________________________________| |Interface | Classification | Comments | |_____________________|________________________|__________| |be_init | Consolidation Private | See [1] | |be_mount | Consolidation Private | See [1] | |be_unmount | Consolidation Private | See [1] | |be_create | Consolidation Private | See [1] | |be_destroy | Consolidation Private | See [1] | |be_rename | Consolidation Private | See [1] | |be_activate | Consolidation Private | See [1] | |be_create_snapshot | Consolidation Private | See [1] | |be_destroy_snapshot | Consolidation Private | See [1] | |be_rollback | Consolidation Private | See [1] | |be_list | Consolidation Private | See [1] | |be_free_list | Consolidation Private | See [1] | |beadm list | Committed | See [2] | |beadm create | Committed | See [2] | |beadm destroy | Committed | See [2] | |beadm mount | Committed | See [2] | |beadm unmount/umount | Committed | See [2] | |beadm rename | Committed | See [2] | |beadm activate | Committed | See [2] | |_____________________|________________________|__________| 1. contained in the underlying libbe library 2. CLI interface The project imports the following interfaces. ___________________________________________________ | Interfaces Imported | |___________________________________________________| |Interface | Classification | Package | |______________|___________________|________________| |libinstzones | Uncommitted | SUNWinstallint | |______________|___________________|________________| |libzfs | Contract Private | SUNWzfsu | |______________|___________________|________________| |installgrub | Uncommitted | SUNWcsr | |______________|___________________|________________| 4. Describe any dependencies on hardware (e.g. SPARC exclusive), and on other projects within Solaris. There are no hardware dependencies. We depend on zfs boot's process of mounting all the subordinate datasets under a BE's root dataset when a BE is booting up. For example: /ROOT/myBE mounted as / /ROOT/myBE/usr mounted as /usr /ROOT/myBE/var mounted as /var /ROOT/myBE/opt mounted as /opt 5. Projects need to be aware of the overall security of the system and how their components affect it. Which parts of this project are critical to the security of the system to avoid such unintended consequences such as unauthorized system entry, unauthorized access to or modification of data, elevation of privilege, denial of service, violation of labeled security, ...? Does this project require elevated privilege? A number of specific policies and practices address various aspects of the security of the system. They are found in appendix 1. Which of these are applicable to this project, and how are they addressed? Yes, all subcommands other than list require elevated privileges which are maintained through RBAC. 6. Describe means of observing project functionality and performance, by an end user or by a system administrator. The use of the beadm list command and it's options provide the ability to view all of the BE's on the system and their properties. 7. How does the project deal with faults and interruptions? Initialization and restarting? The only functionality that can be impacted by an interruption is the create functionality. In this case if the create is interrupted it is seen as a failure and the partially created BE is cleaned up and removed. Other issues may include things like calls to things like installgrub which if it is interrupted an error is returned to the user. This is how any of the imported interfaces are dealt with. If they are interrupted an error is returned to us and that is then passed on o the user. 8. How does the project interact with Solaris virtualization technologies (xVM, LDOMs, zones, Branded zones, SunCluster, etc.)? This project will interact with zones which support IPS by not only cloning zones when a new global zone BE is created but by also being available inside of a zone. This gives the ability to create boot environments inside of a non-global zone and the ability to update a zone using IPS in the same way that a global zone is updated (pkg image-update). 9. Does this project require administration (i.e., configuration or management)? If so, * How is the project administered, and what sort of review process has this user interface undergone? * Is there a means of aggregating management and/or configuration with other related projects? * Does this project deliver its own administration along with the other components, or is this project an administration interface for other projects? * Are there any external (to Solaris) management interfaces to consider, or being consumed? No Projects that require or deliver administrative interfaces are often by their nature security components of the system and should likely address the security question (#5 above, with attention to RBAC and Audit). (See also appendix 2). This project delivers it's own administration through the beadm CLI. There are no external management interfaces used. No configuration is required and the only configuration we rely on is the ZFS boot dataset layout defined in PSARC case 2006/370 10. Have you reviewed the Policies and Best Practices? Are there any exceptions this project needs? See http://www.opensolaris.org/os/community/arc/policies/ http://www.opensolaris.org/os/community/arc/bestpractices/ Reviewed. No exceptions.