From nw141292@sac.sfbay.sun.com Fri Apr 11 12:04:09 2008 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 m3BJ484r021322 for ; Fri, 11 Apr 2008 12:04:09 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m3BJ41fd011095; Sat, 12 Apr 2008 03:04:07 +0800 (SGT) 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 <0JZ600I0JCYRDE00@nwk-avmta-2.sfbay.sun.com>; Fri, 11 Apr 2008 12:04:03 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZ600AZ7CYR2UE0@nwk-avmta-2.sfbay.sun.com>; Fri, 11 Apr 2008 12:04:03 -0700 (PDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3BJ42UB000454; Fri, 11 Apr 2008 12:04:02 -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 m3BJ40rf021317; Fri, 11 Apr 2008 12:04:01 -0700 (PDT) Received: (from nw141292@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m3BJ405a021313; Fri, 11 Apr 2008 12:04:00 -0700 (PDT) Date: Fri, 11 Apr 2008 12:04:00 -0700 (PDT) From: Nicolas Williams Subject: Native LDAP standalone tools (Duckwater) [PSARC/2008/256 FastTrack timeout 04/18/2008] To: PSARC-ext@sun.com Cc: Nicolas.Williams@sun.com, duckwater-discuss@opensolaris.org Message-id: <200804111904.m3BJ405a021313@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 8727 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Native LDAP standalone tools (Duckwater) 1.2. Name of Document Author/Supplier: Author: Nicolas Williams 1.3 Date of This Document: 11 April, 2008 4. Technical Description I'm sponsoring this fasttrack for Tomas Heran. The timer is set to expire on April 18, 2008. The requested release binding is 'patch'. Duckwater Standalone LDAP naming client utilities BACKGROUND ========== The Duckwater project (see PSARC/2007/694 and PSARC/2006/247) intends to deliver simplified naming services configuration and management by updating old tools, and introducing new tools and components that leverage SMF to store naming configurations, and provide consistent 'SMF-like' cfg/adm interfaces for administrative use. This case provides for separate delivery of a phase 0 sub-component of the duckwater project that has no dependencies on SMF or other duckwater enhancements that are planned for subsequent phases. This separate delivery is needed to address some high call generating CRs and improve some serious approachability issues in LDAP setup and configuration immediately. PROBLEM ======= There are four highly visible issues with LDAP naming services that are documented/tracking by the following CRs: 4880322 TLSv1/SSL support needs to become integrated in all LDAP client programs 4942874 RFE: native ldap client with ssl restricted to ports 636/389 5035244 Make ldapaddent a standalone tool 6227396 *ldaplist* should refer to ldapclient(1M) when ldap not configured These issues can be summarized as: [1] Administrators are unable to upload naming data into directory server using ldapaddent(1M) unless the system running ldapaddent, has first been configured for LDAP naming. This implies that the Initial state of the network repository must be empty, and the client using the repository must be configured to use the empty repository before the repository can be loaded with data from an existing repository (i.e., existing NIS data). ldaplist(1) has same limitation. You can not query a repository to see if it has naming data unless your client is configured to use that naming data. This is a serious administration design flaw and approachability issue in LDAP naming today. [2] The tool used to initialize the client machine ldapclient(1M) has no provision to specify authentication credentials or credential type when initializing a client. This forces all directory servers to support open (port 389 with no security) binds to the directory server to initialize clients. Customers that want to secure a directory server to use only TLS/SSL for all access to the directory server are unable to do so. [3] Related to [2], ldap_cachemgr(1M) currently requires anonymous (open port 389) non-TLS access to the RootDSE of any directory server even if other access is specified as TLS/SSL. [4] Users wishing to use TLS/SSL are required to use port 636 (the default LDAP TLS/SSL port). Even though LDAP servers typically allow other ports to be specified, the current implementation only supports port 636. [Note: The standard method for using TLS with LDAP ("StartTLS") is not supported by Solaris' libldap5.so. More on this below.] SOLUTION ======== To address problems [1] and [2], ldapclient(1M), ldapaddent(1M) and ldaplist(1) will be updated to support a common set of command line options that are both consistent amongst all three programs and also consistent with the other LDAP tool interfaces delivered by the Solaris and directory server product lines. [I.e., the ldapsearch(1), ldapadd(1), ldapdelete(1), ldapmodify(1), ldapmodrdn(1) command line APIs]. The following command line options to be supported are: -h LDAP_server[:serverPort] An address (or a name) and a port of the LDAP server in which the entries will be stored. The current naming service specified in the nsswitch.conf file is used. The default value for the port is 389, except when TLS is specified in the authentication method. In this case, the default LDAP server port number is 636. -M domainName The name of a domain served by the specified server. If not specified, the default domain name will be used. This is used to derive a base DN for searches. -N profileName Specify the DUAProfile name. A profile with such a name is supposed to exist on the server specified by -h option. Otherwise, a default DUAProfile will be used. The default value is default. -P certifPath The certificate path for the location of the certificate database. The value is the path where security database files reside. This is used for TLS support, which is specified in the authenticationMethod and serviceAuthen- ticationMethod attributes. The default is /var/ldap. -D bindDN Specifies an entry which has read (and write in case of ldapaddent(1M)) permission to appropriate part of the DIT. -w bind_password Password to be used for authenticating the bindDN. If this parameter is missing, the command will prompt for a password. NULL passwords are not supported in LDAP. When you use -w bind_password to specify the password to be used for authentication, the password is visible to other users of the system by means of the ps command, in script files or in shell history. If the value of "-" is supplied as a password, the command will prompt for a password. -j filename Specify a file containing the password for the bind DN or the password for the SSL client's key database. To protect the password, use this option in scripts and place the password in a secure file. This option is mutually exclusive of the -w opt- ion. Man page diffs listing which of the commands ldaplist(1), ldapaddent(1M) and ldapclient(1M) will receive which new command line options are provided in the materials directory. The interface stability level of ldapaddent(1M), ldaplist(1) and ldapclient(1M) remain Committed. In addition to modifying the command line tools, internal enhancements will be made to the Contracted Consolidation Private private interfaces in the libsldap library and in ldap_cachemgr(1M) to support the new command line options of the modified tools and to address the problems in [3] and [4]. Enhancements to libsldap will not affect existing contracted interfaces. All new enhancements will be considered Contracted Consolidation private. All existing contracts with libsldap will remain in effect. The specific enhancements are provided in the revised libsldap API document and provided in the case materials for reference. Currently libldap.so.5, the default libldap in Solaris, lacks the necessary ldap TLS APIs, that allow a TLS session to be enabled after a unsecured LDAP connection has been made (START-TLS). These APIs will be delivered when the current Mozilla libldap, libldap.so.6, currently delivered by the directory server team (Directory Server 6 [WSARC/2005/285] and later) is integrated into Solaris, replacing libldap.so.5. A future project will address this limitation once the new TLS APIs from libldap.so.6 are available. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ONNV 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Nicolas.Williams@Sun.COM Tue Apr 15 15:27:51 2008 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 m3FMRofF014853 for ; Tue, 15 Apr 2008 15:27:50 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m3FMRMpF006029 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 16 Apr 2008 06:27:49 +0800 (SGT) 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 <0JZE0080312DFF00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 15 Apr 2008 15:27:49 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZE004AT12C9K80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 15 Apr 2008 15:27:48 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m3FMRmtW013225; Tue, 15 Apr 2008 17:27:48 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m3FMRlf9013224; Tue, 15 Apr 2008 17:27:47 -0500 (CDT) Date: Tue, 15 Apr 2008 17:27:47 -0500 From: Nicolas Williams Subject: Re: Native LDAP standalone tools (Duckwater) [PSARC/2008/256 FastTrack timeout 04/18/2008] In-reply-to: <200804152206.m3FM61av011858@marduk.eng.sun.com> To: Gary Winiger Cc: PSARC-ext@Sun.COM, duckwater-discuss@opensolaris.org Mail-followup-to: Gary Winiger , PSARC-ext@sun.com, duckwater-discuss@opensolaris.org Message-id: <20080415222747.GR8027@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200804152206.m3FM61av011858@marduk.eng.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 682 On Tue, Apr 15, 2008 at 03:06:01PM -0700, Gary Winiger wrote: > << off list >> Back on-list. > > The specific enhancements are provided in the revised libsldap API > > document and provided in the case materials for reference. > > I've move the pdf to the SCCS subdirectory so it will not > be viewable. It contains > XXX XXXXXXXXXXXX: Internal Only > > If you want, put a new copy without confidential information > in the case directory, or close the case and rexpose this. This was an editing error. Doug meant to remove that text from all pages but accidentally left it in on page 1. I'll add new versions to the case materials as soon as Doug sends them to me. From gww@eng.sun.com Tue Apr 15 15:54:28 2008 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 m3FMsSeq015894 for ; Tue, 15 Apr 2008 15:54:28 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3FMsRlU062693 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 15 Apr 2008 16:54:28 -0600 (MDT) 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 <0JZE00D012AS1T00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 15 Apr 2008 15:54:28 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZE006MI2AREFB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 15 Apr 2008 15:54:27 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3FMsRvF051623; Tue, 15 Apr 2008 15:54:27 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m3FMs2Q4011994; Tue, 15 Apr 2008 15:54:02 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m3FMs20H011993; Tue, 15 Apr 2008 15:54:02 -0700 (PDT) Date: Tue, 15 Apr 2008 15:54:02 -0700 (PDT) From: Gary Winiger Subject: Re: Native LDAP standalone tools (Duckwater) [PSARC/2008/256 FastTrack timeout 04/18/2008] To: PSARC-ext@sun.com, nw141292@sac.sfbay.sun.com Cc: Nicolas.Williams@sun.com, duckwater-discuss@opensolaris.org Message-id: <200804152254.m3FMs20H011993@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1155 > -w bind_password Password to be used for > authenticating the bindDN. If > this parameter is missing, the > command will prompt for a > password. NULL passwords are not > supported in LDAP. > Man page diffs listing which of the commands ldaplist(1), > ldapaddent(1M) and ldapclient(1M) will receive which new command > line options are provided in the materials directory. Thanks for making this optional. From the man pages it wasn't in the previous code. > The interface stability level of ldapaddent(1M), ldaplist(1) and > ldapclient(1M) remain Committed. Nit, please update the man pages to say Committed when they are putback into the man gate. The one in the case directory say Evolving. Architectural comment: IIRC, at one time the iPlanet Directory Server delivered its own copy of these commands. If my recollection is correct: will the iDS commands be updated as well? will this case allow iDS to not deliver its own set of commands? how will the differing set of commands relate? will there be some future project to harmonize the commands? Gary.. From Nicolas.Williams@sun.com Tue Apr 15 16:18:22 2008 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 m3FNIMA4016978 for ; Tue, 15 Apr 2008 16:18:22 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3FNIMuB022219 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 15 Apr 2008 16:18:22 -0700 (PDT) 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 <0JZE00D033EKXU00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 15 Apr 2008 16:18:20 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZE006593EIEFD0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 15 Apr 2008 16:18:18 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m3FNIGjk013267; Tue, 15 Apr 2008 18:18:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m3FNIGM9013266; Tue, 15 Apr 2008 18:18:16 -0500 (CDT) Date: Tue, 15 Apr 2008 18:18:16 -0500 From: Nicolas Williams Subject: Re: Native LDAP standalone tools (Duckwater) [PSARC/2008/256 FastTrack timeout 04/18/2008] In-reply-to: <200804152254.m3FMs20H011993@marduk.eng.sun.com> To: Gary Winiger Cc: PSARC-ext@sun.com, nw141292@sac.sfbay.sun.com, duckwater-discuss@opensolaris.org Mail-followup-to: Gary Winiger , PSARC-ext@sun.com, nw141292@sac.sfbay.sun.com, duckwater-discuss@opensolaris.org Message-id: <20080415231815.GV8027@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200804152254.m3FMs20H011993@marduk.eng.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1605 On Tue, Apr 15, 2008 at 03:54:02PM -0700, Gary Winiger wrote: > > -w bind_password Password to be used for > > authenticating the bindDN. If > > this parameter is missing, the > > command will prompt for a > > password. NULL passwords are not > > supported in LDAP. > > > Man page diffs listing which of the commands ldaplist(1), > > ldapaddent(1M) and ldapclient(1M) will receive which new command > > line options are provided in the materials directory. > > Thanks for making this optional. From the man pages it > wasn't in the previous code. And there's the -j option too. I'd go so far as to make it so it prompts or reads it from a file, but never from the command line arguments. However, I'm happy enough as it is. > > The interface stability level of ldapaddent(1M), ldaplist(1) and > > ldapclient(1M) remain Committed. > > Nit, please update the man pages to say Committed when they > are putback into the man gate. The one in the case directory > say Evolving. Good catch. We'll do so. > Architectural comment: > > IIRC, at one time the iPlanet Directory Server delivered its own > copy of these commands. I don't know if this is the case. Tomas? Doug? > If my recollection is correct: > will the iDS commands be updated as well? > will this case allow iDS to not deliver its own > set of commands? > how will the differing set of commands relate? > will there be some future project to harmonize the > commands? I don't know the answers to these questions either. Tomas? Doug? Nico -- From Tomas.Heran@sun.com Wed Apr 16 03:10:03 2008 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 m3GAA2i3002789 for ; Wed, 16 Apr 2008 03:10:02 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m3GA9ufv014163 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 16 Apr 2008 18:10:01 +0800 (SGT) 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 <0JZE00L05XKN7G00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 16 Apr 2008 03:09:59 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZE00G38XKLUE50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 16 Apr 2008 03:09:59 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m3GA9vRS022569 for ; Wed, 16 Apr 2008 10:09:57 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JZE00B01X540A00@fe-emea-10.sun.com> (original mail from Tomas.Heran@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 16 Apr 2008 11:09:57 +0100 (BST) Received: from tomas-herans-computer.local ([62.245.95.183]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JZE00A2YXKJ7N40@fe-emea-10.sun.com>; Wed, 16 Apr 2008 11:09:56 +0100 (BST) Date: Wed, 16 Apr 2008 12:10:00 +0200 From: Tomas Heran Subject: Re: Native LDAP standalone tools (Duckwater) [PSARC/2008/256 FastTrack timeout 04/18/2008] In-reply-to: <20080415231815.GV8027@Sun.COM> Sender: Tomas.Heran@sun.com To: Gary Winiger , PSARC-ext@sun.com, nw141292@sac.sfbay.sun.com, duckwater-discuss@opensolaris.org Cc: serge dussud Message-id: <4805D078.7050804@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200804152254.m3FMs20H011993@marduk.eng.sun.com> <20080415231815.GV8027@Sun.COM> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Status: RO Content-Length: 956 Nicolas Williams wrote: > On Tue, Apr 15, 2008 at 03:54:02PM -0700, Gary Winiger wrote: >>> The interface stability level of ldapaddent(1M), ldaplist(1) and >>> ldapclient(1M) remain Committed. >> Nit, please update the man pages to say Committed when they >> are putback into the man gate. The one in the case directory >> say Evolving. > > Good catch. We'll do so. Done and copy of updated man pages sent to Nico. > >> Architectural comment: >> >> IIRC, at one time the iPlanet Directory Server delivered its own >> copy of these commands. > > I don't know if this is the case. Tomas? Doug? > I just checked with Serge D. and he confirmed my assumption (though I didn't know for sure) that only generic LDAP tools - e.g. ldapsearch(1) - were ever delivered by iPlanet DS. We're not proposing to modify those. This case proposes to modify only name services related LDAP tools - ldaplist(1), ldapaddent(1M) and ldapclient(1M). Tomas From gww@eng.sun.com Wed Apr 16 10:44:51 2008 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 m3GHip2i017725 for ; Wed, 16 Apr 2008 10:44:51 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3GHilXk007147 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 16 Apr 2008 10:44:51 -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 <0JZF0081RIMQR200@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 16 Apr 2008 11:44:50 -0600 (MDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZF00MBYIMPRTB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 16 Apr 2008 11:44:49 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3GHiljG001060; Wed, 16 Apr 2008 10:44:47 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m3GHiN93013464; Wed, 16 Apr 2008 10:44:23 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m3GHiN3u013463; Wed, 16 Apr 2008 10:44:23 -0700 (PDT) Date: Wed, 16 Apr 2008 10:44:23 -0700 (PDT) From: Gary Winiger Subject: Re: Native LDAP standalone tools (Duckwater) [PSARC/2008/256 FastTrack timeout 04/18/2008] To: gww@eng.sun.com, PSARC-ext@sun.com, nw141292@sac.sfbay.sun.com, duckwater-discuss@opensolaris.org, Tomas.Heran@sun.com Cc: Serge.Dussud@sun.com Message-id: <200804161744.m3GHiN3u013463@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 722 > >> Architectural comment: > >> > >> IIRC, at one time the iPlanet Directory Server delivered its own > >> copy of these commands. > > > > I don't know if this is the case. Tomas? Doug? > > > > I just checked with Serge D. and he confirmed my assumption (though I > didn't know for sure) that only generic LDAP tools - e.g. ldapsearch(1) > - were ever delivered by iPlanet DS. We're not proposing to modify > those. This case proposes to modify only name services related LDAP > tools - ldaplist(1), ldapaddent(1M) and ldapclient(1M). So, do I parse this correctly: there is no overlap between the tools delivered from iPlanet DS and those from the Native LDAP project(s)? If so great ;-) thanks. Gary.. From Tomas.Heran@sun.com Wed Apr 16 10:50:55 2008 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 m3GHoshV017955 for ; Wed, 16 Apr 2008 10:50:54 -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 m3GHophq020728 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 16 Apr 2008 18:50: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 <0JZF00K0PIWRQO00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 16 Apr 2008 10:50:51 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZF0041BIWM7ID0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 16 Apr 2008 10:50:49 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m3GHokXo005455 for ; Wed, 16 Apr 2008 17:50:46 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JZF00A01IQZWN00@fe-emea-09.sun.com> (original mail from Tomas.Heran@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 16 Apr 2008 18:50:46 +0100 (BST) Received: from tomas-herans-computer.local ([62.245.95.183]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JZF001TIIWHLH40@fe-emea-09.sun.com>; Wed, 16 Apr 2008 18:50:45 +0100 (BST) Date: Wed, 16 Apr 2008 19:50:45 +0200 From: Tomas Heran Subject: Re: Native LDAP standalone tools (Duckwater) [PSARC/2008/256 FastTrack timeout 04/18/2008] In-reply-to: <200804161744.m3GHiN3u013463@marduk.eng.sun.com> Sender: Tomas.Heran@sun.com To: Gary Winiger Cc: psarc-ext@sun.com, nw141292@sac.sfbay.sun.com, duckwater-discuss@opensolaris.org, Serge.Dussud@sun.com Message-id: <48063C75.7030009@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200804161744.m3GHiN3u013463@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Status: RO Content-Length: 796 Gary Winiger wrote: >>>> Architectural comment: >>>> >>>> IIRC, at one time the iPlanet Directory Server delivered its own >>>> copy of these commands. >>> I don't know if this is the case. Tomas? Doug? >>> >> I just checked with Serge D. and he confirmed my assumption (though I >> didn't know for sure) that only generic LDAP tools - e.g. ldapsearch(1) >> - were ever delivered by iPlanet DS. We're not proposing to modify >> those. This case proposes to modify only name services related LDAP >> tools - ldaplist(1), ldapaddent(1M) and ldapclient(1M). > > So, do I parse this correctly: there is no overlap between the > tools delivered from iPlanet DS and those from the Native LDAP > project(s)? If so great ;-) thanks. You do parse it correctly - there is no overlap. Tomas