From nw141292@sac.sfbay.sun.com Wed Aug 6 22:02:14 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 m7752EVC010956 for ; Wed, 6 Aug 2008 22:02:14 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7752Aoa063630; Wed, 6 Aug 2008 23:02:13 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K570060PSNN5300@nwk-avmta-1.sfbay.Sun.COM>; Wed, 06 Aug 2008 22:02:11 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5700I22SNMFD60@nwk-avmta-1.sfbay.Sun.COM>; Wed, 06 Aug 2008 22:02:10 -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 m7752Acs028667; Wed, 06 Aug 2008 22:02:10 -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 m77525PS010950; Wed, 06 Aug 2008 22:02:05 -0700 (PDT) Received: (from nw141292@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m77525xG010946; Wed, 06 Aug 2008 22:02:05 -0700 (PDT) Date: Wed, 06 Aug 2008 22:02:05 -0700 (PDT) From: Nicolas Williams Subject: OpenLDAP for OpenSolaris [PSARC/2008/507 FastTrack timeout 07/13/2008] To: PSARC-ext@sun.com Cc: Doug.Leavitt@sun.com Message-id: <200808070502.m77525xG010946@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 35787 Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: OpenLDAP for OpenSolaris 1.2. Name of Document Author/Supplier: Author: Douglas Leavitt 1.3 Date of This Document: 06 August, 2008 4. Technical Description Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: OpenLDAP 1.2. Name of Document Author/Supplier: Author: Doug Leavitt 1.3 Date of This Document: 6 August, 2008 4. Technical Description Release binding: micro/patch (with no intention to backport). 1. Summary OpenLDAP is a popular LDAP distribution that provides an LDAP server, library and tools set found in most open source distributions. OpenLDAP provides an alternative set of LDAP libraries and tools as compared to the set of Mozilla tools currently found in Solaris/OpenSolaris and the SJS directory server product lines (DSEE). The OpenLDAP project also delivers an alternative directory server to the DSEE product line and the directory server delivered by the OpenDS project. This case proposes to integrate the project's latest release for general use in Solaris (at the time of writing, this is OpenLDAP-2.4.11). 2. Details While, from a Solaris perspective, there are a number of features that OpenLDAP lacks, this case proposes to integrate it anyway. The main reason to provide OpenLDAP on Solaris is to enable developers to adopt Solaris more easily because OpenLDAP is used by a large number of FOSS projects, primarily in the Linux community. The lack of OpenLDAP support in Solaris is considered an impediment to many developers when considering porting applications to Solaris/OpenSolaris. For this case, we propose to integrate the current version of OpenLDAP as is. We acknowledge that Solaris specific additions to OpenLDAP, such as making the OpenLDAP libldap library MT safe by default, would make OpenLDAP a better Solaris citizen, but we defer those additions to future projects based on the willingness of the OpenLDAP community to invest in/accept Sun developed enhancements. 2.1 Library Interface differences and issues Currently the Mozilla LDAP project (for which Sun bases it's Solaris libldap.so.5 and DSEE bases libldap6) and the OpenLDAP projects have shown no interest in working together to produce a more unified API. As a result, beyond some basic LDAP C API's defined by RFC 1823: http://www.ietf.org/rfc/rfc1823.txt both API code bases diverge in a great many ways including headers, APIs for TLS connections and many post RFC 1823 extensions. As a result, application developers are forced choose to code to a specific library API since no standard (such as POSIX) LDAP API exists. The primary use of the current Mozilla libldap code base, in Linux and excluding Solaris and SJS DSEE distributions, is as one of the sub-component libraries distributed in with Mozilla thunderbird. Almost all other known Linux FOSS based utilities using LDAP, use OpenLDAP libraries by default. The current maintainers of the Mozilla LDAP code base are currently expressing no interest in continuing to enhance Mozilla libldap beyond existing minimal maintenance efforts. In reality the OpenLDAP distribution is moving forward, while the Mozilla distribution has stagnated. Today, Solaris/OpenSolaris is the only major distribution that does not deliver the OpenLDAP libldap C APIs. This project corrects this issue. The netrep team is investigating the potential future task of transitioning OpenSolaris [nss_ldap/ldapsearch etc.] off the Mozilla libldap components and onto the OpenLDAP components. This effort is as of yet, not scoped. It is expected the project team will first need to work with the OpenLDAP team to deliver key enhancements, such as multi threading improvements to OpenLDAP libldap MT hot by default before a transition could occur. Currently this effort has not been scheduled. 2.1. OpenLDAP LDAP Server The OpenLDAP server is the primary focus of development in the OpenLDAP community. This code is under continuous development. The community currently makes new distribution deliveries approximately every 6 to 8 weeks. Netrep plans to engage with the community but we currently do not plan to invest any effort into LDAP server development. We only plan to continue to deliver "as is" updates from the OpenLDAP project as they become available. 2.2 LDAP Server/Berkeley BDB The OpenLDAP LDAP server uses Berkeley BDB. Compliant with Sun's Oracle/Berkeley BDB licensing requirements, we build and compile into OpenLDAP slapd, a static copy of BDB 4.5.20 per Sun's current licensing restrictions. Once BDB becomes generally available for use in the SFW consolidation, and/or is updated to a newer version, the OpenLDAP build will be updated accordingly. 2.3 Directory Structure The OpenLDAP project does not deliver any binary distributions. This project delivers a file layout that properly maps into the Solaris structure and closely follows the directory structure deployed in the Debian and RPM distributions. The two caveats are: 1) The Solaris include files are placed in /usr/include/openldap so they do not to collide with the Mozilla headers in /usr/include. 2) the /usr/bin/ldap* commands are prefixed with "o" [as in /usr/bin/oldapsearch] so they do not collide with the existing ldap* Mozilla utilities in /usr/bin. The OpenLDAP library names match known Linux/*BSD distributions. Slapd server databases will be created, by default, in /var/openldap. It should be noted that the OpenLDAP slapd server uses a configuration file to specify the location of the databases and so this default can be easily changed. 2.4 Release bindings The OpenLDAP project roughly follows a Major.Minor.Patch numbering scheme, but does not state that the project won't break compatibility across any specific release boundary. The Major.Minor.Patch revision scheme is based on the bug fixes and the functional enhancements made during any given 6-8 week release cycle. Given the rapidity of release, and the fact that new releases usually revise both the libraries and the server, plus the unspecified compatibility rules across releases, the majority of the interfaces for this project are classified as Volatile. 2.5 SMF Manifest and Runtime behavior This project proposes to provide a SMF manifest, disabled by default, for the OpenLDAP slapd server. The slapd server has the ability to change it's user and group and run as a non-privileged user after binding listener sockets to the privileged LDAP port(s). Generally slapd is run as user openldap and group openldap. The SMF manifest will start slapd as root and with privileges but configured to become openldap:openldap; slapd will retain basic privileges. This project proposes to update the following databases to provide the the necessary dummy openldap user and group entries: Database Entry -------- ----- /etc/passwd openldap:x:75:75:OpenLDAP User:/: /etc/shadow openldap:*LK*::::::: /etc/group openldap::75: 4. Interface table This case delivers the following interfaces: +-------------------------------------------------------------------------+ |Exported Interfaces Classification Comments| |-------------------------------------------------------------------------| |SUNWopenldapr Uncommitted Package name| |/etc/openldap Uncommitted Directory| |/etc/openldap/DB_CONFIG.example Volatile example config| |/etc/openldap/ldap.conf Volatile example config| |/etc/openldap/ldap.conf.default Volatile example config| |/etc/openldap/schema Volatile Directory| |/etc/openldap/schema/README Volatile static config| |/etc/openldap/schema/collective.schema Volatile static config| |/etc/openldap/schema/corba.schema Volatile static config| |/etc/openldap/schema/core.ldif Volatile static config| |/etc/openldap/schema/core.schema Volatile static config| |/etc/openldap/schema/cosine.ldif Volatile static config| |/etc/openldap/schema/cosine.schema Volatile static config| |/etc/openldap/schema/duaconf.schema Volatile static config| |/etc/openldap/schema/dyngroup.schema Volatile static config| |/etc/openldap/schema/inetorgperson.ldif Volatile static config| |/etc/openldap/schema/inetorgperson.schema Volatile static config| |/etc/openldap/schema/java.schema Volatile static config| |/etc/openldap/schema/misc.schema Volatile static config| |/etc/openldap/schema/nadf.schema Volatile static config| |/etc/openldap/schema/nis.ldif Volatile static config| |/etc/openldap/schema/nis.schema Volatile static config| |/etc/openldap/schema/openldap.ldif Volatile static config| |/etc/openldap/schema/openldap.schema Volatile static config| |/etc/openldap/schema/ppolicy.schema Volatile static config| |/etc/openldap/slapd.conf Volatile example config| |/var/openldap Uncommitted Directory| |/var/svc/manifest/network/ldap/ldap-olslapd.xml Uncommitted smf manifest| |svc:/network/ldap/server:openldap_24 Uncommitted FMRI| | | |SUNWopenldapu Uncommitted Package name| |/usr/include/openldap Uncommitted Directory| |/usr/bin/${MACH64}/oldapadd Volatile CLI tool| |/usr/bin/${MACH64}/oldapcompare Volatile CLI tool| |/usr/bin/${MACH64}/oldapdelete Volatile CLI tool| |/usr/bin/${MACH64}/oldapexop Volatile CLI tool| |/usr/bin/${MACH64}/oldapmodify Volatile CLI tool| |/usr/bin/${MACH64}/oldapmodrdn Volatile CLI tool| |/usr/bin/${MACH64}/oldappasswd Volatile CLI tool| |/usr/bin/${MACH64}/oldapsearch Volatile CLI tool| |/usr/bin/${MACH64}/oldapwhoami Volatile CLI tool| |/usr/bin/oldapadd Volatile CLI tool| |/usr/bin/oldapcompare Volatile CLI tool| |/usr/bin/oldapdelete Volatile CLI tool| |/usr/bin/oldapexop Volatile CLI tool| |/usr/bin/oldapmodify Volatile CLI tool| |/usr/bin/oldapmodrdn Volatile CLI tool| |/usr/bin/oldappasswd Volatile CLI tool| |/usr/bin/oldapsearch Volatile CLI tool| |/usr/bin/oldapwhoami Volatile CLI tool| |/usr/include/openldap Uncommitted Directory| |/usr/include/openldap/lber.h Volatile header file| |/usr/include/openldap/lber_types.h Volatile header file| |/usr/include/openldap/ldap.h Volatile header file| |/usr/include/openldap/ldap_cdefs.h Volatile header file| |/usr/include/openldap/ldap_features.h Volatile header file| |/usr/include/openldap/ldap_schema.h Volatile header file| |/usr/include/openldap/ldap_utf8.h Volatile header file| |/usr/include/openldap/slapi-plugin.h Volatile header file| |/usr/lib/${MACH64}/liblber-2.4.so Volatile sym link| |/usr/lib/${MACH64}/liblber-2.4.so.2 Volatile sym link| |/usr/lib/${MACH64}/liblber-2.4.so.2.1.0 Volatile shared library| |/usr/lib/${MACH64}/libldap-2.4.so Volatile sym link| |/usr/lib/${MACH64}/libldap-2.4.so.2 Volatile sym link| |/usr/lib/${MACH64}/libldap-2.4.so.2.1.0 Volatile shared library| |/usr/lib/${MACH64}/libldap_r-2.4.so Volatile sym link| |/usr/lib/${MACH64}/libldap_r-2.4.so.2 Volatile sym link| |/usr/lib/${MACH64}/libldap_r-2.4.so.2.1.0 Volatile shared library| |/usr/lib/liblber-2.4.so Volatile sym link| |/usr/lib/liblber-2.4.so.2 Volatile sym link| |/usr/lib/liblber-2.4.so.2.1.0 Volatile shared library| |/usr/lib/libldap-2.4.so Volatile sym link| |/usr/lib/libldap-2.4.so.2 Volatile sym link| |/usr/lib/libldap-2.4.so.2.1.0 Volatile shared library| |/usr/lib/libldap_r-2.4.so Volatile sym link| |/usr/lib/libldap_r-2.4.so.2 Volatile sym link| |/usr/lib/libldap_r-2.4.so.2.1.0 Volatile shared library| |/usr/lib/slapd Volatile LDAP server| |/usr/lib/${MACH64}/slapd Volatile LDAP server| |/usr/sbin/${MACH64}/slapacl Volatile slapd sym link| |/usr/sbin/${MACH64}/slapadd Volatile slapd sym link| |/usr/sbin/${MACH64}/slapauth Volatile slapd sym link| |/usr/sbin/${MACH64}/slapcat Volatile slapd sym link| |/usr/sbin/${MACH64}/slapdn Volatile slapd sym link| |/usr/sbin/${MACH64}/slapindex Volatile slapd sym link| |/usr/sbin/${MACH64}/slappasswd Volatile slapd sym link| |/usr/sbin/${MACH64}/slaptest Volatile slapd sym link| |/usr/sbin/slapacl Volatile slapd sym link| |/usr/sbin/slapadd Volatile slapd sym link| |/usr/sbin/slapauth Volatile slapd sym link| |/usr/sbin/slapcat Volatile slapd sym link| |/usr/sbin/slapdn Volatile slapd sym link| |/usr/sbin/slapindex Volatile slapd sym link| |/usr/sbin/slappasswd Volatile slapd sym link| |/usr/sbin/slaptest Volatile slapd sym link| |/usr/share/doc/openldap Uncommitted Directory| |/usr/share/doc/openldap/admin24 Volatile Directory| |.../admin24/allmail-en.png Volatile Admin doc| |.../admin24/allusersgroup-en.png Volatile Admin doc| |.../admin24/config_dit.png Volatile Admin doc| |.../admin24/config_local.png Volatile Admin doc| |.../admin24/config_ref.png Volatile Admin doc| |.../admin24/config_repl.png Volatile Admin doc| |.../admin24/dual_dc.png Volatile Admin doc| |.../admin24/guide.html Volatile Admin doc| |.../admin24/index.html Volatile Admin doc| |.../admin24/intro_dctree.png Volatile Admin doc| |.../admin24/intro_tree.png Volatile Admin doc| |.../admin24/push-based-complete.png Volatile Admin doc| |.../admin24/push-based-standalone.png Volatile Admin doc| |.../admin24/refint.png Volatile Admin doc| |.../admin24/set-following-references.png Volatile Admin doc| |.../admin24/set-memberUid.png Volatile Admin doc| |.../admin24/set-recursivegroup.png Volatile Admin doc| |.../admin24/images Volatile Directory| |.../admin24/images/LDAPlogo.gif Volatile Admin doc| |.../admin24/images/LDAPwww.gif Volatile Admin doc| |/usr/share/man/man1oldap Uncommitted Directory| |.../man/man1oldap/oldapadd.1oldap Volatile Man page| |.../man/man1oldap/oldapcompare.1oldap Volatile Man page| |.../man/man1oldap/oldapdelete.1oldap Volatile Man page| |.../man/man1oldap/oldapmodify.1oldap Volatile Man page| |.../man/man1oldap/oldapmodrdn.1oldap Volatile Man page| |.../man/man1oldap/oldappasswd.1oldap Volatile Man page| |.../man/man1oldap/oldapsearch.1oldap Volatile Man page| |.../man/man1oldap/oldapwhoami.1oldap Volatile Man page| |/usr/share/man/man3oldap Uncommitted Directory| |.../man/man3oldap/ber_alloc_t.3oldap Volatile Man page| |.../man/man3oldap/ber_bvarray_add.3oldap Volatile Man page| |.../man/man3oldap/ber_bvarray_free.3oldap Volatile Man page| |.../man/man3oldap/ber_bvdup.3oldap Volatile Man page| |.../man/man3oldap/ber_bvecadd.3oldap Volatile Man page| |.../man/man3oldap/ber_bvecfree.3oldap Volatile Man page| |.../man/man3oldap/ber_bvfree.3oldap Volatile Man page| |.../man/man3oldap/ber_bvstr.3oldap Volatile Man page| |.../man/man3oldap/ber_bvstrdup.3oldap Volatile Man page| |.../man/man3oldap/ber_dupbv.3oldap Volatile Man page| |.../man/man3oldap/ber_first_element.3oldap Volatile Man page| |.../man/man3oldap/ber_flush.3oldap Volatile Man page| |.../man/man3oldap/ber_free.3oldap Volatile Man page| |.../man/man3oldap/ber_get_bitstring.3oldap Volatile Man page| |.../man/man3oldap/ber_get_boolean.3oldap Volatile Man page| |.../man/man3oldap/ber_get_enum.3oldap Volatile Man page| |.../man/man3oldap/ber_get_int.3oldap Volatile Man page| |.../man/man3oldap/ber_get_next.3oldap Volatile Man page| |.../man/man3oldap/ber_get_null.3oldap Volatile Man page| |.../man/man3oldap/ber_get_stringa.3oldap Volatile Man page| |.../man/man3oldap/ber_get_stringb.3oldap Volatile Man page| |.../man/man3oldap/ber_next_element.3oldap Volatile Man page| |.../man/man3oldap/ber_peek_tag.3oldap Volatile Man page| |.../man/man3oldap/ber_printf.3oldap Volatile Man page| |.../man/man3oldap/ber_put_enum.3oldap Volatile Man page| |.../man/man3oldap/ber_put_int.3oldap Volatile Man page| |.../man/man3oldap/ber_put_null.3oldap Volatile Man page| |.../man/man3oldap/ber_put_ostring.3oldap Volatile Man page| |.../man/man3oldap/ber_put_seq.3oldap Volatile Man page| |.../man/man3oldap/ber_put_set.3oldap Volatile Man page| |.../man/man3oldap/ber_put_string.3oldap Volatile Man page| |.../man/man3oldap/ber_scanf.3oldap Volatile Man page| |.../man/man3oldap/ber_skip_tag.3oldap Volatile Man page| |.../man/man3oldap/ber_start_set.3oldap Volatile Man page| |.../man/man3oldap/ber_str2bv.3oldap Volatile Man page| |.../man/man3oldap/lber-decode.3oldap Volatile Man page| |.../man/man3oldap/lber-encode.3oldap Volatile Man page| |.../man/man3oldap/lber-memory.3oldap Volatile Man page| |.../man/man3oldap/lber-sockbuf.3oldap Volatile Man page| |.../man/man3oldap/lber-types.3oldap Volatile Man page| |.../man/man3oldap/ld_errno.3oldap Volatile Man page| |.../man/man3oldap/ldap.3oldap Volatile Man page| |.../man/man3oldap/ldap_abandon.3oldap Volatile Man page| |.../man/man3oldap/ldap_abandon_ext.3oldap Volatile Man page| |.../man/man3oldap/ldap_add.3oldap Volatile Man page| |.../man/man3oldap/ldap_add_ext.3oldap Volatile Man page| |.../man/man3oldap/ldap_add_ext_s.3oldap Volatile Man page| |.../man/man3oldap/ldap_add_s.3oldap Volatile Man page| |.../man/man3oldap/ldap_attributetype2name.3oldap Volatile Man page| |.../man/man3oldap/ldap_attributetype2str.3oldap Volatile Man page| |.../man/man3oldap/ldap_attributetype_free.3oldap Volatile Man page| |.../man/man3oldap/ldap_bind.3oldap Volatile Man page| |.../man/man3oldap/ldap_bind_s.3oldap Volatile Man page| |.../man/man3oldap/ldap_compare.3oldap Volatile Man page| |.../man/man3oldap/ldap_compare_ext.3oldap Volatile Man page| |.../man/man3oldap/ldap_compare_ext_s.3oldap Volatile Man page| |.../man/man3oldap/ldap_compare_s.3oldap Volatile Man page| |.../man/man3oldap/ldap_control_create.3oldap Volatile Man page| |.../man/man3oldap/ldap_control_dup.3oldap Volatile Man page| |.../man/man3oldap/ldap_control_find.3oldap Volatile Man page| |.../man/man3oldap/ldap_control_free.3oldap Volatile Man page| |.../man/man3oldap/ldap_controls.3oldap Volatile Man page| |.../man/man3oldap/ldap_controls_dup.3oldap Volatile Man page| |.../man/man3oldap/ldap_controls_free.3oldap Volatile Man page| |.../man/man3oldap/ldap_count_entries.3oldap Volatile Man page| |.../man/man3oldap/ldap_count_messages.3oldap Volatile Man page| |.../man/man3oldap/ldap_count_references.3oldap Volatile Man page| |.../man/man3oldap/ldap_count_values.3oldap Volatile Man page| |.../man/man3oldap/ldap_count_values_len.3oldap Volatile Man page| |.../man/man3oldap/ldap_dcedn2dn.3oldap Volatile Man page| |.../man/man3oldap/ldap_delete.3oldap Volatile Man page| |.../man/man3oldap/ldap_delete_ext.3oldap Volatile Man page| |.../man/man3oldap/ldap_delete_ext_s.3oldap Volatile Man page| |.../man/man3oldap/ldap_delete_s.3oldap Volatile Man page| |.../man/man3oldap/ldap_dn2ad_canonical.3oldap Volatile Man page| |.../man/man3oldap/ldap_dn2dcedn.3oldap Volatile Man page| |.../man/man3oldap/ldap_dn2str.3oldap Volatile Man page| |.../man/man3oldap/ldap_dn2ufn.3oldap Volatile Man page| |.../man/man3oldap/ldap_err2string.3oldap Volatile Man page| |.../man/man3oldap/ldap_errlist.3oldap Volatile Man page| |.../man/man3oldap/ldap_error.3oldap Volatile Man page| |.../man/man3oldap/ldap_explode_dn.3oldap Volatile Man page| |.../man/man3oldap/ldap_explode_rdn.3oldap Volatile Man page| |.../man/man3oldap/ldap_extended_operation.3oldap Volatile Man page| |.../man/man3oldap/ldap_extended_operation_s.3oldap Volatile Man page| |.../man/man3oldap/ldap_first_attribute.3oldap Volatile Man page| |.../man/man3oldap/ldap_first_entry.3oldap Volatile Man page| |.../man/man3oldap/ldap_first_message.3oldap Volatile Man page| |.../man/man3oldap/ldap_first_reference.3oldapVolatile Man page| |.../man/man3oldap/ldap_free_urldesc.3oldap Volatile Man page| |.../man/man3oldap/ldap_get_dn.3oldap Volatile Man page| |.../man/man3oldap/ldap_get_option.3oldap Volatile Man page| |.../man/man3oldap/ldap_get_values.3oldap Volatile Man page| |.../man/man3oldap/ldap_get_values_len.3oldap Volatile Man page| |.../man/man3oldap/ldap_init.3oldap Volatile Man page| |.../man/man3oldap/ldap_initialize.3oldap Volatile Man page| |.../man/man3oldap/ldap_install_tls.3oldap Volatile Man page| |.../man/man3oldap/ldap_is_ldap_url.3oldap Volatile Man page| |.../man/man3oldap/ldap_matchingrule2name.3oldap Volatile Man page| |.../man/man3oldap/ldap_matchingrule2str.3oldap Volatile Man page| |.../man/man3oldap/ldap_matchingrule_free.3oldap Volatile Man page| |.../man/man3oldap/ldap_memalloc.3oldap Volatile Man page| |.../man/man3oldap/ldap_memcalloc.3oldap Volatile Man page| |.../man/man3oldap/ldap_memfree.3oldap Volatile Man page| |.../man/man3oldap/ldap_memory.3oldap Volatile Man page| |.../man/man3oldap/ldap_memrealloc.3oldap Volatile Man page| |.../man/man3oldap/ldap_memvfree.3oldap Volatile Man page| |.../man/man3oldap/ldap_modify.3oldap Volatile Man page| |.../man/man3oldap/ldap_modify_ext.3oldap Volatile Man page| |.../man/man3oldap/ldap_modify_ext_s.3oldap Volatile Man page| |.../man/man3oldap/ldap_modify_s.3oldap Volatile Man page| |.../man/man3oldap/ldap_modrdn.3oldap Volatile Man page| |.../man/man3oldap/ldap_modrdn2.3oldap Volatile Man page| |.../man/man3oldap/ldap_modrdn2_s.3oldap Volatile Man page| |.../man/man3oldap/ldap_modrdn_s.3oldap Volatile Man page| |.../man/man3oldap/ldap_mods_free.3oldap Volatile Man page| |.../man/man3oldap/ldap_msgfree.3oldap Volatile Man page| |.../man/man3oldap/ldap_msgid.3oldap Volatile Man page| |.../man/man3oldap/ldap_msgtype.3oldap Volatile Man page| |.../man/man3oldap/ldap_next_attribute.3oldap Volatile Man page| |.../man/man3oldap/ldap_next_entry.3oldap Volatile Man page| |.../man/man3oldap/ldap_next_message.3oldap Volatile Man page| |.../man/man3oldap/ldap_next_reference.3oldap Volatile Man page| |.../man/man3oldap/ldap_objectclass2name.3oldap Volatile Man page| |.../man/man3oldap/ldap_objectclass2str.3oldap Volatile Man page| |.../man/man3oldap/ldap_objectclass_free.3oldap Volatile Man page| |.../man/man3oldap/ldap_open.3oldap Volatile Man page| |.../man/man3oldap/ldap_parse_extended_result.3oldap Volatile Man page| |.../man/man3oldap/ldap_parse_reference.3oldap Volatile Man page| |.../man/man3oldap/ldap_parse_result.3oldap Volatile Man page| |.../man/man3oldap/ldap_parse_sasl_bind_result.3oldap Volatile Man page| |.../man/man3oldap/ldap_parse_sort_control.3oldap Volatile Man page| |.../man/man3oldap/ldap_parse_vlv_control.3oldap Volatile Man page| |.../man/man3oldap/ldap_perror.3oldap Volatile Man page| |.../man/man3oldap/ldap_rename.3oldap Volatile Man page| |.../man/man3oldap/ldap_rename_s.3oldap Volatile Man page| |.../man/man3oldap/ldap_result.3oldap Volatile Man page| |.../man/man3oldap/ldap_result2error.3oldap Volatile Man page| |.../man/man3oldap/ldap_sasl_bind.3oldap Volatile Man page| |.../man/man3oldap/ldap_sasl_bind_s.3oldap Volatile Man page| |.../man/man3oldap/ldap_schema.3oldap Volatile Man page| |.../man/man3oldap/ldap_scherr2str.3oldap Volatile Man page| |.../man/man3oldap/ldap_search.3oldap Volatile Man page| |.../man/man3oldap/ldap_search_ext.3oldap Volatile Man page| |.../man/man3oldap/ldap_search_ext_s.3oldap Volatile Man page| |.../man/man3oldap/ldap_search_s.3oldap Volatile Man page| |.../man/man3oldap/ldap_search_st.3oldap Volatile Man page| |.../man/man3oldap/ldap_set_option.3oldap Volatile Man page| |.../man/man3oldap/ldap_set_rebind_proc.3oldap Volatile Man page| |.../man/man3oldap/ldap_simple_bind.3oldap Volatile Man page| |.../man/man3oldap/ldap_simple_bind_s.3oldap Volatile Man page| |.../man/man3oldap/ldap_sort.3oldap Volatile Man page| |.../man/man3oldap/ldap_sort_entries.3oldap Volatile Man page| |.../man/man3oldap/ldap_sort_strcasecmp.3oldap Volatile Man page| |.../man/man3oldap/ldap_sort_values.3oldap Volatile Man page| |.../man/man3oldap/ldap_start_tls.3oldap Volatile Man page| |.../man/man3oldap/ldap_start_tls_s.3oldap Volatile Man page| |.../man/man3oldap/ldap_str2attributetype.3oldap Volatile Man page| |.../man/man3oldap/ldap_str2dn.3oldap Volatile Man page| |.../man/man3oldap/ldap_str2matchingrule.3oldap Volatile Man page| |.../man/man3oldap/ldap_str2objectclass.3oldap Volatile Man page| |.../man/man3oldap/ldap_str2syntax.3oldap Volatile Man page| |.../man/man3oldap/ldap_strdup.3oldap Volatile Man page| |.../man/man3oldap/ldap_sync.3oldap Volatile Man page| |.../man/man3oldap/ldap_syntax2name.3oldap Volatile Man page| |.../man/man3oldap/ldap_syntax2str.3oldap Volatile Man page| |.../man/man3oldap/ldap_syntax_free.3oldap Volatile Man page| |.../man/man3oldap/ldap_tls.3oldap Volatile Man page| |.../man/man3oldap/ldap_tls_inplace.3oldap Volatile Man page| |.../man/man3oldap/ldap_unbind.3oldap Volatile Man page| |.../man/man3oldap/ldap_unbind_ext.3oldap Volatile Man page| |.../man/man3oldap/ldap_unbind_ext_s.3oldap Volatile Man page| |.../man/man3oldap/ldap_unbind_s.3oldap Volatile Man page| |.../man/man3oldap/ldap_url.3oldap Volatile Man page| |.../man/man3oldap/ldap_url_parse.3oldap Volatile Man page| |.../man/man3oldap/ldap_value_free.3oldap Volatile Man page| |.../man/man3oldap/ldap_value_free_len.3oldap Volatile Man page| |/usr/share/man/man5oldap Uncommitted Directory| |.../man/man5oldap/ldap.conf.5oldap Volatile Man page| |.../man/man5oldap/ldif.5oldap Volatile Man page| |.../man/man5oldap/slapd-bdb.5oldap Volatile Man page| |.../man/man5oldap/slapd-config.5oldap Volatile Man page| |.../man/man5oldap/slapd-dnssrv.5oldap Volatile Man page| |.../man/man5oldap/slapd-hdb.5oldap Volatile Man page| |.../man/man5oldap/slapd-ldap.5oldap Volatile Man page| |.../man/man5oldap/slapd-ldbm.5oldap Volatile Man page| |.../man/man5oldap/slapd-ldif.5oldap Volatile Man page| |.../man/man5oldap/slapd-meta.5oldap Volatile Man page| |.../man/man5oldap/slapd-monitor.5oldap Volatile Man page| |.../man/man5oldap/slapd-null.5oldap Volatile Man page| |.../man/man5oldap/slapd-passwd.5oldap Volatile Man page| |.../man/man5oldap/slapd-perl.5oldap Volatile Man page| |.../man/man5oldap/slapd-relay.5oldap Volatile Man page| |.../man/man5oldap/slapd-shell.5oldap Volatile Man page| |.../man/man5oldap/slapd-sock.5oldap Volatile Man page| |.../man/man5oldap/slapd-sql.5oldap Volatile Man page| |.../man/man5oldap/slapd.access.5oldap Volatile Man page| |.../man/man5oldap/slapd.backends.5oldap Volatile Man page| |.../man/man5oldap/slapd.conf.5oldap Volatile Man page| |.../man/man5oldap/slapd.overlays.5oldap Volatile Man page| |.../man/man5oldap/slapd.plugin.5oldap Volatile Man page| |.../man/man5oldap/slapo-accesslog.5oldap Volatile Man page| |.../man/man5oldap/slapo-auditlog.5oldap Volatile Man page| |.../man/man5oldap/slapo-chain.5oldap Volatile Man page| |.../man/man5oldap/slapo-constraint.5oldap Volatile Man page| |.../man/man5oldap/slapo-dds.5oldap Volatile Man page| |.../man/man5oldap/slapo-dyngroup.5oldap Volatile Man page| |.../man/man5oldap/slapo-dynlist.5oldap Volatile Man page| |.../man/man5oldap/slapo-memberof.5oldap Volatile Man page| |.../man/man5oldap/slapo-pcache.5oldap Volatile Man page| |.../man/man5oldap/slapo-ppolicy.5oldap Volatile Man page| |.../man/man5oldap/slapo-refint.5oldap Volatile Man page| |.../man/man5oldap/slapo-retcode.5oldap Volatile Man page| |.../man/man5oldap/slapo-rwm.5oldap Volatile Man page| |.../man/man5oldap/slapo-syncprov.5oldap Volatile Man page| |.../man/man5oldap/slapo-translucent.5oldap Volatile Man page| |.../man/man5oldap/slapo-unique.5oldap Volatile Man page| |.../man/man5oldap/slapo-valsort.5oldap Volatile Man page| |/usr/share/man/man8oldap Uncommitted Directory| |.../man/man8oldap/slapacl.8oldap Volatile Man page| |.../man/man8oldap/slapadd.8oldap Volatile Man page| |.../man/man8oldap/slapauth.8oldap Volatile Man page| |.../man/man8oldap/slapcat.8oldap Volatile Man page| |.../man/man8oldap/slapd.8oldap Volatile Man page| |.../man/man8oldap/slapdn.8oldap Volatile Man page| |.../man/man8oldap/slapindex.8oldap Volatile Man page| |.../man/man8oldap/slappasswd.8oldap Volatile Man page| |.../man/man8oldap/slaptest.8oldap Volatile Man page| +-------------------------------------------------------------------------+ +-------------------------------------------------------------------------+ |Imported Interfaces Classification Comments| |-------------------------------------------------------------------------| |OpenSSL External/Volatile | +-------------------------------------------------------------------------+ 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 Darren.Moffat@sun.com Thu Aug 7 01:34:36 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 m778YZM1015565 for ; Thu, 7 Aug 2008 01:34:35 -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 m778YQqr017262 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 7 Aug 2008 09:34:34 +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 <0K58007012HL7900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 07 Aug 2008 01:34:33 -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 <0K58000LD2HKAT40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 07 Aug 2008 01:34:33 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m778YWCn000270 for ; Thu, 07 Aug 2008 08:34:32 +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 <0K5800I011ZHHQ00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 07 Aug 2008 09:34:16 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5800GFM2GZCE90@fe-emea-10.sun.com>; Thu, 07 Aug 2008 09:34:12 +0100 (BST) Date: Thu, 07 Aug 2008 09:34:11 +0100 From: Darren J Moffat Subject: Re: OpenLDAP for OpenSolaris [PSARC/2008/507 FastTrack timeout 07/13/2008] In-reply-to: <200808070502.m77525xG010946@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Nicolas Williams Cc: PSARC-ext@sun.com, Doug.Leavitt@sun.com Message-id: <489AB383.4080804@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: <200808070502.m77525xG010946@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 1931 [ Yeah Yet Another Ldap Library :-) The more the merrier! ] Is it possible to put the schema in /usr/share somewhere eg: /usr/share/openldap/schema/. Not a big issue just seems that they shouldn't need to be edited. While I see that the prefix of "o" means Open it reads as old-apadd, old-apcompare old-adppasswd. Also given the ancient precent of awk, owak, nawk. Maybe just make the prefix "open" (for the commands and the man page sections) since that is already used in /usr/share/doc/openldap/ giving: openldapadd, openldapcompare, openldappasswd etc. It may also be useful, but I wouldn't inst on it to have /usr/lib/openldap/bin/{ldapadd,ldapcompare,ldappasswd,...} this would allow scripts written to assume OpenLDAP clis to be more easily adapted to OpenSolaris/Solaris by changing $PATH rather than having to change every instance of ldapadd etc to the prefixed name. What is the rationale for starting slapd with root and all privs rather than having SMF start it as openldap:openldap with basic,net_privaddr ? The library naming looks strange but as the case says this is what is used elsewhere, what is recorded as the SONAME in the ELF files ? Can this OpenLDAP server be used as the LDAP *server* for nss_ldap and pam_ldap ? If so can instructions for configuring it be provided somewhere (ideally in /usr/share/doc/openldap but I'd accept wikis.sun.com, opensolaris.org or blogs.sun.com initially). If it doesn't work I'd like to see a short outline of what is needed to make it so. I don't want it to stop the integration of this case but having the existing /usr/lib/ldap.so.5 from Mozilla and the OpenLDAP library in the same process is *highly* toxic and leads to very strange and hard to debug problems - particularly when using LDAP over SSL/TLS. So I'd encourage the projects teams management to fund the switch to OpenLDAP for libsldap and nss_ldap ASAP. -- Darren J Moffat From Milan.Jurik@Sun.COM Thu Aug 7 01:52:47 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 m778qknS016839 for ; Thu, 7 Aug 2008 01:52:46 -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 m778qjOG024126 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 7 Aug 2008 09:52:45 +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 <0K58009073BU6B00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 07 Aug 2008 01:52:42 -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 <0K580004T3BTAT60@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 07 Aug 2008 01:52:41 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m778qeNq005418 for ; Thu, 07 Aug 2008 08:52:40 +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 <0K5800J012S89U00@fe-emea-09.sun.com> (original mail from Milan.Jurik@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 07 Aug 2008 09:52:28 +0100 (BST) Received: from 129.157.18.63 ([129.157.18.63]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K58006VN3B1MBE0@fe-emea-09.sun.com>; Thu, 07 Aug 2008 09:52:14 +0100 (BST) Date: Thu, 07 Aug 2008 10:52:10 +0200 From: Milan Jurik Subject: Re: OpenLDAP for OpenSolaris [PSARC/2008/507 FastTrack timeout 07/13/2008] In-reply-to: <489AB383.4080804@Sun.COM> Sender: Milan.Jurik@Sun.COM To: Darren J Moffat Cc: Nicolas Williams , PSARC-ext@Sun.COM, Doug.Leavitt@Sun.COM Message-id: <1218099130.13290.7.camel@xylabone> Organization: Sun Microsystems - Prague Czech Republic MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301c Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200808070502.m77525xG010946@sac.sfbay.sun.com> <489AB383.4080804@Sun.COM> Status: RO Content-Length: 1034 Hi, V čt, 07. 08. 2008 v 10:34, Darren J Moffat píše: > [ Yeah Yet Another Ldap Library :-) The more the merrier! ] > [...] > > I don't want it to stop the integration of this case but having the > existing /usr/lib/ldap.so.5 from Mozilla and the OpenLDAP library in the > same process is *highly* toxic and leads to very strange and hard to > debug problems - particularly when using LDAP over SSL/TLS. So I'd > encourage the projects teams management to fund the switch to OpenLDAP > for libsldap and nss_ldap ASAP. > What would be the benefit of this switch? Highly volatile, frequently changed (mostly bugfixed) openldap client library vs. mature and stable Mozilla LDAP (I mean libldap.so.6)? And because Mozilla apps depend on libldap, you will have the same problem with Thunderbird (reported several times on other platforms) after the switch. Moving libsldap out of application's space just to nscd by default would have much bigger benefit. Any way, it's out of scope of this case. Best regards, Milan From Nicolas.Williams@sun.com Thu Aug 7 09:12:56 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 m77GCuMr026595 for ; Thu, 7 Aug 2008 09:12:56 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m77GCrEq003935; Thu, 7 Aug 2008 10:12:55 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5800A0BNPHLV00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Aug 2008 09:12:53 -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 <0K58004FONP2YAD0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Aug 2008 09:12:38 -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 m77GCbIc011738; Thu, 07 Aug 2008 11:12:37 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m77GCbUZ011737; Thu, 07 Aug 2008 11:12:37 -0500 (CDT) Date: Thu, 07 Aug 2008 11:12:36 -0500 From: Nicolas Williams Subject: Re: OpenLDAP for OpenSolaris [PSARC/2008/507 FastTrack timeout 07/13/2008] In-reply-to: <200808070502.m77525xG010946@sac.sfbay.sun.com> To: Nicolas Williams Cc: PSARC-ext@sun.com, Doug.Leavitt@sun.com Mail-followup-to: Nicolas Williams , PSARC-ext@sun.com, Doug.Leavitt@sun.com Message-id: <20080807161236.GF25547@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: <200808070502.m77525xG010946@sac.sfbay.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: 52 Sigh, I typoed the timeout. It's 08/13, not 07/13. From Doug.Leavitt@sun.com Thu Aug 7 14:16:55 2008 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 m77LGtMl005849 for ; Thu, 7 Aug 2008 14:16:55 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m77LGswM025618 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 7 Aug 2008 14:16:55 -0700 (PDT) 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 <0K5900K011S75R00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 07 Aug 2008 14:16:55 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5900G0K1S6TY40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 07 Aug 2008 14:16:54 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m77LGs2t014462 for ; Thu, 07 Aug 2008 14:16:54 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5900J011KJEW00@fe-sfbay-10.sun.com> (original mail from Doug.Leavitt@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 07 Aug 2008 14:16:54 -0700 (PDT) Received: from [192.168.0.2] ([70.247.140.31]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5900D4U1S5GV40@fe-sfbay-10.sun.com>; Thu, 07 Aug 2008 14:16:54 -0700 (PDT) Date: Thu, 07 Aug 2008 16:16:53 -0500 From: Doug Leavitt Subject: Re: OpenLDAP for OpenSolaris [PSARC/2008/507 FastTrack timeout 07/13/2008] In-reply-to: <489AB383.4080804@Sun.COM> Sender: Doug.Leavitt@sun.com To: Darren J Moffat Cc: Nicolas Williams , PSARC-ext@sun.com Message-id: <489B6645.9050109@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: <200808070502.m77525xG010946@sac.sfbay.sun.com> <489AB383.4080804@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080714) Status: RO Content-Length: 5496 Darren J Moffat wrote: > [ Yeah Yet Another Ldap Library :-) The more the merrier! ] > > Is it possible to put the schema in /usr/share somewhere eg: > /usr/share/openldap/schema/. Not a big issue just seems that they > shouldn't need to be edited. The schema files are not static in the sense of "these will never change" They are static in the sense of a LDAP server administrator "should not modify these unless they really know what they are doing." The schema files in /etc/openldap/schema are loaded via include statements during the initialization phase via the slapd.conf configuration file. Server administrators need to be able [and do] to modify, add and potentially delete some schemas as part of the configuration setup for the server. > > While I see that the prefix of "o" means Open it reads as > old-apadd, old-apcompare old-adppasswd. Also given the ancient precent > of awk, owak, nawk. Maybe just make the prefix "open" (for the > commands and the man page sections) since that is already used in > /usr/share/doc/openldap/ giving: > > openldapadd, openldapcompare, openldappasswd etc. > > It may also be useful, but I wouldn't inst on it to have > /usr/lib/openldap/bin/{ldapadd,ldapcompare,ldappasswd,...} this would > allow scripts written to assume OpenLDAP clis to be more easily adapted > to OpenSolaris/Solaris by changing $PATH rather than having to change > every instance of ldapadd etc to the prefixed name. We are willing to adjust the names of the tools from o* to open* and adding a second directory [/usr/lib/openldap/bin] of symlinks as suggested above if that is the consensus of PSARC? If so I will revise the spec. > > What is the rationale for starting slapd with root and all privs rather > than having SMF start it as openldap:openldap with basic,net_privaddr ? It seemed the simple solution. I will revise the spec, correct the SMF manifest, and retest etc. > > The library naming looks strange but as the case says this is what is > used elsewhere, what is recorded as the SONAME in the ELF files ? The history, as I understand it, is that OpenLDAP 2.3.x use libldap.so.2.3.* [and the default name of libldap.so]. Some Linux's still distribute both libldap.2.3.* and the newer libldap.2.4 forms. The default name was changed so that both libraries can exist parallel on Linux boxes. It just happens to work for us (OpenSolaris) as well, but for a different reason. [Mozilla vs. OpenLDAP.2.4...] The SONAMES from the libraries are: $ dump -Lvp libldap-2.4.so.2.1.0|grep SONAME [11] SONAME libldap-2.4.so.2 $ dump -Lvp libldap_r-2.4.so.2.1.0|grep SONAME [11] SONAME libldap_r-2.4.so.2 > > Can this OpenLDAP server be used as the LDAP *server* for nss_ldap and > pam_ldap ? If so can instructions for configuring it be provided > somewhere (ideally in /usr/share/doc/openldap but I'd accept > wikis.sun.com, opensolaris.org or blogs.sun.com initially). If it > doesn't work I'd like to see a short outline of what is needed to make > it so. Yes, it can. At the moment Google has multiple references. Some are: http://docs.alkaloid.net/index.php/Solaris_LDAP_client_with_OpenLDAP_server http://www.bolthole.com/solaris/LDAP.html http://docs.lucidinteractive.ca/index.php/Solaris_LDAP_client_with_OpenLDAP_server ... As part of this projects testing we are testing nss_ldap against the OpenLDAP builds with the intent of publishing our own set of instructions to opensolaris.org (probably the Sparks project) with relevant blog pointers, and in order to gather the list of issues for additional improvements. One of those future tasks includes making the necessary modifications to nss_ldap to make OpenLDAP setup easier, and needed changes to idsconfig so that idsconfig can configure both SJS DSEE and OpenLDAP slapd. [Side note, when we change idsconfig, we expect pull out the inline schema code and place it in a previously suggested shared location. The expectation would be to update the LDAP admin guide with additional new instructions as part of these idsconfig enhancements. We expect to submit a fast track for this work once it is further along. > > I don't want it to stop the integration of this case but having the > existing /usr/lib/ldap.so.5 from Mozilla and the OpenLDAP library in the > same process is *highly* toxic and leads to very strange and hard to > debug problems - particularly when using LDAP over SSL/TLS. So I'd > encourage the projects teams management to fund the switch to OpenLDAP > for libsldap and nss_ldap ASAP. We are currently investigating the conversion of nss_ldap/libsldap to OpenLDAP. Additionally, OpenSolaris and s10u4+ are currently integrated with the sparks enhancements to the name service switch (PSARC/2005/133). By design, in sparks when nscd is running, the only application that should ever load nss_ldap is nscd. Currently all LDAP processing is managed by nscd. This LDAP processing includes connection pooling and shared connections of multiple requests/responses over those managed connections. Given that nscd/nss_ldap/libldap.so.5 are all built in a controlled environment w/ -Bdirect, nscd already properly loads with the correct libraries. This greatly reduces the possibility of a collision due to naming services linkage issues. In general any application linking with a libldap today, should no longer have library collisions due to the nsswitch's use of libldap. > > -- > Darren J Moffat From Nicolas.Williams@Sun.COM Thu Aug 7 14:27:36 2008 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 m77LRarL005966 for ; Thu, 7 Aug 2008 14:27:36 -0700 (PDT) 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 m77LRVnS028542; Thu, 7 Aug 2008 14:27:34 -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 <0K5900A0929VY100@brm-avmta-1.central.sun.com>; Thu, 07 Aug 2008 15:27:31 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K59000CP29VFP70@brm-avmta-1.central.sun.com>; Thu, 07 Aug 2008 15:27:31 -0600 (MDT) 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 m77LRUJs012063; Thu, 07 Aug 2008 16:27:30 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m77LRUqJ012062; Thu, 07 Aug 2008 16:27:30 -0500 (CDT) Date: Thu, 07 Aug 2008 16:27:29 -0500 From: Nicolas Williams Subject: Re: OpenLDAP for OpenSolaris [PSARC/2008/507 FastTrack timeout 07/13/2008] In-reply-to: <489B6645.9050109@sun.com> To: Doug Leavitt Cc: Darren J Moffat , Nicolas Williams , PSARC-ext@Sun.COM Mail-followup-to: Doug Leavitt , Darren J Moffat , Nicolas Williams , PSARC-ext@sun.com Message-id: <20080807212729.GB25547@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: <200808070502.m77525xG010946@sac.sfbay.sun.com> <489AB383.4080804@Sun.COM> <489B6645.9050109@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: 2228 On Thu, Aug 07, 2008 at 04:16:53PM -0500, Doug Leavitt wrote: > Darren J Moffat wrote: > >[ Yeah Yet Another Ldap Library :-) The more the merrier! ] > > > >Is it possible to put the schema in /usr/share somewhere eg: > >/usr/share/openldap/schema/. Not a big issue just seems that they > >shouldn't need to be edited. > > The schema files are not static in the sense of "these will never > change" They are static in the sense of a LDAP server administrator > "should not modify these unless they really know what they are doing." If the sysadmin needs to modify them they can copy them to $TMPDIR, edit them, and load them. There's no need to keep them around once edited, but if there is we can deliver an empty /etc/openldap/schema/ and put the standard schemas in /usr/share/openldap/schema as Darren suggests. > The schema files in /etc/openldap/schema are loaded via include > statements during the initialization phase via the slapd.conf > configuration file. Server administrators need to be able [and do] to > modify, add and potentially delete some schemas as part of the > configuration setup for the server. Right, but we should probably be able to deliver new versions of these files without clobbering the admins' modified versions. Following the CDE/X11 model I think that means putting originals in /usr/share and admin-edited versions in /etc. > >I don't want it to stop the integration of this case but having the > >existing /usr/lib/ldap.so.5 from Mozilla and the OpenLDAP library in > >the same process is *highly* toxic and leads to very strange and hard > >to debug problems - particularly when using LDAP over SSL/TLS. So > >I'd encourage the projects teams management to fund the switch to > >OpenLDAP for libsldap and nss_ldap ASAP. > > [...] > > In general any application linking with a libldap today, should no > longer have library collisions due to the nsswitch's use of libldap. But there are other potential sources of conflict. For example, the integration of PSARC/2008/342 introduced a dependency by libsec on libidmap, which brings in libldap, which brings in NSPR, which broke VirtualBox because VirtualBox has a private copy of NSPR in one of its shared objects. Nico -- From glenn.skinner@sun.com Thu Aug 7 15:16:44 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 m77MGhOg006553 for ; Thu, 7 Aug 2008 15:16:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m77MGeJO015105; Thu, 7 Aug 2008 23:16:41 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K59001094JRJ400@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Aug 2008 15:16:39 -0700 (PDT) Received: from ivrel.sfbay.sun.com ([129.146.74.76]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5900M024JR1950@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Aug 2008 15:16:39 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id m77MGdct003847; Thu, 07 Aug 2008 15:16:39 -0700 (PDT) Date: Thu, 07 Aug 2008 15:16:39 -0700 (PDT) From: Glenn Skinner Subject: Re: 2008/507 [ OpenLDAP for OpenSolaris] To: PSARC-ext@sun.com, nw141292@sac.sfbay.sun.com Cc: Doug.Leavitt@sun.com Reply-to: Glenn Skinner Message-id: <200808072216.m77MGdct003847@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: 6FO7wm4eKGI9UYZEC/DrFQ== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1318 Date: Wed, 06 Aug 2008 22:02:05 -0700 (PDT) From: Nicolas Williams Subject: OpenLDAP for OpenSolaris [PSARC/2008/507 FastTrack timeout 07/13/2008] ... 2.5 SMF Manifest and Runtime behavior This project proposes to provide a SMF manifest, disabled by default, for the OpenLDAP slapd server. The slapd server has the ability to change it's user and group and run as a non-privileged user after binding listener sockets to the privileged LDAP port(s). Generally slapd is run as user openldap and group openldap. The SMF manifest will start slapd as root and with privileges but configured to become openldap:openldap; slapd will retain basic privileges. This project proposes to update the following databases to provide the the necessary dummy openldap user and group entries: Database Entry -------- ----- /etc/passwd openldap:x:75:75:OpenLDAP User:/: /etc/shadow openldap:*LK*::::::: /etc/group openldap::75: Is it really necessary to allocate another user:group pair from our dwindling stock of reserved values? Would it be possible to share one of the already allocated entries from the reserved part of the name space? -- Glenn From Nicolas.Williams@Sun.COM Thu Aug 7 15:22: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 m77MMMqw006614 for ; Thu, 7 Aug 2008 15:22:22 -0700 (PDT) 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 m77MMMhv027317; Thu, 7 Aug 2008 15:22:22 -0700 (PDT) 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 <0K590040F4T9L900@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Aug 2008 15:22:21 -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 <0K5900GVX4T8TYA0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Aug 2008 15:22:20 -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 m77MMJOf012115; Thu, 07 Aug 2008 17:22:19 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m77MMJAA012114; Thu, 07 Aug 2008 17:22:19 -0500 (CDT) Date: Thu, 07 Aug 2008 17:22:19 -0500 From: Nicolas Williams Subject: Re: 2008/507 [ OpenLDAP for OpenSolaris] In-reply-to: <200808072216.m77MGdct003847@ivrel.sfbay.sun.com> To: Glenn Skinner Cc: PSARC-ext@Sun.COM, nw141292@sac.sfbay.sun.com, Doug.Leavitt@Sun.COM Mail-followup-to: Glenn Skinner , PSARC-ext@sun.com, nw141292@sac.sfbay.sun.com, Doug.Leavitt@sun.com Message-id: <20080807222218.GD25547@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: <200808072216.m77MGdct003847@ivrel.sfbay.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: 1000 On Thu, Aug 07, 2008 at 03:16:39PM -0700, Glenn Skinner wrote: > Database Entry > -------- ----- > /etc/passwd openldap:x:75:75:OpenLDAP User:/: > /etc/shadow openldap:*LK*::::::: > /etc/group openldap::75: > > Is it really necessary to allocate another user:group pair from our > dwindling stock of reserved values? Would it be possible to share one > of the already allocated entries from the reserved part of the name > space? My impression (please correct me if I'm wrong) is that with IPS the UIDs and GIDs can be allocated dynamically and that most pkgs that install local users/groups will often not be installed by the user anyways. Of course, this may well collide with existing openldap user/group in customer environments... I.e., we have a namespace problem no matter what, and probably the best way to deal with this is by not installing everything, just what the user needs. Nico -- From Nicolas.Williams@sun.com Thu Aug 7 15:52:12 2008 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 m77MqCFT007281 for ; Thu, 7 Aug 2008 15:52:12 -0700 (PDT) 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 m77Mq3JL022533; Thu, 7 Aug 2008 15:52:11 -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 <0K590030X66Y9300@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Aug 2008 15:52:10 -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 <0K5900M7166W1B90@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Aug 2008 15:52:08 -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 m77Mq7EX012154; Thu, 07 Aug 2008 17:52:07 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m77Mq7Do012153; Thu, 07 Aug 2008 17:52:07 -0500 (CDT) Date: Thu, 07 Aug 2008 17:52:07 -0500 From: Nicolas Williams Subject: Re: 2008/507 [ OpenLDAP for OpenSolaris] In-reply-to: <20080807222218.GD25547@Sun.COM> To: Glenn Skinner , PSARC-ext@sun.com, nw141292@sac.sfbay.sun.com, Doug.Leavitt@sun.com Mail-followup-to: Glenn Skinner , PSARC-ext@sun.com, nw141292@sac.sfbay.sun.com, Doug.Leavitt@sun.com Message-id: <20080807225207.GG25547@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: <200808072216.m77MGdct003847@ivrel.sfbay.sun.com> <20080807222218.GD25547@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: 1623 On Thu, Aug 07, 2008 at 05:22:19PM -0500, Nicolas Williams wrote: > On Thu, Aug 07, 2008 at 03:16:39PM -0700, Glenn Skinner wrote: > > Is it really necessary to allocate another user:group pair from our > > dwindling stock of reserved values? Would it be possible to share one > > of the already allocated entries from the reserved part of the name > > space? > > My impression (please correct me if I'm wrong) is that with IPS the UIDs > and GIDs can be allocated dynamically and that most pkgs that install > local users/groups will often not be installed by the user anyways. I've confirmed this with Dave Miner. That still won't save us should users want to install everything available from the repository and should we run out of UIDs and GIDs reserved for the OS. Should it come to it I suppose IPS could ask the user to provide a suitable range of UIDs/GIDs for use for this. Alternatively we could explore use of ephemeral UIDs/GIDs for this. But none of that is this case. I think the answer to your first question is "yes." I don't know how to answer your second question. Perhaps things like DNS servers, OpenDS, OpenLDAP, ... all could share one account and use zones to avoid sharing resources amongst them. That too is "not this case." In other words, I don't have really satisfying answers to your questions. IPS will alleviate the pressure, perhaps enough so that we can dodge this matter indefinitely. Heck, OpenSolaris being a sort of Major release I suppose we could even dodge this by increasing the set of UIDs/GIDs set aside for OS users/groups! (No, I'm not proposing that). Nico -- From glenn.skinner@sun.com Thu Aug 7 16:25:11 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 m77NPBNt010529 for ; Thu, 7 Aug 2008 16:25:11 -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 m77NP3fo008372; Thu, 7 Aug 2008 17:25:09 -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 <0K59004057PWS000@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Aug 2008 16:25:08 -0700 (PDT) Received: from ivrel.sfbay.sun.com ([129.146.74.76]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5900MOB7PW19B0@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Aug 2008 16:25:08 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id m77NP8jF004069; Thu, 07 Aug 2008 16:25:08 -0700 (PDT) Date: Thu, 07 Aug 2008 16:25:08 -0700 (PDT) From: Glenn Skinner Subject: Re: 2008/507 [ OpenLDAP for OpenSolaris] To: PSARC-ext@sun.com, nw141292@sac.sfbay.sun.com, Doug.Leavitt@sun.com, Nicolas.Williams@sun.com Reply-to: Glenn Skinner Message-id: <200808072325.m77NP8jF004069@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: Xvkw9xA19SlVjm/TXfwS5Q== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 896 Date: Thu, 07 Aug 2008 17:52:07 -0500 From: Nicolas Williams Subject: Re: 2008/507 [ OpenLDAP for OpenSolaris] On Thu, Aug 07, 2008 at 05:22:19PM -0500, Nicolas Williams wrote: > On Thu, Aug 07, 2008 at 03:16:39PM -0700, Glenn Skinner wrote: > > Is it really necessary to allocate another user:group pair > > from our dwindling stock of reserved values? Would it be > > possible to share one of the already allocated entries from > > the reserved part of the name space? > > My impression (please correct me if I'm wrong) is that with IPS > the UIDs and GIDs can be allocated dynamically and that most > pkgs that install local users/groups will often not be installed > by the user anyways. I've confirmed this with Dave Miner. Are you proposing a dependency of this case on the IPS case? -- Glenn From danek.duvall@sun.com Thu Aug 7 16:58:30 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 m77NwTKu010894 for ; Thu, 7 Aug 2008 16:58:29 -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 m77NwMe4009314 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 8 Aug 2008 07:58:28 +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 <0K5900F0399EM500@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 07 Aug 2008 16:58:26 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5900AI399DFRE0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 07 Aug 2008 16:58:25 -0700 (PDT) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m77NwPAV020035; Thu, 07 Aug 2008 16:58:25 -0700 (PDT) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m77NwOqY018276; Thu, 07 Aug 2008 16:58:24 -0700 (PDT) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m77NwNaE018275; Thu, 07 Aug 2008 16:58:23 -0700 (PDT) Date: Thu, 07 Aug 2008 16:58:23 -0700 From: Danek Duvall Subject: Re: 2008/507 [ OpenLDAP for OpenSolaris] In-reply-to: <20080807225207.GG25547@Sun.COM> To: Glenn Skinner , PSARC-ext@sun.com, nw141292@sac.sfbay.sun.com, Doug.Leavitt@sun.com Message-id: <20080807235823.GI2024@zruty.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: <200808072216.m77MGdct003847@ivrel.sfbay.sun.com> <20080807222218.GD25547@Sun.COM> <20080807225207.GG25547@Sun.COM> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 707 On Thu, Aug 07, 2008 at 05:52:07PM -0500, Nicolas Williams wrote: > IPS will alleviate the pressure, perhaps enough so that we can dodge > this matter indefinitely. Er, I don't think that IPS alleviates the pressure. The pressure is the fact that we've traditionally only reserved uids < (<=?) 100, and IPS doesn't change that. If anything, it *increases* the pressure by making it so easy to create new users without having the bottleneck of integrating into ON. We can hope that administrators won't install all packages that install new users, but that's not a very good plan. Someone ought to tackle the problem, certainly, but (as others have already said) I don't think that's this case. Danek From glenn.skinner@sun.com Thu Aug 7 17:03:00 2008 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 m78030W4011066 for ; Thu, 7 Aug 2008 17:03:00 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7802xgD010250; Thu, 7 Aug 2008 17:02:59 -0700 (PDT) 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 <0K5900G0D9GZ3F00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Aug 2008 17:02:59 -0700 (PDT) Received: from ivrel.sfbay.sun.com ([129.146.74.76]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5900FL39GYW000@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Aug 2008 17:02:58 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id m7802w0Q004138; Thu, 07 Aug 2008 17:02:58 -0700 (PDT) Date: Thu, 07 Aug 2008 17:02:58 -0700 (PDT) From: Glenn Skinner Subject: Re: 2008/507 [ OpenLDAP for OpenSolaris] To: PSARC-ext@sun.com, nw141292@sac.sfbay.sun.com, Doug.Leavitt@sun.com, danek.duvall@sun.com Reply-to: Glenn Skinner Message-id: <200808080002.m7802w0Q004138@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: H3r0+5hdLyz7coYO2YylBQ== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1007 Date: Thu, 07 Aug 2008 16:58:23 -0700 From: Danek Duvall Subject: Re: 2008/507 [ OpenLDAP for OpenSolaris] On Thu, Aug 07, 2008 at 05:52:07PM -0500, Nicolas Williams wrote: > IPS will alleviate the pressure, perhaps enough so that we can dodge > this matter indefinitely. Er, I don't think that IPS alleviates the pressure. The pressure is the fact that we've traditionally only reserved uids < (<=?) 100, and IPS doesn't change that. If anything, it *increases* the pressure by making it so easy to create new users without having the bottleneck of integrating into ON. We can hope that administrators won't install all packages that install new users, but that's not a very good plan. Someone ought to tackle the problem, certainly, but (as others have already said) I don't think that's this case. See the (newly added) issue gcs-9 in 2008/190 [IPS]'s issues file. Feel free to refine or augment it. -- Glenn From Doug.Leavitt@sun.com Thu Aug 7 17:43:52 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 m780hpkh012322 for ; Thu, 7 Aug 2008 17:43:51 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m780hldC007721 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 8 Aug 2008 01:43:50 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K590080BBD0K400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 07 Aug 2008 17:43:48 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K59006UUBCZP110@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 07 Aug 2008 17:43:47 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m780hlqQ001990 for ; Thu, 07 Aug 2008 17:43:47 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5900B01B92DP00@fe-sfbay-09.sun.com> (original mail from Doug.Leavitt@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 07 Aug 2008 17:43:47 -0700 (PDT) Received: from [192.168.0.2] ([70.247.140.31]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K590003JBCY6AD0@fe-sfbay-09.sun.com>; Thu, 07 Aug 2008 17:43:47 -0700 (PDT) Date: Thu, 07 Aug 2008 19:43:46 -0500 From: Doug Leavitt Subject: Re: OpenLDAP for OpenSolaris [PSARC/2008/507 FastTrack timeout 07/13/2008] In-reply-to: <20080807212729.GB25547@Sun.COM> Sender: Doug.Leavitt@sun.com To: Doug Leavitt , Darren J Moffat , Nicolas Williams , PSARC-ext@sun.com Message-id: <489B96C2.3060705@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: <200808070502.m77525xG010946@sac.sfbay.sun.com> <489AB383.4080804@Sun.COM> <489B6645.9050109@sun.com> <20080807212729.GB25547@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080714) Status: RO Content-Length: 5566 I think that it is important that I point out a few key pieces of information on the issue of schema file locations. While it is true that LDAPv3 servers generally define their schemas according to the attribute type definitions specified in rfc4512 http://www.faqs.org/rfcs/rfc4512.html it's not true that the file formats containing those schema definitions are compatible across directory servers. In fact, the file formats for OpenLDAP and DSEE are both incompatible. Specifically, DSEE uses an LDIF based file format that defines each schema in terms of DSEE's built-in ldapSubentry and subschema classes. Like: dn: cn=schema objectclass: top objectclass: ldapSubentry objectclass: subschema cn: schema # # aci to ensure that the standard schema attributes are visible to # all LDAP clients (anonymous access). # aci: (target="ldap:///cn=schema")(targetattr !="aci")(version 3.0;acl "anonymous, no acis"; allow (read, search, compare) userdn = "ldap:///anyone";) ... attributeTypes: ( 1.3.6.1.1.1.1.0 NAME 'uidNumber' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'RFC 2307' ) attributeTypes: ( 1.3.6.1.1.1.1.1 NAME 'gidNumber' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'RFC 2307' ) attributeTypes: ( 1.3.6.1.1.1.1.2 NAME 'gecos' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'RFC 2307' ) However OpenLDAP uses a different approach. In OpenLDAP schema definitions are specified by using the attribute type definitions directly as in: # builtin #attributetype ( 1.3.6.1.1.1.1.0 NAME 'uidNumber' # DESC 'An integer uniquely identifying a user in an administrative domain' # EQUALITY integerMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) # builtin #attributetype ( 1.3.6.1.1.1.1.1 NAME 'gidNumber' # DESC 'An integer uniquely identifying a group in an administrative domain' # EQUALITY integerMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) attributetype ( 1.3.6.1.1.1.1.2 NAME 'gecos' DESC 'The GECOS field; the common name' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) Neither server can read the others format (to the best of my knowledge). So, while in general, all directory servers have common "schemas", it is important to realize that the schema files provided by this project are really server configuration files and not "abstract schema" files that would normally be shared by other components. That said, if PSARC feels that it is important to move this configuration data away from the other configuration files for the server [/etc/openldap/slapd.conf] into /usr/share or other, I will comply. I believe however, this will only serve to confuse admins and make OpenSolaris look odd compared to both Linux and our own DSEE product. Note in DSEE, the equivalent files are placed in the same layout: .../config/dse.ldif == /etc/openldap/slapd.conf .../config/schema/* == /etc/openldap/schema/* and there exist no "/usr/share" equivalents for DSEE of any release. Doug. Nicolas Williams wrote: > On Thu, Aug 07, 2008 at 04:16:53PM -0500, Doug Leavitt wrote: >> Darren J Moffat wrote: >>> [ Yeah Yet Another Ldap Library :-) The more the merrier! ] >>> >>> Is it possible to put the schema in /usr/share somewhere eg: >>> /usr/share/openldap/schema/. Not a big issue just seems that they >>> shouldn't need to be edited. >> The schema files are not static in the sense of "these will never >> change" They are static in the sense of a LDAP server administrator >> "should not modify these unless they really know what they are doing." > > If the sysadmin needs to modify them they can copy them to $TMPDIR, edit > them, and load them. There's no need to keep them around once edited, > but if there is we can deliver an empty /etc/openldap/schema/ and put > the standard schemas in /usr/share/openldap/schema as Darren suggests. > >> The schema files in /etc/openldap/schema are loaded via include >> statements during the initialization phase via the slapd.conf >> configuration file. Server administrators need to be able [and do] to >> modify, add and potentially delete some schemas as part of the >> configuration setup for the server. > > Right, but we should probably be able to deliver new versions of these > files without clobbering the admins' modified versions. Following the > CDE/X11 model I think that means putting originals in /usr/share and > admin-edited versions in /etc. > >>> I don't want it to stop the integration of this case but having the >>> existing /usr/lib/ldap.so.5 from Mozilla and the OpenLDAP library in >>> the same process is *highly* toxic and leads to very strange and hard >>> to debug problems - particularly when using LDAP over SSL/TLS. So >>> I'd encourage the projects teams management to fund the switch to >>> OpenLDAP for libsldap and nss_ldap ASAP. >> [...] >> >> In general any application linking with a libldap today, should no >> longer have library collisions due to the nsswitch's use of libldap. > > But there are other potential sources of conflict. > > For example, the integration of PSARC/2008/342 introduced a dependency > by libsec on libidmap, which brings in libldap, which brings in NSPR, > which broke VirtualBox because VirtualBox has a private copy of NSPR in > one of its shared objects. > > Nico From Doug.Leavitt@sun.com Thu Aug 7 17:56:05 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 m780u4HJ014259 for ; Thu, 7 Aug 2008 17:56:04 -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 m780tvRh027466; Fri, 8 Aug 2008 08:56:01 +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 <0K5900M03BXC8W00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Aug 2008 17:56:00 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5900FPPBXCW270@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Aug 2008 17:56:00 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m780u0Ut002544; Thu, 07 Aug 2008 17:56:00 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5900701BVQOP00@fe-sfbay-10.sun.com> (original mail from Doug.Leavitt@Sun.COM); Thu, 07 Aug 2008 17:55:59 -0700 (PDT) Received: from [192.168.0.2] ([70.247.140.31]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5900HLLBXBF1D0@fe-sfbay-10.sun.com>; Thu, 07 Aug 2008 17:55:59 -0700 (PDT) Date: Thu, 07 Aug 2008 19:55:58 -0500 From: Doug Leavitt Subject: Re: 2008/507 [ OpenLDAP for OpenSolaris] In-reply-to: <200808072325.m77NP8jF004069@ivrel.sfbay.sun.com> Sender: Doug.Leavitt@sun.com To: Glenn Skinner Cc: PSARC-ext@sun.com, nw141292@sac.sfbay.sun.com, Nicolas.Williams@sun.com Message-id: <489B999E.9070504@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: <200808072325.m77NP8jF004069@ivrel.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080714) Status: RO Content-Length: 1324 As the person looking to integrate this FOSS in a reasonable time frame, I would prefer not to add any IPS dependencies to this case. The [optional] SMF manifest, and resulting user/group were written as an administrative convenience for the expected administrator. The manifest and resulting issue could be removed, if PSARC desires... Or other... Doug. Glenn Skinner wrote: > Date: Thu, 07 Aug 2008 17:52:07 -0500 > From: Nicolas Williams > Subject: Re: 2008/507 [ OpenLDAP for OpenSolaris] > > On Thu, Aug 07, 2008 at 05:22:19PM -0500, Nicolas Williams wrote: > > On Thu, Aug 07, 2008 at 03:16:39PM -0700, Glenn Skinner wrote: > > > > Is it really necessary to allocate another user:group pair > > > from our dwindling stock of reserved values? Would it be > > > possible to share one of the already allocated entries from > > > the reserved part of the name space? > > > > My impression (please correct me if I'm wrong) is that with IPS > > the UIDs and GIDs can be allocated dynamically and that most > > pkgs that install local users/groups will often not be installed > > by the user anyways. > > I've confirmed this with Dave Miner. > > Are you proposing a dependency of this case on the IPS case? > > -- Glenn > From Nicolas.Williams@sun.com Thu Aug 7 17:56:31 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 m780uUZJ014284 for ; Thu, 7 Aug 2008 17:56:30 -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 m780uSNe002030; Thu, 7 Aug 2008 17:56:30 -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 <0K590090VBY57100@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Aug 2008 17:56:29 -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 <0K59006SSBY5OX20@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Aug 2008 17:56:29 -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 m780uPaS012309; Thu, 07 Aug 2008 19:56:25 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m780uOaP012308; Thu, 07 Aug 2008 19:56:24 -0500 (CDT) Date: Thu, 07 Aug 2008 19:56:24 -0500 From: Nicolas Williams Subject: Re: 2008/507 [ OpenLDAP for OpenSolaris] In-reply-to: <20080807235823.GI2024@zruty.sfbay.sun.com> To: Danek Duvall Cc: Glenn Skinner , PSARC-ext@sun.com, nw141292@sac.sfbay.sun.com, Doug.Leavitt@sun.com Mail-followup-to: Danek Duvall , Glenn Skinner , PSARC-ext@sun.com, nw141292@sac.sfbay.sun.com, Doug.Leavitt@sun.com Message-id: <20080808005624.GH25547@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: <200808072216.m77MGdct003847@ivrel.sfbay.sun.com> <20080807222218.GD25547@Sun.COM> <20080807225207.GG25547@Sun.COM> <20080807235823.GI2024@zruty.sfbay.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: 964 On Thu, Aug 07, 2008 at 04:58:23PM -0700, Danek Duvall wrote: > On Thu, Aug 07, 2008 at 05:52:07PM -0500, Nicolas Williams wrote: > > > IPS will alleviate the pressure, perhaps enough so that we can dodge > > this matter indefinitely. > > Er, I don't think that IPS alleviates the pressure. The pressure is the > fact that we've traditionally only reserved uids < (<=?) 100, and IPS > doesn't change that. If anything, it *increases* the pressure by making it > so easy to create new users without having the bottleneck of integrating > into ON. We can hope that administrators won't install all packages that > install new users, but that's not a very good plan. I thought it'd alleviate the pressure by causing most such packages not to be installed most of the time (e.g., most users won't need the OpenLDAP service installed). > Someone ought to tackle the problem, certainly, but (as others have already > said) I don't think that's this case. Right. From Nicolas.Williams@sun.com Thu Aug 7 17:57:23 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 m780vMVF014324 for ; Thu, 7 Aug 2008 17:57:23 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m780vDH2011961; Fri, 8 Aug 2008 01:57:20 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K590090PBZI8D00@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Aug 2008 17:57:18 -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 <0K59006FUBZHOZ20@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Aug 2008 17:57: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 m780vHRS012318; Thu, 07 Aug 2008 19:57:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m780vGwJ012317; Thu, 07 Aug 2008 19:57:16 -0500 (CDT) Date: Thu, 07 Aug 2008 19:57:16 -0500 From: Nicolas Williams Subject: Re: 2008/507 [ OpenLDAP for OpenSolaris] In-reply-to: <200808072325.m77NP8jF004069@ivrel.sfbay.sun.com> To: Glenn Skinner Cc: PSARC-ext@sun.com, nw141292@sac.sfbay.sun.com, Doug.Leavitt@sun.com Mail-followup-to: Glenn Skinner , PSARC-ext@sun.com, nw141292@sac.sfbay.sun.com, Doug.Leavitt@sun.com Message-id: <20080808005716.GI25547@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: <200808072325.m77NP8jF004069@ivrel.sfbay.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: 187 On Thu, Aug 07, 2008 at 04:25:08PM -0700, Glenn Skinner wrote: > I've confirmed this with Dave Miner. > > Are you proposing a dependency of this case on the IPS case? No. Nico -- From Darren.Moffat@sun.com Fri Aug 8 01:49:35 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 m788nYX5023910 for ; Fri, 8 Aug 2008 01:49:35 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m788nRsA021587 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 8 Aug 2008 16:49:34 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5900H01XULIG00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 08 Aug 2008 02:49:33 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K59009N8XUKX430@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 08 Aug 2008 02:49:32 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m788nVbt008624 for ; Fri, 08 Aug 2008 08:49:31 +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 <0K5900F01WROX900@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 08 Aug 2008 09:49:25 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5900BTWXTSIP90@fe-emea-10.sun.com>; Fri, 08 Aug 2008 09:49:05 +0100 (BST) Date: Fri, 08 Aug 2008 09:49:04 +0100 From: Darren J Moffat Subject: Re: OpenLDAP for OpenSolaris [PSARC/2008/507 FastTrack timeout 07/13/2008] In-reply-to: <489B96C2.3060705@sun.com> Sender: Darren.Moffat@sun.com To: Doug Leavitt Cc: Nicolas Williams , PSARC-ext@sun.com Message-id: <489C0880.6060809@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: <200808070502.m77525xG010946@sac.sfbay.sun.com> <489AB383.4080804@Sun.COM> <489B6645.9050109@sun.com> <20080807212729.GB25547@Sun.COM> <489B96C2.3060705@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 404 Given the interface stability of this case and the context on the modifiable nature of the schema files, together with the "incompatible" nature of them between directory servers, I'm happy for them to stay where they were originally specified to go for now. If a future case raises the interface stability of this case we can look at this issue again if it is still an issue. -- Darren J Moffat From carlsonj@phorcys.east.sun.com Fri Aug 8 03:57:30 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 m78AvUbl026841 for ; Fri, 8 Aug 2008 03:57:30 -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 m78AvThX000384; Fri, 8 Aug 2008 03:57:29 -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 <0K5A00G053RT5Z00@nwk-avmta-2.sfbay.sun.com>; Fri, 08 Aug 2008 03:57:29 -0700 (PDT) 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 <0K5A00FYY3RSGC00@nwk-avmta-2.sfbay.sun.com>; Fri, 08 Aug 2008 03:57:29 -0700 (PDT) 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 m78AvR3w017386; Fri, 08 Aug 2008 06:57:27 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m78AvRTL017383; Fri, 08 Aug 2008 06:57:27 -0400 (EDT) Date: Fri, 08 Aug 2008 06:57:27 -0400 From: James Carlson Subject: Re: 2008/507 [ OpenLDAP for OpenSolaris] In-reply-to: <20080807222218.GD25547@Sun.COM> To: Nicolas Williams Cc: Glenn Skinner , PSARC-ext@sun.com, nw141292@sac.sfbay.sun.com, Doug.Leavitt@sun.com Message-id: <18588.9879.930141.632871@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: <200808072216.m77MGdct003847@ivrel.sfbay.sun.com> <20080807222218.GD25547@Sun.COM> Status: RO Content-Length: 945 Nicolas Williams writes: > My impression (please correct me if I'm wrong) is that with IPS the UIDs > and GIDs can be allocated dynamically and that most pkgs that install > local users/groups will often not be installed by the user anyways. I don't understand how dynamic assignment would be administratively useful outside of the lone laptop environment. UIDs can be shared across machines. They show up in backups and file archives, in NFSv[23] messages, and in clustered file systems. How is assigning "well-known" UIDs in a dynamic manner something that would work when the user has more than one machine? We need a fix for this problem -- and fast -- but I don't see how what you're suggesting gets us closer. -- 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 Nicolas.Williams@sun.com Fri Aug 8 07:29:16 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 m78ETFWd002320 for ; Fri, 8 Aug 2008 07:29:16 -0700 (PDT) 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 m78ETDgm019452; Fri, 8 Aug 2008 07:29:14 -0700 (PDT) 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 <0K5A00003DKPHP00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 08 Aug 2008 07:29:13 -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 <0K5A00CPPDKNDN80@nwk-avmta-1.sfbay.Sun.COM>; Fri, 08 Aug 2008 07:29:11 -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 m78ETAiD012973; Fri, 08 Aug 2008 09:29:10 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m78ET9rH012972; Fri, 08 Aug 2008 09:29:09 -0500 (CDT) Date: Fri, 08 Aug 2008 09:29:09 -0500 From: Nicolas Williams Subject: Re: 2008/507 [ OpenLDAP for OpenSolaris] In-reply-to: <18588.9879.930141.632871@gargle.gargle.HOWL> To: James Carlson Cc: Glenn Skinner , PSARC-ext@sun.com, nw141292@sac.sfbay.sun.com, Doug.Leavitt@sun.com Mail-followup-to: James Carlson , Glenn Skinner , PSARC-ext@sun.com, nw141292@sac.sfbay.sun.com, Doug.Leavitt@sun.com Message-id: <20080808142909.GS25547@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: <200808072216.m77MGdct003847@ivrel.sfbay.sun.com> <20080807222218.GD25547@Sun.COM> <18588.9879.930141.632871@gargle.gargle.HOWL> 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: 1627 On Fri, Aug 08, 2008 at 06:57:27AM -0400, James Carlson wrote: > Nicolas Williams writes: > > My impression (please correct me if I'm wrong) is that with IPS the UIDs > > and GIDs can be allocated dynamically and that most pkgs that install > > local users/groups will often not be installed by the user anyways. > > I don't understand how dynamic assignment would be administratively > useful outside of the lone laptop environment. > > UIDs can be shared across machines. They show up in backups and file > archives, in NFSv[23] messages, and in clustered file systems. I wasn't trying to design the feature here. But let's say you filter out new dynamic assignments -- we're already doing such things with ephemeral IDs. IOW, new local system accounts would be really, _really_ local-only. But if we really need to represent the IDs of local system accounts on the wire in AUTH_SYS, NFSv3 then I'm not sure how to break the 100 reserved UID/GID barrier that we have short of using major release binding. If it could work (I've not explored this enough), I'd propose local system accounts with ephemeral IDs. Those would be representable on the wire in NFSv4, CIFS and tar/cpio/... (though not AUTH_SYS, and not NFSv2/3, but in the case of CIFS only if clients can understand SIDs where the server adds not one, but two RIDs to its computer SID (er, scratch Vista then), or where the server can have more than one SID, or if we switch to uing the SID authorities number 22 and 23. (We'd also need a convention for representing such local accounts in NFSv4 and archives; what to use as the "domain" name?) Nico -- From Nicolas.Williams@Sun.com Tue Aug 12 09:31:13 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 m7CGVDbq020764 for ; Tue, 12 Aug 2008 09:31:13 -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 m7CGV8FU061083; Tue, 12 Aug 2008 10:31:11 -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 <0K5H00C0TXVXN100@nwk-avmta-2.sfbay.sun.com>; Tue, 12 Aug 2008 09:31:09 -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 <0K5H00CHSXVW4D00@nwk-avmta-2.sfbay.sun.com>; Tue, 12 Aug 2008 09:31:08 -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 m7CGV7IK015723; Tue, 12 Aug 2008 11:31:07 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m7CGV7DO015722; Tue, 12 Aug 2008 11:31:07 -0500 (CDT) Date: Tue, 12 Aug 2008 11:31:07 -0500 From: Nicolas Williams Subject: Re: OpenLDAP for OpenSolaris [PSARC/2008/507 FastTrack timeout 07/13/2008] In-reply-to: <489B96C2.3060705@sun.com> To: Doug Leavitt Cc: Darren J Moffat , Nicolas Williams , PSARC-ext@Sun.com Mail-followup-to: Doug Leavitt , Darren J Moffat , Nicolas Williams , PSARC-ext@sun.com Message-id: <20080812163106.GT25547@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: <200808070502.m77525xG010946@sac.sfbay.sun.com> <489AB383.4080804@Sun.COM> <489B6645.9050109@sun.com> <20080807212729.GB25547@Sun.COM> <489B96C2.3060705@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: 7795 Doug has provided updates to the materials. I've placed these in the case directory as 'proposal.txt'. Diffs are included below for your convenience. Nico *** openldap.5 Tue Aug 12 08:28:41 2008 --- openldap Tue Aug 12 09:11:55 2008 *************** *** 128,137 **** so they do not to collide with the Mozilla headers in /usr/include. ! 2) the /usr/bin/ldap* commands are prefixed with "o" [as in ! /usr/bin/oldapsearch] so they do not collide with the existing ldap* Mozilla utilities in /usr/bin. The OpenLDAP library names match known Linux/*BSD distributions. Slapd server databases will be created, by default, in /var/openldap. --- 128,141 ---- so they do not to collide with the Mozilla headers in /usr/include. ! 2) The /usr/bin/ldap* commands are prefixed with "open" [as in ! /usr/bin/openldapsearch] so they do not collide with the existing ldap* Mozilla utilities in /usr/bin. + 3) The directory /usr/lib/openldap/bin contains sym links to + the /usr/bin/openldap* commands, using names matching the + original ldap* names [as in /usr/lib/openldap/bin/ldapsearch]. + The OpenLDAP library names match known Linux/*BSD distributions. Slapd server databases will be created, by default, in /var/openldap. *************** *** 155,167 **** 2.5 SMF Manifest and Runtime behavior This project proposes to provide a SMF manifest, disabled by ! default, for the OpenLDAP slapd server. The slapd server has the ! ability to change it's user and group and run as a non-privileged ! user after binding listener sockets to the privileged LDAP port(s). Generally slapd is run as user openldap and group openldap. The ! SMF manifest will start slapd as root and with privileges but ! configured to become openldap:openldap; slapd will retain basic ! privileges. This project proposes to update the following databases to provide the the necessary dummy openldap user and group entries: --- 159,168 ---- 2.5 SMF Manifest and Runtime behavior This project proposes to provide a SMF manifest, disabled by ! default, for the OpenLDAP slapd server. Generally slapd is run as user openldap and group openldap. The ! SMF manifest will start slapd as user openldap, group openldap using ! the privileges basic,net_privaddr. This project proposes to update the following databases to provide the the necessary dummy openldap user and group entries: *************** *** 212,235 **** | | |SUNWopenldapu Uncommitted Package name| |/usr/include/openldap Uncommitted Directory| ! |/usr/bin/${MACH64}/oldapadd Volatile CLI tool| ! |/usr/bin/${MACH64}/oldapcompare Volatile CLI tool| ! |/usr/bin/${MACH64}/oldapdelete Volatile CLI tool| ! |/usr/bin/${MACH64}/oldapexop Volatile CLI tool| ! |/usr/bin/${MACH64}/oldapmodify Volatile CLI tool| ! |/usr/bin/${MACH64}/oldapmodrdn Volatile CLI tool| ! |/usr/bin/${MACH64}/oldappasswd Volatile CLI tool| ! |/usr/bin/${MACH64}/oldapsearch Volatile CLI tool| ! |/usr/bin/${MACH64}/oldapwhoami Volatile CLI tool| ! |/usr/bin/oldapadd Volatile CLI tool| ! |/usr/bin/oldapcompare Volatile CLI tool| ! |/usr/bin/oldapdelete Volatile CLI tool| ! |/usr/bin/oldapexop Volatile CLI tool| ! |/usr/bin/oldapmodify Volatile CLI tool| ! |/usr/bin/oldapmodrdn Volatile CLI tool| ! |/usr/bin/oldappasswd Volatile CLI tool| ! |/usr/bin/oldapsearch Volatile CLI tool| ! |/usr/bin/oldapwhoami Volatile CLI tool| |/usr/include/openldap Uncommitted Directory| |/usr/include/openldap/lber.h Volatile header file| |/usr/include/openldap/lber_types.h Volatile header file| --- 213,254 ---- | | |SUNWopenldapu Uncommitted Package name| |/usr/include/openldap Uncommitted Directory| ! |/usr/bin/${MACH64}/openldapadd Volatile CLI tool| ! |/usr/bin/${MACH64}/openldapcompare Volatile CLI tool| ! |/usr/bin/${MACH64}/openldapdelete Volatile CLI tool| ! |/usr/bin/${MACH64}/openldapexop Volatile CLI tool| ! |/usr/bin/${MACH64}/openldapmodify Volatile CLI tool| ! |/usr/bin/${MACH64}/openldapmodrdn Volatile CLI tool| ! |/usr/bin/${MACH64}/openldappasswd Volatile CLI tool| ! |/usr/bin/${MACH64}/openldapsearch Volatile CLI tool| ! |/usr/bin/${MACH64}/openldapwhoami Volatile CLI tool| ! |/usr/bin/openldapadd Volatile CLI tool| ! |/usr/bin/openldapcompare Volatile CLI tool| ! |/usr/bin/openldapdelete Volatile CLI tool| ! |/usr/bin/openldapexop Volatile CLI tool| ! |/usr/bin/openldapmodify Volatile CLI tool| ! |/usr/bin/openldapmodrdn Volatile CLI tool| ! |/usr/bin/openldappasswd Volatile CLI tool| ! |/usr/bin/openldapsearch Volatile CLI tool| ! |/usr/bin/openldapwhoami Volatile CLI tool| ! |/usr/lib/openldap/bin/${MACH64}/ldapadd Volatile sym link| ! |/usr/lib/openldap/bin/${MACH64}/ldapcompare Volatile sym link| ! |/usr/lib/openldap/bin/${MACH64}/ldapdelete Volatile sym link| ! |/usr/lib/openldap/bin/${MACH64}/ldapexop Volatile sym link| ! |/usr/lib/openldap/bin/${MACH64}/ldapmodify Volatile sym link| ! |/usr/lib/openldap/bin/${MACH64}/ldapmodrdn Volatile sym link| ! |/usr/lib/openldap/bin/${MACH64}/ldappasswd Volatile sym link| ! |/usr/lib/openldap/bin/${MACH64}/ldapsearch Volatile sym link| ! |/usr/lib/openldap/bin/${MACH64}/ldapwhoami Volatile sym link| ! |/usr/lib/openldap/bin/ldapadd Volatile sym link| ! |/usr/lib/openldap/bin/ldapcompare Volatile sym link| ! |/usr/lib/openldap/bin/ldapdelete Volatile sym link| ! |/usr/lib/openldap/bin/ldapexop Volatile sym link| ! |/usr/lib/openldap/bin/ldapmodify Volatile sym link| ! |/usr/lib/openldap/bin/ldapmodrdn Volatile sym link| ! |/usr/lib/openldap/bin/ldappasswd Volatile sym link| ! |/usr/lib/openldap/bin/ldapsearch Volatile sym link| ! |/usr/lib/openldap/bin/ldapwhoami Volatile sym link| |/usr/include/openldap Uncommitted Directory| |/usr/include/openldap/lber.h Volatile header file| |/usr/include/openldap/lber_types.h Volatile header file| From Nicolas.Williams@sun.com Wed Aug 13 10:07:13 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 m7DH6cHb007772 for ; Wed, 13 Aug 2008 10:07:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m7DH6YcH001620; Thu, 14 Aug 2008 01:06:36 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5J00605U6XMM00@brm-avmta-1.central.sun.com>; Wed, 13 Aug 2008 11:06:33 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5J002D7U6X7L30@brm-avmta-1.central.sun.com>; Wed, 13 Aug 2008 11:06:33 -0600 (MDT) 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 m7DH6HkF016653; Wed, 13 Aug 2008 12:06:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m7DH6GsV016652; Wed, 13 Aug 2008 12:06:16 -0500 (CDT) Date: Wed, 13 Aug 2008 12:06:16 -0500 From: Nicolas Williams Subject: Re: OpenLDAP for OpenSolaris [PSARC/2008/507 FastTrack timeout 07/13/2008] In-reply-to: <200808070502.m77525xG010946@sac.sfbay.sun.com> To: Nicolas Williams Cc: PSARC-ext@sun.com, Doug.Leavitt@sun.com Mail-followup-to: Nicolas Williams , PSARC-ext@sun.com, Doug.Leavitt@sun.com Message-id: <20080813170616.GO25547@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: <200808070502.m77525xG010946@sac.sfbay.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: 65 This case was approved today during open ARC business. Nico --