From dhain@sac.sfbay.sun.com Thu Dec 17 14:59:00 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBHMx0sw013596 for ; Thu, 17 Dec 2009 14:59:00 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nBHMwxUX043540; Thu, 17 Dec 2009 15:58:59 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUT00407JUBH500@brm-avmta-1.central.sun.com>; Thu, 17 Dec 2009 15:58:59 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUT0082XJUBIXB0@brm-avmta-1.central.sun.com>; Thu, 17 Dec 2009 15:58:59 -0700 (MST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBHMwwds013301; Thu, 17 Dec 2009 14:58:58 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBHMwvu4013591; Thu, 17 Dec 2009 14:58:57 -0800 (PST) Received: (from dhain@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id nBHMwuE4013587; Thu, 17 Dec 2009 14:58:56 -0800 (PST) Date: Thu, 17 Dec 2009 14:58:56 -0800 (PST) From: Daniel Hain Subject: Update Samba to release 3.4 [PSARC/2009/682 FastTrack timeout 12/24/2009] To: PSARC-ext@sun.com Cc: Jiri.Sasek@sun.com, Lukas.Rovensky@sun.com Message-id: <200912172258.nBHMwuE4013587@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 10405 I'm submitting this fasttrack for Jiri Sasek, seeking patch binding for backport to S10. Timeout is on 12/24/2009. The proposal is to upgrade the current version of Samba to 3.4. The change in license from GPlv2 to GPLv3 has been reviewed by legal. https://opensourcereview.central.sun.com/app?action=ViewReq&traq_num=8443 The case directory contains 2 files, pkgs-1 contains a list of the package contents for the upgrade, ldap-pkg contains the package contents for the ldap deliverables. -Dan Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Update Samba to release 3.4 1.2. Name of Document Author/Supplier: Author: Jiri Sasek 1.3 Date of This Document: 17 December, 2009 4. Technical Description Proposal: Update Samba to release 3.4 and above in Solaris 10 and above. Detail: Samba is the only available CIFS volume and printing server in Solaris 10 and 9 (production releases of the Solaris). Samba is the only available CIFS printing server in Solaris 9 and above. Besides Apache, Samba is the most important component in Solaris in the case of the business deployment. It plays primary role in interoperability with the MS Windows on Solaris 10 and 9. Samba.org community discontinued support of the Samba 3.0.x currently bundled with all releases of Solaris. Samba.org community also changed the release model for samba where the minor release number is expected to be increased each approx. 6 month. Currently samba 3.5 pre-release is available and is expected to be released this year. Align the bundled release to community latest stable (3.4.3 in time of writing of this document) will allow to continue in porting all of the fixes released by the community into the Solaris bundle. As with any other FOSS component it is important to maintain the integrated version of Samba on "community supported stable version", so Sun can leverage the bug fixing work done by the community as well as getting new product features being added by the community. This is simply the most cost-effective approach, otherwise Sun needs to invest its own resources to bug fixing and does not get any new features on Samba, so it stays behind the community. Such approach is now possible only with Samba 3.4.x. In scope of this project is to update Samba to "latest stable" release supported by the community in Solaris 10 and above. Update of the samba in Solaris 9 is out of scope of this project where only the security fixes are expected in Solaris 9. Original integration of samba in Solaris introduced in PSARC/2000/488 was related to samba 2.2.x so it does not fully respect the current releases of samba, which are designed on modular basis. Placing of the samba loadable modules and libraries into the private locations should be accented here to prevent unintentional linking of the 3-rd party SWs to it. Samba executable objects will be moved from its original location in /usr/sfw to more generic paths in /usr/bin, /usr/sbin and /etc. Respecting the PSARC/2007/047 (/usr/gnu) the conflicting objects will be prefixed by "smb". Currently the "profiles" will be renamed to "smbprofiles". Private modules of the samba will be "separated" in the /usr/lib/samba subdirectory to hide these objects from the standard linker paths to prevent unintentional linking on it. On Solaris 10 the symbolic links will be created on the original positions of samba utilities in /usr/sfw/bin pointing to the new locations of these utilities in /usr/bin to conserve the compatibility of scripts created before this change. Current releases of Samba are released under the GPLv3 where 3.0.x releases of Samba replaced by this case were released under GPLv2. To prevent unintentional detecting of samba headers by GNU autoconf during the build of the other FOSS Solaris components we should isolate such samba headers into the separated directory (/usr/include/samba) to prevent possible legal issues in case of the automaticaly ported GPLv2 applications. Only the application bundled by hand will be allowed to browse this non-standard path by GNU autoconf if it will be allowed to do so. To fulfill conditions of the LSARC/2006/350/ contract where gnome-vfs released under GPLv2 is contracted to link libsmbclient so libsmbclient built from the samba 3.0. release (GPLv2) source will not be removed from the updated samba packages. GPLv2 licensed libsmbclient will remain located in /usr/sfw/lib (libraries) and /usr/sfw/include (header) as is currently located. Configuration file smb.conf and private-data directory currently located in /etc/sfw will be moved to separate directory /etc/samba to make samba removal from the system more simple in case of the CIFS server migration. In such case is more clean which private data belongs to samba than to the other SFW applications. This case adds 64-bit modules for PAM and NSS also which were missing from previous Samba cases by mistake and it brought problems for some applications in 64-bit enviroment in some setups. Samba man pages will be moved on Solaris 10 from the SUNWsfman package directly to SUNWsmbau samba package so further samba patches will not address changes in SUNWsfman. Samba man pages on Nevada together with samba html pages will be moved to the newly created package SUNWsmbadocu. Samba html pages are accessed via SWAT (Samba Web Admin. Tool) available as SMF(5) service. SMF(5) xml-manifest will be delivered by SUNWsmbadocr package. Samba html pages are currently located in /etc/sfw/swat and will be moved to /usr/share/samba/swat. There is intention to put also the DocBook source xml-code into the /usr/share/samba/xml but current release os DocBook in Nevada is too obsoleted to handle the xml-sources from samba.org archive. Availability of xml-source will allow to generate also the different output formats (i.e. PDF) by user. Samba 3.3 and above support remote administration by Win-RPC directly from registry editting application (i.e. regedit.exe). This style of remote administration is most common for MS Windows admins who are using gui administration tools. Forking the html documentation and Web based administration of samba into the separate packages will allow not to install these componnents in such case where just the documentation is representing majority in amount of data in SUNWsmbau package. It will make samba updates more flexible and lower the footprint. Exported Interfaces: In general samba is 3-rd party OpenSource product so only the committed interfaces are: - subdirectories to place the samba components - package names - SMF(5) services name description ------- Committed interfaces ---------------------------------------- /usr/sbin location of samba daemons /usr/bin location of samba utilities /usr/share/man manual pages /usr/include/samba location of headers exported by samba /usr/lib/samba location of samba libraries, modules, static data and docs /usr/lib/samba/$(MACH64) 64-bit libs needed by 64-bits modules /etc/samba configuration and passwords directory /etc/samba/smb.conf location of the default configuration file /var/samba runtime data directory /usr/share/samba samba .html docs for SWAT SUNWsmbar Samba (Root) package SUNWsmbau Samba (Usr) package samba SMF(5) service - CIFS session winbind SMF(5) service - idmap wins SMF(5) service - WINS hostnames swat SMF(5) service - Samba Web Adm. Tool --- The following packages will be added on Nevada --- SUNWmozldapC-SDK Mozilla DS6 C-SDK package DS6 C-SDK file objects will be delivered by SUNWsmbau package on Solaris 10. SUNWsmbadocr Samba documentation (Root) package SUNWsmbadocu Samba documentation (Usr) package Doc packages will not fork from SUNWsmbar SUNWsmbar packages on Solaris 10. ------ Uncommitted interfaces --------------------------------------- smb.conf Configuration file option syntax Imported Interfaces: Mozilla DS6 C-SDK ldap client API Directory Server C-SDK (LDAP client's C-API) is described by RFC 1823 IETF document. It provides set of library calls to handle data in directory by application. This is Mozilla community project. Extensions to RFC 1823 are documented in: http://www.mozilla.org/directory/ietf-docs/draft-ietf-ldapext-ldap-c-api-05.txt DS 6 C-API depend on other external interfaces also provided by Mozilla: NSS (Network Security Services) Homepage of the project is: http://www.mozilla.org/projects/security/pki/nss/ Bundled in solaris by the: SUNWtls package NSPR (Netscape Portable Runtime) Homepage of the project is: http://www.mozilla.org/projects/nspr/ Bundled in solaris by the: SUNWpr package libkrb5 Kerberos v5 API NSS interface is attached in modules: /usr/lib/nss_wins.so /usr/lib/$(MACH64)/nss_wins.so /usr/lib/nss_winbind.so /usr/lib/$(MACH64)/nss_winbind.so PAM interface is attached in modules: /usr/lib/security/pam_winbind.so /usr/lib/security/$(MACH64)/pam_winbind.so References: [01] http://samba.org/ Author(s) of Samba: Samba has many individual contributors and also the corporations like IBM, RedHat, SuSe. Authorship should be mentioned in each individual file in the Samba upstream. Core team is here: http://www.samba.org/samba/team/ [02] 6852659 Update samba to 3.3.5 or later [03] 6647164 net ads keytab add host fails to create keytab entry [04] https://wiki.mozilla.org/LDAP_C_SDK [05] 6892860 Samba needs Directory Server 6 C-SDK [06] 6447666 ldap_add_result_entry() is LOCL in libldap.so.5 ; Samba can not be built with the ADS support [07] 6706912 SWAT component of Samba should be a separate package. [08] 6902485 stealth samba man pages [09] 6770655 Samba: Bugzilla 5655 "Mac OS X 10.5.4 clients fail to authenticate with Kerberos credententials" [10] 6891889 Write keytab to file method is missing in krb5_keytab [11] 4900104 Insufficient number of interfaces allowed [SunIT] [12] 6902485 stealth samba man pages 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Peter.Harvey@sun.com Fri Dec 18 05:39:07 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBIDd7gk011781 for ; Fri, 18 Dec 2009 05:39:07 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nBIDd6Tt004077 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 18 Dec 2009 06:39:07 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUU0021DOL6IS00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 18 Dec 2009 05:39:06 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUU00FQMOL58Q90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 18 Dec 2009 05:39:05 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBIDd4nC004726 for ; Fri, 18 Dec 2009 13:39:04 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUU00H00MEQ4D00@fe-emea-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 18 Dec 2009 13:38:44 +0000 (GMT) Received: from [129.156.173.94] ([unknown] [129.156.173.94]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUU00DNQOKCS070@fe-emea-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 18 Dec 2009 13:38:36 +0000 (GMT) Date: Fri, 18 Dec 2009 13:38:36 +0000 From: Peter Harvey Subject: Re: Update Samba to release 3.4 [PSARC/2009/682 FastTrack timeout 12/24/2009] In-reply-to: <200912172258.nBHMwuE4013587@sac.sfbay.sun.com> Sender: Peter.Harvey@sun.com To: Dan Hain Cc: PSARC-ext@sun.com, Jiri Sasek , Lukas Rovensky , Michen Chang , Raja Gopal Andra Message-id: <4B2B85DC.9040609@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912172258.nBHMwuE4013587@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091027) Status: RO Content-Length: 1493 What is the status of the new Mozilla LDAP 6 libraries? > Imported Interfaces: > > Mozilla DS6 C-SDK ldap client API > Directory Server C-SDK (LDAP client's C-API) is described > by RFC 1823 IETF document. It provides set of library calls > to handle data in directory by application. This is Mozilla > community project. See: Jiri and I have already had an extended discussion on whether Solaris should be providing an updated libldap. Currently we have modified (aka hacked) Mozilla LDAP 5 (libldap.so.5), we'd like to move to standard Mozilla LDAP 6 (libldap.so.6) but the work isn't funded at present. Is this private to Samba? If not, how do we support other consumers of this interface? > DS 6 C-API depend on other external interfaces also provided by Mozilla: > NSS (Network Security Services) > Homepage of the project is: > http://www.mozilla.org/projects/security/pki/nss/ > Bundled in solaris by the: > SUNWtls package Any necessity to update our NSS versions? Current version is 3.12.x, see: 6821612 NSS 3.12.x series I couldn't find an explicit ARC for that change, WSARC 2007/548 is the closest I got. -- Peter Software Engineering Manager, Solaris RPE Naming - Sun Microsystems Details: Blogs: SunIM: peteh@im.sun.com From Lukas.Rovensky@sun.com Fri Dec 18 05:43:21 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBIDhLm8011812 for ; Fri, 18 Dec 2009 05:43:21 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBIDhJMj009156 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 18 Dec 2009 07:43:20 -0600 (CST) 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 <0KUU00307OS8EL00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 18 Dec 2009 05:43:20 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUU00FUYOS78K80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 18 Dec 2009 05:43:19 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBIDhIBx005304 for ; Fri, 18 Dec 2009 13:43:18 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUU00M00OL59700@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 18 Dec 2009 13:43:11 +0000 (GMT) Received: from [129.157.18.67] ([unknown] [129.157.18.67]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUU00FUZORZXZE0@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 18 Dec 2009 13:43:11 +0000 (GMT) Date: Fri, 18 Dec 2009 14:42:14 +0100 From: Lukas Rovensky Subject: Re: Update Samba to release 3.4 [PSARC/2009/682 FastTrack timeout 12/24/2009] In-reply-to: <4B2B85DC.9040609@Sun.COM> Sender: Lukas.Rovensky@sun.com To: Peter Harvey Cc: Dan Hain , PSARC-ext@sun.com, Jiri Sasek , Michen Chang , Raja Gopal Andra Message-id: <4B2B86B6.6000905@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912172258.nBHMwuE4013587@sac.sfbay.sun.com> <4B2B85DC.9040609@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 1808 I believe that all the new Mozilla LDAP 6 libraries should be marked as "private" to Samba in this PSARC. Until there is a funding to integrate and support them they cannot be "public". Lukas Peter Harvey wrote: > What is the status of the new Mozilla LDAP 6 libraries? > >> Imported Interfaces: >> >> Mozilla DS6 C-SDK ldap client API >> Directory Server C-SDK (LDAP client's C-API) is described >> by RFC 1823 IETF document. It provides set of library calls >> to handle data in directory by application. This is Mozilla >> community project. > > See: > > Jiri and I have already had an extended discussion on whether Solaris > should be providing an updated libldap. Currently we have modified (aka > hacked) Mozilla LDAP 5 (libldap.so.5), we'd like to move to standard > Mozilla LDAP 6 (libldap.so.6) but the work isn't funded at present. > > Is this private to Samba? If not, how do we support other consumers of > this interface? > >> DS 6 C-API depend on other external interfaces also provided by >> Mozilla: >> NSS (Network Security Services) >> Homepage of the project is: >> http://www.mozilla.org/projects/security/pki/nss/ >> Bundled in solaris by the: >> SUNWtls package > > Any necessity to update our NSS versions? Current version is 3.12.x, see: > > 6821612 NSS 3.12.x series > > > I couldn't find an explicit ARC for that change, WSARC 2007/548 is the > closest I got. > > -- Peter > Software Engineering Manager, Solaris RPE Naming - Sun Microsystems > Details: > Blogs: > SunIM: peteh@im.sun.com From Darren.Moffat@sun.com Mon Dec 21 13:59:15 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBLLxFaf023391 for ; Mon, 21 Dec 2009 13:59:15 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBLLxE1N026171 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 21 Dec 2009 15:59:15 -0600 (CST) 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 <0KV000L09VQRXU00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 21 Dec 2009 13:59:15 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV000A64VQQZQA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 21 Dec 2009 13:59:14 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBLLxDOb002645 for ; Mon, 21 Dec 2009 21:59:13 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KV000D00VES7W00@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 21 Dec 2009 21:59:05 +0000 (GMT) Received: from [192.168.2.108] (99-52-200-208.lightspeed.snjsca.sbcglobal.net [99.52.200.208]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KV00050PVQCBD60@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 21 Dec 2009 21:59:05 +0000 (GMT) Date: Mon, 21 Dec 2009 13:56:42 -0800 From: Darren J Moffat Subject: Re: Update Samba to release 3.4 [PSARC/2009/682 FastTrack timeout 12/24/2009] In-reply-to: <4B2B86B6.6000905@sun.com> Sender: Darren.Moffat@sun.com To: Lukas Rovensky Cc: Peter Harvey , Dan Hain , PSARC-ext@sun.com, Jiri Sasek , Michen Chang , Raja Gopal Andra Message-id: <4B2FEF1A.5030500@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912172258.nBHMwuE4013587@sac.sfbay.sun.com> <4B2B85DC.9040609@Sun.COM> <4B2B86B6.6000905@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091109) Status: RO Content-Length: 1344 Lukas Rovensky wrote: > I believe that all the new Mozilla LDAP 6 libraries should be marked as > "private" to Samba in this PSARC. Until there is a funding to integrate > and support them they cannot be "public". That is generally not the acceptable stance. In this particular case given the history of the Mozilla LDAP libraries in Solaris going back many more years I think this is even more unacceptable. The risk of having multiple versions of the LDAP libraries dragged into the same process (Samba in this case) is quite high. I strongly encourage the project team to find away so that the Mozilla LDAP 6 library is made common (ie a public taxonomy) for all to use - that doesn't mean supporting it themselves but working with the appropriate groups to do so. If the project can't do that then I feel I have to derail this case given the history of LDAP libraries in Solaris and the fact it has already been stated by RPE (Revenue Product Engineering) that they would rather see the Mozilla LDAP 6 library replace the current (hacked up) Mozilla LDAP 5. Remember that derail does not mean your case is rejected just that it needs a vote and ARC opinion. It may not even need a full review in this case since the issue isn't with the core architecture of Samba but an issue with a dependency. -- Darren J Moffat From Lukas.Rovensky@sun.com Mon Dec 21 22:37:12 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBM6bCGr029671 for ; Mon, 21 Dec 2009 22:37:12 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBM6Yq7o014744 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 21 Dec 2009 22:37:10 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV100L01JPC8600@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 21 Dec 2009 23:36:48 -0700 (MST) 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 <0KV100B64JPB4O50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 21 Dec 2009 23:36:47 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBM6akQa019981 for ; Tue, 22 Dec 2009 06:36:47 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KV100L00JEAVJ00@fe-emea-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 22 Dec 2009 06:36:21 +0000 (GMT) Received: from MyspulinMini.local ([unknown] [85.207.15.101]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KV100IJIJOFEQ20@fe-emea-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 22 Dec 2009 06:36:21 +0000 (GMT) Date: Tue, 22 Dec 2009 07:36:15 +0100 From: Lukas Rovensky Subject: Re: Update Samba to release 3.4 [PSARC/2009/682 FastTrack timeout 12/24/2009] In-reply-to: <4B2FEF1A.5030500@Sun.COM> Sender: Lukas.Rovensky@sun.com To: Darren J Moffat Cc: Peter Harvey , Dan Hain , PSARC-ext@sun.com, Jiri Sasek , Michen Chang , Raja Gopal Andra Message-id: <4B3068DF.4000907@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912172258.nBHMwuE4013587@sac.sfbay.sun.com> <4B2B85DC.9040609@Sun.COM> <4B2B86B6.6000905@sun.com> <4B2FEF1A.5030500@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Status: RO Content-Length: 2223 Darren J Moffat wrote: > Lukas Rovensky wrote: >> I believe that all the new Mozilla LDAP 6 libraries should be marked >> as "private" to Samba in this PSARC. Until there is a funding to >> integrate and support them they cannot be "public". > > That is generally not the acceptable stance. In this particular case > given the history of the Mozilla LDAP libraries in Solaris going back > many more years I think this is even more unacceptable. > > The risk of having multiple versions of the LDAP libraries dragged into > the same process (Samba in this case) is quite high. > > I strongly encourage the project team to find away so that the Mozilla > LDAP 6 library is made common (ie a public taxonomy) for all to use - > that doesn't mean supporting it themselves but working with the > appropriate groups to do so. If the project can't do that then I feel I > have to derail this case given the history of LDAP libraries in Solaris > and the fact it has already been stated by RPE (Revenue Product > Engineering) that they would rather see the Mozilla LDAP 6 library > replace the current (hacked up) Mozilla LDAP 5. > > Remember that derail does not mean your case is rejected just that it > needs a vote and ARC opinion. It may not even need a full review in > this case since the issue isn't with the core architecture of Samba but > an issue with a dependency. > Darren, I understand your concerns but your request is really out of scope of Samba I-team responsibilities. Regardless, we actually tried several times to get the Mozilla LDAP 6 C SDK integrated to Solaris as common component but there was always someone who had objections to this. Anyway, I will try yet again to explore what are our options in this space and get back to this forum in early January. However, I guess that we will have to ask for the vote and ARC opinion to proceed with this case as you explained. Just a note -- having up to data Samba in S10 is really about making money and keeping our customers on Solaris. Old version of Samba in S10 means more expensive support for us, lack of new features for customers and represents a danger that some customers will walk away from Solaris. Lukas From Milan.Jurik@sun.com Tue Dec 22 02:33:40 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBMAXeZe017070 for ; Tue, 22 Dec 2009 02:33:40 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBMAXesv004561 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 22 Dec 2009 02:33:40 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV10000PUO3F800@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Dec 2009 03:33:39 -0700 (MST) 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 <0KV100EBJUO1CX60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Dec 2009 03:33:38 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBMAXa8p018237 for ; Tue, 22 Dec 2009 10:33:37 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KV100500UCE2I00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Dec 2009 10:33:36 +0000 (GMT) Received: from [129.157.18.63] ([unknown] [129.157.18.63]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KV100K16UNY05G0@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Dec 2009 10:33:34 +0000 (GMT) Date: Tue, 22 Dec 2009 11:33:29 +0100 From: Milan Jurik Subject: Re: Update Samba to release 3.4 [PSARC/2009/682 FastTrack timeout 12/24/2009] In-reply-to: <4B2FEF1A.5030500@Sun.COM> Sender: Milan.Jurik@sun.com To: Darren J Moffat Cc: Lukas Rovensky , Peter Harvey , Dan Hain , PSARC-ext@sun.com, Jiri Sasek , Michen Chang , Raja Gopal Andra Message-id: <1261478009.2799.43.camel@xylabone> Organization: Sun Microsystems - Prague Czech Republic MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200912172258.nBHMwuE4013587@sac.sfbay.sun.com> <4B2B85DC.9040609@Sun.COM> <4B2B86B6.6000905@sun.com> <4B2FEF1A.5030500@Sun.COM> Status: RO Content-Length: 1724 Hi, Darren J Moffat píše v po 21. 12. 2009 v 13:56 -0800: > Lukas Rovensky wrote: > > I believe that all the new Mozilla LDAP 6 libraries should be marked as > > "private" to Samba in this PSARC. Until there is a funding to integrate > > and support them they cannot be "public". > > That is generally not the acceptable stance. In this particular case > given the history of the Mozilla LDAP libraries in Solaris going back > many more years I think this is even more unacceptable. > > The risk of having multiple versions of the LDAP libraries dragged into > the same process (Samba in this case) is quite high. > > I strongly encourage the project team to find away so that the Mozilla > LDAP 6 library is made common (ie a public taxonomy) for all to use - > that doesn't mean supporting it themselves but working with the > appropriate groups to do so. If the project can't do that then I feel I > have to derail this case given the history of LDAP libraries in Solaris > and the fact it has already been stated by RPE (Revenue Product > Engineering) that they would rather see the Mozilla LDAP 6 library > replace the current (hacked up) Mozilla LDAP 5. > > Remember that derail does not mean your case is rejected just that it > needs a vote and ARC opinion. It may not even need a full review in > this case since the issue isn't with the core architecture of Samba but > an issue with a dependency. > One remainder, for business reasons we had similar situation in Solaris 8 - sldaputil.so.5 - for Native LDAP II. Yes, libldap.so.6 for Nevada as public is more than needed, to solve a lot of troubles and limits. But for Solaris 10? Plus in reasonable timeframe? Best regards, Milan From Lukas.Rovensky@sun.com Sun Jan 10 11:46:44 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0AJkiZW024964 for ; Sun, 10 Jan 2010 11:46:44 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0AJkhjR009026 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 10 Jan 2010 13:46:44 -0600 (CST) 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 <0KW10090HQXVMF00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Sun, 10 Jan 2010 11:46:43 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KW100F60QXTXTC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Sun, 10 Jan 2010 11:46:42 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0AJkfCJ006313 for ; Sun, 10 Jan 2010 19:46:41 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KW100C00QNGHU00@fe-emea-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sun, 10 Jan 2010 19:46:37 +0000 (GMT) Received: from MyspulinMini.local ([unknown] [85.207.15.101]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KW1003ADQXOS5D0@fe-emea-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sun, 10 Jan 2010 19:46:37 +0000 (GMT) Date: Sun, 10 Jan 2010 20:46:35 +0100 From: Lukas Rovensky Subject: Re: Update Samba to release 3.4 [PSARC/2009/682 FastTrack timeout 12/24/2009] In-reply-to: <4B3068DF.4000907@sun.com> Sender: Lukas.Rovensky@sun.com To: Darren J Moffat , PSARC-ext@sun.com Cc: Lukas Rovensky , Peter Harvey , Dan Hain , Jiri Sasek , Michen Chang , Raja Gopal Andra Message-id: <4B4A2E9B.5000205@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912172258.nBHMwuE4013587@sac.sfbay.sun.com> <4B2B85DC.9040609@Sun.COM> <4B2B86B6.6000905@sun.com> <4B2FEF1A.5030500@Sun.COM> <4B3068DF.4000907@sun.com> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Status: RO Content-Length: 4557 Hi all, as promised, I explored the options we have concerning Samba 3.4 x Mozilla LDAP 6 C SDK. As you can see below there is currently no ideal solution and a compromise will be needed. From the business point of view we really would like to be able to put Samba 3.4 to S10U9 -- we are already getting requests for interoperability with Windows 7, [1] and again the answer is Samba 3.4. Here is a list of options, which were discussed off-channel -- any feedback is welcome: 1) Leave the PSARC case as it is and ask PSARC members for the vote and opinion as mentioned by Darren. This is currently the preferred option by the I-team. 2) Use OpenLDAP, which is already integrated in Nevada and use Mozilla LDAP 6 C SDK as Samba's private component in S10. This will have a clear disadvantage of having different Samba's in S10 and Nevada. Any LDAP related issue will have to be solved separately for Nevada and S10 and the maintenance cost will increase. 3) Mark the Mozilla LDAP 6 C SDK a "public" component in Nevada. Jiri can still help with the integration but we will need a commitment from the Naming folks that they will support this component (at least on level C). The LDAP 6 C SDK still shall be Samba's private component in S10. However, based on the discussion with Naming engineers this would basically mean an LDAP C SDK update in Nevada, a separate PSARC case will be required and such solution will certainly take longer than the time frame we have for S10U9. Besides, we still may have a problem with getting resources from the Naming team to assist with this task. 4) Use OpenLDAP instead of Mozilla LDAP 6 C SDK. This will work in Nevada but will represent a problem for S10. As per the experiments performed by Jiri -- integration of OpenLDAP to S10 (as private Samba's component) is not trivial and this will also mean to integrate much bigger beast than just the LDAP C SDK. OpenLDAP is being changed rather often, so this will also bring an additional burden for the I-team to maintain it as part of Samba in S10. We will have a problem to find resources to do this work (both in terms of people and time). Regards, Lukas [1] http://monaco.sfbay.sun.com/detail.jsf?cr=6913134 Lukas Rovensky wrote: > Darren J Moffat wrote: >> Lukas Rovensky wrote: >>> I believe that all the new Mozilla LDAP 6 libraries should be marked >>> as "private" to Samba in this PSARC. Until there is a funding to >>> integrate and support them they cannot be "public". >> >> That is generally not the acceptable stance. In this particular case >> given the history of the Mozilla LDAP libraries in Solaris going back >> many more years I think this is even more unacceptable. >> >> The risk of having multiple versions of the LDAP libraries dragged >> into the same process (Samba in this case) is quite high. >> >> I strongly encourage the project team to find away so that the Mozilla >> LDAP 6 library is made common (ie a public taxonomy) for all to use - >> that doesn't mean supporting it themselves but working with the >> appropriate groups to do so. If the project can't do that then I feel >> I have to derail this case given the history of LDAP libraries in >> Solaris and the fact it has already been stated by RPE (Revenue >> Product Engineering) that they would rather see the Mozilla LDAP 6 >> library replace the current (hacked up) Mozilla LDAP 5. >> >> Remember that derail does not mean your case is rejected just that it >> needs a vote and ARC opinion. It may not even need a full review in >> this case since the issue isn't with the core architecture of Samba >> but an issue with a dependency. >> > Darren, > > I understand your concerns but your request is really out of scope of > Samba I-team responsibilities. Regardless, we actually tried several > times to get the Mozilla LDAP 6 C SDK integrated to Solaris as common > component but there was always someone who had objections to this. > > Anyway, I will try yet again to explore what are our options in this > space and get back to this forum in early January. However, I guess > that we will have to ask for the vote and ARC opinion to proceed with > this case as you explained. > > Just a note -- having up to data Samba in S10 is really about making > money and keeping our customers on Solaris. Old version of Samba in S10 > means more expensive support for us, lack of new features for customers > and represents a danger that some customers will walk away from Solaris. > > Lukas > From Darren.Moffat@sun.com Mon Jan 11 01:47:29 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0B9lTiA022464 for ; Mon, 11 Jan 2010 01:47:29 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0B9lSM5012589 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 11 Jan 2010 03:47:28 -0600 (CST) 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 <0KW200C07TV4TH00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 11 Jan 2010 02:47:28 -0700 (MST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KW2007RNTV1UX20@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 11 Jan 2010 02:47:26 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0B9lOk5012106 for ; Mon, 11 Jan 2010 09:47:25 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KW200K00SI0QN00@fe-emea-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 11 Jan 2010 09:47:15 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KW200FD3TUJ7VB0@fe-emea-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 11 Jan 2010 09:47:07 +0000 (GMT) Date: Mon, 11 Jan 2010 09:47:07 +0000 From: Darren J Moffat Subject: Re: Update Samba to release 3.4 [PSARC/2009/682 FastTrack timeout 12/24/2009] In-reply-to: <4B4A2E9B.5000205@sun.com> Sender: Darren.Moffat@sun.com To: Lukas Rovensky Cc: psarc-ext@sun.com, Peter Harvey , Dan Hain , Jiri Sasek , Michen Chang , Raja Gopal Andra Message-id: <4B4AF39B.7000404@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912172258.nBHMwuE4013587@sac.sfbay.sun.com> <4B2B85DC.9040609@Sun.COM> <4B2B86B6.6000905@sun.com> <4B2FEF1A.5030500@Sun.COM> <4B3068DF.4000907@sun.com> <4B4A2E9B.5000205@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091124) Status: RO Content-Length: 2615 Lukas Rovensky wrote: > Hi all, > > as promised, I explored the options we have concerning Samba 3.4 x > Mozilla LDAP 6 C SDK. As you can see below there is currently no ideal > solution and a compromise will be needed. From the business point of > view we really would like to be able to put Samba 3.4 to S10U9 -- we are > already getting requests for interoperability with Windows 7, [1] and > again the answer is Samba 3.4. > > Here is a list of options, which were discussed off-channel -- any > feedback is welcome: > > 1) Leave the PSARC case as it is and ask PSARC members for the vote and > opinion as mentioned by Darren. This is currently the preferred option > by the I-team. > > 2) Use OpenLDAP, which is already integrated in Nevada and use Mozilla > LDAP 6 C SDK as Samba's private component in S10. This will have a > clear disadvantage of having different Samba's in S10 and Nevada. Any > LDAP related issue will have to be solved separately for Nevada and S10 > and the maintenance cost will increase. > > 3) Mark the Mozilla LDAP 6 C SDK a "public" component in Nevada. Jiri > can still help with the integration but we will need a commitment from > the Naming folks that they will support this component (at least on > level C). The LDAP 6 C SDK still shall be Samba's private component in > S10. However, based on the discussion with Naming engineers this would > basically mean an LDAP C SDK update in Nevada, a separate PSARC case > will be required and such solution will certainly take longer than the > time frame we have for S10U9. Besides, we still may have a problem with > getting resources from the Naming team to assist with this task. > > 4) Use OpenLDAP instead of Mozilla LDAP 6 C SDK. This will work in > Nevada but will represent a problem for S10. As per the experiments > performed by Jiri -- integration of OpenLDAP to S10 (as private Samba's > component) is not trivial and this will also mean to integrate much > bigger beast than just the LDAP C SDK. OpenLDAP is being changed rather > often, so this will also bring an additional burden for the I-team to > maintain it as part of Samba in S10. We will have a problem to find > resources to do this work (both in terms of people and time). The ARC can't answer this for you, this is a business decision based on resources and the risks of S10 and Nevada source trees diverging in this area. The above information is great background but the project team should pick one as their proposal (I think you are saying option 1) and ask the ARC's opinion. -- Darren J Moffat From peter.harvey@sun.com Mon Jan 11 02:20:28 2010 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 o0BAKSuI023112 for ; Mon, 11 Jan 2010 02:20:28 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o0BAKSMM045367 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 11 Jan 2010 03:20:28 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KW200G19VE4E800@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 11 Jan 2010 03:20:28 -0700 (MST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KW20075HVE2UX50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 11 Jan 2010 03:20:27 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0BAKPlW017767 for ; Mon, 11 Jan 2010 10:20:26 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KW200A00V7BG400@fe-emea-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 11 Jan 2010 10:20:16 +0000 (GMT) Received: from [129.156.173.94] ([unknown] [129.156.173.94]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KW200FJAVDO7VD0@fe-emea-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 11 Jan 2010 10:20:12 +0000 (GMT) Date: Mon, 11 Jan 2010 10:20:12 +0000 From: Peter Harvey Subject: Re: Update Samba to release 3.4 [PSARC/2009/682 FastTrack timeout 12/24/2009] In-reply-to: <4B4A2E9B.5000205@sun.com> Sender: peter.harvey@sun.com To: Lukas Rovensky Cc: Darren J Moffat , PSARC-ext@sun.com, Dan Hain , Jiri Sasek , Michen Chang , Raja Gopal Andra Message-id: <4B4AFB5C.2070705@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912172258.nBHMwuE4013587@sac.sfbay.sun.com> <4B2B85DC.9040609@Sun.COM> <4B2B86B6.6000905@sun.com> <4B2FEF1A.5030500@Sun.COM> <4B3068DF.4000907@sun.com> <4B4A2E9B.5000205@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091027) Status: RO Content-Length: 2249 Just to reiterate the Naming sustaining view: We would favour in no particular order: - NV: OpenLDAP, S10: private Mozilla LDAP (option 2) - NV: true /usr/lib/libldap.so.6, S10: private Mozilla LDAP) > Here is a list of options, which were discussed off-channel -- any > feedback is welcome: > > 1) Leave the PSARC case as it is and ask PSARC members for the vote and > opinion as mentioned by Darren. This is currently the preferred option > by the I-team. > > 2) Use OpenLDAP, which is already integrated in Nevada and use Mozilla > LDAP 6 C SDK as Samba's private component in S10. This will have a > clear disadvantage of having different Samba's in S10 and Nevada. Any > LDAP related issue will have to be solved separately for Nevada and S10 > and the maintenance cost will increase. > > 3) Mark the Mozilla LDAP 6 C SDK a "public" component in Nevada. Jiri > can still help with the integration but we will need a commitment from > the Naming folks that they will support this component (at least on > level C). The LDAP 6 C SDK still shall be Samba's private component in > S10. However, based on the discussion with Naming engineers this would > basically mean an LDAP C SDK update in Nevada, a separate PSARC case > will be required and such solution will certainly take longer than the > time frame we have for S10U9. Besides, we still may have a problem with > getting resources from the Naming team to assist with this task. We'd be better off having a true libldap.so.6 in Nevada than have both libldap.so.5 as we have now and a public/supported Mozilla LDAP 6 in parallel. > 4) Use OpenLDAP instead of Mozilla LDAP 6 C SDK. This will work in > Nevada but will represent a problem for S10. As per the experiments > performed by Jiri -- integration of OpenLDAP to S10 (as private Samba's > component) is not trivial and this will also mean to integrate much > bigger beast than just the LDAP C SDK. OpenLDAP is being changed rather > often, so this will also bring an additional burden for the I-team to > maintain it as part of Samba in S10. We will have a problem to find > resources to do this work (both in terms of people and time). Option 4 looks to be the least favourable. -- Peter From Lukas.Rovensky@sun.com Mon Jan 11 04:07:46 2010 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 o0BC7kRa024460 for ; Mon, 11 Jan 2010 04:07:46 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o0BC7kux052822 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 11 Jan 2010 05:07:46 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KW3004070CYIT00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 11 Jan 2010 05:07:46 -0700 (MST) 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 <0KW3007Z10CXUV90@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 11 Jan 2010 05:07:45 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0BC7iTF020525 for ; Mon, 11 Jan 2010 12:07:44 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KW200G00ZEP8M00@fe-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 11 Jan 2010 12:07:30 +0000 (GMT) Received: from [129.157.18.67] ([unknown] [129.157.18.67]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KW300G9T0C99QF0@fe-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 11 Jan 2010 12:07:21 +0000 (GMT) Date: Mon, 11 Jan 2010 13:06:26 +0100 From: Lukas Rovensky Subject: Re: Update Samba to release 3.4 [PSARC/2009/682 FastTrack timeout 12/24/2009] In-reply-to: <4B4AF39B.7000404@Sun.COM> Sender: Lukas.Rovensky@sun.com To: Darren J Moffat Cc: psarc-ext@sun.com, Peter Harvey , Dan Hain , Jiri Sasek , Michen Chang , Raja Gopal Andra Message-id: <4B4B1442.7060201@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912172258.nBHMwuE4013587@sac.sfbay.sun.com> <4B2B85DC.9040609@Sun.COM> <4B2B86B6.6000905@sun.com> <4B2FEF1A.5030500@Sun.COM> <4B3068DF.4000907@sun.com> <4B4A2E9B.5000205@sun.com> <4B4AF39B.7000404@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 2868 Darren J Moffat wrote: > Lukas Rovensky wrote: >> Hi all, >> >> as promised, I explored the options we have concerning Samba 3.4 x >> Mozilla LDAP 6 C SDK. As you can see below there is currently no >> ideal solution and a compromise will be needed. From the business >> point of view we really would like to be able to put Samba 3.4 to >> S10U9 -- we are already getting requests for interoperability with >> Windows 7, [1] and again the answer is Samba 3.4. >> >> Here is a list of options, which were discussed off-channel -- any >> feedback is welcome: >> >> 1) Leave the PSARC case as it is and ask PSARC members for the vote >> and opinion as mentioned by Darren. This is currently the preferred >> option by the I-team. >> >> 2) Use OpenLDAP, which is already integrated in Nevada and use Mozilla >> LDAP 6 C SDK as Samba's private component in S10. This will have a >> clear disadvantage of having different Samba's in S10 and Nevada. Any >> LDAP related issue will have to be solved separately for Nevada and >> S10 and the maintenance cost will increase. >> >> 3) Mark the Mozilla LDAP 6 C SDK a "public" component in Nevada. Jiri >> can still help with the integration but we will need a commitment from >> the Naming folks that they will support this component (at least on >> level C). The LDAP 6 C SDK still shall be Samba's private component >> in S10. However, based on the discussion with Naming engineers this >> would basically mean an LDAP C SDK update in Nevada, a separate PSARC >> case will be required and such solution will certainly take longer >> than the time frame we have for S10U9. Besides, we still may have a >> problem with getting resources from the Naming team to assist with >> this task. >> >> 4) Use OpenLDAP instead of Mozilla LDAP 6 C SDK. This will work in >> Nevada but will represent a problem for S10. As per the experiments >> performed by Jiri -- integration of OpenLDAP to S10 (as private >> Samba's component) is not trivial and this will also mean to integrate >> much bigger beast than just the LDAP C SDK. OpenLDAP is being changed >> rather often, so this will also bring an additional burden for the >> I-team to maintain it as part of Samba in S10. We will have a problem >> to find resources to do this work (both in terms of people and time). > > The ARC can't answer this for you, this is a business decision based on > resources and the risks of S10 and Nevada source trees diverging in this > area. The above information is great background but the project team > should pick one as their proposal (I think you are saying option 1) and > ask the ARC's opinion. > Hi Darren, thanks for the clarification. As for the Samba 3.4 project team I can confirm that we would like to pick option 1) now in order to be able to get Samba 3.4 to S10U9. Thanks, Lukas From Darren.Moffat@sun.com Thu Jan 28 10:32:36 2010 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 o0SIWZiu014772 for ; Thu, 28 Jan 2010 10:32:35 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o0SIVl1f060602 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 28 Jan 2010 11:32:35 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWY00L09ZI18N00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 28 Jan 2010 10:32:25 -0800 (PST) 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 <0KWY00H4UZI0KS20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 28 Jan 2010 10:32:25 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0SIWO9p019845 for ; Thu, 28 Jan 2010 18:32:24 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KWY00B00ZAUTJ00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 28 Jan 2010 18:31:59 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KWY004NZZH5HV80@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 28 Jan 2010 18:31:53 +0000 (GMT) Date: Thu, 28 Jan 2010 18:31:53 +0000 From: Darren J Moffat Subject: Re: Update Samba to release 3.4 [PSARC/2009/682 FastTrack timeout 12/24/2009] Sender: Darren.Moffat@sun.com To: PSARC-ext@sun.com, Jiri.Sasek@sun.com, Lukas.Rovensky@sun.com Message-id: <4B61D819.10606@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100103 Lightning/1.0b1 Thunderbird/3.0 Status: RO Content-Length: 863 Having discussed this offline with some people the following is my suggestion to move this forward. Samba can integrate with a private copy of the Mozilla 6 LDAP for Solaris 10 U9 onwards. Until such time as there as an active project team and a stated direction (hopefully an ARC inception review) for updating the the current libldap.so in OpenSolaris Samba can carry a private copy of the Mozilla 6 LDAP there as well. This is on the assumption that the Samba project team will work with any future LDAP project team for OpenSolaris to ensure that the needs of Samba are considered in changing the system libldap. While this is less than ideal given the desire to quickly get an updated Samba into Solaris 10 U9, where there is no in kernel CIFS server, I think this is the best that this project team can be expected to do. -- Darren J Moffat From Lukas.Rovensky@Sun.COM Fri Jan 29 03:56:08 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0TBu81E017486 for ; Fri, 29 Jan 2010 03:56:08 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0TBu6iu021498 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 29 Jan 2010 05:56:08 -0600 (CST) 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 <0KX000013BTJJ600@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Jan 2010 03:56:07 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KX000NANBTI1C00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Jan 2010 03:56:06 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0TBu4xv026688 for ; Fri, 29 Jan 2010 11:56:05 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KX000900AQZMQ00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Jan 2010 11:56:05 +0000 (GMT) Received: from MyspulinPro.local ([unknown] [129.150.125.91]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KX000ENFBT48F90@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Jan 2010 11:55:53 +0000 (GMT) Date: Fri, 29 Jan 2010 12:56:32 +0100 From: Lukas Rovensky Subject: Re: Update Samba to release 3.4 [PSARC/2009/682 FastTrack timeout 12/24/2009] In-reply-to: <4B61D819.10606@Sun.COM> Sender: Lukas.Rovensky@Sun.COM To: Darren J Moffat Cc: PSARC-ext@Sun.COM, Jiri.Sasek@Sun.COM Message-id: <4B62CCF0.2060201@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B61D819.10606@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Status: RO Content-Length: 1170 Hi Darren, thanks for your message -- this is good news for Samba in S10. When there is an active project team for updating current libldap.co then Samba team will certainly cooperate and once possible switch to the public Mozilla LDAP 6 C SDK. Regards, Lukas Darren J Moffat wrote: > Having discussed this offline with some people the following is my > suggestion to move this forward. > > Samba can integrate with a private copy of the Mozilla 6 LDAP for > Solaris 10 U9 onwards. > > Until such time as there as an active project team and a stated > direction (hopefully an ARC inception review) for updating the the > current libldap.so in OpenSolaris Samba can carry a private copy of the > Mozilla 6 LDAP there as well. This is on the assumption that the Samba > project team will work with any future LDAP project team for OpenSolaris > to ensure that the needs of Samba are considered in changing the system > libldap. > > While this is less than ideal given the desire to quickly get an updated > Samba into Solaris 10 U9, where there is no in kernel CIFS server, I > think this is the best that this project team can be expected to do. > From Daniel.Hain@Sun.COM Fri Jan 29 08:49:14 2010 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 o0TGnE1j021357 for ; Fri, 29 Jan 2010 08:49:14 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o0TGnDuS016585 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 29 Jan 2010 09:49:13 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KX000E09PE18U00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Jan 2010 08:49:13 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KX000AX2PE1PC40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Jan 2010 08:49:13 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0TGnDSX008091 for ; Fri, 29 Jan 2010 08:49:13 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KX000E00OJ2BD00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Jan 2010 08:49:13 -0800 (PST) Received: from [192.168.1.5] ([unknown] [72.197.209.207]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KX000EJZPDZRH60@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Jan 2010 08:49:12 -0800 (PST) Date: Fri, 29 Jan 2010 08:49:11 -0800 From: Daniel Hain Subject: Re: Update Samba to release 3.4 [PSARC/2009/682 FastTrack timeout 12/24/2009] In-reply-to: <4B61D819.10606@Sun.COM> Sender: Daniel.Hain@Sun.COM To: PSARC-ext@Sun.COM Cc: Jiri.Sasek@Sun.COM, Lukas.Rovensky@Sun.COM Message-id: <4B631187.4090702@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B61D819.10606@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100103 Thunderbird/3.0 Status: RO Content-Length: 1275 Could we get a +1 to allow the project team to move ahead or do we need to wait for the next meeting for the litany (or other objections)? The project team is eager to move forward integrating this into Nevada before the window of opportunity for S10U9 soak/backport closes. Thanks, Dan On 01/28/10 10:31 AM, Darren J Moffat wrote: > Having discussed this offline with some people the following is my > suggestion to move this forward. > > Samba can integrate with a private copy of the Mozilla 6 LDAP for > Solaris 10 U9 onwards. > > Until such time as there as an active project team and a stated > direction (hopefully an ARC inception review) for updating the the > current libldap.so in OpenSolaris Samba can carry a private copy of > the Mozilla 6 LDAP there as well. This is on the assumption that the > Samba project team will work with any future LDAP project team for > OpenSolaris to ensure that the needs of Samba are considered in > changing the system libldap. > > While this is less than ideal given the desire to quickly get an > updated Samba into Solaris 10 U9, where there is no in kernel CIFS > server, I think this is the best that this project team can be > expected to do. > -- Dan Hain Systems Revenue Product Engineering (RPE) From Darren.Moffat@sun.com Fri Jan 29 08:59:21 2010 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 o0TGxLFq021817 for ; Fri, 29 Jan 2010 08:59:21 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0TGxKIJ024634 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 29 Jan 2010 08:59:20 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KX000E0XPUWRU00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Jan 2010 08:59:20 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KX000AJGPUUP250@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Jan 2010 08:59:19 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0TGxIRG001991 for ; Fri, 29 Jan 2010 16:59:18 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KX000A00PBPTZ00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Jan 2010 16:58:55 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KX0000W6PU6YN40@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Jan 2010 16:58:55 +0000 (GMT) Date: Fri, 29 Jan 2010 16:58:51 +0000 From: Darren J Moffat Subject: Re: Update Samba to release 3.4 [PSARC/2009/682 FastTrack timeout 12/24/2009] In-reply-to: <4B631187.4090702@sun.com> Sender: Darren.Moffat@sun.com To: Daniel Hain Cc: PSARC-ext@sun.com, Jiri.Sasek@sun.com, Lukas.Rovensky@sun.com Message-id: <4B6313CB.305@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B61D819.10606@Sun.COM> <4B631187.4090702@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100103 Lightning/1.0b1 Thunderbird/3.0 Status: RO Content-Length: 1369 On 29/01/2010 16:49, Daniel Hain wrote: > Could we get a +1 to allow the project team to move ahead or do we need > to wait for the next meeting for the litany (or other objections)? What I sent was equivalent, I don't actually have to type '+1'. > The project team is eager to move forward integrating this into Nevada > before the window of opportunity for S10U9 soak/backport closes. > > Thanks, > > Dan > > On 01/28/10 10:31 AM, Darren J Moffat wrote: >> Having discussed this offline with some people the following is my >> suggestion to move this forward. >> >> Samba can integrate with a private copy of the Mozilla 6 LDAP for >> Solaris 10 U9 onwards. >> >> Until such time as there as an active project team and a stated >> direction (hopefully an ARC inception review) for updating the the >> current libldap.so in OpenSolaris Samba can carry a private copy of >> the Mozilla 6 LDAP there as well. This is on the assumption that the >> Samba project team will work with any future LDAP project team for >> OpenSolaris to ensure that the needs of Samba are considered in >> changing the system libldap. >> >> While this is less than ideal given the desire to quickly get an >> updated Samba into Solaris 10 U9, where there is no in kernel CIFS >> server, I think this is the best that this project team can be >> expected to do. >> > > -- Darren J Moffat From Lukas.Rovensky@sun.com Fri Jan 29 09:04:21 2010 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 o0TH4KY3021947 for ; Fri, 29 Jan 2010 09:04:20 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0TH4KGH028259 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 29 Jan 2010 09:04:20 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KX000E6JQ38Z700@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Jan 2010 09:04:20 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KX000AT8Q31PA50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Jan 2010 09:04:14 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0TH4CBT002389 for ; Fri, 29 Jan 2010 17:04:13 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KX000A00PBPTZ00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Jan 2010 17:04:02 +0000 (GMT) Received: from MyspulinPro.local ([unknown] [129.150.125.50]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KX0000QOQ2KMX20@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Jan 2010 17:03:57 +0000 (GMT) Date: Fri, 29 Jan 2010 18:04:36 +0100 From: Lukas Rovensky Subject: Re: Update Samba to release 3.4 [PSARC/2009/682 FastTrack timeout 12/24/2009] In-reply-to: <4B6313CB.305@Sun.COM> Sender: Lukas.Rovensky@sun.com To: Darren J Moffat Cc: Daniel Hain , PSARC-ext@sun.com, Jiri.Sasek@sun.com Message-id: <4B631524.9070303@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B61D819.10606@Sun.COM> <4B631187.4090702@sun.com> <4B6313CB.305@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Status: RO Content-Length: 1435 Darren J Moffat wrote: > On 29/01/2010 16:49, Daniel Hain wrote: >> Could we get a +1 to allow the project team to move ahead or do we need >> to wait for the next meeting for the litany (or other objections)? > > What I sent was equivalent, I don't actually have to type '+1'. > Thanks ... Lukas >> The project team is eager to move forward integrating this into Nevada >> before the window of opportunity for S10U9 soak/backport closes. >> >> Thanks, >> >> Dan >> >> On 01/28/10 10:31 AM, Darren J Moffat wrote: >>> Having discussed this offline with some people the following is my >>> suggestion to move this forward. >>> >>> Samba can integrate with a private copy of the Mozilla 6 LDAP for >>> Solaris 10 U9 onwards. >>> >>> Until such time as there as an active project team and a stated >>> direction (hopefully an ARC inception review) for updating the the >>> current libldap.so in OpenSolaris Samba can carry a private copy of >>> the Mozilla 6 LDAP there as well. This is on the assumption that the >>> Samba project team will work with any future LDAP project team for >>> OpenSolaris to ensure that the needs of Samba are considered in >>> changing the system libldap. >>> >>> While this is less than ideal given the desire to quickly get an >>> updated Samba into Solaris 10 U9, where there is no in kernel CIFS >>> server, I think this is the best that this project team can be >>> expected to do. >>> >> >> > >