From jyri@sac.sfbay.sun.com Sat Feb 21 17:32:21 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 n1M1WLpw025912 for ; Sat, 21 Feb 2009 17:32:21 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1M1WB8A007242; Sat, 21 Feb 2009 17:32:21 -0800 (PST) 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 <0KFG00B3T1LU3X00@nwk-avmta-1.sfbay.Sun.COM>; Sat, 21 Feb 2009 17:32:18 -0800 (PST) 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 <0KFG00FHA1LSFP40@nwk-avmta-1.sfbay.Sun.COM>; Sat, 21 Feb 2009 17:32:16 -0800 (PST) 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 n1M1WGYT027535; Sat, 21 Feb 2009 17:32:16 -0800 (PST) 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 n1M1W8VI025895; Sat, 21 Feb 2009 17:32:08 -0800 (PST) Received: (from jyri@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n1M1W8l9025891; Sat, 21 Feb 2009 17:32:08 -0800 (PST) Date: Sat, 21 Feb 2009 17:32:08 -0800 (PST) From: Jyri Virkki Subject: Apache and APR-Util Using OpenLDAP [LSARC/2009/123 FastTrack timeout 02/27/2009] To: LSARC-ext@sun.com Cc: webstack-discuss@opensolaris.org Message-id: <200902220132.n1M1W8l9025891@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 9387 I am sponsoring this case for Jeff Trawick. It enables Apache (via APR) to use OpenLDAP. I'll make the contract between this case and PSARC/2008/507 available soon. Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Apache and APR-Util Using OpenLDAP 1.2. Name of Document Author/Supplier: Author: Jeff Trawick 1.3 Date of This Document: 21 February, 2009 4. Technical Description 2. Summary 2.1. Switch APR-Util to OpenLDAP APR-Util is a support library used by Apache HTTP Server and other applications. APR-Util provides limited abstractions for LDAP libraries; it detects which libraries are available, determines their capabilities, and provides helper functions for more complex features such as configuring SSL certificates for communication with the LDAP server. Applications are expected to make direct calls to portable functions in the underlying LDAP library and use APR-Util-specific calls for non-portable operations. APR-Util is most often used with OpenLDAP, though it does have some support for a handful of other LDAP libraries, including native Solaris LDAP. However, ldaps does not work with native Solaris LDAP. This project will change the APR-Util build configuration to use OpenLDAP instead of native Solaris LDAP. 2.2 Switch Apache HTTP Server to OpenLDAP Apache HTTP Server (Apache) uses the LDAP feature of APR-Util to handle most LDAP details. (In fact it is the only publically known application on any platform which uses that feature.) It links to the LDAP libraries specified by APR-Util, includes header files from paths specified by APR-Util, etc.; it uses a mix of portable LDAP library calls and APR-Util calls to implement Apache's LDAP features. Apache will not need to be modified to build with OpenLDAP, but the APR-Util changes will be reflected in different libraries and header files used by Apache, and the LDAP calls made by Apache could change based on compile-time tests for symbols in the APR-Util or LDAP header files. Note that the Apache documentation for mod_ldap at http://httpd.apache.org/docs/2.2/mod/mod_ldap.html#settingcerts states "SSL/TLS for the native Solaris LDAP libraries is not yet supported. If required, install and use the OpenLDAP libraries instead." 4. Technical Description: 4.1. Special library issues 4.1.1. Implications of the choice of LDAP SDK The native Solaris LDAP and OpenLDAP SDKs implement some of the same symbols. Any libraries loaded into the same process as APR-Util and Apache must use the same LDAP SDK, or the behavior is undefined. Other users of the OpenSolaris-delivered OpenLDAP client library should understand that the interfaces are Volatile and hence may change in an incompatible manner in the future. The LDAP SDK use in APR-Util is segregated to the separate library apr_ldap.so which is loaded dynamically if APR-Util LDAP functions are called, providing mitigation for a potential user-provided APR-Util application which independently uses LDAP. A list of packages within Nevada (b105) using APR-Util are shown below, along with their use of LDAP: i. Apache (and its commands) in SUNWapch22 This currently uses Solaris libldap, but that will be changed by this project via the APR-Util build changes. ii. mod_perl's APR.so, also packaged within SUNWapch22 and iii. Subversion commands and libraries in SUNWsvn, Subversion Perl and Python interfaces in SUNWsvn-python These all use APR-Util but use neither the APR-Util LDAP interfaces nor the Solaris LDAP interfaces. Thus, the other applications in Nevada which use APR-Util will not be negatively impacted by this change. Special note about APR and Solaris LDAP: Any application which uses APR-Util (libaprutil-1.so) also uses APR (libapr-1.so). libapr-1.so has an unused reference to libldap.so via another Solaris library it uses. Thus, any application which uses APR-Util has an unused reference to libldap.so. The packages in Nevada using APR-Util, listed above, were checked with ldd -u to confirm that they did not use libldap.so (other than Apache, which is changed with this project). 4.1.2. Special OpenLDAP reentrancy considerations OpenLDAP provides reentrant builds of the LDAP client functions in libldap_r-2.4.so, and non-reentrant builds in libldap-2.4.so. Because APR-Util supports threaded applications, it will use the reentrant build. Traditionally this distinction between libldap vs. libldap_r has been a problem, particularly with applications like Apache which have a plugin architecture which leads to unanticipated combinations of code in the same address space. If APR-Util (and thus Apache) uses the reentrant build and some Apache module uses a library which uses the non-reentrant build, it is undefined which build will actually be used. Some distributors of OpenLDAP solve this problem by providing only the reentrant build of the library, and pointing libldap to the reentrant build. Because the potential problem has not been avoided on OpenSolaris, a restriction for any applications or libraries which may also use OpenLDAP in conjunction with APR-Util is that they use the reentrant build. 4.1.3. Existing reference to native Solaris LDAP in libraries used by Apache libapr-1.so (APR, used by Apache and APR-Util) indirectly references libldap.so, but ldd reports that libldap.so is an unused dependency. 4.2. Bug/RFE Number(s): 6778978 ldaps causes Apache to segfault 6798092 APR-Util should use OpenLDAP instead of native Solaris LDAP 4.5. Interfaces: This affects both APR-Util and Apache. Imported Interfaces removed (no longer being imported): NAME STABILITY NOTES ---------------------------------------------------------------------- LDAP Evolving PSARC/1997/276 et seq. New Imported Interfaces: NAME STABILITY NOTES ---------------------------------------------------------------------- OpenLDAP Volatile PSARC/2008/507 A contract for consuming the Volatile OpenLDAP interfaces from PSARC/2008/507 will signed as part of this case proceedings. 4.6. Doc Impact: Web Stack documentation should indicate that Apache and APR-Util use the OpenLDAP SDK. (The important detail of which LDAP SDK is utilized has been omitted from the documentation in previous releases.) 4.6.1. Implications for Apache configuration Refer users to the OpenLDAP-specific details for configuring ldaps connections at http://httpd.apache.org/docs/2.2/mod/mod_ldap.html#settingcerts If practical, include within the documentation a sample LDAP configuration showing ldaps connections to a directory server. 4.6.1. Implications for libraries that can be loaded into Apache or other processes with APR-Util State that Apache and APR-Util use the OpenLDAP SDK, and specifically the libraries libldap_r-2.4.so and liblber-2.4.so, so any other LDAP libraries cannot be loaded into Apache or other processes with APR-Util. Note also that the OpenLDAP interfaces in OpenSolaris are classified as Volatile and may change in an incompatible manner in future updates or releases. 4.7. Admin/Config Impact: APR-Util does not have an administration interface. Non-SSL LDAP configurations of Apache will continue to work as-is. SSL LDAP connections can now be configured. 4.10. Packaging & Delivery: // What packages, clusters or metaclusters does this proposal // impact? What is its impact on install/upgrade? APR-Util's LDAP interface is package SUNWapu13-ldap. SUNWapu13-ldap will be changed to add a dependency on SUNWopenldap. Native Solaris LDAP is part of SUNWcsl, which will continue to be a dependency of SUNWapu13-ldap. 4.12. Dependencies: // List all dependencies that this proposal has on other // proposals, components or products. Include interface // specifics above in the interfaces section; list component // version requirements here. OpenLDAP 2.4.x in package SUNWopenldap (/usr/include/openldap/*.h, libldap_r-2.4.so, liblber-2.4.so) 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: sfw 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From carlsonj@phorcys.east.sun.com Mon Feb 23 12:55:44 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 n1NKthhr029565 for ; Mon, 23 Feb 2009 12:55:44 -0800 (PST) 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 n1NKtdii006700 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@Sun.Com>; Mon, 23 Feb 2009 20:55:42 GMT 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 <0KFJ00B05E4TQJ00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Mon, 23 Feb 2009 12:55:41 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFJ00HVVE4S0450@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Mon, 23 Feb 2009 12:55:40 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1NKlxkT006811; Mon, 23 Feb 2009 15:47:59 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n1NKlxOb006808; Mon, 23 Feb 2009 15:47:59 -0500 (EST) Date: Mon, 23 Feb 2009 15:47:59 -0500 From: James Carlson Subject: Re: Apache and APR-Util Using OpenLDAP [LSARC/2009/123 FastTrack timeout 02/27/2009] In-reply-to: <200902220132.n1M1W8l9025891@sac.sfbay.sun.com> To: Jyri Virkki Cc: LSARC-ext@sun.com, webstack-discuss@opensolaris.org Message-id: <18851.2943.727062.210695@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902220132.n1M1W8l9025891@sac.sfbay.sun.com> Status: RO Content-Length: 1055 Jyri Virkki writes: > The native Solaris LDAP and OpenLDAP SDKs implement some of the > same symbols. Any libraries loaded into the same process as > APR-Util and Apache must use the same LDAP SDK, or the behavior > is undefined. > > Other users of the OpenSolaris-delivered OpenLDAP client library > should understand that the interfaces are Volatile and hence may > change in an incompatible manner in the future. I don't think switching from the native Solaris LDAP to the OpenLDAP library is either obvious or non-controversial. My read of 2008/507 suggests that OpenLDAP was intended to allow others to use the library if wanted (and despite the compatibility risks it poses), and not as a way for us to deliver software. Are you sure this is indeed a fast-track? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Jyri.Virkki@sun.com Tue Feb 24 01:45:20 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 n1O9jKRJ019589 for ; Tue, 24 Feb 2009 01:45:20 -0800 (PST) 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 n1O9jAh4046372; Tue, 24 Feb 2009 02:45:19 -0700 (MST) 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 <0KFK00E1ZDRHCF00@brm-avmta-1.central.sun.com>; Tue, 24 Feb 2009 02:45:17 -0700 (MST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFK002E4DRGRY70@brm-avmta-1.central.sun.com>; Tue, 24 Feb 2009 02:45:17 -0700 (MST) Received: from dm-usca15-11.red.iplanet.com (host-185-56-18-192.iplanet.com [192.18.56.185] (may be forged)) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1O9jF0V003132; Tue, 24 Feb 2009 09:45:16 +0000 (GMT) Received: from buye.red.iplanet.com (buye [192.18.65.224]) by dm-usca15-11.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id n1O9jF002535; Tue, 24 Feb 2009 01:45:15 -0800 (PST) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id n1O9jF25017479; Tue, 24 Feb 2009 01:45:15 -0800 (PST) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id n1O9jFq6017478; Tue, 24 Feb 2009 01:45:15 -0800 (PST) Date: Tue, 24 Feb 2009 01:45:15 -0800 From: Jyri Virkki Subject: Re: Apache and APR-Util Using OpenLDAP [LSARC/2009/123 FastTrack timeout 02/27/2009] In-reply-to: <18851.2943.727062.210695@gargle.gargle.HOWL> To: James Carlson Cc: LSARC-ext@sun.com, webstack-discuss@opensolaris.org Message-id: <20090224094515.GA15251@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: <200902220132.n1M1W8l9025891@sac.sfbay.sun.com> <18851.2943.727062.210695@gargle.gargle.HOWL> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 1708 James Carlson wrote: > > > The native Solaris LDAP and OpenLDAP SDKs implement some of the > > same symbols. Any libraries loaded into the same process as > > APR-Util and Apache must use the same LDAP SDK, or the behavior > > is undefined. > > > > Other users of the OpenSolaris-delivered OpenLDAP client library > > should understand that the interfaces are Volatile and hence may > > change in an incompatible manner in the future. > > I don't think switching from the native Solaris LDAP to the OpenLDAP > library is either obvious or non-controversial. My read of 2008/507 > suggests that OpenLDAP was intended to allow others to use the library > if wanted (and despite the compatibility risks it poses), and not as a > way for us to deliver software. > > Are you sure this is indeed a fast-track? It's obvious and non-controversial to me. Opinions may differ. It is also sub-optimal, but that's not a criteria. In an alternate universe where Solaris LDAP team is resourced, it'd be good if they fix the OpenLDAP compatibility either by switching to OpenLDAP or making Sun's LDAP fully compatible. Three years later we're still waiting for the Solaris LDAP team (if such a team exists anymore) to get resourced to do something as simple as updating the version of the library (called out in WSARC/2006/582) so the chances of getting to more involved work are nil. The Apache/APR project team has done a good job investigating and documenting in detail all the issues. Jeff has an AI to follow up on Danek's earlier suggestion, beyond that there's not much more left to say. -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From Jyri.Virkki@sun.com Tue Feb 24 10:56:17 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 n1OIuGCc002340 for ; Tue, 24 Feb 2009 10:56:16 -0800 (PST) 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 n1OIuBX1003805 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 24 Feb 2009 18:56:15 GMT 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 <0KFL00K1L39QK200@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 24 Feb 2009 11:56:14 -0700 (MST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFL00DA339O6S60@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 24 Feb 2009 11:56:12 -0700 (MST) Received: from dm-usca19-13.red.iplanet.com (host-179-56-18-192.iplanet.com [192.18.56.179] (may be forged)) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1OIuCgM026685 for ; Tue, 24 Feb 2009 18:56:12 +0000 (GMT) Received: from buye.red.iplanet.com (buye [192.18.65.224]) by dm-usca19-13.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id n1OIuBs22204 for ; Tue, 24 Feb 2009 10:56:12 -0800 (PST) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id n1OIuBMm004411 for ; Tue, 24 Feb 2009 10:56:11 -0800 (PST) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id n1OIuBs5004410 for lsarc-ext@sun.com; Tue, 24 Feb 2009 10:56:11 -0800 (PST) Received: from fe-sfbay-10.sun.com ([unknown] [192.18.34.120]) by sfbay1-mail1.sfbay.sun.com (Sun Java(tm) System Messaging Server 7.0-4.01 64bit (built Jan 8 2009)) with ESMTP id <0KFH00DMOPHZHNC0@sfbay1-mail1.sfbay.sun.com> for jyri@sfbay1-mail1.sfbay.sun.com; Sun, 22 Feb 2009 15:05:59 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFH00A00PDQZR00@fe-sfbay-10.sun.com> for jyri@sfbay1-mail1.sfbay.sun.com (ORCPT jyri@sfbay1-mail1.sfbay.sun.com); Sun, 22 Feb 2009 15:05:59 -0800 (PST) Received: from phys-sfbay1-1.sfbay.sun.com ([unknown] [129.145.47.10]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTP id <0KFH00GCVPHZ6YC0@fe-sfbay-10.sun.com> for jyri@sfbay1-mail1.sfbay.sun.com (ORCPT jyri@sfbay1-mail1.sfbay.sun.com); Sun, 22 Feb 2009 15:05:59 -0800 (PST) Received: from sac.sfbay.sun.com ([unknown] [129.146.226.132]) by sfbay1-mail1.sfbay.sun.com (Sun Java(tm) System Messaging Server 7.0-4.01 64bit (built Jan 8 2009)) with ESMTP id <0KFH00DMMPHZHNC0@sfbay1-mail1.sfbay.sun.com> for jyri@sfbay1-mail1.sfbay.sun.com; Sun, 22 Feb 2009 15:05:59 -0800 (PST) Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1MN5wsY024687 for ; Sun, 22 Feb 2009 15:05:58 -0800 (PST) Received: from mumak.SFBay.Sun.COM (loghost [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1MN82T3023085; Sun, 22 Feb 2009 15:08:02 -0800 (PST) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1MN82SC023084; Sun, 22 Feb 2009 15:08:02 -0800 (PST) Resent-date: Tue, 24 Feb 2009 10:56:11 -0800 Date: Sun, 22 Feb 2009 15:08:02 -0800 Resent-from: jyri@sun.com From: Danek Duvall Subject: Re: Apache and APR-Util Using OpenLDAP [LSARC/2009/123 FastTrack timeout 02/27/2009] In-reply-to: <200902220132.n1M1W8l9025891@sac.sfbay.sun.com> Resent-to: lsarc-ext@sun.com To: Jyri Virkki Cc: webstack-discuss@opensolaris.org Resent-message-id: <20090224185611.GA4330@sun.com> Message-id: <20090222230802.GX1905@mumak.SFBay.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: <200902220132.n1M1W8l9025891@sac.sfbay.sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 233 Would the binding problems go away if you linked against openldap with direct binding? I also see that the library is linked against libsendfile and libuuid, which are also unused -- perhaps -z ignore on the link would help? Danek From Jyri.Virkki@sun.com Tue Feb 24 11:02:46 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1OJ2ktI002565 for ; Tue, 24 Feb 2009 11:02:46 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1OJ2fAH014274; Tue, 24 Feb 2009 11:02:45 -0800 (PST) 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 <0KFL00L673KJ0C00@brm-avmta-1.central.sun.com>; Tue, 24 Feb 2009 12:02:43 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFL00D423KJ6T70@brm-avmta-1.central.sun.com>; Tue, 24 Feb 2009 12:02:43 -0700 (MST) Received: from dm-usca19-13.red.iplanet.com (host-179-56-18-192.iplanet.com [192.18.56.179] (may be forged)) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1OJ2gFF023981; Tue, 24 Feb 2009 19:02:43 +0000 (GMT) Received: from buye.red.iplanet.com (buye [192.18.65.224]) by dm-usca19-13.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id n1OJ2gs26229; Tue, 24 Feb 2009 11:02:42 -0800 (PST) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id n1OJ2gHG004860; Tue, 24 Feb 2009 11:02:42 -0800 (PST) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id n1OJ2gCl004859; Tue, 24 Feb 2009 11:02:42 -0800 (PST) Date: Tue, 24 Feb 2009 11:02:42 -0800 From: Jyri Virkki Subject: Re: Apache and APR-Util Using OpenLDAP [LSARC/2009/123 FastTrack timeout 02/27/2009] To: lsarc-ext@sun.com Cc: Jeffrey.Trawick@sun.com Message-id: <20090224190242.GA4801@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 User-Agent: Mutt/1.5.11 Status: RO Content-Length: 1419 (forwarding to case archives) > From: Jeff Trawick > To: webstack-discuss@opensolaris.org > Subject: Re: [webstack-discuss] Apache and APR-Util Using OpenLDAP > [LSARC/2009/123 FastTrack timeout 02/27/2009] > Date: Mon, 23 Feb 2009 12:25:50 -0500 > > Danek Duvall wrote: > >Would the binding problems go away if you linked against openldap with > >direct binding? I also see that the library is linked against libsendfile > >and libuuid, which are also unused -- perhaps -z ignore on the link would > >help? > > > > Although I'm familiar with using linker tricks on other platforms to > deal with multiple ldaps, I'm just finding out exactly what you mean by > the term "direct binding" from the Linker and Libraries Guide. Just so I > don't go off in the wrong direction: > > By "binding problem", you mean two symbols used by different objects in > the process, which have the same name, right? > > And anything in an unused library by definition (of "unused") doesn't > participate in a binding problem, right? > > So you're talking about the potential concern that some other user-added > code uses Solaris libldap, while the OpenSolaris-delivered code running > inside Apache uses OpenLDAP, right? > > APR-Util's apr_ldap.so and httpd could link with OpenLDAP using the > direct binding option so that the use of OpenLDAP would be limited to > those objects, right? From Jeffrey.Trawick@sun.com Tue Feb 24 14:41:58 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 n1OMfv7X028586 for ; Tue, 24 Feb 2009 14:41:57 -0800 (PST) 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 n1OMfvb6044822 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 24 Feb 2009 15:41:57 -0700 (MST) 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 <0KFL00705DPXCG00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 24 Feb 2009 14:41:57 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFL0050GDPWH410@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 24 Feb 2009 14:41:56 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1OMfuEF012156 for ; Tue, 24 Feb 2009 22:41:56 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFL00J00AT91600@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 24 Feb 2009 15:41:56 -0700 (MST) Received: from [10.0.2.15] ([unknown] [71.70.232.5]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFL0081WDPNP7A0@mail-amer.sun.com>; Tue, 24 Feb 2009 15:41:48 -0700 (MST) Date: Tue, 24 Feb 2009 17:41:47 -0500 From: Jeff Trawick Subject: Re: [webstack-discuss] Apache and APR-Util Using OpenLDAP [LSARC/2009/123 FastTrack timeout 02/27/2009] In-reply-to: <20090222230802.GX1905@mumak.SFBay.Sun.COM> Sender: Jeffrey.Trawick@sun.com To: Danek Duvall Cc: LSARC-ext@sun.com, webstack-discuss@opensolaris.org Message-id: <49A477AB.4070005@Sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902220132.n1M1W8l9025891@sac.sfbay.sun.com> <20090222230802.GX1905@mumak.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.19 (X11/20090105) Status: RO Content-Length: 1312 Danek Duvall wrote: > Would the binding problems go away if you linked against openldap with > direct binding? I expect that direct binding can be used to ensure that two objects in the same process can use different LDAP libraries. Here's an example I tried: Build APR-Util with OpenLDAP. Sample app uses APR-Util LDAP APIs; works fine. The app starts calling a shared library which uses native Solaris LDAP, but that shared library unexpectedly uses OpenLDAP when loaded into the APR-Util application. Relink the shared library with "-B direct". Now both pieces use the expected LDAP library. I don't think this is a magic solution for the web stack delivery though. The problem is going to occur when a user creates or otherwise adds some glue that loads something into Apache/PHP/etc. that uses native Solaris LDAP; that glue must bind directly to libldap.so regardless of how the web stack links to OpenLDAP, as I understand it. The user will see a problem and hopefully learn the solution and modify the build of the piece they added. > I also see that the library is linked against libsendfile > and libuuid, which are also unused -- perhaps -z ignore on the link would > help? > I'll experiment with that separately. (The libsendfile issue at least has a more appropriate solution.) From Jeffrey.Trawick@sun.com Tue Feb 24 17:04:16 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1P14Gbb023632 for ; Tue, 24 Feb 2009 17:04:16 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1P140Np000508 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 24 Feb 2009 17:04:16 -0800 (PST) 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 <0KFL0092BKB1LJ00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 24 Feb 2009 18:04:13 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFL00IJGKB0LR60@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 24 Feb 2009 18:04:12 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1P14CMP026831 for ; Wed, 25 Feb 2009 01:04:12 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFL00800JPMJ500@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 24 Feb 2009 18:04:12 -0700 (MST) Received: from [10.0.2.15] ([unknown] [71.70.232.5]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFL00MLQKAZIM00@mail-amer.sun.com>; Tue, 24 Feb 2009 18:04:12 -0700 (MST) Date: Tue, 24 Feb 2009 20:04:11 -0500 From: Jeff Trawick Subject: Re: [webstack-discuss] Apache and APR-Util Using OpenLDAP [LSARC/2009/123 FastTrack timeout 02/27/2009] In-reply-to: <49A477AB.4070005@Sun.com> Sender: Jeffrey.Trawick@sun.com To: webstack-discuss@opensolaris.org Cc: Danek Duvall , LSARC-ext@sun.com Message-id: <49A4990B.4090506@Sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902220132.n1M1W8l9025891@sac.sfbay.sun.com> <20090222230802.GX1905@mumak.SFBay.Sun.COM> <49A477AB.4070005@Sun.com> User-Agent: Thunderbird 2.0.0.19 (X11/20090105) Status: RO Content-Length: 520 Jeff Trawick wrote: > Danek Duvall wrote: . > >> I also see that the library is linked against libsendfile >> and libuuid, which are also unused -- perhaps -z ignore on the link >> would >> help? > > I'll experiment with that separately. (The libsendfile issue at least > has a more appropriate solution.) It turns out that "ldd -u" is not sufficient for detecting unused libraries. libsendfile really is unused; libuuid isn't. "ldd -u -r" might be the solution; I'll start redoing that analysis tomorrow morning. From Jyri.Virkki@sun.com Tue Feb 24 17:20:54 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1P1Krgb023799 for ; Tue, 24 Feb 2009 17:20:53 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1P1Kqdn008905; Tue, 24 Feb 2009 17:20:52 -0800 (PST) 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 <0KFL00A05L2QZ100@nwk-avmta-2.sfbay.sun.com>; Tue, 24 Feb 2009 17:20:50 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFL002N7L2P3M70@nwk-avmta-2.sfbay.sun.com>; Tue, 24 Feb 2009 17:20:50 -0800 (PST) Received: from dm-usca19-13.red.iplanet.com (host-179-56-18-192.iplanet.com [192.18.56.179] (may be forged)) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1P1Kmox013278; Wed, 25 Feb 2009 01:20:48 +0000 (GMT) Received: from buye.red.iplanet.com (buye [192.18.65.224]) by dm-usca19-13.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id n1P1Kms01152; Tue, 24 Feb 2009 17:20:48 -0800 (PST) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id n1P1Kld8015472; Tue, 24 Feb 2009 17:20:47 -0800 (PST) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id n1P1KlwD015471; Tue, 24 Feb 2009 17:20:47 -0800 (PST) Date: Tue, 24 Feb 2009 17:20:47 -0800 From: Jyri Virkki Subject: Re: PHP5 Feature Enhancements [LSARC/2009/124] [LSARC/2009/123] In-reply-to: <18852.28130.713991.974913@gargle.gargle.HOWL> To: James Carlson Cc: Doug Leavitt , webstack-discuss@opensolaris.org, LSARC-ext@sun.com Message-id: <20090225012047.GG10144@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: <200902220157.n1M1vePR027002@sac.sfbay.sun.com> <18851.2453.443161.244404@gargle.gargle.HOWL> <49A319DE.3040401@Sun.com> <18851.6960.184612.482754@gargle.gargle.HOWL> <49A466E4.7070500@sun.com> <18852.28130.713991.974913@gargle.gargle.HOWL> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 1239 James Carlson wrote: > > On the grounds that there's a distinct lack of system architecture > here that would allow the project team to make an informed choice (and > allow the ARC to evaluate that choice), and thus this project is > certainly not "obvious," I ask that either the LSARC chair grant me > temporary standing here so that I can derail, or that (alternatively) > an active LSARC member speak up to pull that lever. Note most of this discussion has been happening in the wrong thread, 2009/123 is the case which switches APR to OpenLDAP. This case, 2009/124 is merely a consequence (what Apache does, PHP must do). I'm derailing 2009/123 myself. If nothing else, the case was filed given the understanding that the contract was ready to go, the change in that status means management has some figuring out to do. > At a minimum, we need to have a written opinion noting that LDAP is a > fundamental system service, and that building it atop a foundation of > sand is a very bad idea. To keep some perspective, what Sun calls volatile sand is what all of these 3rd party applications build their ldap support on and their sky isn't falling from what I'm told. -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From carlsonj@phorcys.east.sun.com Wed Feb 25 07:07:13 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 n1PF7C5N013805 for ; Wed, 25 Feb 2009 07:07:12 -0800 (PST) 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 n1PF76rA057085; Wed, 25 Feb 2009 08:07:12 -0700 (MST) 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 <0KFM00J11NBY7400@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Feb 2009 07:07:10 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFM00H13NBV7T80@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Feb 2009 07:07:07 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1PExQUs012799; Wed, 25 Feb 2009 09:59:26 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n1PExQoJ012796; Wed, 25 Feb 2009 09:59:26 -0500 (EST) Date: Wed, 25 Feb 2009 09:59:26 -0500 From: James Carlson Subject: Re: Apache and APR-Util Using OpenLDAP [LSARC/2009/123] In-reply-to: <20090225012047.GG10144@sun.com> To: Jyri Virkki Cc: Doug Leavitt , webstack-discuss@opensolaris.org, LSARC-ext@sun.com Message-id: <18853.23758.839120.666659@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902220157.n1M1vePR027002@sac.sfbay.sun.com> <18851.2453.443161.244404@gargle.gargle.HOWL> <49A319DE.3040401@Sun.com> <18851.6960.184612.482754@gargle.gargle.HOWL> <49A466E4.7070500@sun.com> <18852.28130.713991.974913@gargle.gargle.HOWL> <20090225012047.GG10144@sun.com> Status: RO Content-Length: 1596 Jyri Virkki writes: > James Carlson wrote: > > > > On the grounds that there's a distinct lack of system architecture > > here that would allow the project team to make an informed choice (and > > allow the ARC to evaluate that choice), and thus this project is > > certainly not "obvious," I ask that either the LSARC chair grant me > > temporary standing here so that I can derail, or that (alternatively) > > an active LSARC member speak up to pull that lever. > > Note most of this discussion has been happening in the wrong thread, > 2009/123 is the case which switches APR to OpenLDAP. This case, > 2009/124 is merely a consequence (what Apache does, PHP must do). Indeed; thanks for the correction. I've updated the subject line to match. > > At a minimum, we need to have a written opinion noting that LDAP is a > > fundamental system service, and that building it atop a foundation of > > sand is a very bad idea. > > To keep some perspective, what Sun calls volatile sand is what all of > these 3rd party applications build their ldap support on and their sky > isn't falling from what I'm told. In that case, "Volatile" might not be the right classification after all. In any event, that's a trivial matter compared to the lack of direction regarding LDAP on Solaris. *That* issue needs to be raised, regardless of the stability attributed to OpenLDAP. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From edh@sun.com Wed Feb 25 10:53:41 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 n1PIrfXh015138 for ; Wed, 25 Feb 2009 10:53:41 -0800 (PST) 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 n1PIrdiV035246 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 25 Feb 2009 11:53:41 -0700 (MST) 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 <0KFM00C4DXTF6P00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 25 Feb 2009 10:53:39 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFM009H2XTBZKC0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 25 Feb 2009 10:53:35 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1PIrZU2005203 for ; Wed, 25 Feb 2009 10:53:35 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFM00J00XKVOC00@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 25 Feb 2009 10:53:35 -0800 (PST) Received: from [129.146.72.131] ([unknown] [129.146.72.131]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFM00819XSTQ700@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 25 Feb 2009 10:53:18 -0800 (PST) Date: Wed, 25 Feb 2009 10:51:42 -0800 From: Edward Hunter Subject: Re: Apache and APR-Util Using OpenLDAP [LSARC/2009/123] In-reply-to: <18853.23758.839120.666659@gargle.gargle.HOWL> Sender: Ed.Hunter@sun.com To: James Carlson Cc: Jyri Virkki , Doug Leavitt , webstack-discuss@opensolaris.org, LSARC-ext@sun.com Message-id: <49A5933E.1040501@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_1X1oDwemOyijOCbH3Sqvqg)" X-PMX-Version: 5.4.1.325704 References: <200902220157.n1M1vePR027002@sac.sfbay.sun.com> <18851.2453.443161.244404@gargle.gargle.HOWL> <49A319DE.3040401@Sun.com> <18851.6960.184612.482754@gargle.gargle.HOWL> <49A466E4.7070500@sun.com> <18852.28130.713991.974913@gargle.gargle.HOWL> <20090225012047.GG10144@sun.com> <18853.23758.839120.666659@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.18 (X11/20081215) Status: RO Content-Length: 4348 This is a multi-part message in MIME format. --Boundary_(ID_1X1oDwemOyijOCbH3Sqvqg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT James, Do you want the ARC to raise the LDAP direction issue or do you think that the project team needs to deal with that? Certainly, the chair could send a note to the appropriate management. -edh On 02/25/09 06:59, James Carlson wrote: > Jyri Virkki writes: > >> James Carlson wrote: >> >>> On the grounds that there's a distinct lack of system architecture >>> here that would allow the project team to make an informed choice (and >>> allow the ARC to evaluate that choice), and thus this project is >>> certainly not "obvious," I ask that either the LSARC chair grant me >>> temporary standing here so that I can derail, or that (alternatively) >>> an active LSARC member speak up to pull that lever. >>> >> Note most of this discussion has been happening in the wrong thread, >> 2009/123 is the case which switches APR to OpenLDAP. This case, >> 2009/124 is merely a consequence (what Apache does, PHP must do). >> > > Indeed; thanks for the correction. I've updated the subject line to > match. > > >>> At a minimum, we need to have a written opinion noting that LDAP is a >>> fundamental system service, and that building it atop a foundation of >>> sand is a very bad idea. >>> >> To keep some perspective, what Sun calls volatile sand is what all of >> these 3rd party applications build their ldap support on and their sky >> isn't falling from what I'm told. >> > > In that case, "Volatile" might not be the right classification after > all. > > In any event, that's a trivial matter compared to the lack of > direction regarding LDAP on Solaris. *That* issue needs to be raised, > regardless of the stability attributed to OpenLDAP. > > --Boundary_(ID_1X1oDwemOyijOCbH3Sqvqg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT James,
  Do you want the ARC to raise the LDAP direction issue or do you think that the project team needs to deal with that?  Certainly, the chair could send a note to the appropriate management.
-edh


On 02/25/09 06:59, James Carlson wrote: 
Jyri Virkki writes:
  
James Carlson wrote:
    
On the grounds that there's a distinct lack of system architecture
here that would allow the project team to make an informed choice (and
allow the ARC to evaluate that choice), and thus this project is
certainly not "obvious," I ask that either the LSARC chair grant me
temporary standing here so that I can derail, or that (alternatively)
an active LSARC member speak up to pull that lever.
      
Note most of this discussion has been happening in the wrong thread,
2009/123 is the case which switches APR to OpenLDAP. This case,
2009/124 is merely a consequence (what Apache does, PHP must do).
    

Indeed; thanks for the correction.  I've updated the subject line to
match.

  
At a minimum, we need to have a written opinion noting that LDAP is a
fundamental system service, and that building it atop a foundation of
sand is a very bad idea.
      
To keep some perspective, what Sun calls volatile sand is what all of
these 3rd party applications build their ldap support on and their sky
isn't falling from what I'm told.
    

In that case, "Volatile" might not be the right classification after
all.

In any event, that's a trivial matter compared to the lack of
direction regarding LDAP on Solaris.  *That* issue needs to be raised,
regardless of the stability attributed to OpenLDAP.
--Boundary_(ID_1X1oDwemOyijOCbH3Sqvqg)-- From carlsonj@phorcys.east.sun.com Wed Feb 25 11:11: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 n1PJBu40015723 for ; Wed, 25 Feb 2009 11:11:56 -0800 (PST) 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 n1PJBqJ6027765; Wed, 25 Feb 2009 19:11:53 GMT 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 <0KFM0020BYNTKH00@brm-avmta-1.central.sun.com>; Wed, 25 Feb 2009 12:11:53 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFM002HQYNS3L00@brm-avmta-1.central.sun.com>; Wed, 25 Feb 2009 12:11:53 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1PJ4B5F019568; Wed, 25 Feb 2009 14:04:11 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n1PJ4BsW019565; Wed, 25 Feb 2009 14:04:11 -0500 (EST) Date: Wed, 25 Feb 2009 14:04:11 -0500 From: James Carlson Subject: Re: Apache and APR-Util Using OpenLDAP [LSARC/2009/123] In-reply-to: <49A5933E.1040501@sun.com> To: Edward Hunter Cc: Jyri Virkki , Doug Leavitt , webstack-discuss@opensolaris.org, LSARC-ext@sun.com Message-id: <18853.38443.75719.441054@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902220157.n1M1vePR027002@sac.sfbay.sun.com> <18851.2453.443161.244404@gargle.gargle.HOWL> <49A319DE.3040401@Sun.com> <18851.6960.184612.482754@gargle.gargle.HOWL> <49A466E4.7070500@sun.com> <18852.28130.713991.974913@gargle.gargle.HOWL> <20090225012047.GG10144@sun.com> <18853.23758.839120.666659@gargle.gargle.HOWL> <49A5933E.1040501@sun.com> Status: RO Content-Length: 1182 Edward Hunter writes: > Do you want the ARC to raise the LDAP direction issue or do you think > that the project team needs to deal with that? Certainly, the chair > could send a note to the appropriate management. I think this is something the ARC needs to drive formally. If the project team members want to bring it up as well, that's great, and it would help highlight the issue that we're still doing work in an area where we've defunded the basic system architecture. The harder call is what to do about _this_ project. If I were given a vote, I would argue first for a case dependency on a to-be-named future project that resolves the OpenLDAP versus Native LDAP conflict and sets direction. Failing that, I'd be forced to vote to deny. I still don't think the project team is necessarily doing anything wrong, and the resulting change may well be for the good, but the lack of direction here is just not tolerable. It's not architecture. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Jyri.Virkki@sun.com Wed Feb 25 11:21:58 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 n1PJLvGI015943 for ; Wed, 25 Feb 2009 11:21:58 -0800 (PST) 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 n1PJL5F8004250; Wed, 25 Feb 2009 19:21:55 GMT 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 <0KFM00H0DZ4ENW00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Feb 2009 11:21:50 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFM009SWZ4EZ7E0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Feb 2009 11:21:50 -0800 (PST) Received: from dm-usca15-11.red.iplanet.com (host-185-56-18-192.iplanet.com [192.18.56.185] (may be forged)) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1PJLmSN021521; Wed, 25 Feb 2009 19:21:49 +0000 (GMT) Received: from buye.red.iplanet.com (buye [192.18.65.224]) by dm-usca15-11.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id n1PJLm029857; Wed, 25 Feb 2009 11:21:48 -0800 (PST) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id n1PJLmgb014234; Wed, 25 Feb 2009 11:21:48 -0800 (PST) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id n1PJLmdZ014233; Wed, 25 Feb 2009 11:21:48 -0800 (PST) Date: Wed, 25 Feb 2009 11:21:48 -0800 From: Jyri Virkki Subject: Re: Apache and APR-Util Using OpenLDAP [LSARC/2009/123] In-reply-to: <18853.23758.839120.666659@gargle.gargle.HOWL> To: James Carlson Cc: Doug Leavitt , LSARC-ext@sun.com, webstack-discuss@opensolaris.org Message-id: <20090225192148.GD8913@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: <200902220157.n1M1vePR027002@sac.sfbay.sun.com> <18851.2453.443161.244404@gargle.gargle.HOWL> <49A319DE.3040401@Sun.com> <18851.6960.184612.482754@gargle.gargle.HOWL> <49A466E4.7070500@sun.com> <18852.28130.713991.974913@gargle.gargle.HOWL> <20090225012047.GG10144@sun.com> <18853.23758.839120.666659@gargle.gargle.HOWL> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 1676 James Carlson wrote: > > > To keep some perspective, what Sun calls volatile sand is what all of > > these 3rd party applications build their ldap support on and their sky > > isn't falling from what I'm told. > > In that case, "Volatile" might not be the right classification after > all. Perhaps. My sense is that some parts of OpenLDAP APIs are stable (and some apps use only those parts) while other parts are unpredictable, but that's just hearsay. It's up to the team owning OpenLDAP (whoever that is or ends up being) to figure that out. > In any event, that's a trivial matter compared to the lack of > direction regarding LDAP on Solaris. *That* issue needs to be raised, > regardless of the stability attributed to OpenLDAP. Going back to 2009/123, the SWI org management is unlikely to fund any core Solaris work (not that I speak for them or make those decisions, just seems unlikely). Solaris org management will need to handle that. Unfortunately it seems they have already spoken very clearly on the matter (via the non-existence of a team). We can certainly try another "advice to PAC" opinion as we did back in 2006/582, though I remain unconvinced anyone outside ARC reads those. What I don't want to see is a situation where Sun prevents the vast majority of non-Sun applications from having working LDAP support on Solaris (and only on Solaris since they all are known to work fine with OpenLDAP elsewhere) simply because Solaris org hasn't figured out their internal LDAP strategy. It's the kind of thing which prevents Solaris from being taken seriously by developers and deployers. -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From carlsonj@phorcys.east.sun.com Wed Feb 25 11:38:44 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 n1PJchoP016156 for ; Wed, 25 Feb 2009 11:38:43 -0800 (PST) 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 n1PJcbeg017331; Wed, 25 Feb 2009 19:38:40 GMT 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 <0KFM00505ZWE6900@brm-avmta-1.central.sun.com>; Wed, 25 Feb 2009 12:38:38 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFM002BJZWE3T20@brm-avmta-1.central.sun.com>; Wed, 25 Feb 2009 12:38:38 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1PJUuJt026385; Wed, 25 Feb 2009 14:30:56 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n1PJUu1a026382; Wed, 25 Feb 2009 14:30:56 -0500 (EST) Date: Wed, 25 Feb 2009 14:30:56 -0500 From: James Carlson Subject: Re: Apache and APR-Util Using OpenLDAP [LSARC/2009/123] In-reply-to: <20090225192148.GD8913@sun.com> To: Jyri Virkki Cc: Doug Leavitt , LSARC-ext@sun.com, webstack-discuss@opensolaris.org Message-id: <18853.40048.82946.283530@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902220157.n1M1vePR027002@sac.sfbay.sun.com> <18851.2453.443161.244404@gargle.gargle.HOWL> <49A319DE.3040401@Sun.com> <18851.6960.184612.482754@gargle.gargle.HOWL> <49A466E4.7070500@sun.com> <18852.28130.713991.974913@gargle.gargle.HOWL> <20090225012047.GG10144@sun.com> <18853.23758.839120.666659@gargle.gargle.HOWL> <20090225192148.GD8913@sun.com> Status: RO Content-Length: 1307 Jyri Virkki writes: > What I don't want to see is a situation where Sun prevents the vast > majority of non-Sun applications from having working LDAP support on > Solaris (and only on Solaris since they all are known to work fine > with OpenLDAP elsewhere) simply because Solaris org hasn't figured out > their internal LDAP strategy. It's the kind of thing which prevents > Solaris from being taken seriously by developers and deployers. I completely agree. I just do not agree that ignoring the problem will in fact solve it. Our job here isn't to figure out business strategy or how to pay for the projects needed; it's to review architectural changes to a system. Where the system is lacking in architecture, we're obligated to complain about it. If we don't, then we have no function. If "do what everybody else does without regard to overall architecture" is indeed the intended strategy, then let's just not bother with the fiction of architectural review. It's not as though this is the only thing on my plate, or even the thing most important to my management chain. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Matt.Ingenthron@sun.com Wed Feb 25 11:58:23 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 n1PJwMHM016665 for ; Wed, 25 Feb 2009 11:58:22 -0800 (PST) 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 n1PJw2cw001399 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 25 Feb 2009 19:58:21 GMT 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 <0KFN006110T96200@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 25 Feb 2009 11:58:21 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFN00JK00T8JTD0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 25 Feb 2009 11:58:20 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1PJwJM0017779 for ; Wed, 25 Feb 2009 19:58:19 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFN00H000BWWQ00@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 25 Feb 2009 12:58:19 -0700 (MST) Received: from [129.146.123.62] ([unknown] [129.146.123.62]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFN00COB0SXIP70@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 25 Feb 2009 12:58:10 -0700 (MST) Date: Wed, 25 Feb 2009 11:58:08 -0800 From: Matt Ingenthron Subject: Re: [webstack-discuss] Apache and APR-Util Using OpenLDAP [LSARC/2009/123] In-reply-to: <20090225192148.GD8913@sun.com> Sender: Matt.Ingenthron@sun.com To: Jyri Virkki Cc: James Carlson , webstack-discuss@opensolaris.org, LSARC-ext@sun.com, Doug Leavitt Message-id: <49A5A2D0.5000401@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: <200902220157.n1M1vePR027002@sac.sfbay.sun.com> <18851.2453.443161.244404@gargle.gargle.HOWL> <49A319DE.3040401@Sun.com> <18851.6960.184612.482754@gargle.gargle.HOWL> <49A466E4.7070500@sun.com> <18852.28130.713991.974913@gargle.gargle.HOWL> <20090225012047.GG10144@sun.com> <18853.23758.839120.666659@gargle.gargle.HOWL> <20090225192148.GD8913@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.8.1.17) Gecko/20081023 Lightning/0.9 Thunderbird/2.0.0.17 Mnenhy/0.7.6.666 Status: RO Content-Length: 4191 Jyri Virkki wrote: > James Carlson wrote: > >>> To keep some perspective, what Sun calls volatile sand is what all of >>> these 3rd party applications build their ldap support on and their sky >>> isn't falling from what I'm told. >>> >> In that case, "Volatile" might not be the right classification after >> all. >> > > Perhaps. My sense is that some parts of OpenLDAP APIs are stable (and > some apps use only those parts) while other parts are unpredictable, > but that's just hearsay. It's up to the team owning OpenLDAP (whoever > that is or ends up being) to figure that out. > My apologies if this is obvious to some of you, but the paragraphs above don't go with the ARC definitions here, does it? As David Comay educated me on once before, "volatile" doesn't say anything about the code/API stability directly. It defines the contract between the dependencies in OpenSolaris, and therefore says something about what the owner will/can do with updates to the package. From a recent doecument (October 2008): The following are the (new) relevant Public taxonomy levels: Stable: The interface may only change incompatibly in a Major release. Interfaces intended for usage by ISVs and system integrators require this level of support to be useful to these customers. Uncommitted: May only change incompatibly in a Major or Minor release. This is appropriate for some system management facilities and new, untested interfaces. Volatile: May change in any release vehicle. This usually only useful when the interface definition is controlled by a body other than the OpenSolaris community and it is viewed that tracking that community is more important than interface compatibility. Not an Interface: Just a convenience term to label what may appear to a supported interface as not being supported. This is the default classification and this term is only explicitly applied when there is likely to be confusion. The precise terms for the public taxonomy levels is still under discussion, as part of the update to the Interface Taxonomy document. Note that the ability to make an incompatible change in a given release vehicle does not make that a requirement. For example, most interfaces controlled by someone other than the OpenSolaris community are currently classified as Volatile, but synchronization with major incompatibilities introduced by those communities is often deferred until a Minor release is available. It's not clear to me if is updated or not. A lot of this is moot for the Apache/PHP<->OpenLDAP since the Apache/PHP projects (which we aim to integrate without core modification as much as possible) already tracks the OpenLDAP project. I can't speak for other components depending on OpenLDAP, but it would seem that trying to artificially hold back any component would actually cause more harm than good. The only difficulty comes in if various components depending on OpenLDAP diverge. Since the interface definition says this thing may change at any time, doesn't that effectively turn the contract around and say "depend on it, but recognize that you'll be responsible for dealing with any updates that happen to hit you". For the vast majority of things in OpenSolaris which would depend on it, this is probably okay since the upstream projects have demonstrated years of being generally in synch or having reasonably stable interfaces between each other. At least, that's my impression since it just works on other platforms. Prior docs said you shouldn't depend upon things classified as volatile at all, but this has been updated for OpenSolaris as I understand it. Then again, I'm not in engineering.... but I do know that there has to be a reasonably simple resolution here. The functional requirement has come up in Sun deployments of PHP. It's an extremely common use case. Again, my apologies if this is obvious to everyone or I'm way off base here. - Matt From carlsonj@phorcys.east.sun.com Wed Feb 25 15:24:09 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 n1PNO9b9024320 for ; Wed, 25 Feb 2009 15:24:09 -0800 (PST) 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 n1PNO64h014895; Wed, 25 Feb 2009 15:24:08 -0800 (PST) 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 <0KFN00I0ZAC74F00@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Feb 2009 15:24:07 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFN00FO9AC74I60@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Feb 2009 15:24:07 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1PJ4B5F019568; Wed, 25 Feb 2009 14:04:11 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n1PJ4BsW019565; Wed, 25 Feb 2009 14:04:11 -0500 (EST) Date: Wed, 25 Feb 2009 14:04:11 -0500 From: James Carlson Subject: Re: Apache and APR-Util Using OpenLDAP [LSARC/2009/123] In-reply-to: <49A5933E.1040501@sun.com> To: Edward Hunter Cc: Jyri Virkki , Doug Leavitt , webstack-discuss@opensolaris.org, LSARC-ext@sun.com Message-id: <18853.38443.75719.441054@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902220157.n1M1vePR027002@sac.sfbay.sun.com> <18851.2453.443161.244404@gargle.gargle.HOWL> <49A319DE.3040401@Sun.com> <18851.6960.184612.482754@gargle.gargle.HOWL> <49A466E4.7070500@sun.com> <18852.28130.713991.974913@gargle.gargle.HOWL> <20090225012047.GG10144@sun.com> <18853.23758.839120.666659@gargle.gargle.HOWL> <49A5933E.1040501@sun.com> Status: RO Content-Length: 1182 Edward Hunter writes: > Do you want the ARC to raise the LDAP direction issue or do you think > that the project team needs to deal with that? Certainly, the chair > could send a note to the appropriate management. I think this is something the ARC needs to drive formally. If the project team members want to bring it up as well, that's great, and it would help highlight the issue that we're still doing work in an area where we've defunded the basic system architecture. The harder call is what to do about _this_ project. If I were given a vote, I would argue first for a case dependency on a to-be-named future project that resolves the OpenLDAP versus Native LDAP conflict and sets direction. Failing that, I'd be forced to vote to deny. I still don't think the project team is necessarily doing anything wrong, and the resulting change may well be for the good, but the lack of direction here is just not tolerable. It's not architecture. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Jyri.Virkki@sun.com Wed Feb 25 15:48:39 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 n1PNmcrI005704 for ; Wed, 25 Feb 2009 15:48:38 -0800 (PST) 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 n1PNmYwC019577; Thu, 26 Feb 2009 07:48:34 +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 <0KFN00001BGX2G00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Feb 2009 15:48:33 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFN00GKBBGWBED0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Feb 2009 15:48:33 -0800 (PST) Received: from dm-usca19-13.red.iplanet.com (host-179-56-18-192.iplanet.com [192.18.56.179] (may be forged)) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1PNmV7B003798; Wed, 25 Feb 2009 23:48:31 +0000 (GMT) Received: from buye.red.iplanet.com (buye [192.18.65.224]) by dm-usca19-13.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id n1PNmVs14110; Wed, 25 Feb 2009 15:48:31 -0800 (PST) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id n1PNmVJw022035; Wed, 25 Feb 2009 15:48:31 -0800 (PST) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id n1PNmV7A022034; Wed, 25 Feb 2009 15:48:31 -0800 (PST) Date: Wed, 25 Feb 2009 15:48:31 -0800 From: Jyri Virkki Subject: Re: [webstack-discuss] Apache and APR-Util Using OpenLDAP [LSARC/2009/123] In-reply-to: <49A5A2D0.5000401@sun.com> To: Matt Ingenthron Cc: webstack-discuss@opensolaris.org, LSARC-ext@sun.com, Doug Leavitt Message-id: <20090225234831.GD19533@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: <200902220157.n1M1vePR027002@sac.sfbay.sun.com> <18851.2453.443161.244404@gargle.gargle.HOWL> <49A319DE.3040401@Sun.com> <18851.6960.184612.482754@gargle.gargle.HOWL> <49A466E4.7070500@sun.com> <18852.28130.713991.974913@gargle.gargle.HOWL> <20090225012047.GG10144@sun.com> <18853.23758.839120.666659@gargle.gargle.HOWL> <20090225192148.GD8913@sun.com> <49A5A2D0.5000401@sun.com> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 1254 Matt Ingenthron wrote: > > >Perhaps. My sense is that some parts of OpenLDAP APIs are stable (and > >some apps use only those parts) while other parts are unpredictable, > >but that's just hearsay. It's up to the team owning OpenLDAP (whoever > >that is or ends up being) to figure that out. > > My apologies if this is obvious to some of you, but the paragraphs above > don't go with the ARC definitions here, does it? Yes ;-) I was specifically avoiding the words with double meaning (regular English adjectives vs. Sun [current] interface taxonomy) to try to avoid confusion. It's up to the project team delivering OpenLDAP to create the mapping based on what they decide to guarantee. > (October 2008): > > The following are the (new) relevant Public taxonomy levels: > > Stable: The interface may only change incompatibly in a Major Don't know what the above doc is but looks like it is out of date, "Stable" went out of fashion several years ago. Latest should be here: http://opensolaris.org/os/community/arc/policies/interface-taxonomy/ ("should be" because page has been loading for ~5 minutes now and not done) -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From Jyri.Virkki@sun.com Mon Mar 2 12:24:22 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 n22KOLXA013558 for ; Mon, 2 Mar 2009 12:24:22 -0800 (PST) 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 n22KOJ1x007936 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Mon, 2 Mar 2009 13:24:21 -0700 (MST) 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 <0KFW0070NBCJ6400@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 02 Mar 2009 12:24:19 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFW0037KBCJEN40@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 02 Mar 2009 12:24:19 -0800 (PST) Received: from dm-usca15-11.red.iplanet.com (host-185-56-18-192.iplanet.com [192.18.56.185] (may be forged)) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n22KOIuB013701; Mon, 02 Mar 2009 20:24:18 +0000 (GMT) Received: from buye.red.iplanet.com (buye [192.18.65.224]) by dm-usca15-11.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id n22KOH012764; Mon, 02 Mar 2009 12:24:17 -0800 (PST) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id n22KOHx7017947; Mon, 02 Mar 2009 12:24:17 -0800 (PST) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id n22KOHB2017946; Mon, 02 Mar 2009 12:24:17 -0800 (PST) Date: Mon, 02 Mar 2009 12:24:17 -0800 From: Jyri Virkki Subject: Re: Apache and APR-Util Using OpenLDAP [LSARC/2009/123 FastTrack timeout 02/27/2009] In-reply-to: <200902220132.n1M1W8l9025891@sac.sfbay.sun.com> To: LSARC-ext@sun.com Cc: webstack-discuss@opensolaris.org Message-id: <20090302202417.GA17936@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: <200902220132.n1M1W8l9025891@sac.sfbay.sun.com> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 567 > 1. Introduction > 1.1. Project/Component Working Name: > Apache and APR-Util Using OpenLDAP > 1.2. Name of Document Author/Supplier: > Author: Jeff Trawick > 1.3 Date of This Document: > 21 February, 2009 As I'm still waiting to hear from various involved management chains on the details of how they plan to proceed with project direction, I've placed this case in "waiting need spec" for the moment. I'll update status and reschedule a time slot when those issues are sorted out. -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems