From gww@sac.sfbay.sun.com Mon Oct 5 16:45:14 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n95NjDJ5011333 for ; Mon, 5 Oct 2009 16:45:14 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n95NjDTe054444; Mon, 5 Oct 2009 17:45:13 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR200B01FBDRK00@brm-avmta-1.central.sun.com>; Mon, 05 Oct 2009 17:45:13 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR2002BVFBCX640@brm-avmta-1.central.sun.com>; Mon, 05 Oct 2009 17:45:13 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n95NjC9e025656; Mon, 05 Oct 2009 16:45:12 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n95NjB7a011328; Mon, 05 Oct 2009 16:45:11 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n95NjBvv011324; Mon, 05 Oct 2009 16:45:11 -0700 (PDT) Date: Mon, 05 Oct 2009 16:45:11 -0700 (PDT) From: Gary Winiger Subject: Removal of NIS+ [PSARC/2009/530 FastTrack timeout 10/12/2009] To: psarc-ext@sun.com Cc: nisplus-core@sun.com, rajagolal.andra@sun.com Message-id: <200910052345.n95NjBvv011324@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 7457 I'm sponsoring this Fast Track for Raja Gopal Andra, the RPE naming team, and the NIS+ core team. It requests removal of all the NIS+ related interfaces and documentation in a Minor Release. While this is somewhat long, the case owner and project team believe it still qualifies for a Fast Track as the length details the how the EOL required dependences are satisfied. This project is unrelated to pam_ldap(5) and has no effect on it or the Sun Java System Directory Server. The current NIS+(1) man page and redacted opinions for PSARC/2000/370 (EOL of NIS+) and PSARC/2004/638 (Removal of Sun Directory Server 5.1 from Solaris WOS) are in the case directory. The timer is set for 12 Oct., 2009. Gary.. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Background: ========== NIS+(1) seems to have been introduced prior to the recording of PSARC cases in 1991. The first references I've found are Vikul Khosla's nisaddcred flag (PSARC/1992/187) and Chuck McManis' NIS+ diagnostics (PSARC/1992/188) cases. They refer to NIS+, but not to any previous cases, though ZNS demos (PSARC/1991/023) seems somehow related. The NIS+ promise never achieved sufficient traction to supplant NIS (nee YP). X500 directory servers and the Lightweight Directory Access Protocol (LDAP) have supplanted the promise of NIS+. EOL of NIS+ (PSARC/2000/370) started the process leading to this case. Dependences: =========== o PSARC/2000/370 (EOL of NIS+) opinion states: 2. Decision & Precedence Information . . . Note: the approval of this case 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 LSARC/2001/101 Bundling of LDAP Directory Server {actually PSARC/2001/101 -gww} 4. Opinion The main issue raised for this case was that of providing adequate notice and support to existing NIS+ users. The requirement to announce the upcoming EOL of NIS+ as soon as possible in order to head off new adoption of the technology was seen as conflicting with the requirement not to panic existing users. The committee decided that a three step schedule: 1. adequate notice 2. availability of all replacement technology 3. actual EOL would satisfy both requirements and imposed technical changes needed to obtain such a schedule. See [2] for opposing views. {[2] Email discussion. File: mail} o PSARC/2004/638 (Removal of Sun Directory Server 5.1 from Solaris WOS) was denied. The denial was overturned on appeal and iDS was removed from the Solaris WOS. That removal impacts the removal of NIS+ as the opinion states: 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. Details: ======= * PSARC/2000/311 NIS+/LDAP Migration and PSARC/2000/363 Native LDAP phase II have both been delivered since Solaris 9. * 1) adequate notice The announcement of the EOL of NIS+ has been completed since Solaris 9 The current (S10u8) NIS+ man pages contain the note: NIS+ might not be supported in future releases of the Solaris operating system. Tools to aid the migration from NIS+ to LDAP are available in the current Solaris release. For more information, visit http://www.sun.com/directory/nisplus/transition.html. * 2) availability of all replacement technology With the integration of PSARC/2008/745 nss_ldap shadowAccount support in the current development release and the back port to S10u8, all the functionality that was provided by NIS+ is now available using a LDAP directory server as a name service (i.e., nsswitch.conf configuration such as shown in the delivered sample nsswitch.ldap). * With the permission to remove the bundled LDAP Directory Server by the approval upon appeal of PSARC/2004/638, the conditions of PSARC/2000/370 are not met by the Solaris "letter of the law". The "traditional" Solaris view of what is bundled software appears to be changing with the next Minor release's introduction of the "OpenSolaris" distribution and "Solaris Next" "marketing release". The project team believes that OpenLDAP for OpenSolaris (PSARC/2008/507) and/or Sun OpenDS (LSARC/2008/372) meet the "intent of the law" as written in PSARC/2000/370 for having a "Bundled" LDAP Directory Server. They are "distributed" with OpenSolaris/Solaris Next. The project team has verified that both OpenLDAP and OpenDS support at least all the name service databases and attributes supported by NIS+. (As does the "unbundled" Sun Java System Directory Server.) Proposal: ======== As all the requirements outlined in PSARC/2000/370 have been met, remove all the NIS+ related interfaces and documentation in the a Minor release. (PSARC/2000/370 details the user and administrative commands, RPC services, and Programming API to be removed.) Issues: ====== Conversion of an existing NIS+ server's Tables to LDAP needs to be completed on a system that supports NIS+. Once NIS+ has been removed. conversion using the processes described in "Transitioning From NIS+ to LDAP" (http://docs.sun.com/app/docs/doc/817-2655/6mia7mum5?a=view) isn't available. To mitigate this, the project team notes that the announcement was made in Solaris 9 and the project will ensure that the installation documentation of the Minor release that removes NIS+ will clearly state that the conversion must take place before installation. The project team proposes adding to the Solaris Next System Administration Guide a section similar to: Transitioning from NIS+ to LDAP on Solaris Next: An existing Solaris 9 or 10 NIS+ Server and Client system must be available for the Transition. 1. On a system, install Solaris Next (or Solaris 9 or Solaris 10) with the desired Directory server. 2. Configure the Directory server as documented in System admin guide http://docs.sun.com/app/docs/doc/816-4556/sundssetup-13?l=en&a=view This details the steps for Sun ONE Directory server, similar configuration steps need to be done if other Directory servers like OpneLDAP or OpenDS are used. 3. Migrate the NIS+ tables as documented in System admin guide http://docs.sun.com/app/docs/doc/816-4556/nisplus2ldap-1?l=en&a=view 4. Continue by installing Solaris next with a configured name server that refers to the Directory server of step 1. From gdamore@sun.com Mon Oct 5 17:36:38 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n960ac3W012464 for ; Mon, 5 Oct 2009 17:36:38 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n960acHR013734; Mon, 5 Oct 2009 17:36:38 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR200H05HP2IS00@brm-avmta-1.central.sun.com>; Mon, 05 Oct 2009 18:36:38 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR2002AJHP1WP60@brm-avmta-1.central.sun.com>; Mon, 05 Oct 2009 18:36:37 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n960abZK009858; Mon, 05 Oct 2009 17:36:37 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KR200H00HHUVO00@fe-sfbay-09.sun.com>; Mon, 05 Oct 2009 17:36:37 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KR2008XOHP0XQB0@fe-sfbay-09.sun.com>; Mon, 05 Oct 2009 17:36:37 -0700 (PDT) Date: Mon, 05 Oct 2009 17:36:36 -0700 From: "Garrett D'Amore" Subject: Re: Removal of NIS+ [PSARC/2009/530 FastTrack timeout 10/12/2009] In-reply-to: <200910052345.n95NjBvv011324@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Gary Winiger Cc: psarc-ext@sun.com, nisplus-core@sun.com, rajagolal.andra@sun.com Message-id: <4ACA9114.2070003@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910052345.n95NjBvv011324@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 7839 +1, and good riddance! - Garrett Gary Winiger wrote: > I'm sponsoring this Fast Track for Raja Gopal Andra, the RPE naming team, > and the NIS+ core team. It requests removal of all the NIS+ related > interfaces and documentation in a Minor Release. While this is somewhat > long, the case owner and project team believe it still qualifies for a > Fast Track as the length details the how the EOL required dependences are > satisfied. > > This project is unrelated to pam_ldap(5) and has no effect on it or > the Sun Java System Directory Server. > > The current NIS+(1) man page and redacted opinions for PSARC/2000/370 (EOL of > NIS+) and PSARC/2004/638 (Removal of Sun Directory Server 5.1 from Solaris WOS) > are in the case directory. > > The timer is set for 12 Oct., 2009. > > Gary.. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Background: > ========== > NIS+(1) seems to have been introduced prior to the recording of PSARC cases > in 1991. The first references I've found are Vikul Khosla's nisaddcred flag > (PSARC/1992/187) and Chuck McManis' NIS+ diagnostics (PSARC/1992/188) cases. > They refer to NIS+, but not to any previous cases, though ZNS demos > (PSARC/1991/023) seems somehow related. The NIS+ promise never achieved > sufficient traction to supplant NIS (nee YP). X500 directory servers and > the Lightweight Directory Access Protocol (LDAP) have supplanted the promise > of NIS+. EOL of NIS+ (PSARC/2000/370) started the process leading to this > case. > > Dependences: > =========== > o PSARC/2000/370 (EOL of NIS+) opinion states: > > 2. Decision & Precedence Information > . . . > Note: the approval of this case 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 > > LSARC/2001/101 Bundling of LDAP Directory Server > {actually PSARC/2001/101 -gww} > > 4. Opinion > > The main issue raised for this case was that of providing > adequate notice and support to existing NIS+ users. The > requirement to announce the upcoming EOL of NIS+ as soon as > possible in order to head off new adoption of the technology > was seen as conflicting with the requirement not to panic > existing users. > > The committee decided that a three step schedule: > > 1. adequate notice > > 2. availability of all replacement technology > > 3. actual EOL > > would satisfy both requirements and imposed technical > changes needed to obtain such a schedule. See [2] for > opposing views. > > {[2] Email discussion. File: mail} > > o PSARC/2004/638 (Removal of Sun Directory Server 5.1 from Solaris WOS) was > denied. The denial was overturned on appeal and iDS was removed from > the Solaris WOS. That removal impacts the removal of NIS+ as the > opinion states: > > 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. > > Details: > ======= > * PSARC/2000/311 NIS+/LDAP Migration and PSARC/2000/363 Native LDAP > phase II have both been delivered since Solaris 9. > > * 1) adequate notice > The announcement of the EOL of NIS+ has been completed since Solaris 9 > The current (S10u8) NIS+ man pages contain the note: > NIS+ might not be supported in future releases of the > Solaris operating system. Tools to aid the migration from > NIS+ to LDAP are available in the current Solaris release. > For more information, visit > http://www.sun.com/directory/nisplus/transition.html. > > * 2) availability of all replacement technology > With the integration of PSARC/2008/745 nss_ldap shadowAccount support > in the current development release and the back port to S10u8, > all the functionality that was provided by NIS+ is now available > using a LDAP directory server as a name service (i.e., nsswitch.conf > configuration such as shown in the delivered sample nsswitch.ldap). > > * With the permission to remove the bundled LDAP Directory Server by > the approval upon appeal of PSARC/2004/638, the conditions of > PSARC/2000/370 are not met by the Solaris "letter of the law". > > The "traditional" Solaris view of what is bundled software appears > to be changing with the next Minor release's introduction of the > "OpenSolaris" distribution and "Solaris Next" "marketing release". > The project team believes that OpenLDAP for OpenSolaris > (PSARC/2008/507) and/or Sun OpenDS (LSARC/2008/372) meet the > "intent of the law" as written in PSARC/2000/370 for having a > "Bundled" LDAP Directory Server. They are "distributed" with > OpenSolaris/Solaris Next. The project team has verified that both > OpenLDAP and OpenDS support at least all the name service databases > and attributes supported by NIS+. (As does the "unbundled" Sun > Java System Directory Server.) > > Proposal: > ======== > As all the requirements outlined in PSARC/2000/370 have been met, remove > all the NIS+ related interfaces and documentation in the a Minor release. > (PSARC/2000/370 details the user and administrative commands, RPC services, > and Programming API to be removed.) > > Issues: > ====== > Conversion of an existing NIS+ server's Tables to LDAP needs to be > completed on a system that supports NIS+. Once NIS+ has been removed. > conversion using the processes described in "Transitioning From NIS+ to LDAP" > (http://docs.sun.com/app/docs/doc/817-2655/6mia7mum5?a=view) isn't > available. To mitigate this, the project team notes that the announcement > was made in Solaris 9 and the project will ensure that the installation > documentation of the Minor release that removes NIS+ will clearly state > that the conversion must take place before installation. > > The project team proposes adding to the Solaris Next System > Administration Guide a section similar to: > Transitioning from NIS+ to LDAP on Solaris Next: > An existing Solaris 9 or 10 NIS+ Server and Client system must > be available for the Transition. > > 1. On a system, install Solaris Next (or Solaris 9 or Solaris 10) > with the desired Directory server. > 2. Configure the Directory server as documented in System admin guide > http://docs.sun.com/app/docs/doc/816-4556/sundssetup-13?l=en&a=view > This details the steps for Sun ONE Directory server, similar > configuration steps need to be done if other Directory servers > like OpneLDAP or OpenDS are used. > 3. Migrate the NIS+ tables as documented in System admin guide > http://docs.sun.com/app/docs/doc/816-4556/nisplus2ldap-1?l=en&a=view > 4. Continue by installing Solaris next with a configured name server > that refers to the Directory server of step 1. > From glenn.skinner@sun.com Tue Oct 6 15:28:25 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n96MSPYx028361 for ; Tue, 6 Oct 2009 15:28:25 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n96MSNfK020453; Tue, 6 Oct 2009 16:28:25 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR400G016FCA300@nwk-avmta-1.sfbay.Sun.COM>; Tue, 06 Oct 2009 15:28:24 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR400CEO6FC6DF0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 06 Oct 2009 15:28:24 -0700 (PDT) Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n96MSNE3015651; Tue, 06 Oct 2009 15:28:23 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id n96MKsEF004810; Tue, 06 Oct 2009 15:20:54 -0700 (PDT) Date: Tue, 06 Oct 2009 15:20:54 -0700 (PDT) From: Glenn Skinner Subject: Re: 2009/530 [Removal of NIS+] To: psarc-ext@sun.com Cc: nisplus-core@sun.com, rajagolal.andra@sun.com Reply-to: Glenn Skinner Message-id: <200910062220.n96MKsEF004810@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: cJecdG0zrrwu4feq8x3sWg== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 564 Date: Mon, 05 Oct 2009 16:45:11 -0700 (PDT) From: Gary Winiger Subject: Removal of NIS+ [PSARC/2009/530 FastTrack timeout 10/12/2009] I'm sponsoring this Fast Track for Raja Gopal Andra, the RPE naming team, and the NIS+ core team. It requests removal of all the NIS+ related interfaces and documentation in a Minor Release. Will removing NIS+ have any impact on Solaris 10 zones hosted within a system running a release into which this project has been delivered? (See PSARC/2009/253 [S10C].) -- Glenn From rajagopal.andra@sun.com Tue Oct 6 16:05:28 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n96N5RHV029686 for ; Tue, 6 Oct 2009 16:05:28 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n96N5O9O021090; Wed, 7 Oct 2009 00:05:25 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR400M0F850AO00@nwk-avmta-2.sfbay.sun.com>; Tue, 06 Oct 2009 16:05:24 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR400JKS850AB20@nwk-avmta-2.sfbay.sun.com>; Tue, 06 Oct 2009 16:05:24 -0700 (PDT) Received: from [129.146.56.89] (moyar.SFBay.Sun.COM [129.146.56.89]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n96N5Oo3355451; Tue, 06 Oct 2009 16:05:24 -0700 (PDT) Date: Tue, 06 Oct 2009 16:03:43 -0700 From: Raja Gopal Andra Subject: Re: 2009/530 [Removal of NIS+] In-reply-to: <200910062220.n96MKsEF004810@ivrel.sfbay.sun.com> To: Glenn Skinner Cc: psarc-ext@sun.com, nisplus-core@sun.com, rajagolal.andra@sun.com Message-id: <4ACBCCCF.6050507@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910062220.n96MKsEF004810@ivrel.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 1076 On 10/06/09 15:20, Glenn Skinner wrote: > Date: Mon, 05 Oct 2009 16:45:11 -0700 (PDT) > From: Gary Winiger > Subject: Removal of NIS+ [PSARC/2009/530 FastTrack timeout > 10/12/2009] > > I'm sponsoring this Fast Track for Raja Gopal Andra, the RPE > naming team, and the NIS+ core team. It requests removal of all > the NIS+ related interfaces and documentation in a Minor Release. > > Will removing NIS+ have any impact on Solaris 10 zones hosted within a > system running a release into which this project has been delivered? From my understanding after reading the PSARC case, the answer is that there will be no impact of removing NIS+ on S10 zones. Thank you, Raja > > (See PSARC/2009/253 [S10C].) > > -- Glenn > > -- Raja Gopal Andra Sun Microsystems Phone: +1 650 786 4273 Solaris RPE 17 Network Circle, Fax : +1 650 786 7994 Naming Group Menlo Park, CA 94025 mailto: andra@sun.com -- The secret to success is to work less as individuals and more as a team. From Alan.Coopersmith@sun.com Tue Oct 6 16:44:29 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n96NiStG000693 for ; Tue, 6 Oct 2009 16:44:28 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n96NiNLu014923; Wed, 7 Oct 2009 00:44:27 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR40010B9Y1IO00@brm-avmta-1.central.sun.com>; Tue, 06 Oct 2009 17:44:25 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR400LL69Y0ILH0@brm-avmta-1.central.sun.com>; Tue, 06 Oct 2009 17:44:25 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n96NiJur003253; Tue, 06 Oct 2009 16:44:19 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KR400K009P8KP00@fe-sfbay-09.sun.com>; Tue, 06 Oct 2009 16:44:19 -0700 (PDT) Received: from [129.145.155.53] ([unknown] [129.145.155.53]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KR400I2Q9XVQF20@fe-sfbay-09.sun.com>; Tue, 06 Oct 2009 16:44:19 -0700 (PDT) Date: Tue, 06 Oct 2009 16:44:19 -0700 From: Alan Coopersmith Subject: Re: 2009/530 [Removal of NIS+] In-reply-to: <4ACBCCCF.6050507@sun.com> Sender: Alan.Coopersmith@sun.com To: Raja Gopal Andra Cc: Glenn Skinner , psarc-ext@sun.com, nisplus-core@sun.com, rajagolal.andra@sun.com Message-id: <4ACBD653.4040506@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200910062220.n96MKsEF004810@ivrel.sfbay.sun.com> <4ACBCCCF.6050507@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090720) Status: RO Content-Length: 695 Raja Gopal Andra wrote: > From my understanding after reading the PSARC case, the answer is that > there will be no impact of removing NIS+ on S10 zones. In fact, shouldn't the availablity of S10 zones help with the transition steps that require a machine running S10? Can that be tested and documented as an option (along side the currently documented option of just having a natively running S9 or S10 machine) in the steps you listed in the fasttrack for the transition plan? (Just a suggestion, don't think it should be a requirement if it turns out to have an issue.) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From rajagopal.andra@sun.com Tue Oct 6 17:10:57 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n970AunR001706 for ; Tue, 6 Oct 2009 17:10:56 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n970AaPM029841; Wed, 7 Oct 2009 01:10:53 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR40070JB63H700@nwk-avmta-1.sfbay.Sun.COM>; Tue, 06 Oct 2009 17:10:51 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR40033ZB63JG60@nwk-avmta-1.sfbay.Sun.COM>; Tue, 06 Oct 2009 17:10:51 -0700 (PDT) Received: from [129.146.56.89] (moyar.SFBay.Sun.COM [129.146.56.89]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n970AoR8364845; Tue, 06 Oct 2009 17:10:50 -0700 (PDT) Date: Tue, 06 Oct 2009 17:09:10 -0700 From: Raja Gopal Andra Subject: Re: 2009/530 [Removal of NIS+] In-reply-to: <4ACBD653.4040506@sun.com> To: Alan Coopersmith Cc: Glenn Skinner , psarc-ext@sun.com, nisplus-core@sun.com, Raja Gopal Andra Message-id: <4ACBDC26.8070901@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910062220.n96MKsEF004810@ivrel.sfbay.sun.com> <4ACBCCCF.6050507@sun.com> <4ACBD653.4040506@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 1091 On 10/06/09 16:44, Alan Coopersmith wrote: > Raja Gopal Andra wrote: >> From my understanding after reading the PSARC case, the answer is that >> there will be no impact of removing NIS+ on S10 zones. > > In fact, shouldn't the availablity of S10 zones help with the transition > steps that require a machine running S10? Yes, that is true. > Can that be tested and documented > as an option (along side the currently documented option of just having a > natively running S9 or S10 machine) in the steps you listed in the fasttrack > for the transition plan? (Just a suggestion, don't think it should be a > requirement if it turns out to have an issue.) I tend to agree with your suggestion - will try to test this out and add it to documentation as the time/resources permit. Thanks, Raja -- Raja Gopal Andra Sun Microsystems Phone: +1 650 786 4273 Solaris RPE 17 Network Circle, Fax : +1 650 786 7994 Naming Group Menlo Park, CA 94025 mailto: andra@sun.com -- The secret to success is to work less as individuals and more as a team. From gww@sac.sfbay.sun.com Wed Oct 7 10:09:47 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n97H9kaR004920 for ; Wed, 7 Oct 2009 10:09:47 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n97H9e09025661; Thu, 8 Oct 2009 01:09:45 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR500303MC8PV00@brm-avmta-1.central.sun.com>; Wed, 07 Oct 2009 11:09:44 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR500LKQMC8IPI2@brm-avmta-1.central.sun.com>; Wed, 07 Oct 2009 11:09:44 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n97H9h47012245; Wed, 07 Oct 2009 10:09:43 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n97H9hBw004918; Wed, 07 Oct 2009 10:09:43 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n97H9hVl004917; Wed, 07 Oct 2009 10:09:43 -0700 (PDT) Date: Wed, 07 Oct 2009 10:09:43 -0700 (PDT) From: Gary Winiger Subject: Re: Removal of NIS+ [PSARC/2009/530 FastTrack timeout 10/12/2009] To: PSARC-ext@sun.com Cc: nisplus-core@sun.com, rajagolal.andra@sun.com Message-id: <200910071709.n97H9hVl004917@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 456 > I'm sponsoring this Fast Track for Raja Gopal Andra, the RPE naming team, > and the NIS+ core team. It requests removal of all the NIS+ related > interfaces and documentation in a Minor Release. While this is somewhat > long, the case owner and project team believe it still qualifies for a > Fast Track as the length details the how the EOL required dependences are > satisfied. This case was approved as specified at today's PSARC meeting. Gary..