sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Removal of Sun Directory Server 5.1 from Solaris WOS Submitted by: Ludovic Poitou File: PSARC/2004/638/opinion.ms Date: October 6th, 2004 Committee: Gary Winiger, James Carlson, Joseph Kowalski, Bill Sommerfeld. Minority: Darren Moffat (WSARC), Glenn Skinner. Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com Identity Management PAC identity-management-pac@sun.com Java Enterprise System (JES, Orion) PAC jespac@sun.com 1. Summary This project proposed removal of PSARC/2001/101 "iPlanet Directory Services Integration project" (SunOne Directory Server (iDS) 5.1) as a bundled component of Solaris. In essence, without customer notice, the project proposes to rescind PSARC/2001/101, the initial request to be a bundled component and to follow an invalid release model that does not support upgrade from previous releases. In particular, the project proposed: o to remove iDS 5.1 from the Solaris install, o to abort Solaris upgrade from any previous release of Solaris that contains an active instance of iDS 5.1, o to require manual installation iDS 5.2.x from some other media onto the previous release of Solaris, o to require manual upgrade of the active directory server on the previous release of Solaris, o to go back to the original Solaris 10 upgrade media and upgrade to the new release of Solaris which will remove the previously bundled iDS 5.1. PSARC/2004/638 Copyright 2004 Sun Microsystems - 2 - 2. Decision & Precedence Information This project is specified in references [1], [2], [3], [4], and as modified by the required technical change listed in Appendix A below. This project is denied. This project may not integrate into any version of Solaris. The presently integrated version of iDS must continue to ship with Solaris as a fully supported product. The project proposed to depend on the following other pro- jects. WSARC/2002/184 iPlanet Directory Server 5.2 WSARC/2003/531 SunOne Directory Server 5.2.1 WSARC/2004/074 Directory Server : Auto upgrade mechan- ism WSARC/2004/553 Minor changes to Directory Server 5.2 for JES3 3. Interfaces The project proposed to export the following interfaces. _____________________________________________________________________________ | Interfaces Exported | |_________________________|___________________|_____________________________| |Interface | Classification | Comments | |_________________________|___________________|_____________________________| |/usr/sbin/directoryserver| Obsolete; Removed| PSARC/2001/101 Evolving | | | | interface; Removed | |directoryserver(1M) | Obsolete; Removed| man page; Removed | |/etc/init.d/directory | Obsolete; Removed| Evolving interface; Removed| |/usr/iplanet/ds5 | Obsolete; Removed| Consolidation Private* Exe-| | | | cutable files; Removed | |/usr/share/iplanet/ds5 | Obsolete; Removed| Consolidation Private Docu-| | | | mentation; Removed | |IPLTdscon | Obsolete; Removed| Package; Removed | |IPLTdsman | | | |IPLTdsr | | | |IPLTdsu | | | |/usr/iplanet/adminv5.0 | Obsolete; Removed| Consolidation Private; Exe-| | | | cutable files; Removed | |IPLTadcon | Obsolete; Removed| Package; Removed | |IPLTadman | | | |IPLTadmin | | | | | | | |_________________________|___________________|_____________________________| _________________________ * iPlanet Consolidation PSARC/2004/638 Copyright 2004 Sun Microsystems - 3 - _____________________________________________________________________________ | Interfaces Exported | |_________________________|___________________|_____________________________| |Interface | Classification | Comments | |_________________________|___________________|_____________________________| |/etc/iplanet/ds5 | Obsolete; Removed| Consolidation Private Con- | | | | figuration files; Removed | |/var/ds5 | Obsolete | Consolidation Private Data-| | | | bases | |_________________________|___________________|_____________________________| 4. Opinion Sun accepted the architectural responsibility for SunOne Directory Server (iDS) 5.1 as a core component of Solaris which includes rules for stability, notification of change, and upgrade when iDS was integrated into core Solaris. There is no valid release model (except for major releases) that does not support upgrade. At the last minute, this project requests architectural permission to break all these rules. The majority was not convinced that the project presented a compelling architectural reason to remove iDS from Solaris without customer notice. The majority was not convinced that the project did all that could be done to migrate from iDS 5.1 to iDS 5.2.x without breaking the expected Solaris upgrade experience. Consequently, this project is denied. The project could have acted within the well known Solaris rules. However, the project either choose or was told not to do so. 4.1. Aborting Upgrade As described in PSARC/1992/118 "4/93 Upgrade," Solaris com- ponents are required to support upgrade from previous ver- sions of Solaris through the use of the standard packaging ABI. This project does not do so. PSARC/1992/118 delivers mechanisms by which administrators may be informed of post- upgrade steps requiring manual intervention for components that cannot be automatically upgraded or are being obsoleted. This project does not use these components, instead, it aborts the upgrade. The committee found the proposed project behavior unacceptable in the light of the presence of these mechanisms. The history and goals of Solaris upgrade preclude the project team's desire to abort an upgrade due to a single Solaris component's incompatibil- ity with the resulting system. The committee felt the failure to upgrade would result in a much larger customer dissatisfier than proceeding with the upgrade, and providing migratory information to the user afterwards. Aborting upgrade in cases where the machine can never PSARC/2004/638 Copyright 2004 Sun Microsystems - 4 - support the new release (e.g., EOL hardware) has significant precedent. This case of aborting due to mere software con- figuration issues has no precedent. It is effectively an admission that Solaris cannot be upgraded, and that Solaris 10 is not a Minor release. 4.2. Multi-step Manual Upgrade Even if iDS 5.2.x were bundled with Solaris, the project team stated that a conventional upgrade from a previous release of Solaris would not be possible. Upgrade of the database from iDS 5.1 to iDS 5.2.x must be done manually with both versions present at the same time. WSARC/2003/531 "SunOne Directory Server 5.2.1" describes the need for both servers and the multi-step upgrade nature. The integration of the denied WSARC/2003/567 "Orion 1 use of NSS," without implementation of the possible relief measures described in that case is the cause. That intergration broke some iDS database formats. The committee inquired if iDS 5.2.x could recognize that the database format had changed, and if so convert the database. The project team said it could, but choose to require a manual upgrade rather than to automati- cally convert the database. Since iDS 5.2.x could recognize that the database format had changed, the members felt it should automatically convert database formats and eliminate the proposed multi-step manual upgrade. 4.3. Upgrade Requires Planning The project team claimed that upgrading systems with active directory servers tended to, by necessity, be very carefully planned events. Consequently, there would be a low proba- bility that these customers would find themselves subject to the pitfalls described in this opinion. Some members felt, while this may be true for some customers, it was not an acceptable reason to break the requirements of Solaris upgrade and customer notification. 4.4. Lack of Coherent Upgrade The upgrade installation process has no coherent way to do what the project team suggests. Even though the substantive upgrade difficulty was due to another project, the team asserts they were told not to fix the upgrade issues. Car- ried to its conclusion, this may lead to an untenable pros- pect for customers: attempt to upgrade, get error message saying X needs to be done first, do X, attempt to upgrade, get error message saying Y needs to be done first, do Y, attempt to upgrade, and so on. 4.5. Name Services Core to Solaris "The network is the computer" is the long standing architec- tural model of Solaris. As such, Solaris has a long history PSARC/2004/638 Copyright 2004 Sun Microsystems - 5 - of providing name services as core to this architectural model. Some members felt Solaris needed to be a complete system and wouldn't be without bundled fundamental network- ing components such as name services. In the proposed pro- ject, it was not clear to some members how the core Solaris customer who may wish to use ldap as a name service would know to get iDS 5.2.x if not delivered as a core Solaris component. 4.6. Lack of Customer Notification No customer notification of the removal of a stable Solaris component has been made. At the project inception review the project team was advised that if the team believed the project would go forward to immediately start the customer notification process so the largest set of customers would have the greatest notice time. As of the commitment review, no such notification process had been proposed or started. The committee asked for estimates of how many customers would be affected. The project team initially gave an order of magnitude estimate of a thousand. When questioned further, the project team was unable to substantiate that estimate and concluded they had no order of magnitude esti- mate of the iDS 5.1 customers. The team explained that iDS use could not be determined and that, in all likelihood, some but not all iDS 5.1 users will have already migrated to iDS 5.2.x. 4.7. Customer Notification at Upgrade For business rather than technical reasons, this project removes an Evolving interface of Solaris without notice to the customer and replaces it with an unbundled interface. The Solaris upgrade process is broken by this project. Cus- tomer notification only comes in the form of an aborted upgrade. The project proposes to have upgrade abort if iDS 5.1 use is detected and cause the customer to find other media an then to manually upgrade from the bundled iDS 5.1 to the unbundled iDS 5.2.x. The project team asserts this condition is no worse than keeping iDS 5.2.x bundled because of the manual upgrade as discussed above. The committee felt it was worse. 4.8. Requirement for Synchronized Delivery During the inception review, it was noted that removal of iDS from core Solaris would require synchronized delivery of iDS from other media. Such synchronized delivery was not planned. In fact, the project materials point out that iDS was going to release twice a year. The nominal plan for Solaris releases is four times a year. Thus it appears that removal of iDS will require additional testing and coordina- tion between product release schedules. PSARC/2004/638 Copyright 2004 Sun Microsystems - 6 - 4.9. Product Numbering Broken The project's assertion that iDS 5.1 is not upgradable to iDS 5.2.x point out the iDS 5.2.x is not a minor or micro/patch release of iDS, but rather a major release. In addition to failure to upgrade, this numbering also breaks the Solaris customers expectations for compatibility in minor and micro/patch releases. 4.10. Potential Impact on NIS+ Removal PSARC/2000/370 "EOL of NIS+" states: "Note: the approval of this case {PSARC/2000/370} does not authorize the actual removal of NIS+ support from Solaris. That removal will need to be the subject of another case. That case will depend on at least: PSARC/2000/311 NIS+/LDAP Migration PSARC/2000/363 Native LDAP phase II PSARC/2001/101 Bundling of LDAP Directory Server" Without a bundled LDAP directory server, the preconditions for the removal of NIS+ from Solaris are not met and NIS+ may not be removed from Solaris based on the approved archi- tectural decisions. 4.11. Potential Impact on Solaris Common Criteria (CC) Evaluation Additional investigation outside the project review meeting showed that with the demise of NIS+ as the name service com- ponent of the Solaris CC evaluation, the use of ldap as a name service was planned. The Solaris 10 evaluation project has not yet started; the impact may or may not be signifi- cant. 4.12. Other Paths That Could Be Pursued The committee believes that there are multiple paths that the project team could have pursued rather than the one pro- posed. These include: o to have iDS 5.2.x remain bundled, remove iDS 5.1 on upgrade, recognize the iDS 5.1 database format, and automatically convert it (this seems to have been the intent of the initial WSARC cases), o to have iDS 5.2.x remain bundled, not remove iDS 5.1 on upgrade, but require manual upgrade and removal of iDS 5.1 (this path requires some level PSARC/2004/638 Copyright 2004 Sun Microsystems - 7 - of support for iDS 5.1 on Solaris 10),** o to notify the upgrade customer that they must install iDS 5.2.x from other media, remove iDS 5.1 on upgrade, recognize the iDS 5.1 database format, and automatically convert it, o to have iDS 5.1 remain on the upgraded machine (Solaris 10) and function sufficiently for upgrade, to notify the upgrade customer that they must install iDS 5.2.x from other media, but require manual upgrade and removal of iDS 5.1. 5. Minority Opinion(s) The minority was swayed to approval by the project team's arguments noted above in section 4.3: Systems running name servers tend to be critically important to their owning organizations and, therefore, are not upgraded without care- ful planning. In particular, the minority is concerned by the removal of support for the server side of name services from core Solaris; this issue was almost enough to tip the balance toward rejection even for the minority. The scales remained tilted on the approval side only because of the company's efforts to synchronize delivery and availability of all its products on a coordinated schedule, so that cus- tomers desiring to run name servers can obtain the requisite software from Sun with minimal difficulty. The minority was swayed to approval by arguments that pro- ject team made that systems running name servers tend to be critically important to their owning organizations and, therefore, they are not upgraded without careful planning. Issues to be considered in any such upgrade include migrat- ing from one release to the next of both the underlying operating system and the name server software itself, but also include consideration of alterations to be made to the naming schema. It was the project team's contention that the requisite planning for a name service upgrade is sub- stantial enough that concurrently moving from a previous Solaris release to Solaris 10 in tandem with moving from iDS 5.1 to iDS 5.2.x would not seem burdensome. The minority has chosen to defer to the project team's domain expertise and accepts this claim. _________________________ ** At the inception review, the project team was advised that resources would need to be committed to iDS 5.1 testing on Solaris 10 because the team could not assume that this project would be accepted, or if accepted, would be accepted in time for the Solaris 10 release schedule. PSARC/2004/638 Copyright 2004 Sun Microsystems - 8 - In this vein, it is also worth noting that the upgrade scenario laid out in section 1 is the worst case scenario. One could avoid many of the pitfalls described there by choosing to install and migrate to iDS 5.2.x before upgrad- ing to Solaris 10. This consideration does underline the need for prompt notification to the community that will be faced with these migration issues, and the minority shares the majority's consternation that no attempt at such notifi- cation has as yet been made. In summary, it is only with considerable reservations that the minority voted to approve; the only saving grace was the belief that name service migration of necessity requires careful planning that can reasonably accommodate the sequencing that this proposal requires. 6. Advisory Information The majority of the members found the proposal to be unac- ceptable because it did not follow the standard Sun prac- tices both for upgrading of Solaris components and removing components from Solaris. Not only is no customer notice given, but also no equivalent core Solaris functionality is provided (this also impacts the potential future removal of NIS+). Furthermore, the proposed project did not provide an acceptable upgrade experience for existing iDS users. The upgrade experience described by this project is likely to be a substantial customer dissatisfier, generate customer calls, and fail to live up to Sun's espoused goals for cus- tomer "delight." The product approval committees are advised to immediately fund one of the paths discussed above and include that project in core Solaris. 6.1. Process Failed This project points out gross process failure at Sun. The denied WSARC/2003/567 "Orion 1 use of NSS" should not have been allowed to ship without corrective action of the pro- jects that relied upon it. This committee strongly advises the product approval committees to take immediate action to ensure ARC decision are enforced. Or, if overridden, that a full picture of the engineering and customer costs are accounted for. Such cost must include not only actual moni- tory costs to Sun, but also minimally loss of business, goodwill, and Sun product reputation. Additionally, the product release numbering was inconsistent with the release taxonomy by numbering a non-upgradable product with a minor release numbering. The committee strongly advises the pro- duct approval committees to ensure that products are upgrad- able, and if not upgradable, that all products are con- sistently numbered relative to their actual release taxon- omy. For example, iDS 5.2.x would be numbered iDS 6.x. PSARC/2004/638 Copyright 2004 Sun Microsystems - 9 - 6.2. Requirements for Acceptance The committee believes for approval this project must be modified to not significantly worsen the current Solaris upgrade experience. This minimally implies: o no pre-upgrade action is required o the additional interactions required by Solaris upgrade be limited to "please switch the CD/DVD" or similar statements o upon the completion of the upgrade, the system will have a functional directory service. If the directory server was enabled before, it should be enabled following the upgrade. That directory service could either be: + iDS 5.2.x - by implementing automatic data- base conversion (the preferred solution) + iDS 5.1 - requiring a manual transition to iDS 5.2.x 6.3. iDS not a smf(5) Service This project pointed out that iDS in particular, and Java Enterprise System (JES) in general, does not deliver as a PSARC/2002/547 "Greenline" (smf(5)) controlled service. The product approval committees are encouraged to fund a project or projects to have all Sun delivered services software be controlled by smf. 6.4. Impact on NIS+ Removal During the investigation of this case, it was discovered that PSARC/2000/370 "EOL of NIS+" requires that removal of NIS+ depend on a bundled LDAP directory server to provide similar scalable name service support. The product approval committees are advised to resolve this issue or re-enstate NIS+ support and possibly development. 6.5. Impact on Common Criteria Evaluation Solaris undergoes independent Common Criteria (CC) evalua- tions in order to sell into a number of large market seg- ments. These evaluations have been based on a scalable name service with various evaluatable security properties. The product approval committees are advised to ensure that no project is accepted that would have an adverse impact on the viability of Solaris evaluations. PSARC/2004/638 Copyright 2004 Sun Microsystems - 10 - 7. Appendices 7.1. Appendix A: Technical Changes Required 1. The case, as proposed, is unclear about the remo- val of iDS 5.1 upon upgrade. During review, the project team asserted that iDS 5.1 would not be supported upon upgrade. The case is unacceptable, however if it were to be accepted, the project is required to remove iDS 5.1 as part of Solaris upgrade. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2004/638. 1. PSARC 20 Questions File: commitment.materials/PSARC_2004_638_20Q.txt 2. Migration plan File: commitment.materials/migrateds.pdf 3. iDS 5.1 detection plan File: commitment.materials/DS51_detection.txt 4. Contract for iDS interfaces File: commitment.materials/2004_638_contract-01 PSARC/2004/638 Copyright 2004 Sun Microsystems