PSARC Questions Version 1.17 Here is a comprehensive list of questions that ARC members may ask of project presenters. Providing this information in advance of your review will greatly simplify the ARC's process of identifying the critical information relevant to your project. It is expected that many of these issues may be unresolved at the time of an inception review. However, they should be answerable at commitment review, and may be addressed at inception if significant. Please make your answers concise! Most if not all of these questions will be addressed in related documents such as 1-pagers, specs, design documents, etc. There is no reason to duplicate effort, and "see section 3.2 in the design spec" is an excellent answer. Of course, the referenced material must be provided with your submission. Entire sets of questions may be N/A for your project. For example, device drivers rarely have GUIs, and so the entire GUI section can just be deleted. In such cases, PLEASE NOTE N/A FOR THE MAIN QUESTION, AND DELETE THE REST OF THAT QUESTION SET. This questionnaire is meant to provide the ARC with an overview of your project, and it touches on the main areas of architectural interest. This template will be revised based on its users' experiences; your comments and suggestions are welcome. Send them to john.plocher@sun.com. For advice about architectural choices, pointers to various SAC guidelines, and other project considerations including Licensing and Patents, see http://sac.sfbay/arc/ARC-Considerations.html ------------------------------------------------------------------------ 1. What specifically is the proposal that we are reviewing? - What is the technical content of the project? A: NDMP project covers the implementation of Network Data Management Porotocol service on Solaris which is primarily used for network-based management of the data backup. This project will support versions 2, 3 and 4 of the NDMP protocol. NDMP runs as a user-space program on Solaris and interfaces with the filesystem and secondary storage devices such as tapes and SCSI robots. - 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? A: NDMP is ported from Sun's non-Solaris NAS to Solaris. The change can be considered micro. - If your project is an evolution of a previous project, what changed from one version to another? A: this is an evolution of Sun XXXXXXXXXXX NAS operating system's NDMP service implementation. - 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.) A: To include NDMP support for Solaris. NDMP support would enable Solaris to participate in a centralized or distributed NDMP infrastructure, with support of various backup and restore polices and roles. - What are the expected benefits for Sun? A: Customers with existing NDMP infrastructure would be potential customers for this project. NDMP can be seen on the NAS market checklist very often. - By what criteria will you judge its success? A: By providing ability to backup and restore files using NDMP. NDMP in other non-Solaris NAS products has shown a good success. 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? A: A new NDMP service will be added which after configuration, user can use other NDMP backup solution providers software to run backup on Solaris. 3. What is its plan? - What is its current status? Has a design review been done? Are there multiple delivery phases? A: The project is almost complete now and at the integration phase. The design review has been done by the team engineers. There would be a single delivery phase for the project. 4. Are there related projects in Sun? A: As of now, there is no other 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? - 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. 5. How is the project delivered into the system? - Identify packages, directories, libraries, databases, etc. A: The packages are SUNWndmpu and SUNWndmpr which contain the main binary of the server and contains some manifest files for SMF and a man page. 6. Describe the project's hardware platform dependencies. - Explain any reasons why it would not work on both SPARC and Intel? A: There is no dependency to the underlying hardware. Multi-processor and endian adaptiveness constraints had been considered inside the project. 7. System administration - How will the project's deliverables be installed and (re)configured? A: NDMP is installed as a package by: pkgadd -d . SUNWndmpu pkgadd -d . SUNWndmpr It can be configured using SMF setup: svcadm enable ndmpd Then the server will come up and ready to go. - How will the project's deliverables be uninstalled? A: NDMP is uninstalled by: svcadm disable ndmp pkgrm SUNWndmpr pkgrm SUNWndmpu - Does it use inetd to start itself? A: It can be started manually by commanline: ndmpd or by SMF as described above. Refer to the manpage for manual startup options. - Does it need installation within any global system tables? A: That would be done by svccfg or rebooting the server after installation for SMF database update. - Does it use a naming service such as NIS, NIS+ or LDAP? A: No. - What are its on-going maintenance requirements (e.g. Keeping global tables up to date, trimming files)? A: No special maintenance is necessary. - 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: NDMP provides a CLI tools that is a user command that provides administration interface for the NDMP service. It also can be administered by updating the SMF properties defined in ndmp_design.pdf. - 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)? A: the parameters include: listening port number, log file path, active version number, debug mode and some backup specific options such as direct restore mode, etc. No reboot will be necessary but the service needs to be restarted: svcadm restart ndmp 8. Reliability, Availability, Serviceability (RAS) - Does the project make any material improvement to RAS? A: No. - 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?) A: Users and adminstrators will use third-party NDMP client applications which they would report problems and failures promptly back to the user. - What are the project's effects on boot time requirements? A: No requirements. - How does the project handle dynamic reconfiguration (DR) events? A: N/A. - What mechanisms are provided for continuous availability of service? A: The service is handle by SMF and if it fails due to hardware problems, normally SMF will retry to bring up the service. If the backup operation fails due to any reason, it has to be restarted again. - Does the project call panic()? Explain why these panics cannot be avoided. A: No panics are possible, the project runs as a user-space process. - How are significant administrative or error conditions transmitted? SNMP traps? Email notification? A: NDMP has its own logging mechanism which directly sends the errors to the third-party NDMP client program. - How does the project deal with failure and recovery? A: There is no failure recovery phase. If the backup fails in the middle it has to be started over. But if there is problem in the service, SMF maintenance mode and service logs will indicate that. - Does it ever require reboot? If so, explain why this situation cannot be avoided. A: No reboots necessary unless needed for attaching and configuring new hardware to Solaris. - 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? A: It uses TCP so it should be reliable. The hardware failure in tape library and secondary storages need separate handling and cannot be handled from NDMP. - Can it save/restore or checkpoint and recover? A: No state/checkpoint is kept during the backup. However there is a Restartable Backup Extension that can be added to NDMP for that reason. - Can its files be corrupted by failures? Does it clean up any locks/files after crashes? A: The corruption can happen on the tape which will not be an issue if the backup is restarted. Proper clean up is done per crash. 9. Observability - Does the project export status, either via observable output (e.g., netstat) or via internal data structures (kstats)? A: NDMP log can be enabled which gives detailed debugging information. Other status can be obtained from the third-party NDMP client. - How would a user or administrator tell that this subsystem is or is not behaving as anticipated? A: The behavior is observed from the third-party NDMP client. - What statistics does the subsystem export, and by what mechanism? A: The statistics and details, e.g. number of files/bytes backed up, is gathered by the third-party NDMP client which is sent to that client using NDMP protocol. - What state information is logged? A: The logs are kept on the NDMP client and consists of the timestamps of backup started/finished, the number of files and bytes backed up, and the error codes. - In principle, would it be possible for a program to tune the activity of your project? A: NDMP activity can be tunable via configuration setup and NDMP environment variables passed from NDMP client to the server. 10. What are the security implications of this project? - What security issues do you address in your project? A: Proper rights profiles are added for managing the service. The service properties are kept in SMF database which requires authorization to be accessed. The service access through the network is also limited to client-server authentication which is done using CRAM-MD5 digest method. - 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? A: No. - Is system or subsystem security compromised in any way if your project's configuration files are corrupt or missing? A: Corrupted or missing configuration couldnt cause any security issues. - Please justify the introduction of any (all) new setuid executables. A: None. - 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. A: A new TCP port (10000 by default) needs to be open for NDMP incoming connection. User authentication with encrypted password is done by the server. 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) A: A new TCP port, authentication is necessary before using it. - 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. A: An admin user and password should be provided by the requestor, CRAM-MD5 could be used to protect it from tampering. - What privileges beyond what a common user (e.g. 'noaccess') can perform does this project require and why those are necessary. A: It needs high privilege in order to have read/write/search access to the files for taking backup or restoring the data to the disk. So namely it would be PRIV_FILE_DAC_READ, PRIV_FILE_DAC_WRITE and PRIV_FILE_DAC_SEARCH, refer to ndmp_rbac.txt for the full list of privileges. - What parts of the project are active upon default install and how it can be turned off. A: Upon install, the default password for client access to the service is set to null, indicating that no accesses will be granted. The administrator user has to define a non-null password which is saved in SMF database as a secure property (PSARC 2007/177). Only after that the service could be used and the clients authenticated if they provide the right password. The text-mode password option is always available per protocol specification However this option can be turned off on installation and then turned on later if the user wants to use this option. 11. What is its UNIX operational environment: - Which Solaris release(s) does it run on? A: Solaris 5.11. - Environment variables? Exit status? Signals issued? Signals caught? (See signal(3HEAD).) A: Ignores terminal stop signals and sigpipe, no exit status, no signals issued or caught. - Device drivers directly used (e.g. /dev/audio)? .rc/defaults or other resource/configuration files or databases? A: /dev/rmt /dev/scsi/changer - Does it use any "hidden" (filename begins with ".") or temp files? A: No. - Does it use any locking files? A: No. - Command line or calling syntax: What options are supported? (please include man pages if available) Does it conform to getopt() parsing requirements? A: Usage: ndmpd [-nqr] [-v version] [-p port] [-l dbg-level] [-P dbg-path] -n do not run as a daemon -q quiet mode -r Enable DAR mode (default disabled) -v set the maximum version number (2, 3 or 4) -p override the default port number (default 10000) -l debugging mode, log file will be created (default off) -P the path where the log file is created (default /var/ndmp) Complete man page is attached. It conforms to getopt() requirements. - Is there support for standard forms, e.g. "-display" for X programs? Are these propagated to sub-environments? A: No. - What shared libraries does it use? (Hint: if you have code use "ldd" and "dump -Lv")? A: /lib/libsocket.so.1 /lib/libnsl.so.1 /lib/libpthread.so.1 /lib/libzfs.so.1 /lib/libc.so.1 /lib/libmp.so.2 /lib/libmd.so.1 /lib/libscf.so.1 /lib/libm.so.2 /lib/libdevinfo.so.1 /lib/libdevid.so.1 /lib/libgen.so.1 /lib/libnvpair.so.1 /lib/libuutil.so.1 /lib/libsec.so.1 /lib/libavl.so.1 - Identify and justify the requirement for any static libraries. A: There is none. - 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)? A: 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? A: It is 64-bit clean and ready. - 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? A: No dependency on a particular software. - Is the project internationalized and localized? A: No internationalization identified. - Is the project compatible with IPV6 interfaces and addresses? A: The code is IPV6-ready but the NDMP protocol itself, has some dependencies on IPV4. So until the protocol is revised we can't support it. 12. What is its window/desktop operational environment? - Is it ICCCM compliant (ICCCM is the standard protocol for interacting with window managers)? A: The interface is provided by a third-party application. - X properties: Which ones does it depend on? Which ones does it export, and what are their types? A: None. - Describe your project's support for User Interface facilities including Help, Undo, Cut/Paste, Drag and Drop, Props, Find, Stop? A: None. - How do you respond to property change notification and ICCCM client messages (e.g. Do you respond to "save workspace")? A: N/A. No. - Which window-system toolkit/desktop does your project depend on? A: None. - Can it execute remotely? Is the user aware that the tool is executing remotely? Does it matter? A: All the connections are made from remote and controlled by a third-party application. - Which X extensions does it use (e.g. SHM, DGA, Multi-Buffering? (Hint: use "xdpyinfo") A: None. - How does it use colormap entries? Can you share them? A: None. N/A. - Does it handle 24-bit operation? A: N/A. 13. What interfaces does your project import and export? - Please provide a table of imported and exported interfaces, including stability levels. Pay close attention to the classification of these interfaces in the Interface Taxonomy -- e.g., "Committed," "Uncommitted," and "*Private;" see: http://sac.sfbay/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp Use the following format: Interfaces Imported Interface Classification Comments The_referring_standard Committed ANSI Xy.Tz 1999 draft 37 Somebody_else () Consolidation Private Interfaces Exported Interface Classification Comments My_subroutine_name Committed MY_MACRO Project Private Etc, etc, etc... A: Refer to NDMP design document (ndmpd_design.pdf) Section 4 for interfaces. - Exported public library APIs and ABIs Protocols (public or private) Drag and Drop ToolTalk Cut/Paste A: None. - Other interfaces A: None. - What other applications should it interoperate with? How will it do so? A: Uses NDMP protocol to work with NDMP client/server applications such as NBU (Symantec), Tivoli (IBM), EBS (Legato), Netvault (Bakbone), Brightstor (CA). - Is it "pipeable"? How does it use stdin, stdout, stderr? A: No piping. No stdin. Stdout/stderr is used for print outs. - Explain the significant file formats, names, syntax, and semantics. A: No significant file format. - Is there a public namespace? (Can third parties create names in your namespace?) How is this administered? A: No namespace is maintained. - Are the externally visible interfaces documented clearly enough for a non-Sun client to use them successfully? A: NDMP protocol is documented and interfaces are based on the protocol. 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? A: No significant internal interface is being used. 15. Is the interface extensible? How will the interface evolve? A: The main interface would be NDMP protocol which for that versioning is provided. The version detection and changes are all defined in detail by the protocol. Details are provided in the attached NDMPv4 protocol document. Other interfaces such as the NDMP library are extensible but not versioned. - How is versioning handled? A: NDMP versions are started from 2, 3 and 4. - What was the commitment level of the previous version? A: version 3. - Can this version co-exist with existing standards and with earlier and later versions or with alternative implementations (perhaps by other vendors)? A: Yes all versions support can coexist. - What are the clients over which a change should be managed? A: NDMP clients and the change is applied by the protocol. - How is transition to a new version to be accomplished? What are the consequences to ISV's and their customers? A: The new features in the protocol should be followed for the upgrade. ISV needs to certify the changes and versions with other customers product. 16. How do the interfaces adapt to a changing world? A: It follows the protocol version of NDMP. - 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)? A: It is used in a NAS for network-wide file management. 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? A: It can interoperate with other hardware/software platforms as long as the NDMP protocol is used for the connection. Yes most of the implementations are Microsoft based and they operate with the NDMP server. - What would be different about installing your project in a heterogeneous site instead of a homogeneous one (such as Sun)? A: No effect as NDMP is high in application layer and independent of the underlying platform. - Does your project assume that a Solaris-based system must be in control of the primary administrative node? A: Primary setup should be done either by an administrative node or directly on the host. 18. Performance - How will the project contribute (positively or negatively) to "system load" and "perceived performance"? A: When running, the effect on performance is similar to running tar command. Backup work is usually activated during low utilization period. - What are the performance goals of the project? How were they evaluated? What is the test or reference platform? A: Performance goals for backup should be close to the performance of the secondary storages. For LTO-2 it would be around 30MB/s and for LTO-3 60MB/s is the upper bound. - Does the application pause for significant amounts of time? Can the user interact with the application while it is performing long-duration tasks? A: Backup of a disk containing more than couple of terabytes can take hours. The user can abort the backup at any time. Changing the tapes also and tape rewind can be time consuming. - 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? A: Uses P-threads and it uses call backs. Call backs dont create any threads. - 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? A: Impact on overal system performance is low. Average working set is dependent on the data size. For example for a 1 TB data it would take about 10 hours. - Does this application "wake up" periodically? How often and under what conditions? What is the working set associated with this behavior? A: No waking up. The NDMP client can remotely schedule periodic backups but the "wake up" would happen on another system. - Will it require large files/databases (for example, new fonts)? A: If debugging is enabled, it could create a large text file. Debugging is disabled by default and if it is enabled, it will disable across the boots. - 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? A: No. 19. Please identify any issues that you would like the ARC to address. - Interface classification, deviations from standards, architectural conflicts, release constraints... A: NDMP is a very high level protocol and runs as a user-space application. The interfaces to the system are very general and independent of any special features. - Are there issues or related projects that the ARC should advise the appropriate steering committees? A: No specific issues. 20. Appendices to include - One-Pager. - Prototype specification. - References to other documents. (Place copies in case directory.)