PSARC Questions Version 1.22 Approved Oct. 2008 (PSARC/2008/625) The 20 questions outline serves several purposes. One is to present to the ARC in a uniform manner pertinent information about any case. Many of the answers to these questions can be direct and specific references to other case materials (although care must be taken to keep the references current). A second purpose is to allow an ARC member to get a concise overview of the case in an efficient manner. Another purpose is that the 20 questions should provoke thought and questions for project teams unfamiliar with the ARC process, by asking questions about aspects of the project that need be considered. Lastly, the 20 questions serves as a vehicle between the case owner and the project team as an indicator of preparedness. The 20 questions, as do other ARC materials, remain as documentation of the case plan of record. 1. What is the proposal being presented for review? * Give an overview of the project and its phase(s). This project improves over the existing network interface configuration tools and provides a new command line utility, ipadm(1M) that can do * interface management (plumb/unplumb) * address management (add/delete/show addresses) * property management (set/get/reset NDD tunables persistently) * address/property persistence See section 2 of [1] and section 1 of [2] for more information on project. Section 3.1 of [1] defines the technical scope of the first phase. As described in [1], we are going to do phased delivery of features. See section 3 of [1] for more information on various components (phases) of this project. In the first phase, tracked by PSARC 2009/306, we will deliver the tool /sbin/ipadm (1M) and Consolidation private library libipadm.so. * Describe the exposure (OpenSolaris), scope and type of review desired (overview, full case, etc.) This is an umbrella case, with initial phase of the project tracked by PSARC 2009/306. The subsequent components of the project will be raised in future cases with this case as a back drop. Further this is a full case with open exposure. All development related to it is open. * Indicate the release binding requested by the project team. See: http://www.opensolaris.org/os/community/arc/policies/release-taxonomy/ The project team requests Minor release binding. No back-port is intended or expected. * What are the project's deliverables? These are a new command-line network utility (/sbin/ipadm(1M)), a consolidation private dynamic shared object (libipadm) and a private data repository (/etc/ipadm/ipadm.conf) * How does this project align with existing or proposed ARC cases? This project consolidates all the networking configuration into one library, in order to avoid code duplication and provide better maintainability. So, various network configuration tools like NWAM, pppd, Sun Cluster, IPMP, et al, would use the deliverables of this project. 2. Describe user interactions. * Are new user interfaces being proposed, or existing interfaces being changed? New command /sbin/ipadm is added and it does not change any existing interfaces * Explain the similarities in proposed interfaces with existing OS user interfaces (Solaris, Linux, Windows, etc.). The proposed interface, which provides persistent network configuration is new and does not have equivalent counterparts in other OS'es. They achieve the proposed interfaces very crudely in a non-elegant manner. On Linux and BSD, persistent configuration settings are applied by editing system files. The proposed change will make the persistence mechanism transparent to the user. This makes the mechanism (and interfaces) consistent with other administrative tools like dladm, and also paves the way for future projects that provide networking services through SMF. The improved interfaces, and transparent persistence would be a value-add feature for Solaris in comparison with other Operating Systems. Provision of clean interfaces for obtaining interface/address status will aid application portability of networking apps like routing daemons. * Are there any install time changes? Not in the first phase of the project. However in a future phase, a transition tool will be provided to convert existing persistence mechansim like /etc/hostname.intf 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/ Exported --------- Please see section 4 of [1] Imported --------- Interface Stability Comments --------- --------- -------- Socket IOCTL's (SIOC[G|S]*) committed man -s 7P if_tcp 4. Describe any dependencies on hardware (e.g. SPARC exclusive), and on other projects within Solaris. No hardware dependencies. No project dependencies as such. But we are planning this with 'Clearview IP tunnel' cleanup of ifconfig tunnel commands in mind. 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? changes to exec_attr: --------------------- We need to provide 'file_dac_write' privilege to 'ipadm' command along with 'sys_ip_config and proc_audit'. So in /etc/security/exec_attr we should have a line like this for 'ipadm' Network Management:solaris:cmd:::/sbin/ipadm:euid=ipadm;egid=sys; privs=sys_ip_config,proc_audit,file_dac_write. This should allow 'write' access to the db store 'ipadm.conf (owned by user ipadm)', from within the library, irrespective of any user with right authorization executing 'ipadm'. Further whoever links to libipadm.so.1 library should provide this privilege for that utility or daemon. changes to auth_attr: --------------------- No existing authorization seem to suffice. So a new authorization would have to be defined. This authorization then need to be added to Network Management profile, which is by default assigned to 'root' role. 6. Describe means of observing project functionality and performance, by an end user or by a system administrator. Project functionality information is available via following ipadm subcommands * ipadm show-if * ipadm show-addr * ipadm show-dhcp * ipadm show=v6addr * ipadm show-prop * ipadm show-ifprop * ipadm show-addrprop For more information on each subcommand, please refer [2]. 7. How does the project deal with faults and interruptions? Initialization and restarting? In principle, on faults and interruptions, we should return the system back to what it was before the execution of the command. In the case of ipadm, appropriate error message will be displayed to the end user. The project team will take all the efforts to make the error messages clear, precise and succinct. In the case of library API's appropriate error message will be returned to the caller. Any consumer who makes call into library, should first get a library handle using ipadm_open() and once the work is done they should close the handle using ipadm_close(). This handle will hold socket descriptors, interface name and other implementation specific flags. On system initialization, a new process netstart(1M) will reapply all the module (ip/udp/tcp/sctp) tunnables using API's defined in libipadm. Then the network-physical script using 'ipadm up-if' will resurrect the interface, it's addresses and properties. On failure, error message will be printed to stderr and system will continue to boot. Nothing special needs to be done during system restart. 8. How does the project interact with Solaris virtualization technologies (xVM, LDOMs, zones, Branded zones, SunCluster, etc.)? In principle, this technology should work from within xVM and LDOMs. There are no known impediments to use within a SunCluster environment for this component. The project team will work with the SunCluster team to make sure the two technologies are sufficiently tested (CR 6843030). This can be used on systems with non-global zones installed as well as in non-global zones themselves. 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? The new /sbin/ipadm(1M) will be used. The subcommands provided by ipadm has been extensively reviewed on opensolaris. * Is there a means of aggregating management and/or configuration with other related projects? No. * Does this project deliver its own administration along with the other components, or is this project an administration interface for other projects? Yes, it provides a new administrative interface to configure network interfaces. * 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). 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/ After reviewing the Policies and Best Practices, no exceptions are required for this project. References (enclosed in case directory) --------------------------------------- [1] Brussels II umbrella case document - brussels2_umbrella.txt [2] "Brussels II - ipadm and libipadm" design document - brussels2_design.pdf [3] one-pager http://arc.opensolaris.org/caselog/PSARC/2009/306/20090515_girish.moodalbail.2