1. What specifically is the proposal that we are reviewing? - What is the technical content of the project? Network Automagic, Phase 0.5 "picea" -- a stop-gap effort before Phase 1 is ready. See picea-on-design.pdf and nwam-ui.html for technical project details. - Is this a new product, or a change to a pre-existing one? If it is a change, would you consider it a "major", "minor", or "micro" change? It's a Minor change in an existing project (NWAM) that has not yet been released with Solaris. - If your project is an evolution of a previous project, what changed from one version to another? This version has a completely redesigned GUI along with several minor features and bug fixes. - What is the motivation for it, in general as well as specific terms? (Note that not everyone on the ARC will be an expert in the area.) This project is a stop-gap effort. It is intended as a minimal set of repairs to the existing NWAM to make it more usable by more OpenSolaris participants. It's not intended to fix all NWAM problems. (Indeed, many problems reported as "NWAM" are in fact in other areas of the system.) It is intended to improve observability and provide some breathing room before Phase 1 (which will have substantially improved capabilities) is ready. - What are the expected benefits for Sun? - By what criteria will you judge its success? This should reduce the number of complaints about NWAM failing and improve our ability to diagnose other networking problems. 2. Describe how your project changes the user experience, upon installation and during normal operation. - What does the user perceive when the system is upgraded from a previous release? The new version does not use zenity pop-ups, and instead includes a GNOME GUI. 3. What is its plan? - What is its current status? Has a design review been done? Are there multiple delivery phases? This is one delivery (intended for OpenSolaris 2008.11) of a project that has multiple phases. Phase 0 was described in PSARC 2007/132. Phase 1 has not yet come to ARC review, but should be available soon. 4. Are there related projects in Sun? - If so, what is the proposal's relationship to their work? Which not-yet- delivered Sun (or non-Sun) projects (libraries, hardware, etc.) does this project depend upon? What other projects, if any, depend on this one? This is related to Phase 1 of NWAM. To the extent possible, the features and components designed for Phase 0.5 will be reused for Phase 1. That, however, is not a hard requirement: some of Phase 0.5 may be throw-away work. The hard requirements are meeting the next OpenSolaris delivery date and making the new GUI functional. - Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose? If not, please explain the areas of disagreement. This is entirely within NWAM and the desktop team; all participants approve. 5. How is the project delivered into the system? - Identify packages, directories, libraries, databases, etc. The new private libnwam.so.1 library (used by the GUI system) delivers through SUNWcslr, an existing package. The private interfaces shared with the desktop team from ON are built as internal (SUNWnwamintr and SUNWnwamintu) packages. These are not delivered to the WOS. The GNOME Netstatus Applet and Network Admin are existing utilities. The new NWAM Manager application will be packaged by the desktop team. (TBD) 6. Describe the project's hardware platform dependencies. - Explain any reasons why it would not work on both SPARC and Intel? N/A 7. System administration - How will the project's deliverables be installed and (re)configured? Package install. - How will the project's deliverables be uninstalled? pkgrm - Does it use inetd to start itself? No. - Does it need installation within any global system tables? No. - Does it use a naming service such as NIS, NIS+ or LDAP? Not directly. (Validation of user authorizations takes place through libsecdb, which can use those services.) - What are its on-going maintenance requirements (e.g. Keeping global tables up to date, trimming files)? None. - How does this project's administrative mechanisms fit into Sun's system administration strategies? E.g., how does it fit under the Solaris Management Console (SMC) and Web-Based Enterprise Management (WBEM), how does it make use of roles, authorizations and rights profiles? Additionally, how does it provide for administrative audit in support of the Solaris BSM configuration? A new authorization (solaris.network.autoconf) is defined, and this is added to the "Network Management" profile. See the design document for details. - What tunable parameters are exported? Can they be changed without rebooting the system? Examples include, but are not limited to, entries in /etc/system and ndd(8) parameters. What ranges are appropriate for each tunable? What are the commitment levels associated with each tunable (these are interfaces)? N/A 8. Reliability, Availability, Serviceability (RAS) - Does the project make any material improvement to RAS? Serviceability is improved by exposing internal NWAM state via a GUI. - How can users/administrators diagnose failures or determine operational state? (For example, how could a user tell the difference between a failure and very slow performance?) Use the GUI. - What are the project's effects on boot time requirements? None - How does the project handle dynamic reconfiguration (DR) events? Yes - What mechanisms are provided for continuous availability of service? N/A - Does the project call panic()? Explain why these panics cannot be avoided. No. - How are significant administrative or error conditions transmitted? SNMP traps? Email notification? Primarily syslog, but the GUI itself serves as an event notification mechanism as well. - How does the project deal with failure and recovery? Failure of the GUI causes nwamd to go into "automatic" mode, where all choices revert to defaults. This is similar to the existing nwamd behavior when zenity fails to contact the user, or the user kills the window. Failure of nwamd causes the API to return errors to the GUI, which should then report status to the user. - Does it ever require reboot? If so, explain why this situation cannot be avoided. No. - How does your project deal with network failures (including partition and re- integration)? How do you handle the failure of hardware that your project depends on? It switches between network interfaces on failure; this is existing nwamd behavior. - Can it save/restore or checkpoint and recover? Yes, it saves state in /etc/nwam/ for the known interfaces and wireless access points. - Can its files be corrupted by failures? Does it clean up any locks/files after crashes? The updates are atomic and should not result in corruption. If the files are somehow corrupt, "rm" will fix the problem. 9. Observability - Does the project export status, either via observable output (e.g., netstat) or via internal data structures (kstats)? A private door-based library sends events to a GUI. - How would a user or administrator tell that this subsystem is or is not behaving as anticipated? Observe the GUI status. - What statistics does the subsystem export, and by what mechanism? None. - What state information is logged? Significant error events are logged via syslog. Debug level events can also be enabled. All state changes are sent to the GUI for (optional) display. - In principle, would it be possible for a program to tune the activity of your project? Yes. 10. What are the security implications of this project? - What security issues do you address in your project? The nwamd daemon runs with privileges such that it can administer network interfaces. It takes commands from an unprivileged user, and uses chkauthattr(3SECDB) to make sure that the user has the authorization to change network configuration. - The Solaris BSM configuration carries a Common Criteria (CC) Controlled Access Protection Profile (CAPP) -- Orange Book C2 -- and a Role Based Access Control Protection Profile (RBAC) -- rating, does the addition of your project effect this rating? E.g., does it introduce interfaces that make access or privilege decisions that are not audited, does it introduce removable media support that is not managed by the allocate subsystem, does it provide administration mechanisms that are not audited? Beyond calling chkauthattr, no auditing is reported for any of the nwamd actions. Nwamd itself execs out to ifconfig to modify interface configuration. - Is system or subsystem security compromised in any way if your project's configuration files are corrupt or missing? No. - Please justify the introduction of any (all) new setuid executables. N/A - Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project. A separate Security Questionnaire http://sac.sfbay/cgi-bin/bp.cgi?NAME=Security.bp is provided for more detailed guidance on the necessary information. Cases are encouraged to fill out and include the Security questionnaire (leveraging references to existing documentation) in the case materials. Projects must highlight information for the following important areas: - What features are newly visible on the network and how are they protected from exploitation (e.g. unauthorized access, eavesdropping) - If the project makes decisions about which users, hosts, services, ... are allowed to access resources it manages, how is the requestor's identity determined and what data is used to determine if the access granted. Also how this data is protected from tampering. - What privileges beyond what a common user (e.g. 'noaccess') can perform does this project require and why those are necessary. - What parts of the project are active upon default install and how it can be turned off. TBD. 11. What is its UNIX operational environment: - Which Solaris release(s) does it run on? OpenSolaris - Environment variables? Exit status? Signals issued? Signals caught? (See signal(3HEAD).) N/A - Device drivers directly used (e.g. /dev/audio)? .rc/defaults or other resource/configuration files or databases? N/A - Does it use any "hidden" (filename begins with ".") or temp files? A door is created in /var/nwam/ - Does it use any locking files? No. - Command line or calling syntax: What options are supported? (please include man pages if available) Does it conform to getopt() parsing requirements? N/A - Is there support for standard forms, e.g. "-display" for X programs? Are these propagated to sub-environments? N/A - What shared libraries does it use? (Hint: if you have code use "ldd" and "dump -Lv")? libnwam.so.1 - Identify and justify the requirement for any static libraries. N/A - Does it depend on kernel features not provided in your packages and not in the default kernel (e.g. Berkeley compatibility package, /usr/ccs, /usr/ucblib, optional kernel loadable modules)? No. - Is your project 64-bit clean/ready? If not, are there any architectural reasons why it would not work in a 64-bit environment? Does it interoperate with 64-bit versions? Yes - Does the project depend on particular versions of supporting software (especially Java virtual machines)? If so, do you deliver a private copy? What happens if a conflicting or incompatible version is already or subsequently installed on the system? No. - Is the project internationalized and localized? TBD (GUI issue, not nwamd) - Is the project compatible with IPV6 interfaces and addresses? Yes 12. What is its window/desktop operational environment? - Is it ICCCM compliant (ICCCM is the standard protocol for interacting with window managers)? N/A - X properties: Which ones does it depend on? Which ones does it export, and what are their types? N/A - Describe your project's support for User Interface facilities including Help, Undo, Cut/Paste, Drag and Drop, Props, Find, Stop? N/A - How do you respond to property change notification and ICCCM client messages (e.g. Do you respond to "save workspace")? N/A - Which window-system toolkit/desktop does your project depend on? GNOME - Can it execute remotely? Is the user aware that the tool is executing remotely? Does it matter? It could. - Which X extensions does it use (e.g. SHM, DGA, Multi-Buffering? (Hint: use "xdpyinfo") N/A - How does it use colormap entries? Can you share them? N/A - Does it handle 24-bit operation? Yes. 13. What interfaces does your project import and export? Interfaces Exported Interface Classification Comments NWAM Manager Uncommitted New control/status GUI libnwam.so.1 Contr. Project Private Wrapper library for GUI SUNWnwamintr, Contr. Project Private Internal-only packages SUNWnwamintu libnwam.h Contr. Project Private Library header file /var/nwam/door Project Private "priority" Uncommitted New /etc/nwam/llp keyword - Exported public library APIs and ABIs Protocols (public or private) Drag and Drop ToolTalk Cut/Paste N/A - Other interfaces N/A - What other applications should it interoperate with? How will it do so? N/A - Is it "pipeable"? How does it use stdin, stdout, stderr? No. - Explain the significant file formats, names, syntax, and semantics. Existing files (/etc/nwam/llp and /etc/nwam/known_wifi_nets) have a simple text line-oriented format. - Is there a public namespace? (Can third parties create names in your namespace?) How is this administered? No. - Are the externally visible interfaces documented clearly enough for a non-Sun client to use them successfully? No; they're intentionally private. 14. What are its other significant internal interfaces inter-subsystem and inter-invocation)? - Protocols (public or private) - Private ToolTalk usage - Files - Other - Are the interfaces re-entrant? libnwam.so.1 uses a door-based communication mechanism, described in the design document. 15. Is the interface extensible? How will the interface evolve? - How is versioning handled? libnwam.so.1 and the door protocol are delivered together. libnwam.so.1 and the GUI are dependent on each other and must be delivered as one. - What was the commitment level of the previous version? - Can this version co-exist with existing standards and with earlier and later versions or with alternative implementations (perhaps by other vendors)? - What are the clients over which a change should be managed? - How is transition to a new version to be accomplished? What are the consequences to ISV's and their customers? N/A 16. How do the interfaces adapt to a changing world? - What is its relationship with (or difficulties with) multimedia? 3D desktops? Nomadic computers? Storage-less clients? A networked file system model (i.e., a network-wide file manager)? N/A 17. Interoperability - If applicable, explain your project's interoperability with the other major implementations in the industry. In particular, does it interoperate with Microsoft's implementation, if one exists? - What would be different about installing your project in a heterogeneous site instead of a homogeneous one (such as Sun)? - Does your project assume that a Solaris-based system must be in control of the primary administrative node? N/A 18. Performance - How will the project contribute (positively or negatively) to "system load" and "perceived performance"? - What are the performance goals of the project? How were they evaluated? What is the test or reference platform? - Does the application pause for significant amounts of time? Can the user interact with the application while it is performing long-duration tasks? - What is your project's MT model? How does it use threads internally? How does it expect its client to use threads? If it uses callbacks, can the called entity create a thread and recursively call back? - What is the impact on overall system performance? What is the average working set of this component? How much of this is shared/sharable by other apps? - Does this application "wake up" periodically? How often and under what conditions? What is the working set associated with this behavior? - Will it require large files/databases (for example, new fonts)? - Do files, databases or heap space tend to grow with time/load? What mechanisms does the user have to use to control this? What happens to performance/system load? N/A 19. Please identify any issues that you would like the ARC to address. - Interface classification, deviations from standards, architectural conflicts, release constraints... - Are there issues or related projects that the ARC should advise the appropriate steering committees? This project is just a stop-gap effort. As a fast-track, it would be surprising to see issues about multiple active interfaces, integration with other Solaris technologies (such as filtering and IPMP), and so forth ignored. Furthermore, it's likely that Phase 1 will be substantially different in several areas. This effort is intended to ease some of the existing problems, but it does risk some chance of future pain when the full solution (Phase 1) is delivered, because we are intentionally not guaranteeing at this point that we'll keep strict compatibility. We're running this as a full case in order to allow for any needed discussion on this tactic. 20. Appendices to include - One-Pager. - Prototype specification. - References to other documents. (Place copies in case directory.)