From sacadmin Wed Oct 25 14:06:55 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9PL6shV020311 for ; Wed, 25 Oct 2006 14:06:55 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9PL6WGX003861; Wed, 25 Oct 2006 22:06:37 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7P00I1DMNCW600@brm-avmta-1.central.sun.com>; Wed, 25 Oct 2006 15:06:48 -0600 (MDT) Received: from sac.sfbay.sun.com ([129.146.175.66]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7P00A3VMNB36B0@brm-avmta-1.central.sun.com>; Wed, 25 Oct 2006 15:06:48 -0600 (MDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9PL6lMO020308; Wed, 25 Oct 2006 14:06:47 -0700 (PDT) Received: (from ss146556@localhost) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6/Submit) id k9PL6lGZ020307; Wed, 25 Oct 2006 14:06:47 -0700 (PDT) Date: Wed, 25 Oct 2006 14:06:47 -0700 (PDT) From: PSARC-coord@sun.com Subject: New PSARC Materials Submitted 2005/695 CIFS Client on Solaris To: PSARC@sun.com Cc: p.kumar@sun.com, PSARC-coord@sun.com Message-id: <200610252106.k9PL6lGZ020307@sac.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 700 New Materials submitted for PSARC 2005/695 CIFS Client on Solaris Status: inception scheduled 11/01/2006 Files: /shared/sac/PSARC/2005/695/inception.materials/20questions.txt /shared/sac/PSARC/2005/695/inception.materials/CIFS_Client_des_diag.jpg /shared/sac/PSARC/2005/695/inception.materials/cifs_client_prd.html /shared/sac/PSARC/2005/695/inception.materials/CIFS_Design_Doc.html /shared/sac/PSARC/2005/695/inception.materials/cifs_high_level.gif /shared/sac/PSARC/2005/695/inception.materials/mount_smbfs_final /shared/sac/PSARC/2005/695/inception.materials/sec_questions.html /shared/sac/PSARC/2005/695/inception.materials/smbutil_man_final Please let me know if you have questions. - PSARC From sacadmin Wed Nov 1 11:47:54 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kA1JlrOE022063 for ; Wed, 1 Nov 2006 11:47:54 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id kA1Jlia3013668 for <@sunmail3.sfbay.sun.com:PSARC@sun.com>; Thu, 2 Nov 2006 03:47:52 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J820090DHNS4O00@nwk-avmta-2.sfbay.sun.com> for PSARC@sun.com (ORCPT PSARC@sun.com); Wed, 01 Nov 2006 11:47:52 -0800 (PST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J82006QHHNQR010@nwk-avmta-2.sfbay.sun.com> for PSARC@sun.com (ORCPT PSARC@sun.com); Wed, 01 Nov 2006 11:47:51 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kA1JloIM021059; Wed, 01 Nov 2006 11:47:50 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id kA1JoxFg015109; Wed, 01 Nov 2006 11:50:59 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id kA1JowAY015108; Wed, 01 Nov 2006 11:50:58 -0800 (PST) Date: Wed, 01 Nov 2006 11:50:58 -0800 (PST) From: Gary Winiger Subject: Re: Inception review 2005/695 CIFS Client on Solaris To: PSARC@sun.com Cc: p.kumar@sun.com Message-id: <200611011950.kA1JowAY015108@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 699 I've updated the issues file with the issues from the whiteboard. Don and Kais, please check that I correctly captured them. I've dropped my mp3 of the review in the case directory. It's a bit faint is some places. Rob's volumn never did improve after I asked. Not desiging for the team, and in the review, I made a comment about admins possibly storing passwords in a property of the smf service. That should be tempered with the fact that properties are visible to all. It might be more appropriate to give a path name to a file that is read only to the system instead. Some way of administering that file (not $EDITOR) would be needed and perhaps some stability of that file. Cheers, Gary.. From sacadmin Wed Nov 1 12:14:03 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kA1KE31V023380 for ; Wed, 1 Nov 2006 12:14:03 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id kA1KE2707254; Wed, 1 Nov 2006 13:14:02 -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 <0J8200A0VIVCXQ00@nwk-avmta-2.sfbay.sun.com>; Wed, 01 Nov 2006 12:14:00 -0800 (PST) Received: from spartan.SFBay.Sun.COM ([129.146.226.64]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J82006FAIVCR030@nwk-avmta-2.sfbay.sun.com>; Wed, 01 Nov 2006 12:14:00 -0800 (PST) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6) with SMTP id kA1KE05c006284; Wed, 01 Nov 2006 12:14:00 -0800 (PST) Date: Wed, 01 Nov 2006 12:14:00 -0800 (PST) From: Don Cragun Subject: Re: Inception review 2005/695 CIFS Client on Solaris To: PSARC@Sun.COM Cc: p.kumar@Sun.COM Reply-to: Don Cragun Message-id: <200611012014.kA1KE05c006284@spartan.SFBay.Sun.COM> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: 4azi9Et8OrjJzca0cA2czg== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 598 >Date: Wed, 01 Nov 2006 11:50:58 -0800 (PST) >From: Gary Winiger > >I've updated the issues file with the issues from the whiteboard. >Don and Kais, please check that I correctly captured them. >I've dropped my mp3 of the review in the case directory. It's a bit >faint is some places. Rob's volumn never did improve after I asked. Gary, Thanks for putting my issue in the issues file during the meeting. I updated the issues file to fix a typo. (You had translated my scribbling to be "operations" when I meant "operands".) Thanks, Don ... ... ... >Cheers, >Gary.. From sacadmin Tue Nov 7 08:11:47 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kA7GBk2Q028127 for ; Tue, 7 Nov 2006 08:11:47 -0800 (PST) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id kA7GBhL4023297; Tue, 7 Nov 2006 16:11:44 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J8D00D0FBNJO400@nwk-avmta-1.sfbay.Sun.COM>; Tue, 07 Nov 2006 08:11:43 -0800 (PST) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J8D0088IBNIF040@nwk-avmta-1.sfbay.Sun.COM>; Tue, 07 Nov 2006 08:11:42 -0800 (PST) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kA7GBgIV004593; Tue, 07 Nov 2006 08:11:42 -0800 (PST) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J8D00D01BL2TH00@d1-sfbay-10.sun.com> (original mail from Sherri.Shieh@Sun.COM); Tue, 07 Nov 2006 08:11:42 -0800 (PST) Received: from [129.150.29.103] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J8D00CGRBNHOHOD@d1-sfbay-10.sun.com>; Tue, 07 Nov 2006 08:11:42 -0800 (PST) Date: Tue, 07 Nov 2006 08:11:46 -0800 From: Sherri Shieh Subject: PSARC Meeting Minutes 11/01/2006 Inception: 2005/695 Sender: Sherri.Shieh@sun.com To: psarc@sun.com, M Pavan Reddy , Robert Thurlow Reply-to: Sherri.Shieh@sun.com Message-id: <4550B042.8070809@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_xuQNpFLSObRAbCHGlMr9fQ)" X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Status: RO Content-Length: 15647 This is a multi-part message in MIME format. --Boundary_(ID_xuQNpFLSObRAbCHGlMr9fQ) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT All, Meeting minutes for 11/01/2006 are now available and are attached. Audio files are available as well: (1) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20061101.arcbiz.mp3 (2) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20061101.2005.695.inception.mp3 Sum up available at: http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20061101.html If you have any corrections/feedback, please direct them to me. Thanks, Sherri -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sherri Shieh Program Manager, Systems Architecture Sun Microsystems, Inc. Phone: 650-786-5245/x85245 Email: Sherri.Shieh@sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --Boundary_(ID_xuQNpFLSObRAbCHGlMr9fQ) Content-type: text/plain; name=20061101.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=20061101.txt SYSTEM ARCHITECTURE COUNCIL Platform Software ARC --------------------------------- PSARC Regular Meeting time: Wednesdays 10:00-1:00pm in MPK17-3507. 11/01/2006 MEETING MINUTES ============================================================== CORRECTIONS, additions, deletions to sherri.shieh@sun.com. Minutes are archived in sac.Eng:/sac/export/sac/Minutes/PSARC. ATTENDEES - Members: Joseph Kowalski: no (on sabbatical) Glenn Skinner: yes Robert Berube no James Carlson: yes Bill Sommerfeld: no Gary Winiger: yes Michael Haines no Tim Marsland: no (on sabbatical) Ed Gould: yes Kais Belgaied: yes Sherri Shieh: yes ATTENDEES - Interns: Don Cragun: yes Peter Dennis: no (on sabbatical) Wyllys Ingersoll: no Rick Matthews: no Alec Muffett: no (on sabbatical) James Falkner: no (on sabbatical) Phil Harman: no Calum Mackay yes Michael Speer no Ienup Sung no Cecilia Hu: no Brian Utterback yes Michael Haines no Sebastien Roy yes Alan Hargreaves no Darren Reed yes Guests: Pavan Kumar Robert Thurlow Thomas Mark Sweeny Alan Coopersmith --------------------------------------------------------------------------- AGENDA ------- 11/01/2006 (glenn ARC business only) 10:00-10:10 ARC Business 10:10-10:55 Inception: CIFS Client on Solaris (2005/695) Submitter: P. Kumar Owner: Gary Winiger Intern: Darren Reed --------------------------------------------------------------------------- ARC Business ============ Fast tracks ----------- 2006/568 direct boot (dboot) for x86 John Danielson waiting fast-track 11/03/2006 Jerry Gilliam * let it run 2006/598 Swap resource control; locked memory RM Stephen Lawrence waiting fast-track 11/01/2006 Daniel Price * push the timer out a week 2006/601 Battery Project David Chieu waiting fast-track 11/01/2006 Cecilia Hu * Bill is waiting to see some spec updates * push timer out to next week 2006/603 SMF-ize nfslogd Doug McCallum waiting fast-track 11/01/2006 Calum Mackay * push timer out another week 2006/608 Zones Upgrade (Zulu) Amendments Ethan Quach waiting fast-track 11/06/2006 James Carlson * Approved 2006/609 Xserver provider for DTrace Alan Coopersmith waiting fast-track 11/06/2006 Alan Coopersmith * Approved 2006/610 Data Encryption Kit (SUNWcry) Removal Darren Moffat waiting fast-track 11/07/2006 Darren Moffat * Approved 2006/555 Move OpenSSL to /usr Jan Pechanec waiting fast-track 10/02/2006 Darren Moffat * EdG will follow up with the submitter on this case (either has converged or really close to) 2006/561 libcmd must die Joseph Kowalski waiting fast-track 09/05/2006 Joseph Kowalski 2006/573 Human-readable number library routine Eric Lowe waiting fast-track 10/17/2006 Eric Lowe * change IAM file to waiting need spec Other Business -------------- * 2005/575 - fix directory....this happens every time someone builds a subdirectory (Sherri will try and fix this and talk to John) Issues to Escalate ------------------ NONE ============================================================================ Inception: CIFS Client on Solaris (2005/695) Submitter: P. Kumar Owner: Gary Winiger Intern: Darren Reed SUMMARY ======= * Complete the design and spec of SMF integration and how the admin is set and gets global properties * More work on password handling (unattended mounts, etc.) * Table needed for what the default dialect is for this client and what normal servers are expecting in this field * Must be using the Crypto Framework ISSUES ======= gw-1 Will Sun KDC tickets work with CIFS? * A fifth server or a fifth client may need to know this info. * To project team: please make this clear inthe documentation for commitment. * This will be tested. There is magic sauce required by the client in order for it to interoperate with Active Directory. The interoperability capabilities of CIFS need to be made clear when the case is presented for commitment. gw-2 Check with Greenline on service to just contain properties. value authorizations. * There is an SMF policy that deals with this - please check. gw-3 20Q #8 Log via syslog. Should FMA be used? * Should make this clear in the documentation. * The team is required to expand on how and why syslog will be used, vs FMA, prior to commitment review. gw-4 20Q #10, there's CLIP and then there's CLIP. What's important is to align with like commands. * This will be updated. gw-5 Passwords. Syntax user:password how is this all done? In particular is it possible to set a password for a specified user, or can the user only set her own password? Goes to PAM service module. What protection is there on setting another user's password? * The password is disabled by default and the authentication level is SMF property. * Need spec: will need a man page for this * Project team has yet to document the thin clients or the service yet. The SMF is still under design right now. * Plaintext passwords, on the wire, are disabled by default, however, it will be possible to enable this mode of behaviour through changing an SMF property. It was pointed out that the man page must spell this out, especially the implications on interactions with other implementations of CIFS. gw-6 mount_smbfs: Nit ensure the defaults are all documented. case= seems to be missing the default. gw-7 smbutil: does logout require a password? gw-8 Spec: DES, MD4, HMAC-MD5 uses Crypto Framework? Use of Solaris network byte order routines. * There is no MD4 - should be using the Crypto Framework (potential TCR) * The project is required to use the cryptographic framework for all algorithems supported by Solaris today. The project will be providing its own implementation of MD-4 for its use as this algorithm is not currently supported by the Solaris cryptographic framework. gw-9 How will users get sys_mount? * This should be clearer (not very different from NSF). gw-99 Spec updates to align 20Q and Spec. Interface table completion. 5.3.5 Ethereal vs snoop. seb-1 20q 4: PSARC 2005/562 introduces multicast DNS based service discovery. Are SMB shares a good fit to discover using that facility? For example, could the smbutil command use multicast DNS (using the APIs introduced by 2005/562) to discover local servers? * This doesn't allow you to find out who is on your subdirectory - you will have to bring this in. seb-2 20q 12: How does this relate to the existing Gnome functionality that allows the user to browse SMB shares and load SMB files. This works today in Nevada. What is the existing code that does this, and will ripping that out in favour of this project be a problem wrt keeping the Gnome Nautilus code in sync with the community? * Right now, there isn't an answer regarding Nautilus. It should be possible to drop new code on the API for this but right now, the project team isn't sure yet. * The CIFS team has an outstanding task to meet with the Nautilus people and discuss how the CIFS project will interact with Nautilus. Feedback from this is required prior to commitment. wes-0 form of materials: specs should be self-contained; please avoid links outside the submitted materials, especially to alternate copies of files included in the submission. * This will get fixed. wes-1 client_prd: "ability to use CIFS resources other than files & directories" ? * Microsoft specific private stuff wes-2 "browsing inside CIFS shares via nautilus" why wouldn't this just work? doesn't nautilus just use normal POSIX file I/O, and this project provides a VFS for that? * Already discussed with seb-2 wes-3 Why no "packet signing" ? * Integrity protection of traffic * In response to the question of why there is no packet signing, the team pointed out that the specifications related to this were too new. Being able to support "packet signing" is considered to be "highly desirable". wes-4 design 2.2.4: this is really talking about behavioral differences of *system calls* not commands. * Nit wes-5 design 2.2.4: choice of ENOSYS for failures seems odd to me. seems like with respect to mknod it would be better to always flag the mounted filesystem as a "nodevices" mount. what does mknod return on a filesystem mounted -o nodevices ? wes-6 design 2.2.4: I thought M$ had valiently reinvented symlinks recently.. * There are shortcuts that feel like symlinks but are a little different that what is current. * Project team will look into this before commitment. * With respect to symbolic links, more details on how the various versions of Windows do and do not support these is required, including if or how the behaviour of "shortcuts" will be mapped onto Unix. wes-7 design 2.2.4: for link(2): EMLINK ("The maximum number of links to a file would be exceeded") or EXDEV ("can't create a link between here and there") would seem more likely to trigger appropriate application recovery behavior.. wes-8 3.4: IMHO we should not be supporting/delivering multiple copies of MS/DCE RPC; please coordinate with Pebble Beach to avoid doing this work multiple times. wes-9 6.1.2: plaintext passwords section is unclear. will this project, by default, send cleartext passwords for "share-level security" ? * Please clarify this. * The team has agreed to provide further clarification between user and share level security and how the authentication process for both of these modes of operation differs. wes-10 6.1.3: Will "LM Challenge" be enabled by default? seems like both LM and NTLM permit dictionary precomputation unless the client adds a per-exchange nonce to the hash.. * Make this very clear in the documentation about the security issues of this. * The authentication mechanisms used by the CIFS protocols lend themselves to dictionary based attacks on the authentication. The security ramifications of this must be clearly documented so that users/administrators are aware of the potential consequenes when using and administering CIFS. wes-11 6.1.6: "the integrity of the TCP connection is assumed to be sufficient". oh really?? wes-12 7.5.2: "mblks don't have previous and next pointers" huh? looking at a traditional BSD, *mbufs* don't have previous pointers, while mblk's do: mbuf m_next is mblk b_cont mbuf m_nextpkt is mblk b_next mblk has b_prev with no mbuf equivalent. wes-13 7.8.4: zones. the fact that nfs mounts have to be per-zone has been troublesome for install/upgrade; there should be a way to do a (read only) SMB mount from the global zone and have other zones share the read-only mount. we currently have to do obscene hacks to permit this with NFS for install. wes-14 CIFS_Client_des_diag.jpg: is the kernel/user boundary reversed from normal here? (kernel on top, userspace below?) wes-15 The inclusion of passwords in a URL passed to mount(1m) via argv or the enviroment goes against the SAC Best Practice on Reusable Passwords In Command Line Arguments and Environment Variables http://sac.eng/cgi-bin/bp.cgi?NAME=passwords-cli.bp There MUST be an alternative secure way of providing the password. (for instance, instead of including the password in vfstab directly as part of the URL, it should be readable from a mode 0600 file containing just the passwords). If this (mis)feature isn't removed, the man pages must strongly caution against using this. * It will certainly prompt if a password is needed. * If there is no password supplied, the user will be prompted for the password. The team mentioned that it would be easy to add a further option to the behaviour here in order to retrieve the password from a file. On Whiteboard ------------- dwc-1 smbutil: Why // in front of some operands? * In the MS environment will be using back slashes for this but then it is converted to forward slashes in a different environment. Why 2 operands instead of 1 for login and logout commands? * The 2 operands might be a typo ( 2 modes of operations). The intent is that the client should try to connect and not prompt the user for another password. * There should be no space between the // for login and logout * Server names always have a // * The manner in which "examples" is used within the documentation presented for inception is somewhat 'messy' and leads to the wrong conclusions about what directories and files are present. The team has agreed to clean this up prior to commitment review. dwc-1 Is it really ./examples for details or is it just /examples (in the files section)? * The intent is not to create a directory every time for examples. The path name that is something unedited on a Darwin machine. There is possibly a "~" missing and this will be cleaned up. * There will be a man page for this. kb-1 Interface table "evolving" should be [un]committed * Project team didn't have time to get the design doc reviewed in time - project team will update the document. * The team agreed to update the interface table to match the new terminology in use. kb-2 Interactive password Need a hands off password for service that needs to start without prompting for user input * This shouldn't always be mandated that the user should be entering in a password. NEXT STEP ========== * Project team will go back and resolve all issues from today's review before coming back for commitment. --Boundary_(ID_xuQNpFLSObRAbCHGlMr9fQ)-- From sacadmin Wed May 16 13:02:15 2007 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 l4GK2Fkt011573 for ; Wed, 16 May 2007 13:02:15 -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 l4GK17fS010432; Wed, 16 May 2007 13:01:07 -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 <0JI50030HGXV6S00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 16 May 2007 13:01:07 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JI500KMXGXUL540@nwk-avmta-1.sfbay.Sun.COM>; Wed, 16 May 2007 13:01:06 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4GK16qt022350; Wed, 16 May 2007 13:01:06 -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 l4GK2EDV011570; Wed, 16 May 2007 13:02:14 -0700 (PDT) Received: (from ss146556@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l4GK2ECg011569; Wed, 16 May 2007 13:02:14 -0700 (PDT) Date: Wed, 16 May 2007 13:02:14 -0700 (PDT) From: PSARC-coord@sun.com Subject: New PSARC Materials Submitted 2005/695 CIFS Client on Solaris To: PSARC@sun.com Cc: p.kumar@sun.com, PSARC-coord@sun.com Message-id: <200705162002.l4GK2ECg011569@sac.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1028 New Materials submitted for PSARC 2005/695 CIFS Client on Solaris Status: commitment scheduled 05/23/2007 Files: /shared/sac/PSARC/2005/695/commitment.materials/20questions.txt /shared/sac/PSARC/2005/695/commitment.materials/changes_since_inception.txt /shared/sac/PSARC/2005/695/commitment.materials/CIFS_Client_diagram.jpg /shared/sac/PSARC/2005/695/commitment.materials/cifs_client_prd.html /shared/sac/PSARC/2005/695/commitment.materials/CIFS_Design_Doc.html /shared/sac/PSARC/2005/695/commitment.materials/mount_smbfs.1m.pdf /shared/sac/PSARC/2005/695/commitment.materials/mount_smbfs.1m.txt /shared/sac/PSARC/2005/695/commitment.materials/nsmbrc.4.pdf /shared/sac/PSARC/2005/695/commitment.materials/nsmbrc.4.txt /shared/sac/PSARC/2005/695/commitment.materials/sec_questions.html /shared/sac/PSARC/2005/695/commitment.materials/sharectl.1m.txt /shared/sac/PSARC/2005/695/commitment.materials/smbutil.1.pdf /shared/sac/PSARC/2005/695/commitment.materials/smbutil.1.txt Please let me know if you have questions. - PSARC From psarc-member-list-request@sun.com Wed May 23 14:09:23 2007 Date: Wed, 23 May 2007 14:08:46 -0700 (PDT) From: Gary Winiger Subject: 2005/695 CIFS Client and TX To: psarc-ext@sun.com Cc: cifsclient-team@sun.com, p.kumar@sun.com, Robert.Thurlow@sun.com Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-PMX-Version: 5.2.0.264296 X-Lines: 25 Status: RO Content-Type: TEXT/PLAIN; charset="us-ascii" Content-Length: 791 In talking with some of the Solaris Trusted Extensions (TX) folk today, they asked about how the CIFS client would work on TX. I had presumed there were no real issues. The client mounts would just take place in labeled zones the same as NFS mounts. The TX folk pointed out that would be true for mounts at the same label, however TX supports configuring a labeled zone for read down NFS mounts. The issue then is should CIFS client in a labeled zone operate in a similar fashion? I have the impression from the TX folk that any additional work would be straight forward and desirable to do. Architecturally I believe that CIFS client should operate the same the other file systems (including NFS client) on TX. The TX project team can be contacted at rampart-dev-team@sun.com Gary.. From robert.thurlow@sun.com Wed May 23 18:05:22 2007 Date: Wed, 23 May 2007 19:03:15 -0600 From: Robert Thurlow User-Agent: Thunderbird 2.0b2 (X11/20070227) To: Gary Winiger CC: psarc-ext@sun.com, cifsclient-team@sun.com, p.kumar@sun.com Subject: Re: 2005/695 CIFS Client and TX Content-Transfer-Encoding: 7bit X-Lines: 18 Status: RO Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Length: 941 Gary Winiger wrote: > In talking with some of the Solaris Trusted Extensions (TX) folk today, > they asked about how the CIFS client would work on TX. I had presumed > there were no real issues. The client mounts would just take place > in labeled zones the same as NFS mounts. The TX folk pointed out > that would be true for mounts at the same label, however TX supports > configuring a labeled zone for read down NFS mounts. The issue then > is should CIFS client in a labeled zone operate in a similar fashion? > I have the impression from the TX folk that any additional work would > be straight forward and desirable to do. Architecturally I believe > that CIFS client should operate the same the other file systems (including > NFS client) on TX. The TX project team can be contacted at > rampart-dev-team@sun.com Thanks, Gary - we'd planned to mimic the NFS changes and invite them to review, so I think we're in sync. Rob T From gww@eng.sun.com Wed May 23 18:12:12 2007 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 l4O1CBvE019204 for ; Wed, 23 May 2007 18:12:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l4O1AuEh019400; Thu, 24 May 2007 02:10:58 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JII00I01TY9X100@brm-avmta-1.central.sun.com>; Wed, 23 May 2007 19:10:57 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JII00419TY8AW80@brm-avmta-1.central.sun.com>; Wed, 23 May 2007 19:10:57 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4O1Aukw004387; Wed, 23 May 2007 18:10:56 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l4O1D0bT018131; Wed, 23 May 2007 18:13:00 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l4O1Cxx5018130; Wed, 23 May 2007 18:12:59 -0700 (PDT) Date: Wed, 23 May 2007 18:12:59 -0700 (PDT) From: Gary Winiger Subject: 2005/695 CIFS Client Commit Minutes To: gww@eng.sun.com, psarc-ext@sun.com Cc: Robert.Thurlow@sun.com, cifsclient-team@sun.com, p.kumar@sun.com Message-id: <200705240112.l4O1Cxx5018130@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2545 Here are my notes from today's commitment review of 2005/695 CIFS Client. Please let me know if I've missed or misstated anything. Presuming that the project team follows through with closing the umount issue (as they seem ready to do), I've added a call for a vote to next weeks business. I believe the TX issue I raised after the meeting can be met with a TCR -- CIFS Client support when TX is enabled should mirror that of NFS client support. If this cannot be accomplished, submit a fast track to amend this case. presuming the project team agrees ;=) Thanks, Gary.. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There was a straw vote to approve. The outstanding issue that prevented a vote was the architecture that would allow a regular user to umount CIFS shares to align with regular users being allowed to mount CIFS shares. Since the meeting, the project team has made a tentative proposal that looks like it will close this issue. It seems that umount functions similarly to mount and does have file system specific handlers. TCR: o Document the search order relative to NetBIOS and nsswitch.conf. o Add password support to nsmbrc(4) in a user friendly way. o Provide support for Kerberos credentials when Kerberos is the login mechanism. If this cannot be accomplished, submit a fast track to amend this case. o Provide for appropriate value and action authorizations for the smb/client service. Ensure that the authorizations are delivered in a Rights Profile and documented in the sharectl(1M) man page or on a separate smb/client man page if appropriate. o Enable the service in the generic profile(s) as appropriate. Case dependency: An additional case dependency is on a yet to be submitted case for a PAM service module to support automatic password setting. Contract dependency: Use of libkrb5 (PSARC/2006/027) is contracted external. Opinion fodder and PAC advice: While this case is approved for a Patch release binding, it presents what appears to be a large project with many dependences on other projects. The impact of any backport to previous releases should be carefully considered, fully staffed and not taken lightly. As seen in other recent cases Solaris patch quality and stability suffers when doing large feature backports. Opinion fodder and project team advice: Should a backport be undertaken, it is likely that a contract will be needed for package removal of the smf/client service (use of /var/svc/profile/upgrade). From robert.thurlow@sun.com Thu May 24 08:35:55 2007 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 l4OFZs8L002657 for ; Thu, 24 May 2007 08:35:55 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l4OFYXji001980; Thu, 24 May 2007 16:34:37 +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 <0JIJ00F01XXPDA00@nwk-avmta-2.sfbay.sun.com>; Thu, 24 May 2007 08:34:37 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIJ00BUPXXOK4E0@nwk-avmta-2.sfbay.sun.com>; Thu, 24 May 2007 08:34:36 -0700 (PDT) Received: from [192.9.61.79] (punchin-client-192-9-61-79.SFBay.Sun.COM [192.9.61.79]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l4OFYZek258631; Thu, 24 May 2007 08:34:36 -0700 (PDT) Date: Thu, 24 May 2007 09:34:34 -0600 From: Robert Thurlow Subject: Unmount design closure on CIFS Client (PSARC 2005/695) To: psarc-ext@sun.com, Gary Winiger Cc: CIFS client team Message-id: <4655B08A.5020904@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1332 We have a proposal to address the mount vs. unmount gap that was identified at the CIFS Client inception review. The proposal makes use of the fact that the umount(1M) looks for fs-specific binaries in the same manner as mount, permitting a similar design. We will deliver a /usr/lib/fs/smbfs/umount binary that will use the same method to grant unmount privileges, and add permissions checking as appropriate. The materials changes are as follows: mount_smbfs(1M) man page: Add information about umount_smbfs(!M) and language that unmounting will also be permitted by regular users with the same restrictions Design Doc, 4.1 Exported interfaces: Add umount_smbfs to the row with mount_smbfs Design Doc, 6.2.1 Challenges of Multi-user mounts Add text highlighted between slashes: "Users will be able to do smbfs mounts /and unmounts/ on directories they own." Design Doc, 6.3 RBAC and privileges Add a new paragraph at the end: "Following along with permitting regular users to mount on directories they own, they will also be permitted to umount shares they've mounted. A separate umount_smbfs will be delivered which will be granted the sys_mount privilege in the "Basic Solaris User" Rights Profile." The smbfs version of VFS_UNMOUNT() will confirm the ownership of the covered vnode before permitting the unmount. Rob T From gww@eng.sun.com Thu May 24 09:09:36 2007 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 l4OG9ZfO003811 for ; Thu, 24 May 2007 09:09:36 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l4OG8Be4017661; Fri, 25 May 2007 00:08:20 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JIJ00G0FZHTUV00@nwk-avmta-2.sfbay.sun.com>; Thu, 24 May 2007 09:08:17 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIJ00FUPZHSJV20@nwk-avmta-2.sfbay.sun.com>; Thu, 24 May 2007 09:08:16 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4OG8Gia012816; Thu, 24 May 2007 09:08:16 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l4OGALqv018648; Thu, 24 May 2007 09:10:21 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l4OGALNG018647; Thu, 24 May 2007 09:10:21 -0700 (PDT) Date: Thu, 24 May 2007 09:10:21 -0700 (PDT) From: Gary Winiger Subject: Re: Unmount design closure on CIFS Client (PSARC 2005/695) To: psarc-ext@sun.com, gww@eng.sun.com, robert.thurlow@sun.com Cc: cifsclient-team@sun.com Message-id: <200705241610.l4OGALNG018647@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1642 > We have a proposal to address the mount vs. unmount gap that was Please review this proposal. I'm requesting a vote during ARC business 30 May. Members who may not be in attendance, please feel free to vote by email to me. TCRs and other opinion summary are contained in a previous mail. Thanks, Gary.. > identified at the CIFS Client inception review. The proposal > makes use of the fact that the umount(1M) looks for fs-specific > binaries in the same manner as mount, permitting a similar design. > We will deliver a /usr/lib/fs/smbfs/umount binary that will use > the same method to grant unmount privileges, and add permissions > checking as appropriate. The materials changes are as follows: > > mount_smbfs(1M) man page: > Add information about umount_smbfs(!M) and language that unmounting > will also be permitted by regular users with the same restrictions > > Design Doc, 4.1 Exported interfaces: > Add umount_smbfs to the row with mount_smbfs > > Design Doc, 6.2.1 Challenges of Multi-user mounts > Add text highlighted between slashes: > "Users will be able to do smbfs mounts /and unmounts/ on directories > they own." > > Design Doc, 6.3 RBAC and privileges > Add a new paragraph at the end: > "Following along with permitting regular users to mount on directories > they own, they will also be permitted to umount shares they've mounted. > A separate umount_smbfs will be delivered which will be granted the > sys_mount privilege in the "Basic Solaris User" Rights Profile." The > smbfs version of VFS_UNMOUNT() will confirm the ownership of the covered > vnode before permitting the unmount. > > Rob T > From Darren.Reed@sun.com Thu May 24 19:53:56 2007 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 l4P2rtN8020471 for ; Thu, 24 May 2007 19:53:55 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l4P2qaVL019876; Fri, 25 May 2007 03:52:39 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JIK00H3ZTBOW200@brm-avmta-1.central.sun.com>; Thu, 24 May 2007 20:52:36 -0600 (MDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIK003LCTBKPJH0@brm-avmta-1.central.sun.com>; Thu, 24 May 2007 20:52:34 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4P2qVfm002788; Fri, 25 May 2007 02:52:32 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIK00I01T0KCB00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM); Fri, 25 May 2007 10:52:31 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIK002QPTBH8Y88@mail-apac.sun.com>; Fri, 25 May 2007 10:52:31 +0800 (SGT) Date: Thu, 24 May 2007 19:52:29 -0700 From: Darren.Reed@sun.com Subject: Re: 2005/695 CIFS Client Commit Minutes In-reply-to: <200705240112.l4O1Cxx5018130@marduk.eng.sun.com> Sender: Darren.Reed@sun.com To: Robert.Thurlow@sun.com, cifsclient-team@sun.com Cc: Gary Winiger , psarc-ext@sun.com, P.Kumar@sun.com Message-id: <46564F6D.1030502@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200705240112.l4O1Cxx5018130@marduk.eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 2514 Notes from me included below. Darren * The use of NetBIOS to resolve hostnames will be restricted to CIFS and will not be avialable for other utilities in Solaris. In the big picture, use of NetBIOS is slowly being deprecated by Microsoft. The only other forseeable use of NetBIOS for hostname resolution is likely to be for interaction with printers made available via CIFS. The planned control of enabling NetBIOS follows the same model as is used by Microsoft in how they deliver SMB over TCP/IP. * This case depends on a collection of other PSARC cases, which could impact the delivery of this project in the context of a patch. The project team needs to be aware of the full dependency list as they draw up plans to backport to Solaris 10. * Through nsmbrc(4), we will be providing support for user specific options to be used with smbutil. On Darwin, this includes provision for a hashed password. Discussion was held on the merits of storing a hashed vs plaintext password in the file and how the such a password should find its way into the file. It was generally considered to be a worthwhile feature, especially given its presence elsewhere and that it is upto the project team to provide a suitable mechanism. * A final question was asked of how the project intended to allow users to unmount its shares. At the time of this discussion, the project team did not have an answer and assumed that the same mechanism that is used for removing CDs/floppies would work without realising that this was very specific to that problem. The ARC concluded that without this final piece of design the project was incomplete and ineligable for a binding vote of approval for commitment. In summary, there were 5 TCRs: TCR: provide a convenience mechanism with which it is possible to store an appropriate password in the nsmbrc file. TCR: ensure that Kerberos interoperability is delivered via pam. TCR: a new fast-track will be drafted for which this case will be dependant on (Gary offered to write the fast-track.) TCR: The project is required to provide action authisations in proper accordance with the SMF policy. TCR: the project team was asked to come up with a design for unmounting filesystems that allowed for an otherwise unprivileged user to unmount the filesystem. In wrapping up the meeting, a straw vote was held between the members present with 4 approvals, no abstinations or disapprovals. From gww@eng.sun.com Wed May 30 14:53:12 2007 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 l4ULrBgE016823 for ; Wed, 30 May 2007 14:53:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l4ULplHj011572; Wed, 30 May 2007 22:51:50 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JIV00D01JEDDQ00@brm-avmta-1.central.sun.com>; Wed, 30 May 2007 15:51:49 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIV002UFJEDXA80@brm-avmta-1.central.sun.com>; Wed, 30 May 2007 15:51:49 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4ULpmwa017292; Wed, 30 May 2007 14:51:48 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l4ULs31M025535; Wed, 30 May 2007 14:54:03 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l4ULs3p1025534; Wed, 30 May 2007 14:54:03 -0700 (PDT) Date: Wed, 30 May 2007 14:54:03 -0700 (PDT) From: Gary Winiger Subject: Re: 2005/695 CIFS Client Commit Minutes To: gww@eng.sun.com, psarc-ext@sun.com Cc: Robert.Thurlow@sun.com, cifsclient-team@sun.com, p.kumar@sun.com Message-id: <200705302154.l4ULs3p1025534@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 729 > I believe the TX issue I raised after the meeting can be met with a > TCR -- CIFS Client support when TX is enabled should mirror that of NFS > client support. If this cannot be accomplished, submit a fast > track to amend this case. > presuming the project team agrees ;=) At today's PSARC this case was approved, Glenn, Kais, Gary, Jim approve, no NP, no abstain, no deny with the above TCR. > TCR: > o Enable the service in the generic profile(s) as appropriate. And I commented that if CIFS client service is a property repository and does not really do anything (i.e., start and stop methods are :true), that the smf folk say the service doesn't need to be enabled just to set or get the properties. Gary.. From sacadmin Fri Jun 1 11:31:37 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l51IVb8P015651 for ; Fri, 1 Jun 2007 11:31:37 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l51IUGgp000462 for ; Fri, 1 Jun 2007 11:30:16 -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 l51IUBVR009189 for ; Fri, 1 Jun 2007 11:30:11 -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 <0JIY00001ZC07G00@fe-sfbay-10.sun.com> (original mail from Sherri.Shieh@Sun.COM) for PSARC-members@sac.sfbay.sun.com; Fri, 01 Jun 2007 11:30:11 -0700 (PDT) Received: from [129.150.20.231] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JIY00HJXZEAFOB0@fe-sfbay-10.sun.com>; Fri, 01 Jun 2007 11:30:11 -0700 (PDT) Date: Fri, 01 Jun 2007 11:30:40 -0700 From: Sherri Shieh Subject: Automated draft opinion ready: 2005/695 Sender: Sherri.Shieh@Sun.COM To: Gary Winiger Cc: Darren Reed , PSARC-members@sac.sfbay.sun.com Reply-to: Sherri.Shieh@Sun.COM Message-id: <466065D0.8050805@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Status: RO Content-Length: 907 All, The draft opinion has been generated and is in the case directory: http://sac.eng/arc/PSARC/2005/695/draftopinion.txt http://sac.eng/arc/PSARC/2005/695/draftopinion.ms Let me know if I need to change anything in it. Thanks, Sherri -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sherri Shieh Program Manager, Systems Architecture Sun Microsystems, Inc. Phone: 650-786-5245/x85245 Email: Sherri.Shieh@sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From Darren.Reed@sun.com Thu Jun 7 18:58:02 2007 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 l581w0eZ003243 for ; Thu, 7 Jun 2007 18:58:01 -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 l581uS8t018936; Fri, 8 Jun 2007 09:56:33 +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 <0JJA00E01O277Q00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Jun 2007 18:56:31 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJA005PMO26WED0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Jun 2007 18:56:31 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l581uTQI009723; Fri, 08 Jun 2007 01:56:29 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JJA00601NYKY600@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM); Fri, 08 Jun 2007 09:56:29 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJA00DRAO23949A@mail-apac.sun.com>; Fri, 08 Jun 2007 09:56:29 +0800 (SGT) Date: Thu, 07 Jun 2007 18:56:27 -0700 From: Darren.Reed@sun.com Subject: Re: Unmount design closure on CIFS Client (PSARC 2005/695) In-reply-to: <4655B08A.5020904@sun.com> Sender: Darren.Reed@sun.com To: Robert Thurlow Cc: psarc-ext@sun.com, Gary Winiger , CIFS client team Message-id: <4668B74B.5030007@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <4655B08A.5020904@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 752 Robert Thurlow wrote: > We have a proposal to address the mount vs. unmount gap that was > identified at the CIFS Client inception review. The proposal > makes use of the fact that the umount(1M) looks for fs-specific > binaries in the same manner as mount, permitting a similar design. > We will deliver a /usr/lib/fs/smbfs/umount binary that will use > the same method to grant unmount privileges, and add permissions > checking as appropriate. The materials changes are as follows: > > mount_smbfs(1M) man page: > Add information about umount_smbfs(!M) and language that unmounting > will also be permitted by regular users with the same restrictions Just to tie up a loose end, will umount_smbfs be a "Committed" exported interface? Darren From robert.thurlow@sun.com Wed Jun 13 12:56:52 2007 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 l5DJup3j021525 for ; Wed, 13 Jun 2007 12:56:52 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5DJtEGS015897; Wed, 13 Jun 2007 20:55:16 +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 <0JJL00C49BC32J00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 13 Jun 2007 12:55:15 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJL008LABC1JM20@nwk-avmta-1.sfbay.Sun.COM>; Wed, 13 Jun 2007 12:55:13 -0700 (PDT) Received: from [10.7.250.28] (punchin-client-10-7-250-28.SFBay.Sun.COM [10.7.250.28]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5DJtCVV269209; Wed, 13 Jun 2007 12:55:13 -0700 (PDT) Date: Wed, 13 Jun 2007 13:55:11 -0600 From: Robert Thurlow Subject: Re: Unmount design closure on CIFS Client (PSARC 2005/695) In-reply-to: <4668B74B.5030007@Sun.COM> To: Darren.Reed@sun.com Cc: psarc-ext@sun.com, Gary Winiger , CIFS client team Message-id: <46704B9F.6040303@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4655B08A.5020904@sun.com> <4668B74B.5030007@Sun.COM> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 234 Darren.Reed@Sun.COM wrote: > Just to tie up a loose end, will umount_smbfs be a "Committed" exported > interface? Definitely - I've made that change in the current design doc & 20q, which I haven't sent to you and Gary yet. Rob T From Darren.Reed@Sun.COM Tue Jun 26 17:49:15 2007 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 l5R0nESv018967 for ; Tue, 26 Jun 2007 17:49:14 -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 l5R0lQPJ017921; Wed, 27 Jun 2007 08:47:29 +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 <0JK900C01RJ4SW00@brm-avmta-1.central.sun.com>; Tue, 26 Jun 2007 18:47:28 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JK9009LBRJ2NU20@brm-avmta-1.central.sun.com>; Tue, 26 Jun 2007 18:47:27 -0600 (MDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5R0lQsb009548; Wed, 27 Jun 2007 00:47:26 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JK900A01RDCEL00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM); Wed, 27 Jun 2007 08:47:26 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JK900FJFRIZWRHO@mail-apac.sun.com>; Wed, 27 Jun 2007 08:47:25 +0800 (SGT) Date: Tue, 26 Jun 2007 17:47:23 -0700 From: Darren.Reed@Sun.COM Subject: Draft opinion (PSARC 2005/695) In-reply-to: <46704B9F.6040303@sun.com> Sender: Darren.Reed@Sun.COM To: PSARC-ext@Sun.COM Cc: Robert Thurlow , Gary Winiger , CIFS client team Message-id: <4681B39B.1080606@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_PSkhtwa3aPGF2N1iKSW1Wg)" X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <4655B08A.5020904@sun.com> <4668B74B.5030007@Sun.COM> <46704B9F.6040303@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 9831 This is a multi-part message in MIME format. --Boundary_(ID_PSkhtwa3aPGF2N1iKSW1Wg) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Please find the draft opinion for this case attached. The .ms version can be found in the case directory for those wishing to render it to non-text. Darren --Boundary_(ID_PSkhtwa3aPGF2N1iKSW1Wg) Content-type: text/plain; name=draftopinion.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=draftopinion.txt sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: CIFS Client on Solaris Submitted by: Pavan Kumar Mettu File: PSARC/2005/695/opinion.ms Date: May 30, 2007 Committee: Kais Belgaied, James D Carlson, Glenn Skinner, Gary Winiger (opinion written by Darren Reed.) Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary CIFS Client for Solaris is a virtual file system on Solaris providing access to the servers which support the CIFS protocol(Windows, Samba on Unix/Linux). The CIFS protocol allows sharing of files, printers and other resources across a network. Using the CIFS client, users can mount remote CIFS server shares (directories) on their system. The CIFS client uses TCP naming and supports authentication, oplocks, caching, DFS, Extended Attributes, Unicode resource names and secu- rity signatures. Authorisation will be given to all users to mount and unmount CIFS filesystems. 2. Decision & Precedence Information The project is approved as specified in reference [5], but as modified by the required technical changes listed in Appendix A below. The project may be delivered in a patch release of the ON consolidation. The project depends on the following other project and may not be delivered before it. PSARC/2007/303 pam_smb_login PSARC/2005/695 Copyright 2007 Sun Microsystems - 2 - 3. Interfaces The project exports the following interfaces. _________________________________________________________________________________ | Interfaces Exported | |_____________________|_______________________|_________________________________| |Interface | Classification | Comments | |_____________________|_______________________|_________________________________| |smbutil | Committed | | |mount_smbfs | Committed | | |umount_smbfs | Committed | | |libsmbfs.so | Project Private | Will contract with Nautilus | |smbfs module | Consolidation Private| | |nsmb module | Project Private | | |SMF service | Committed | svc:/network/smb/client:default| |SUNWsmbfsr SUNWsmbfsu| Committed | Package names | |_____________________|_______________________|_________________________________| The project imports the following interfaces. __________________________________________________________________ | Interfaces Imported | |______________|_______________________|_________________________| |Interface | Classification | Comments | |______________|_______________________|_________________________| |libkrb5 | Contracted | PSARC/2006/027 | |uconv routines| Consolidation Private| PSARC/2005/446 | |md4 routines | Consolidation Private| PSARC/2007/139 | |sockfs calls | Project Private | See design [5], 8.5.2.3| |______________|_______________________|_________________________| 4. Opinion 4.1. NetBIOS name resolution The CIFS client will make use of NetBIOS for name resolution if it is enabled and if nornmal hostname resolution has already failed to provide an answer for the name. This fol- lows the algorithm used by Microsoft. We need to pay atten- tion to their moves in this so that in the event that they abandon use of NetBIOS, Solaris is similarly adjusted. 4.2. Patch binding Although this case has sought and had approved a request for patch binding, the case presented is a large project, with the following 6 dependencies identified in during commitment review: PSARC/2004/047 Enabling user mounts in Solaris in S10 PSARC/2005/695 Copyright 2007 Sun Microsystems - 3 - PSARC/2005/446 Unicode encoding conversion functions at the kernel in SNV PSARC/2006/027 Open Kerberos APIs (contracted) in SNV PSARC/2006/715 CIFS Service (parts) PSARC/2007/139 Kernel Crypto support for MD4 in SNV PSARC/2005/374 Share management improvements (sharectl(1M)) in SNV In addition to this, contracts will be required for linking with the Kerberos APIs being used and SMF for removal of the SMF service on patch backout using /var/svc/profile/ugprade. 4.3. Kerberos and Single Sign On The ARC spent some time discussion the interaction of CIFS with Kerberos for single sign on. The project team com- mented that while it was within scope of their project, it was not considered to be a "must" for them to deliver. At the time of the meeting it was believed that the code worked, with the actual status unclear, which led to the ARC prescribing a TCR for the delivery of it to work. 4.4. Storing CIFS share passwords The use of the .nsmbrc file to hold user passwords for CIFS shares was discussed and points made about how this is han- dled elsewhere. At the very least, the file needs to be protected by making it read and write for the owner only. To store the password, a recoverable hash is used, obscuring the plaintext password. Whilst some mechanics such as the need to support a different password per share were also discussed, the end result must be something that is easy for the user to use and should not require direct editing of the file. 5. Minority Opinion(s) None. 6. Advisory Information 6.1. Backport If the project team pursues a backport of this project, the ARC advised the project team to proceed with caution due to the large number of case dependencies as outlined earlier. PSARC/2005/695 Copyright 2007 Sun Microsystems - 4 - 6.2. Case incomplete without unmount In closing, the issue of how the project intends to allow users to unmount filesystems was raised. At the time of the meeting, there was no proposal put forward on how to do this. Without this part of the architecture the case was considered to be incomplete. In lieu of a vote being able to be taken because of this, a straw poll was taken on whether or not it would be approved with all members present approving. The advice to the project was to find a solu- tion to this problem and present it to the ARC which would then hold a vote via email. This advice was taken up and a solution presented before the next PSARC meeting, allowing the project to be voted on and formally approved. 7. Appendices 7.1. Appendix A: Technical Changes Required 1. Document the search order relative to NetBIOS and nsswitch.conf. 2. Add password support to nsmbrc(4) in a user friendly way. 3. Provide support for Kerberos credentials when Ker- beros is the login mechanism. If this cannot be accomplished, submit a fast track to amend this case. 4. Provide for appropriate value and action authori- zations for the smb/client service. Ensure that the authorizations are delivered in a Rights Pro- file and documented in the sharectl(1M) man page or on a separate smb/client man page if appropri- ate. 5. CIFS Client support when TX is enabled should mir- ror that of NFS client support. If this cannot be accomplished, submit a fast track to amend this case. 7.2. Appendix B: Technical Changes Advised none 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2005/695. PSARC/2005/695 Copyright 2007 Sun Microsystems - 5 - 1 20 Questions file: commitment.materials/20questions.txt 2 nsmbrc(4) file: commitment.materials/nsmbrc.4.txt file: commitment.materials/nsmbrc.4.pdf 3 CIFS Client Diagram file: commitment.materials/CIFS_Client_diagram.jpg 4 Security Questionaire file: commitment.materials/sec_questions.html file: commitment.materials/sec_questions.txt 5 CIFS design document file: commitment.materials/CIFS_Design_Doc.html 6 Changes since inception file: commitment.materials/changes_since_inception.txt 7 sharectl(1m) file: commitment.materials/sharectl.1m.txt 8 Project requirements specification file: commitment.materials/cifs_client_prd.html 9 mount_smbfs(1m) file: commitment.materials/mount_smbfs.1m.txt file: commitment.materials/mount_smbfs.1m.pdf 10 smbutil(1) file: commitment.materials/smbutil.1.txt file: commitment.materials/smbutil.1.pdf PSARC/2005/695 Copyright 2007 Sun Microsystems --Boundary_(ID_PSkhtwa3aPGF2N1iKSW1Wg)-- From carlsonj@phorcys.east.sun.com Wed Jun 27 06:38:24 2007 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 l5RDcNYv000718 for ; Wed, 27 Jun 2007 06:38:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5RDaWWJ016238; Wed, 27 Jun 2007 14:36:36 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JKA00M0HR4XX800@brm-avmta-1.central.sun.com>; Wed, 27 Jun 2007 07:36:33 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKA00JC9R4V6950@brm-avmta-1.central.sun.com>; Wed, 27 Jun 2007 07:36:31 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5RDaU20004556; Wed, 27 Jun 2007 09:36:30 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l5RDaUHJ004553; Wed, 27 Jun 2007 09:36:30 -0400 (EDT) Date: Wed, 27 Jun 2007 09:36:30 -0400 From: James Carlson Subject: Re: Draft opinion (PSARC 2005/695) In-reply-to: <4681B39B.1080606@Sun.COM> To: Darren.Reed@sun.com Cc: PSARC-ext@sun.com, Robert Thurlow , CIFS client team , Gary Winiger Message-id: <18050.26590.692208.920147@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.2.0.264296 References: <4655B08A.5020904@sun.com> <4668B74B.5030007@Sun.COM> <46704B9F.6040303@sun.com> <4681B39B.1080606@Sun.COM> Status: RO Content-Length: 1210 [nit: usually, the project team isn't part of the opinion review, because we've already had the vote. Not a problem, though.] Darren.Reed@Sun.COM writes: > Committee: Kais Belgaied, James D Carlson, Glenn > Skinner, Gary Winiger (opinion written by > Darren Reed.) Case owner goes first, followed by your name in parenthesis (as you have it here), then the rest of the committee in alphabetic order. > 6.2. Case incomplete without unmount [...] > This advice was taken up and a solution presented before the > next PSARC meeting, allowing the project to be voted on and > formally approved. This doesn't look like advisory information, because we're not asking the project team or management or anyone to do anything. Instead, it looks like a note for section 4. > 7.1. Appendix A: Technical Changes Required This item from the minutes seems to be missing: o Enable the service in the generic profile(s) as appropriate. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Darren.Reed@sun.com Wed Jun 27 11:34:25 2007 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 l5RIYP9m009208 for ; Wed, 27 Jun 2007 11:34:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5RIWekB011099; Wed, 27 Jun 2007 11:32:42 -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 <0JKB00I094UHV200@brm-avmta-1.central.sun.com>; Wed, 27 Jun 2007 12:32:41 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKB00IH84UFAH00@brm-avmta-1.central.sun.com>; Wed, 27 Jun 2007 12:32:40 -0600 (MDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5RIWdLT003175; Wed, 27 Jun 2007 18:32:39 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKB00M014S30G00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM); Thu, 28 Jun 2007 02:32:39 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKB006OK4UCR7TO@mail-apac.sun.com>; Thu, 28 Jun 2007 02:32:38 +0800 (SGT) Date: Wed, 27 Jun 2007 11:32:35 -0700 From: Darren.Reed@sun.com Subject: Re: Draft opinion (PSARC 2005/695) In-reply-to: <18050.26590.692208.920147@gargle.gargle.HOWL> Sender: Darren.Reed@sun.com To: James Carlson Cc: PSARC-ext@sun.com, Robert Thurlow , CIFS client team , Gary Winiger Message-id: <4682AD43.4040301@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <4655B08A.5020904@sun.com> <4668B74B.5030007@Sun.COM> <46704B9F.6040303@sun.com> <4681B39B.1080606@Sun.COM> <18050.26590.692208.920147@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 802 James Carlson wrote: >[nit: usually, the project team isn't part of the opinion review, >because we've already had the vote. Not a problem, though.] > > Sure, I just wasn't sure if the protocol was to cc the team on the draft opinion. >>6.2. Case incomplete without unmount >> >> >[...] > > >>This advice was taken up and a solution presented before the >>next PSARC meeting, allowing the project to be voted on and >>formally approved. >> >> > >This doesn't look like advisory information, because we're not asking >the project team or management or anyone to do anything. Instead, it >looks like a note for section 4. > > I put this here because it more or less follows on from the paragraph directly before it and thus it seemed like the logical place for it to go. Darren From gww@eng.sun.com Wed Jun 27 19:00:30 2007 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 l5S20TuD022318 for ; Wed, 27 Jun 2007 19:00:30 -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 l5S1wVd7027036; Thu, 28 Jun 2007 09:58:45 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JKB00403PHVEU00@brm-avmta-1.central.sun.com>; Wed, 27 Jun 2007 19:58:43 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKB002YYPHUBC00@brm-avmta-1.central.sun.com>; Wed, 27 Jun 2007 19:58:43 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5S1weJp009915; Wed, 27 Jun 2007 18:58:40 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l5S21b72002316; Wed, 27 Jun 2007 19:01:37 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l5S21b6p002315; Wed, 27 Jun 2007 19:01:37 -0700 (PDT) Date: Wed, 27 Jun 2007 19:01:37 -0700 (PDT) From: Gary Winiger Subject: Re: Draft opinion (PSARC 2005/695) To: Darren.Reed@sun.com, james.d.carlson@sun.com Cc: PSARC-ext@sun.com, Robert.Thurlow@sun.com, cifsclient-team@sun.com, gww@eng.sun.com Message-id: <200706280201.l5S21b6p002315@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 535 > This item from the minutes seems to be missing: > > o Enable the service in the generic profile(s) as appropriate. That's because my research with the SMF team turned up that services don't need to be enabled to set and get their properties. So there's no reason to enable the sbm/client service. When I mentioned this do Darren in an earlier draft, I should have suggested that the opinion body discuss the TCR and why it wasn't a TCR in the ``final'' opinion. Darren please add this to the opinion body. Gary.. From gww@eng.sun.com Wed Jun 27 19:40:25 2007 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 l5S2ePIN023085 for ; Wed, 27 Jun 2007 19:40:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5S2c2IX004340 for <@newsunmail1brm.central.sun.com:psarc-ext@Sun.COM>; Wed, 27 Jun 2007 20:38:02 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JKB0070FRCFHI00@brm-avmta-1.central.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 27 Jun 2007 20:38:39 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKB002EMRCFBT20@brm-avmta-1.central.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 27 Jun 2007 20:38:39 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5S2cbBe012793; Wed, 27 Jun 2007 19:38:37 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l5S2fY8R002365; Wed, 27 Jun 2007 19:41:34 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l5S2fYjh002364; Wed, 27 Jun 2007 19:41:34 -0700 (PDT) Date: Wed, 27 Jun 2007 19:41:34 -0700 (PDT) From: Gary Winiger Subject: Re: Draft opinion (PSARC 2005/695) To: Darren.Reed@sun.com Cc: gww@eng.sun.com, psarc-ext@sun.com Message-id: <200706280241.l5S2fYjh002364@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 3562 > Committee: Kais Belgaied, James D Carlson, Glenn > Skinner, Gary Winiger (opinion written by > Darren Reed.) As Jim already mentioned, please follow the order as perscribed in the template. As Jim already mentioned, please follow the order as perscribed in the template. "\fBCommittee:\fP" 15 .\" .\" List here the names of the committee who participated in the decision. .\" List the majority first, in alphabetical order. Except, place the name .\" of the person writing the majority opinion first. List the minority .\" second, after a "." and the word "Minority:". Again, place the name .\" of the author of the minority opinion first, but then alphabetically. .\" E.g.: Joe Blow, Allan Able, Charlie Carlson. Minority: George Wrong, .\" Devils Advocate. List abstentions last. .\" .\" Interns should not be included in the committee list unless an intern .\" wrote the opinion. In that situation, list the intern in parentheses .\" after the case owner. .\" E.g.: August Case-Owner (opinion written by Aspiring Intern) .\" .\" Note that /committee contains a list of committee .\" members in a form suitable for inclusion here. The review minutes .\" are another source for this information. .\" .\" Delete those members not present or not participating. Please update .\" this opinion template when the membership changes. .\" > 2. Decision & Precedence Information > > The project is approved as specified in reference [5], but Is reference [5] the complete specification of the project? I would think [1-10] is more complete. > The project may be delivered in a patch release of the ON > consolidation. Please follow the template. ON is not a release vehicle: .\" The classification of the deliverable as a major, minor, micro .\" or patch as defined in Release Taxonomy document and for what .\" product [Solaris, a specific unbundled, ...]. .\" E.g.: .\" The project may be delivered in a minor release of Solaris. ** Appropriate release vehicle(s). ** The interface table seems to be missing nsmbrc(4) Committed Please add as I noted in the commitment notes. > |SUNWsmbfsr SUNWsmbfsu| Committed | Package names | Nit put these on separate lines. > 4.3. Kerberos and Single Sign On I believe included in the discussion relivant to signon and ease of use is the case depencency on pam_smb_login to act remove the need for smbutil login. I believe it also lead to the case dependency on pam_smb. > 6. Advisory Information > > 6.1. Backport > > If the project team pursues a backport of this project, the > ARC advised the project team to proceed with caution due to ^^^ We usually say Committee. > the large number of case dependencies as outlined earlier. I'd make this to the PAC and anyone suggesting a backport. Something like: As noted in the 4.2, this project depends on many tentacles spread throughout the present development release. Backports of projects with such dependences often introduce a higher level of instability and bugs than fully contained projects. The committee advises the PAC and any project teams to not undertake such a backport without thoroughly understanding the downside consequences. > 6.2. Case incomplete without unmount As Jim said, this is really opinion body material. Please move to section 4. Please give folk a couple more days to comment on the draft, incorporate changes and then start PSARC review. Thankx, Gary.. From Darren.Reed@sun.com Thu Jun 28 15:39:18 2007 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 l5SMdHor022843 for ; Thu, 28 Jun 2007 15:39:17 -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 l5SMbNYv020737 for <@newsunmail1brm.central.sun.com:psarc-ext@sun.com>; Fri, 29 Jun 2007 06:37:32 +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 <0JKD00M09AUGFK00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Thu, 28 Jun 2007 16:37:28 -0600 (MDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKD00F8RAUEOT80@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Thu, 28 Jun 2007 16:37:27 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5SMbQPf018277 for ; Thu, 28 Jun 2007 22:37:26 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKD00101AOZRF00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 29 Jun 2007 06:37:25 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKD0027HAU994NO@mail-apac.sun.com>; Fri, 29 Jun 2007 06:37:25 +0800 (SGT) Date: Thu, 28 Jun 2007 15:37:20 -0700 From: Darren.Reed@sun.com Subject: Re: Draft opinion (PSARC 2005/695) In-reply-to: <200706280241.l5S2fYjh002364@marduk.eng.sun.com> Sender: Darren.Reed@sun.com To: Gary Winiger Cc: psarc-ext@sun.com Message-id: <46843820.3020504@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200706280241.l5S2fYjh002364@marduk.eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 2331 Gary Winiger wrote: >... >"\fBCommittee:\fP" 15 >.\" >.\" List here the names of the committee who participated in the decision. >.\" List the majority first, in alphabetical order. Except, place the name >.\" of the person writing the majority opinion first. List the minority >.\" second, after a "." and the word "Minority:". Again, place the name >.\" of the author of the minority opinion first, but then alphabetically. >.\" E.g.: Joe Blow, Allan Able, Charlie Carlson. Minority: George Wrong, >.\" Devils Advocate. List abstentions last. >.\" >.\" Interns should not be included in the committee list unless an intern >.\" wrote the opinion. In that situation, list the intern in parentheses >.\" after the case owner. >.\" E.g.: August Case-Owner (opinion written by Aspiring Intern) >.\" >.\" Note that /committee contains a list of committee >.\" members in a form suitable for inclusion here. The review minutes >.\" are another source for this information. >.\" >.\" Delete those members not present or not participating. Please update >.\" this opinion template when the membership changes. >.\" > > It would make for a more clear understanding if there was mention in the template that the case owner should be placed first (with the intern's name in brackets) should the majority opinion be being written by an intern to a case owner. >>The project may be delivered in a patch release of the ON >>consolidation. >> >> > > Please follow the template. ON is not a release vehicle: > >.\" The classification of the deliverable as a major, minor, micro >.\" or patch as defined in Release Taxonomy document and for what >.\" product [Solaris, a specific unbundled, ...]. >.\" E.g.: >.\" The project may be delivered in a minor release of Solaris. >** Appropriate release vehicle(s). ** > > The default opinion template contains this text: .\" The classification of the deliverable as a major, minor, micro .\" or patch as defined in Release Taxonomy document and for what .\" consolidation [ON, JDS, a specific unbundled, ...]. .\" E.g.: .\" The project may be delivered in a minor release of the ON consolidation. ** Appropriate release vehicle(s). ** ...are you suggesting that the default template should be changed? Darren From John.Plocher@sun.com Thu Jun 28 17:23:57 2007 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 l5T0Nulr026453 for ; Thu, 28 Jun 2007 17:23:57 -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 l5T0LfBx014454 for <@newsunmail1brm.central.sun.com:psarc-ext@sun.com>; Fri, 29 Jun 2007 08:22:11 +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 <0JKD0060FFOVS500@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 28 Jun 2007 18:22:07 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKD00FJIFOUOTE0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 28 Jun 2007 18:22:07 -0600 (MDT) 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 l5T0M64J009666 for ; Thu, 28 Jun 2007 17:22:06 -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 <0JKD00701FK1TR00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 28 Jun 2007 17:22:06 -0700 (PDT) Received: from [129.146.58.86] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JKD00004FOO2X40@fe-sfbay-10.sun.com>; Thu, 28 Jun 2007 17:22:06 -0700 (PDT) Date: Thu, 28 Jun 2007 17:18:16 -0700 From: John Plocher Subject: Re: Draft opinion (PSARC 2005/695) In-reply-to: <46843820.3020504@Sun.COM> Sender: John.Plocher@sun.com To: Darren.Reed@sun.com Cc: Gary Winiger , psarc-ext@sun.com Reply-to: John.Plocher@sun.com Message-id: <46844FC8.9030904@sun.com> Organization: Systems Architecture Council - Tools and Process MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706280241.l5S2fYjh002364@marduk.eng.sun.com> <46843820.3020504@Sun.COM> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 1759 Darren.Reed@Sun.COM wrote: > Gary Winiger wrote: >> >> Please follow the template. ON is not a release vehicle: >> But it is, and the template is correct. The coincidence that ON is usually co-released with other consolidations as part of a product is just that - a coincidence. Gates, C-Teams and integrations don't apply to products like Solaris or Belenix or Nextenta - instead they are associated with consolidations; when we approve an ARC case, we are approving a change to a specific consolidation instrance. Note that there many ON consolidations in play at any given time: The next Minor release: ONnv The Patch trains for the current Minor release: ON-S10u1, ON-S10u2, ON-S10u3, ON-S10u4, ON-S10u5... The Patch trains for earlier Minor releases: ON-S9xxx, ON-S8xxx, ... In an opinion, when we say... > The project may be delivered in a minor release of the ON consolidation ... we are explicitly identifying which specific ON consolidations in the set of all active ON consolidations are acceptable for the project to integrate into. Not unintentionally, it also serves as the context for all those project interfaces marked as Consolidation*Private. Solaris (as in the DVD or vinyl binder of disks or SDLC download images...) has been effectively staging Major releases for the last decade or so - ever since things like try-n-buy, extra-value, SFW, JES/iPlanet/Orion, Oracle and the like have been included in the definition of the product. Don't confuse Solaris (the umbrella product family) with either the ON Consolidation or the core set of pseudo-stable consolidations that have historically been known as the WOS - neither of these collections are really relevant to the ARC's scope. -John From jek3@sun.com Thu Jun 28 20:29:42 2007 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 l5T3Tfh4028911 for ; Thu, 28 Jun 2007 20:29:42 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l5T3RlHs029476; Fri, 29 Jun 2007 11:27:54 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JKD00001OAGNL00@nwk-avmta-2.sfbay.sun.com>; Thu, 28 Jun 2007 20:27:52 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKD00BXAOAFBH70@nwk-avmta-2.sfbay.sun.com>; Thu, 28 Jun 2007 20:27:52 -0700 (PDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5T3RnUY259861; Thu, 28 Jun 2007 20:27:50 -0700 (PDT) Date: Thu, 28 Jun 2007 17:26:29 -1000 From: Joseph Kowalski Subject: Re: Draft opinion (PSARC 2005/695) In-reply-to: <46844FC8.9030904@sun.com> To: John.Plocher@sun.com Cc: Darren.Reed@sun.com, Gary Winiger , psarc-ext@sun.com Message-id: <46847BE5.6030906@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706280241.l5S2fYjh002364@marduk.eng.sun.com> <46843820.3020504@Sun.COM> <46844FC8.9030904@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 133 John Plocher wrote: > Gates, C-Teams and integrations don't apply to products like Solaris > or Belenix or Nextenta, ... Bill Gates? From John.Plocher@sun.com Thu Jun 28 21:32:47 2007 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 l5T4WlZM000218 for ; Thu, 28 Jun 2007 21:32:47 -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 l5T4V121017722 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Thu, 28 Jun 2007 21:31:02 -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 <0JKD00301R7PVQ00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 28 Jun 2007 21:31:01 -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 <0JKD00B2RR7OB8C0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 28 Jun 2007 21:31: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 l5T4V0X8017988 for ; Thu, 28 Jun 2007 21:31: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 <0JKD00901R7NSK00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 28 Jun 2007 21:31:00 -0700 (PDT) Received: from [129.150.12.229] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JKD00I7LR7NAB60@fe-sfbay-10.sun.com>; Thu, 28 Jun 2007 21:31:00 -0700 (PDT) Date: Thu, 28 Jun 2007 21:29:10 -0700 From: John Plocher Subject: Re: Draft opinion (PSARC 2005/695) In-reply-to: <46847BE5.6030906@sun.com> Sender: John.Plocher@sun.com To: Joseph Kowalski Cc: Darren.Reed@sun.com, Gary Winiger , psarc-ext@sun.com Message-id: <46848A96.9030402@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en, es X-PMX-Version: 5.2.0.264296 References: <200706280241.l5S2fYjh002364@marduk.eng.sun.com> <46843820.3020504@Sun.COM> <46844FC8.9030904@sun.com> <46847BE5.6030906@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051027 Status: RO Content-Length: 273 Joseph Kowalski wrote: > John Plocher wrote: > >> Gates, C-Teams and integrations don't apply to products like Solaris >> or Belenix or Nextenta, ... > > Bill Gates? :-) For those not laughing, I *meant* to imply gatekeepers & source tree integration gates. -John From carlsonj@phorcys.east.sun.com Fri Jun 29 05:51:20 2007 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 l5TCpJaw009756 for ; Fri, 29 Jun 2007 05:51:19 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5TCnNnm005498; Fri, 29 Jun 2007 13:49:29 +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 <0JKE00B09EAFWR00@nwk-avmta-2.sfbay.sun.com>; Fri, 29 Jun 2007 05:49:27 -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 <0JKE00CTXEAEEXD0@nwk-avmta-2.sfbay.sun.com>; Fri, 29 Jun 2007 05:49:27 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5TCnPfL013861; Fri, 29 Jun 2007 08:49:25 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l5TCnPSM013858; Fri, 29 Jun 2007 08:49:25 -0400 (EDT) Date: Fri, 29 Jun 2007 08:49:25 -0400 From: James Carlson Subject: Re: Draft opinion (PSARC 2005/695) In-reply-to: <46844FC8.9030904@sun.com> To: John.Plocher@sun.com Cc: Darren.Reed@sun.com, Gary Winiger , psarc-ext@sun.com Message-id: <18052.65493.396415.628182@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.2.0.264296 References: <200706280241.l5S2fYjh002364@marduk.eng.sun.com> <46843820.3020504@Sun.COM> <46844FC8.9030904@sun.com> Status: RO Content-Length: 2856 John Plocher writes: > But it is, and the template is correct. The coincidence that ON is > usually co-released with other consolidations as part of a product is > just that - a coincidence. The template may possibly be correct, but I think Gary and likely others were confused by this change. This section has always indicated the delivery vehicle, and the canonical example of such a vehicle was "a Minor release of Solaris." It seems this changed last September: D 1.21 06/09/14 16:14:35 plocher 23 22 00018/00007/00331 MRs: COMMENTS: updated comments re: advice, changed sec2 product to consolidation ... but it's possible that some of us may have missed the discussion on the implications of that change. > Solaris (as in the DVD or vinyl binder of disks or SDLC download > images...) has been effectively staging Major releases for the > last decade or so - ever since things like try-n-buy, extra-value, > SFW, JES/iPlanet/Orion, Oracle and the like have been included > in the definition of the product. In particular, I reject the idea that Solaris itself has had a Major release because of those things. EV and equivalent experimental bits are clearly labeled as such, and thus are Volatile or worse. It doesn't take or imply a Major release of the product to change them. So, if as you're asserting that only the consolidations may have releases, then exactly what do we tell customers and how do they know what they're getting when they download bits? Do we list each consolidation's release binding or number on a web site somewhere? How does the customer know which consolidations' products he's using? I think what you're saying is that not only are numbers like "Solaris 10" purely marketing (and thus PAC) constructs, but that we no longer guarantee anything other than the contents of ON based on the output of "uname -r." Given that /usr/bin isn't special in Solaris and that any consolidation can deliver there, some now (apparently) with radically different release levels, how does any customer determine what he's getting in the box? Does this new scheme apply only for [Open]Solaris, or is it for all products under review in the ARC? When we see a hardware product, should we assume different release bindings for the hardware itself and the firmware? Do customers ever update just ON on their systems? I suspect that excising or redefining the role of "Product" in our system will have effects that we haven't anticipated. For one, it seems to make this document unusable: http://www.opensolaris.org/os/community/arc/policies/release-taxonomy/ (And since when do we ship Oracle?!) -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gww@eng.sun.com Fri Jun 29 09:37:51 2007 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 l5TGboI5014588 for ; Fri, 29 Jun 2007 09:37:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l5TGZpau020152 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@Sun.COM>; Sat, 30 Jun 2007 00:36:03 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JKE00M07OS2FC00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 29 Jun 2007 09:36:02 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKE00GFKOS0NN60@nwk-avmta-2.sfbay.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 29 Jun 2007 09:36:00 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5TGZwdq020973; Fri, 29 Jun 2007 09:35:58 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l5TGcwbx004626; Fri, 29 Jun 2007 09:38:58 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l5TGcw2r004625; Fri, 29 Jun 2007 09:38:58 -0700 (PDT) Date: Fri, 29 Jun 2007 09:38:58 -0700 (PDT) From: Gary Winiger Subject: Re: Draft opinion (PSARC 2005/695) To: John.Plocher@Sun.COM, james.d.carlson@Sun.COM Cc: Darren.Reed@Sun.COM, gww@eng.sun.com, psarc-ext@Sun.COM Message-id: <200706291638.l5TGcw2r004625@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1120 My last comment on line -- taking off line w/John > John Plocher writes: > > But it is, and the template is correct. The coincidence that ON is > > usually co-released with other consolidations as part of a product is > > just that - a coincidence. > > The template may possibly be correct, but I think Gary and likely > others were confused by this change. This section has always > indicated the delivery vehicle, and the canonical example of such a > vehicle was "a Minor release of Solaris." It seems this changed last > September: > > D 1.21 06/09/14 16:14:35 plocher 23 22 00018/00007/00331 > MRs: > COMMENTS: > updated comments re: advice, changed sec2 product to consolidation > > ... but it's possible that some of us may have missed the discussion > on the implications of that change. The words were introduced: D 1.4 95/02/15 17:14:38 glenn 4 3 00148/00045/00153 MRs: COMMENTS: lots of minor fixups. The biggest change is splitting out an Interfaces section from the Opinion section. There's also a lot more embedded commentary on how to fill out the template, style hints, etc. Gary.. From John.Plocher@sun.com Fri Jun 29 10:13:13 2007 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 l5THDD9s015320 for ; Fri, 29 Jun 2007 10:13:13 -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 l5THAitU017239 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 29 Jun 2007 11:10:46 -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 <0JKE00D13QF2LX00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 29 Jun 2007 10:11:26 -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 <0JKE00KREQF0KPD0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 29 Jun 2007 10:11:24 -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 l5THBO0F015667 for ; Fri, 29 Jun 2007 10:11:24 -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 <0JKE00J01QEXH200@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 29 Jun 2007 10:11:24 -0700 (PDT) Received: from [192.168.168.4] ([66.166.204.98]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JKE001TKQEZKN60@fe-sfbay-09.sun.com>; Fri, 29 Jun 2007 10:11:24 -0700 (PDT) Date: Fri, 29 Jun 2007 10:11:25 -0700 From: John Plocher Subject: Re: Draft opinion (PSARC 2005/695) In-reply-to: <18052.65493.396415.628182@gargle.gargle.HOWL> Sender: John.Plocher@sun.com To: James Carlson Cc: Darren.Reed@sun.com, Gary Winiger , psarc-ext@sun.com Message-id: <46853D3D.3000501@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706280241.l5S2fYjh002364@marduk.eng.sun.com> <46843820.3020504@Sun.COM> <46844FC8.9030904@sun.com> <18052.65493.396415.628182@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) Status: RO Content-Length: 6126 James Carlson wrote: > So, if as you're asserting that only the consolidations may have > releases, then exactly what do we tell customers and how do they know > what they're getting when they download bits? Each consolidation has its own way of marking its reease value. ON uses uname, java uses 'java --version', JDS/Gnome use "help about", etc. In general, we have general mechanism whereby one can iterate thru a list of components and query their version; neither do we have one for expressing the version of a given product. The /etc/issue and /etc/releasename files are/were used by Solaris, and the Product Registry tries to define a framework for unbundleds, and the package database has some poor support for it. > Do we list each > consolidation's release binding or number on a web site somewhere? Why would this matter to the ARC? I presume that the P-Team for a given Solaris-the-vinyl-binder product has a list of consolidations and associated versions that they will use to construct their product. The publication of that list to customers seems to be a product-specific action to be done by the P-Team as they react to their customer's demands. Same for the NetBeans IDE, Java, JES, Identity management, SunGrid, Belenix, Schillix and the other distros... > How does the customer know which consolidations' products he's using? By using each consolidation's "tell me your version" interface as above? > > I think what you're saying is that not only are numbers like "Solaris > 10" purely marketing (and thus PAC) constructs, but that we no longer Yes - they always have been. Go back thru the ARC Chairs minutes from the last decade or so and you will find many discussions about how inadvisable it was to tie marketing names tightly to release taxonomy values... > guarantee anything other than the contents of ON based on the output > of "uname -r." ... and we haven't done so for years and years. ON != WOS != Solaris-the-vinyl-binder... > Given that /usr/bin isn't special in Solaris and that > any consolidation can deliver there, some now (apparently) with > radically different release levels, how does any customer determine > what he's getting in the box? They rely on the fact that the product they are installing delivers a self-consistent set of components. Each of those components evolves at its own rate, subject to any integration measures that the P-Team chose to include. This is how we have been able to include new versions of Java, C, JES, JDS, etc in the Solaris product - even when they have major releases and ON doesn't. > Does this new scheme apply only for [Open]Solaris, or is it for all This isn't a new scheme - it is the way things have always been since we deployed the SDF in the early '90s. Much of the confusion that has been created since then has been caused by people incorrectly expecting that the whole Solaris world must be treated as if it was the ON consolidation. Thru such misguided assumptions, the PAC's request to "put iAS into Solaris" became "we must stuff it into ON because ON is the WOS and that is the only way we know how to do it". This distinction is all the more germain now that we have many different products building on top of the ON consolidation - SX and SDX from Sun, and Belenix, Nextenta, Schillix, ... from outside of Sun - it should be clear that we are not talking about a product instance but instead a consolidation. > products under review in the ARC? When we see a hardware product, > should we assume different release bindings for the hardware itself > and the firmware? Are they part of the same component? Does it make sense to release either of them independently of the other? If they are seperable, then yes, they are independent consolidations, each with (potentially) a different release binding. > > Do customers ever update just ON on their systems? I suspect that Probably not, but they get ON as part of many different products/distros. > excising or redefining the role of "Product" in our system will have > effects that we haven't anticipated. For one, it seems to make this > document unusable: > > http://www.opensolaris.org/os/community/arc/policies/release-taxonomy/ As I said to GaryW, when GaryS wrote this document, he was generalizing from the fact that, conceptually, a product can be made up of one or more consolidations, and, at that point, SunOS was effectively a single consolidation. It wasn't until SunView morphed into a non-kernel resident News/XNews/X server+libs and we broke off the compilers that Solaris became a multi-consolidation product (though it always was a wad of stuff) - but by then the document had already been written. I'm not sure what your concerns are - the ARCs have never controlled products; their impact has always been on the evolution of components and the projects that drive that evolution. The construction of products out of the set of available released consolidation instances is one that is owned and driven by the distro-teams (aka P-teams and Release Engineering). > (And since when do we ship Oracle?!) It shipped in (at least) the S9 and S10 product boxes; I don't know about the update releases. Some of the reviews have even gone thru PSARC: > PSARC 1995/191 DLM Memory Allocator for Oracle on Energizer (19950706_greg.slaughter) > PSARC 1995/424 SunSoft/Oracle "One-Buttton-Installation" for project BandWagon (19951207_steven.uhlir) > LSARC 1996/467 Single Sign On-Oracle (19961221_teodora.ngo) > ASARC 1997/004 Solstice Backup Database Module for Oracle v2.0 (19970107_elizabeth.bermudez) > ASARC 1998/009 Solstice Backup Database Module for Oracle, 2.1 (19980109_gregory.schlabs) > PSARC 1999/229 Oracle Edition (19990302_theresa.garcia) > PSARC 2002/308 Enterprise DHCP Oracle Module (20020528_tobin.coziahr) > LSARC 2005/088 Oracle RDBMS 9i and 10g N1SPS Plugins 1.0 (20050211_ted.persky) > WSARC 2007/159 Oracle 10g support for JES registry (20070318_paul.sterk) -John From John.Plocher@sun.com Fri Jun 29 10:20:38 2007 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 l5THKb2p015409 for ; Fri, 29 Jun 2007 10:20:38 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5THIlo7028838 for <@newsunmail1brm.central.sun.com:psarc-ext@sun.com>; Fri, 29 Jun 2007 18:18:50 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JKE00B07QRC5B00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 29 Jun 2007 11:18:48 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKE002YRQRBFD60@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 29 Jun 2007 11:18:47 -0600 (MDT) 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 l5THIl7l029661 for ; Fri, 29 Jun 2007 10:18:47 -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 <0JKE00E01QMUZM00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 29 Jun 2007 10:18:47 -0700 (PDT) Received: from [192.168.168.4] ([66.166.204.98]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JKE00CRZQRANQA0@fe-sfbay-10.sun.com>; Fri, 29 Jun 2007 10:18:47 -0700 (PDT) Date: Fri, 29 Jun 2007 10:18:49 -0700 From: John Plocher Subject: Re: Draft opinion (PSARC 2005/695) In-reply-to: <46853D3D.3000501@Sun.Com> Sender: John.Plocher@sun.com To: John Plocher Cc: James Carlson , psarc-ext@sun.com, Darren.Reed@sun.com, Gary Winiger Message-id: <46853EF9.8050107@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706280241.l5S2fYjh002364@marduk.eng.sun.com> <46843820.3020504@Sun.COM> <46844FC8.9030904@sun.com> <18052.65493.396415.628182@gargle.gargle.HOWL> <46853D3D.3000501@Sun.Com> User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) Status: RO Content-Length: 160 Oops, Copy/paste error: John Plocher wrote: > In general, we have general mechanism whereby one can iterate thru In general, we do NOT have a mechanism ... From carlsonj@phorcys.east.sun.com Fri Jun 29 11:04:13 2007 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 l5TI4DpR016816 for ; Fri, 29 Jun 2007 11:04:13 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5TI2Lv4011628; Fri, 29 Jun 2007 11:02:26 -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 <0JKE00E25SS0AW00@brm-avmta-1.central.sun.com>; Fri, 29 Jun 2007 12:02:24 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKE0023HSRTFI70@brm-avmta-1.central.sun.com>; Fri, 29 Jun 2007 12:02:18 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5TI2HnF014981; Fri, 29 Jun 2007 14:02:17 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l5TI2Hmj014978; Fri, 29 Jun 2007 14:02:17 -0400 (EDT) Date: Fri, 29 Jun 2007 14:02:16 -0400 From: James Carlson Subject: Re: Draft opinion (PSARC 2005/695) In-reply-to: <46853D3D.3000501@Sun.Com> To: John Plocher Cc: Darren.Reed@sun.com, Gary Winiger , psarc-ext@sun.com Message-id: <18053.18728.971511.943553@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.2.0.264296 References: <200706280241.l5S2fYjh002364@marduk.eng.sun.com> <46843820.3020504@Sun.COM> <46844FC8.9030904@sun.com> <18052.65493.396415.628182@gargle.gargle.HOWL> <46853D3D.3000501@Sun.Com> Status: RO Content-Length: 5713 John Plocher writes: > ON uses uname, java uses 'java --version', JDS/Gnome use "help about", > etc. This skips over a fundamental question: how does any user know which bit belongs with which consolidation in the WOS? I don't see very many helpful bright lines here. Can you help me out? > > Do we list each > > consolidation's release binding or number on a web site somewhere? > > Why would this matter to the ARC? I think it matters deeply, and that seems to be at the core of this confusion. One of the things the ARC must do is make sure that expectations are *clearly* communicated to customers and those who build products atop Sun products, such as Solaris. That's why we have written release and interface taxonomies, and we clearly specify what sorts of documentation and communication mechanisms are expected in support of those designations. If there is no such clear communication, then we're building castles in the air. There's very little point to having an ARC at all if the stability levels and other things we're working so hard to maintain are written into write-only memory. > I presume that the P-Team for > a given Solaris-the-vinyl-binder product has a list of consolidations > and associated versions that they will use to construct their product. > The publication of that list to customers seems to be a product-specific > action to be done by the P-Team as they react to their customer's demands. I presume that, too. The missing part is how any customer or third party vendor who gets that composite "product" knows what the heck the product *is*. > Same for the NetBeans IDE, Java, JES, Identity management, SunGrid, > Belenix, Schillix and the other distros... Sure. They do one of (at least) two things: - Communicate to their respective customers how they're versioning things and what those users can depend on. This could just be the 'largest' of the bindings among the consolidations. - Throw in the towel. Each release is distinct and not a controlled series. They're probably just stamped with a date code like a can of peas. What's in it? Who cares? It's the Latest 'n' Greatest, and that's all you need to know. Just don't try building on it. > > How does the customer know which consolidations' products he's using? > > By using each consolidation's "tell me your version" interface as above? There's no such interface. That's precisely the problem. It does not exist in general, and for something that's suddenly so important, we've put precious little effort into doing this. I say "suddenly" here, because until your change to the template last September (SCCS ID 1.21), the example text read like this: The project may be delivered in a minor release of Solaris. I still don't see where the implications of that change were discussed with the rest of the ARC. > > guarantee anything other than the contents of ON based on the output > > of "uname -r." > > ... and we haven't done so for years and years. > ON != WOS != Solaris-the-vinyl-binder... And, yet, we (in the ARC) have been binding things to Solaris releases for years and years. At least up until this past September, when that rule changed. > This is how we have been able to include new versions of Java, C, > JES, JDS, etc in the Solaris product - even when they have major > releases and ON doesn't. For Java, we've intentionally caused them to ship multiple versions and have a transition story, for *PRECISELY* this reason. If they were just major releases without reference to any sort of Solaris standards, then that wouldn't have been necessary. For JES and JDS, I admit I don't really know what's going on or how it lines up with previously well-known Solaris release standards. I do know that we've had ongoing discussions about whether bundling in the WOS is really the best answer, given expectations. > This distinction is all the more germain now that we have many > different products building on top of the ON consolidation - SX > and SDX from Sun, and Belenix, Nextenta, Schillix, ... from outside > of Sun - it should be clear that we are not talking about a product > instance but instead a consolidation. I don't believe we can or should actually do that until users can identify consolidations. Quick: what consolidations do /usr/sfw/sbin/tcpd and /usr/bin/zip belong to? No fair looking at the source. > I'm not sure what your concerns are - the ARCs have never controlled > products; Agreed. That's not what I'm asserting. > their impact has always been on the evolution of components > and the projects that drive that evolution. Agreed, also. > The construction of products > out of the set of available released consolidation instances is one that > is owned and driven by the distro-teams (aka P-teams and Release Engineering). Still agreed. However, the communication of release bindings is a *KEY* concern of architectural review. If that doesn't happen and (by design) cannot happen, then we might as well pack it in now. We're done here, because we're no longer building a product. > > (And since when do we ship Oracle?!) > > It shipped in (at least) the S9 and S10 product boxes; I don't > know about the update releases. Some of the reviews have even > gone thru PSARC: Surprise to me. Those are mostly support bits, not Oracle the product. > > PSARC 1999/229 Oracle Edition (19990302_theresa.garcia) "closed withdrawn" -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From alan.coopersmith@sun.com Fri Jun 29 11:40:08 2007 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 l5TIe76t017207 for ; Fri, 29 Jun 2007 11:40:08 -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 l5TIcFle023457 for <@newsunmail1brm.central.sun.com:psarc-ext@sun.com>; Sat, 30 Jun 2007 02:38:20 +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 <0JKE00G0HUFVLN00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 29 Jun 2007 12:38:19 -0600 (MDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKE002IFUFUFBA0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 29 Jun 2007 12:38:19 -0600 (MDT) Received: from [129.146.108.211] (almas.SFBay.Sun.COM [129.146.108.211]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5TIcGqp006363; Fri, 29 Jun 2007 11:38:16 -0700 (PDT) Date: Fri, 29 Jun 2007 11:38:16 -0700 From: Alan Coopersmith Subject: Re: Draft opinion (PSARC 2005/695) In-reply-to: <46853D3D.3000501@Sun.Com> To: John Plocher Cc: James Carlson , Darren.Reed@sun.com, Gary Winiger , psarc-ext@sun.com Message-id: <46855198.1060900@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706280241.l5S2fYjh002364@marduk.eng.sun.com> <46843820.3020504@Sun.COM> <46844FC8.9030904@sun.com> <18052.65493.396415.628182@gargle.gargle.HOWL> <46853D3D.3000501@Sun.Com> User-Agent: Thunderbird 2.0.0.0 (X11/20070423) Status: RO Content-Length: 859 John Plocher wrote: > James Carlson wrote: >> So, if as you're asserting that only the consolidations may have >> releases, then exactly what do we tell customers and how do they know >> what they're getting when they download bits? > > Each consolidation has its own way of marking its release value. We do? For X, our release value is the version of the Solaris WOS we bundle into, and we don't provide a way to get any other version of the consolidation as a whole. (Except for the disaster that is patch README's, in which we've always been forbidden from labeling a Solaris 10 patch as "Solaris 10" and thus have complete garbage names in, such as the "X11 6.8.0" patch which delivers Xorg server 1.2 from X11R7.2 to Solaris 10.) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From John.Plocher@sun.com Fri Jun 29 12:47:57 2007 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 l5TJlvBp018235 for ; Fri, 29 Jun 2007 12:47:57 -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 l5TJkBJI017847 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Fri, 29 Jun 2007 12:46: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 <0JKE00803XKZEE00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 29 Jun 2007 12:46:11 -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 <0JKE00G8XXKZNEF0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 29 Jun 2007 12:46:11 -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 l5TJkB9b003050 for ; Fri, 29 Jun 2007 12:46:11 -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 <0JKE00001XHN7K00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 29 Jun 2007 12:46:11 -0700 (PDT) Received: from [129.146.58.87] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JKE002W5XKT7K80@fe-sfbay-09.sun.com>; Fri, 29 Jun 2007 12:46:05 -0700 (PDT) Date: Fri, 29 Jun 2007 12:46:08 -0700 From: John Plocher Subject: Re: Draft opinion (PSARC 2005/695) In-reply-to: <18053.18728.971511.943553@gargle.gargle.HOWL> Sender: John.Plocher@sun.com To: James Carlson Cc: Darren.Reed@sun.com, Gary Winiger , psarc-ext@sun.com Message-id: <46856180.10302@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706280241.l5S2fYjh002364@marduk.eng.sun.com> <46843820.3020504@Sun.COM> <46844FC8.9030904@sun.com> <18052.65493.396415.628182@gargle.gargle.HOWL> <46853D3D.3000501@Sun.Com> <18053.18728.971511.943553@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) Status: RO Content-Length: 6090 James Carlson wrote: > John Plocher writes: >> ON uses uname, java uses 'java --version', JDS/Gnome use "help about", >> etc. > > This skips over a fundamental question: how does any user know which > bit belongs with which consolidation in the WOS? > > I don't see very many helpful bright lines here. Can you help me out? Right now, they can either use the Product Registry or grovel thru /var/sadm/install/contents. Or, better, they could read the release notes and other product literature that came with the product they acquired to see what was in it. How is this an architectural issue and not a product marketing/customer satisfaction issue? > >>> Do we list each >>> consolidation's release binding or number on a web site somewhere? >> Why would this matter to the ARC? > > I think it matters deeply, and that seems to be at the core of this > confusion. > > One of the things the ARC must do is make sure that expectations are > *clearly* communicated to customers and those who build products atop > Sun products, such as Solaris. That's why we have written release and > interface taxonomies, and we clearly specify what sorts of > documentation and communication mechanisms are expected in support of > those designations. I somewhat disagree - the ARC isn't directly responsible for those product-specific details, the distro team (PAC, P-Team...) is. I don't disagree that it is important that the ARC make sure that various interfaces(etc) in a consolidation are sufficiently documented (interface taxonomy and all that) and that the release binding of the various proposals is clearly articulated. It is also part of the (delegated) scope of the ARC to ensure that this release binding info is used appropriately by the gatekeepers for each of the various consolidation instances, so that projects only integrate into the places that they were approved for. > If there is no such clear communication, then we're building castles > in the air. There's very little point to having an ARC at all if the > stability levels and other things we're working so hard to maintain > are written into write-only memory. ??? The ARCs control the evolution of consolidations. This is the same read-write-iterate SDF/ARC process we have been using for the last 17+ years at Sun. Someone (Was the PACs, now is some mix of OS.O communities and the OGB) controls what new consolidation instances are chartered and what their release taxonomy bindings will be. Distro teams build their castles by controling the selection and integration of specific versioned consolidation instances. Where do you see "write-only" memory here? > The missing part is how any customer or third party vendor who gets > that composite "product" knows what the heck the product *is*. Look on the "ingredients list" on the product box? Maybe there is a hole here in that the ARCs have not pushed for the development of a way to iterate thru the list of included consolidations, or that there is no uniform way to query a consolidation for its version information, but I don't see how changing the wording of an ARC Opinion to better reflect its intent affects this problem at all... > - Communicate to their respective customers how they're versioning > things and what those users can depend on. This could just be the > 'largest' of the bindings among the consolidations. I've not seen anything from the other distros that would lead me to presume that their version numbers mean anything more than a way to disambiguate their sequential release stream... > > - Throw in the towel. Each release is distinct and not a controlled > series. They're probably just stamped with a date code like a can > of peas. What's in it? Who cares? It's the Latest 'n' Greatest, > and that's all you need to know. Just don't try building on it. Just like SX and the bi-weekly OS.o ON releases... > >>> How does the customer know which consolidations' products he's using? >> By using each consolidation's "tell me your version" interface as above? > > There's no such interface. That's precisely the problem. Again, how does changing the wording in the opinion template a this? > I still don't see where the implications of that change were discussed > with the rest of the ARC. This is/was a recurring conversation at ARC Chairs; it also was brought up as part of the ARC-Next effort and a reaction to complaints from the ON Cteam. As a clerical cleanup to make the opinion match the SDF and the way that we do business, it didn't need more than a mention in an ARC Chairs meeting. > And, yet, we (in the ARC) have been binding things to Solaris releases > for years and years. ... and engendering confusion throughout the company every time. Projects don't integrate into products - they integrate into consolidations. C-Teams and Gatekeepers consume these opinions to determine which putbacks they can allow, based on their ARC approval and binding. > I don't believe we can or should actually do that until users can > identify consolidations. Sounds OK to me - go start such a project. They can't do so today, yet the world still goes 'round... > Still agreed. However, the communication of release bindings is a > *KEY* concern of architectural review. If that doesn't happen and (by > design) cannot happen, then we might as well pack it in now. We're > done here, because we're no longer building a product. The key consumer of consolidation release bindings is the Distro team that is building a product, NOT the customer who uses that product. If the product is intended to be "Stable", the distro team needs to ensure that the components it uses to build it are also "Stable". That probably means that they need to eschew major releases of their core components and create compatibility glue (like the java stuff) in places where they can't do so. If nothing else, this discussion shows how intertwined PSARC is in the multiple roles of ON-ARC, Distro-agnostic-ARC and Solaris-WOS-ARC, not to mention Platform-ARC... -John From Darren.Reed@sun.com Fri Jun 29 14:39:34 2007 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 l5TLdXv3022240 for ; Fri, 29 Jun 2007 14:39:33 -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 l5TLbfgp012007 for <@newsunmail1brm.central.sun.com:psarc-ext@sun.com>; Sat, 30 Jun 2007 05:37:46 +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 <0JKF006072QVO300@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 29 Jun 2007 15:37:43 -0600 (MDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKF0004S2QT6Z40@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 29 Jun 2007 15:37:42 -0600 (MDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5TLbe8H010355 for ; Fri, 29 Jun 2007 21:37:40 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKF00B012F2YP00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sat, 30 Jun 2007 05:37:40 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKF00AH72QQF3GL@mail-apac.sun.com>; Sat, 30 Jun 2007 05:37:40 +0800 (SGT) Date: Fri, 29 Jun 2007 14:37:38 -0700 From: Darren.Reed@sun.com Subject: Re: Draft opinion (PSARC 2005/695) In-reply-to: <18053.18728.971511.943553@gargle.gargle.HOWL> Sender: Darren.Reed@sun.com To: James Carlson Cc: John Plocher , Gary Winiger , psarc-ext@sun.com Message-id: <46857BA2.3080306@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200706280241.l5S2fYjh002364@marduk.eng.sun.com> <46843820.3020504@Sun.COM> <46844FC8.9030904@sun.com> <18052.65493.396415.628182@gargle.gargle.HOWL> <46853D3D.3000501@Sun.Com> <18053.18728.971511.943553@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 1044 James Carlson wrote: >John Plocher writes: > > > ... > >>>How does the customer know which consolidations' products he's using? >>> >>> >>By using each consolidation's "tell me your version" interface as above? >> >> > >There's no such interface. That's precisely the problem. > >It does not exist in general, and for something that's suddenly so >important, we've put precious little effort into doing this. > >I say "suddenly" here, because until your change to the template last >September (SCCS ID 1.21), the example text read like this: > > The project may be delivered in a minor release of Solaris. > >I still don't see where the implications of that change were discussed >with the rest of the ARC. > > In light of the contention regarding this change, can I please ask for this single line in the opinion template to be reverted back, pending the outcome of this discussion (or any other discussion that is required to change it)? It'll make the life of us novice opinion writers a wee bit easier :) Thanks, Darren From John.Plocher@Sun.COM Fri Jun 29 15:32:05 2007 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 l5TMW5iw024116 for ; Fri, 29 Jun 2007 15:32:05 -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 l5TMUIM3015534 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 29 Jun 2007 15:30:19 -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 <0JKF00K0V56J8W00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 29 Jun 2007 15:30:19 -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 <0JKF00HK156GIDB0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 29 Jun 2007 15:30:16 -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 l5TMUFpl019031 for ; Fri, 29 Jun 2007 15:30:15 -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 <0JKF007014ZVQ200@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 29 Jun 2007 15:30:15 -0700 (PDT) Received: from [129.146.58.87] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JKF00JP456C7Q50@fe-sfbay-09.sun.com>; Fri, 29 Jun 2007 15:30:13 -0700 (PDT) Date: Fri, 29 Jun 2007 15:30:15 -0700 From: John Plocher Subject: Re: Draft opinion (PSARC 2005/695) In-reply-to: <46855198.1060900@sun.com> Sender: John.Plocher@Sun.COM To: Alan Coopersmith Cc: James Carlson , Darren.Reed@Sun.COM, Gary Winiger , psarc-ext@Sun.COM Message-id: <468587F7.5090807@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706280241.l5S2fYjh002364@marduk.eng.sun.com> <46843820.3020504@Sun.COM> <46844FC8.9030904@sun.com> <18052.65493.396415.628182@gargle.gargle.HOWL> <46853D3D.3000501@Sun.Com> <46855198.1060900@sun.com> User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) Status: RO Content-Length: 1155 Alan Coopersmith wrote: > John Plocher wrote: >> James Carlson wrote: >>> So, if as you're asserting that only the consolidations may have >>> releases, then exactly what do we tell customers and how do they know >>> what they're getting when they download bits? >> >> Each consolidation has its own way of marking its release value. > > We do? For X, our release value Sounds to me like there isn't any explicit value to the customer in knowing your release version because your interfaces are stable enough so that it doesn't matter (i.e., everything is effectively a micro release), and you have other mechanisms to enumerate the lists of features you deliver. I'm pretty sure that somewhere in your deliverables or docs you do tell the customer what they are getting (X11r6, Xsun, supported framebuffers, lists of extensions, etc) Either that, or you have a customer need that isn't being met :-) I agree with Jim that there isn't a generalized way to ask this question or how to interpret the answers obtained. I just don't see the connection between this discussion and the opinion content that is the subject of this thread. -John From brian.utterback@Sun.COM Mon Jul 2 11:57:56 2007 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 l62IvtAL011947 for ; Mon, 2 Jul 2007 11:57:56 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l62Iu4Zd016612 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 2 Jul 2007 19:56:07 +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 <0JKK00509F9HA800@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 02 Jul 2007 11:56:05 -0700 (PDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKK00MNAF9GJS60@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 02 Jul 2007 11:56:05 -0700 (PDT) Received: from [129.148.226.14] (sr1-unsh01-04.East.Sun.COM [129.148.226.14]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l62ItwFp013867; Mon, 02 Jul 2007 14:55:59 -0400 (EDT) Date: Mon, 02 Jul 2007 14:55:58 -0400 From: Brian Utterback Subject: Re: Draft opinion (PSARC 2005/695) In-reply-to: <46856180.10302@Sun.Com> To: John Plocher Cc: James Carlson , Darren.Reed@Sun.COM, Gary Winiger , psarc-ext@Sun.COM Message-id: <46894A3E.40908@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706280241.l5S2fYjh002364@marduk.eng.sun.com> <46843820.3020504@Sun.COM> <46844FC8.9030904@sun.com> <18052.65493.396415.628182@gargle.gargle.HOWL> <46853D3D.3000501@Sun.Com> <18053.18728.971511.943553@gargle.gargle.HOWL> <46856180.10302@Sun.Com> User-Agent: Thunderbird 2.0.0.5pre (X11/20070702) Status: RO Content-Length: 1760 John Plocher wrote: > James Carlson wrote: >> This skips over a fundamental question: how does any user know which >> bit belongs with which consolidation in the WOS? > > Right now, they can either use the Product Registry or grovel thru > /var/sadm/install/contents. Or, better, they could read the release > notes and other product literature that came with the product they > acquired to see what was in it. Really? Using Jim's example, I in the contents file I can see that /usr/sfw/sbin/tcpd is part of the SUNWtcpd package. Not much progress there. Using pkginfo I can find out that on my system, tcpd is used for "access control facility for internet services" and apparently was made on January 21, 2005. Using prodreg, I don't see anything more. So, as using your approach, I have no more info about which consolidation delivered tcpd as I had before. Now, in the case of tcpd, I can go to the OpenSolaris source browser and find tcpd there, so I know that tcpd is in the ON consolidation, but suppose the file I was interested in was /kernel/drv/sparcv9/qlc? The contents file would show the package as SUNWqlc which is the "Qlogic ISP 2200/2202 Fibre Channel Device Driver", but what consolidation does it come from? The source browser doesn't help at all in this case. There doesn't seem to be a definitive list, but my calculations there are about 50 consolidations that go into Solaris. -- blu The #1 red flag for privacy advocates is when a law enforcement official says "If you aren't doing anything wrong, then you have nothing to worry about." ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From John.Plocher@sun.com Mon Jul 2 12:42:32 2007 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 l62JgV1w012578 for ; Mon, 2 Jul 2007 12:42:32 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l62JeL08014556 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Tue, 3 Jul 2007 03:40:43 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JKK00H0DHBUY400@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 02 Jul 2007 12:40:42 -0700 (PDT) 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 <0JKK00H97HBTSH00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 02 Jul 2007 12:40:41 -0700 (PDT) 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 l62JefnQ028856 for ; Mon, 02 Jul 2007 12:40:41 -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 <0JKK00C01H6JDE00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 02 Jul 2007 12:40:41 -0700 (PDT) Received: from [129.146.58.87] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JKK000QSHBS1Z50@fe-sfbay-10.sun.com>; Mon, 02 Jul 2007 12:40:41 -0700 (PDT) Date: Mon, 02 Jul 2007 12:40:42 -0700 From: John Plocher Subject: Re: Draft opinion (PSARC 2005/695) In-reply-to: <46894A3E.40908@sun.com> Sender: John.Plocher@sun.com To: Brian Utterback Cc: James Carlson , Darren.Reed@sun.com, Gary Winiger , psarc-ext@sun.com Message-id: <468954BA.4010906@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706280241.l5S2fYjh002364@marduk.eng.sun.com> <46843820.3020504@Sun.COM> <46844FC8.9030904@sun.com> <18052.65493.396415.628182@gargle.gargle.HOWL> <46853D3D.3000501@Sun.Com> <18053.18728.971511.943553@gargle.gargle.HOWL> <46856180.10302@Sun.Com> <46894A3E.40908@sun.com> User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) Status: RO Content-Length: 3328 Brian Utterback wrote: > So, as using your approach I'm not sure how this discussion about making ARC Opinions state the correct consolidation integration parameters ("a minor release of the ON consolidation") has morphed into a diatribe about how hard it is for end users to map artifacts back to consolidations or to enumerate the list of Consolidations found in a specific product. I absolutely agree that it is hard; I'm also completely unconvinced that these problems have anything to do with the wording of the Opinion. This Opinion info is intended to be consumed by the developers of the project, the consolidation and the distro(s) that include them; it is not in itself an end-user deliverable, though there may be reflections of the consolidation in the contents file, the product registry, etc. There may even be ways to extract the consolidation's version info from a running system, but those mechanisms are unfortunately mostly accidental and not very useful. But, even if they existed and were easy to obtain, they still would not provide useful info to the end user. Each Distro has a set of goals - The Solaris distro chose extreme interface stability over time for its core. This means that, when the Solaris Distro Product team goes off and constructs the next release of its product, it will tend to choose to construct it out of the most recent Minor or Micro release of the ON consolidation. Other Distros may make the same or different choices, depending on their needs and what "kinds" of ON instances are available.... If you are a user of the Solaris Distro, you shouldn't have to know or care about /how/ the release team built the product; your questions about stability are answered by the Solaris' product's policy to include such stability info on man pages. Want to know if "foo" is something you can depend on?, look it up with the man(1) command. Where it lives in the filesystem, what consolidation it came out of, whethere it was written by Sun or Someone Else, what language it was written in - all of these are irrelevant when it comes to the interface stability question. When you get the next version of Solaris, you /expect/ it to have been constructed in such a way that its historical stability expectations are honored. It is up to the Solaris Distro producer to inform you of anything that would change those expectations. And, as long as the Distro keeps meeting those expectations, you don't need to care about the details of how they did it. It all boils down to product expectations: The Solaris Distro says that, for its Marketing releases, The core of the system is Committed (see man(1)...) The desktop follows the GNOME Foundation's lead; some things are Committed, others track the community Java evolves faster than the core, but we try to keep the last couple of versions around to help you transition, The Nextenta Distro, on the other hand, seems to say We follow the OS.o ON Community for the core, We follow the cutting edge (unstable) of Debian, and we do a bunch of work to try to make Solaris Distro things "just work", but it all is a work in progress... Certainly, Distro developers care about consolidations and their release taxonomy; I'm unconvinced that end users or ISV developers need to care. -John From Darren.Reed@sun.com Mon Jul 2 14:16:13 2007 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 l62LGDld015945 for ; Mon, 2 Jul 2007 14:16:13 -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 l62LENkm010582; Mon, 2 Jul 2007 14:14:24 -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 <0JKK00M0PLO0N400@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jul 2007 14:14:24 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKK00HQFLNYSK70@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jul 2007 14:14:24 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l62LEMKN022424; Mon, 02 Jul 2007 21:14:22 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKK00B01LMLGQ00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM); Tue, 03 Jul 2007 05:14:22 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKK007OHLNW6YL0@mail-apac.sun.com>; Tue, 03 Jul 2007 05:14:22 +0800 (SGT) Date: Mon, 02 Jul 2007 14:14:19 -0700 From: Darren.Reed@sun.com Subject: Opinion for review: PSARC/2005/695 - CIFS Client on Solaris Sender: Darren.Reed@sun.com To: PSARC-EXT Cc: CIFS client team , Gary Winiger Message-id: <46896AAB.4030208@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_VtSOH6Gl88M6bPfwb1aaJg)" X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 11017 This is a multi-part message in MIME format. --Boundary_(ID_VtSOH6Gl88M6bPfwb1aaJg) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Please review this opinion by Friday the 13th of July, 2007. Thanks, Darren --Boundary_(ID_VtSOH6Gl88M6bPfwb1aaJg) Content-type: text/plain; name=opinion.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=opinion.txt sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: CIFS Client on Solaris Submitted by: Pavan Kumar Mettu File: PSARC/2005/695/opinion.ms Date: May 30, 2007 Committee: Gary Winiger (opinion written by Darren Reed), Kais Belgaied, James D Carlson, Glenn Skinner. Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary CIFS Client for Solaris is a virtual file system on Solaris providing access to the servers which support the CIFS protocol(Windows, Samba on Unix/Linux). The CIFS protocol allows sharing of files, printers and other resources across a network. Using the CIFS client, users can mount remote CIFS server shares (directories) on their system. The CIFS client uses TCP naming and supports authentication, oplocks, caching, DFS, Extended Attributes, Unicode resource names and secu- rity signatures. Authorisation will be given to all users to mount and unmount CIFS filesystems. 2. Decision & Precedence Information The project is approved as specified in reference [1-10], but as modified by the required technical changes listed in Appendix A below. The project may be delivered in a patch release of Solaris. The project depends on the following other project and may not be delivered before it. PSARC/2007/303 pam_smb_login PSARC/2005/695 Copyright 2007 Sun Microsystems - 2 - 3. Interfaces The project exports the following interfaces. ________________________________________________________________________ | Interfaces Exported | |____________|_______________________|_________________________________| |Interface | Classification | Comments | |____________|_______________________|_________________________________| |smbutil | Committed | | |nsmbrc(4) | Committed | | |mount_smbfs | Committed | | |umount_smbfs| Committed | | |libsmbfs.so | Project Private | Will contract with Nautilus | |smbfs module| Consolidation Private| | |nsmb module | Project Private | | |SMF service | Committed | svc:/network/smb/client:default| |SUNWsmbfsr | Committed | Package name | |SUNWsmbfsu | Committed | Package name | |____________|_______________________|_________________________________| The project imports the following interfaces. __________________________________________________________________ | Interfaces Imported | |______________|_______________________|_________________________| |Interface | Classification | Comments | |______________|_______________________|_________________________| |libkrb5 | Contracted | PSARC/2006/027 | |uconv routines| Consolidation Private| PSARC/2005/446 | |md4 routines | Consolidation Private| PSARC/2007/139 | |sockfs calls | Project Private | See design [5], 8.5.2.3| |______________|_______________________|_________________________| 4. Opinion 4.1. NetBIOS name resolution The CIFS client will make use of NetBIOS for name resolution if it is enabled and if nornmal hostname resolution has already failed to provide an answer for the name. This fol- lows the algorithm used by Microsoft. We need to pay atten- tion to their moves in this so that in the event that they abandon use of NetBIOS, Solaris is similarly adjusted. 4.2. Patch binding Although this case has sought and had approved a request for patch binding, the case presented is a large project, with the following 6 dependencies identified in during commitment review: PSARC/2005/695 Copyright 2007 Sun Microsystems - 3 - PSARC/2004/047 Enabling user mounts in Solaris in S10 PSARC/2005/446 Unicode encoding conversion functions at the kernel in SNV PSARC/2006/027 Open Kerberos APIs (contracted) in SNV PSARC/2006/715 CIFS Service (parts) PSARC/2007/139 Kernel Crypto support for MD4 in SNV PSARC/2005/374 Share management improvements (sharectl(1M)) in SNV In addition to this, contracts will be required for linking with the Kerberos APIs being used and SMF for removal of the SMF service on patch backout using /var/svc/profile/ugprade. 4.3. Kerberos and Single Sign On The ARC spent some time discussion the interaction of CIFS with Kerberos for single sign on, particularly with respect to the ease of use gained from this. In particular, when operational inside a Kerberos (or Active Directory) realm, there should be no need to use smbutil's login functionality in order to access CIFS shares. The project team commented that while it was within scope of their project, it was not considered to be a "must" for them to deliver. At the time of the meeting it was believed that the code worked, with the actual status unclear, which led to the ARC prescribing a TCR for the delivery of it to work and a case depenedency on PSARC/2007/303 (pam_smb_login). 4.4. Storing CIFS share passwords The use of the .nsmbrc file to hold user passwords for CIFS shares was discussed and points made about how this is han- dled elsewhere. At the very least, the file needs to be protected by making it read and write for the owner only. To store the password, a recoverable hash is used, obscuring the plaintext password. Whilst some mechanics such as the need to support a different password per share were also discussed, the end result must be something that is easy for the user to use and should not require direct editing of the file. 4.5. Unmounting the filesystem At the close of the meeting, the issue of how the project intends to allow users to unmount filesystems was raised. At the time of the meeting, there was no proposal put for- ward on how to do this. Without this part of the architec- ture the case was considered to be incomplete. In lieu of a vote being able to be taken because of this, a straw poll PSARC/2005/695 Copyright 2007 Sun Microsystems - 4 - was taken on whether or not it would be approved with all members present approving. The advice to the project was to find a solution to this problem and present it to the ARC which would then hold a vote via email. The team took this advice up and presented a solution to PSARC at the next PSARC meeting, allowing the project to be voted on and formally approved. 4.6. Use of SMF to store properties The architecture of this case includes the use of SMF as the means for persistent storage of various properties for the CIFS client service. Initially it was believed that the SMF service needed to be enabled by default and at the commit- ment meeting, the committee requested that the project ensure that it was enabled in the appropriate generic ser- vice profile when the project delivered. In a followup to this after commitment, it was made clear that the service did not need to be enabled in order for properties to be used, so the aforementioned requirement was later dropped. 5. Minority Opinion(s) None. 6. Advisory Information 6.1. Backport As noted in the 4.2, this project depends on many other pro- jects spread throughout the present development release. Backports of projects with such dependences often introduce a higher level of instability and bugs than fully contained projects. The committee advises the PAC and any project teams to not undertake such a backport without thoroughly understanding the downside consequences. 7. Appendices 7.1. Appendix A: Technical Changes Required 1. Document the search order relative to NetBIOS and nsswitch.conf. 2. Add password support to nsmbrc(4) in a user friendly way. 3. Provide support for Kerberos credentials when Ker- beros is the login mechanism. If this cannot be PSARC/2005/695 Copyright 2007 Sun Microsystems - 5 - accomplished, submit a fast track to amend this case. 4. Provide for appropriate value and action authori- zations for the smb/client service. Ensure that the authorizations are delivered in a Rights Pro- file and documented in the sharectl(1M) man page or on a separate smb/client man page if appropri- ate. 5. CIFS Client support when TX is enabled should mir- ror that of NFS client support. If this cannot be accomplished, submit a fast track to amend this case. 7.2. Appendix B: Technical Changes Advised none 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2005/695. 1 20 Questions file: commitment.materials/20questions.txt 2 nsmbrc(4) file: commitment.materials/nsmbrc.4.txt file: commitment.materials/nsmbrc.4.pdf 3 CIFS Client Diagram file: commitment.materials/CIFS_Client_diagram.jpg 4 Security Questionaire file: commitment.materials/sec_questions.html file: commitment.materials/sec_questions.txt 5 CIFS design document file: commitment.materials/CIFS_Design_Doc.html 6 Changes since inception file: commitment.materials/changes_since_inception.txt 7 sharectl(1m) file: commitment.materials/sharectl.1m.txt 8 Project requirements specification file: commitment.materials/cifs_client_prd.html 9 mount_smbfs(1m) file: commitment.materials/mount_smbfs.1m.txt file: commitment.materials/mount_smbfs.1m.pdf PSARC/2005/695 Copyright 2007 Sun Microsystems - 6 - 10 smbutil(1) file: commitment.materials/smbutil.1.txt file: commitment.materials/smbutil.1.pdf PSARC/2005/695 Copyright 2007 Sun Microsystems --Boundary_(ID_VtSOH6Gl88M6bPfwb1aaJg)-- From robert.thurlow@sun.com Fri Jul 6 14:48:17 2007 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 l66LmGvx008966 for ; Fri, 6 Jul 2007 14:48:16 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l66LkEcb021174; Fri, 6 Jul 2007 22:46:17 +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 <0JKS00J031T4AC00@nwk-avmta-2.sfbay.sun.com>; Fri, 06 Jul 2007 14:46:16 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKS0018S1T4YHC0@nwk-avmta-2.sfbay.sun.com>; Fri, 06 Jul 2007 14:46:16 -0700 (PDT) Received: from [10.7.250.28] (punchin-client-10-7-250-28.SFBay.Sun.COM [10.7.250.28]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l66LkEdt247213; Fri, 06 Jul 2007 14:46:15 -0700 (PDT) Date: Fri, 06 Jul 2007 15:46:14 -0600 From: Robert Thurlow Subject: Re: Opinion for review: PSARC/2005/695 - CIFS Client on Solaris In-reply-to: <46896AAB.4030208@Sun.COM> To: Darren.Reed@sun.com Cc: PSARC-EXT , CIFS client team , Gary Winiger Message-id: <468EB826.7020307@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46896AAB.4030208@Sun.COM> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 787 Darren.Reed@sun.com wrote: > Please review this opinion by Friday the 13th of July, 2007. Looks good, a couple of edits below. > The CIFS client uses > TCP naming and supports authentication, oplocks, caching, > DFS, Extended Attributes, Unicode resource names and secu- > rity signatures. Authorisation will be given to all users > to mount and unmount CIFS filesystems. Our first delivery will not support Oplocks, DFS or Extended Attributes. If "security signatures" means packet signing aka integrity, we may not have this at first deliver either. > In addition to this, contracts will be required for linking > with the Kerberos APIs being used and SMF for removal of the > SMF service on patch backout using /var/svc/profile/ugprade. Typo - "ugprade". Rob T From sacadmin Sat Jul 7 16:09:39 2007 Received: from marduk.eng.sun.com (marduk [129.146.108.224]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l67N9dnP025853 for ; Sat, 7 Jul 2007 16:09:39 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l67NAxTZ013083; Sat, 7 Jul 2007 16:10:59 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l67NAxvp013082; Sat, 7 Jul 2007 16:10:59 -0700 (PDT) Date: Sat, 7 Jul 2007 16:10:59 -0700 (PDT) From: Gary Winiger Message-Id: <200707072310.l67NAxvp013082@marduk.eng.sun.com> To: psarc@sac.sfbay.sun.com Subject: Contract between 2005/695 and 2006/027 Cc: anup.sekhar@sun.com, don.traub@sun.com, robert.thurlow@sun.com, p.kumar@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 280 I've executed a contract for the CIFS Client (PSARC/2005/695) to import libkrb5 as exported by Open Kerberos APIs (PSARC/2006/027). This contract is based on the previously executed contract of 2006/027. A signed copy is in contract-02 of 2006/027 and is linked 2005/695. Gary.. From carlsonj@phorcys.east.sun.com Thu Jul 12 09:37:38 2007 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 l6CGbb2N009269 for ; Thu, 12 Jul 2007 09:37:38 -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 l6CGZYXx020997; Fri, 13 Jul 2007 00:35:35 +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 <0JL200J01RF9JT00@brm-avmta-1.central.sun.com>; Thu, 12 Jul 2007 10:35:33 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL200CFIRF8RXC0@brm-avmta-1.central.sun.com>; Thu, 12 Jul 2007 10:35:32 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6CGZVLL025692; Thu, 12 Jul 2007 12:35:31 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l6CGZVPi025689; Thu, 12 Jul 2007 12:35:31 -0400 (EDT) Date: Thu, 12 Jul 2007 12:35:30 -0400 From: James Carlson Subject: Re: Draft opinion (PSARC 2005/695) In-reply-to: <468954BA.4010906@Sun.Com> To: John Plocher Cc: Brian Utterback , Darren.Reed@Sun.COM, Gary Winiger , psarc-ext@Sun.COM Message-id: <18070.22610.892292.622640@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.2.0.264296 References: <200706280241.l5S2fYjh002364@marduk.eng.sun.com> <46843820.3020504@Sun.COM> <46844FC8.9030904@sun.com> <18052.65493.396415.628182@gargle.gargle.HOWL> <46853D3D.3000501@Sun.Com> <18053.18728.971511.943553@gargle.gargle.HOWL> <46856180.10302@Sun.Com> <46894A3E.40908@sun.com> <468954BA.4010906@Sun.Com> Status: RO Content-Length: 4915 John Plocher writes: > Brian Utterback wrote: > > So, as using your approach > > I'm not sure how this discussion about making ARC Opinions state the > correct consolidation integration parameters ("a minor release of the > ON consolidation") has morphed into a diatribe about how hard it is for > end users to map artifacts back to consolidations or to enumerate the That's easy. The discussion morphed because the text specifying the release binding morphed. I have no problem with identifying the consolidation (or list of consolidations) into which a given project is integrating. That's obviously key for interpreting the 'private' interfaces and the contracts. I have a big problem with specifying the release binding as attaching to a particular consolidation. That isn't supported by the release taxonomy, and clearly isn't supported by any ARC practice up through November of last year. Furthermore, the system itself cannot support this sort of release binding, as the user documentation and visible release information does *NOT* indicate what has been done. > Each Distro has a set of goals - The Solaris distro chose extreme > interface stability over time for its core. This means that, when No disagreement with that. However, we still have a requirement that we must be able to make those release bindings usable to those who need to use them. Otherwise, the whole exercise is pointless. The distributors can, of course, ignore what we produce. That's what distributions have in front of them. They can pick content. We are constrained, though, in that we have to produce usable information. If what you're saying is that "a Minor release of Solaris" excludes other distributions, you're quite right. That doesn't mean that we toss release vehicles out the window and use consolidations instead. Instead, it means that we need to get other distributions involved with the process -- so that we can bind to whatever they need as well. I think what you're proposing is that consolidations have release bindings, and that distributors can pick and choose among them without necessarily declaring anything for their releases. At least for Solaris, I categorically reject that notion. If Solaris has Major changes in it, then it needs to be a Major release -- period. We cannot fudge on that or, quite frankly, nobody's going to believe our compatibility story. (And, again, that leads directly to a lack of any real need for ARC review, because we've given up.) > If you are a user of the Solaris Distro, you shouldn't have to > know or care about /how/ the release team built the product; your That's untrue. You do care, and you have to. "Patch xxx" is different from "Minor release yyy" in terms of risk, planning, qualification testing, and third-party product support. If there are "Major" changes in it, then you need to prepare for major change, and you shouldn't adopt it lightly. How can it be otherwise? > questions about stability are answered by the Solaris' product's > policy to include such stability info on man pages. Want to know > if "foo" is something you can depend on?, look it up with the man(1) That tells you exactly nothing if you cannot determine what the releases are. If the release information is buried in each consolidation rather than on the outside of the tin, then you simply cannot tell at all what you're getting, and our carefully-crafted man page documentation isn't worth spit. The man page for something Committed is saying (effectively) "won't change until the next Major release." Great. What if Major releases occur every week, because that's how the consolidation rolls? That's an invitation to chaos. > command. Where it lives in the filesystem, what consolidation it > came out of, whethere it was written by Sun or Someone Else, what > language it was written in - all of these are irrelevant when it > comes to the interface stability question. Release binding is relevant for interpreting stability. Consolidation *becomes* relevant when that's where you bind the release, which is what was done in the last (undiscussed? unreviewed?) change to the opinion template. Bind it elsewhere, and it once again becomes irrelevant. > The Solaris Distro says that, for its Marketing releases, > The core of the system is Committed (see man(1)...) > The desktop follows the GNOME Foundation's lead; > some things are Committed, others track the community > Java evolves faster than the core, but we try to keep > the last couple of versions around to help you transition, "And, dear user, there's no real way to tell which bits are in which bucket, so good luck with all that." -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Wed Aug 22 19:50:30 2007 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 l7N2oTaE003310 for ; Wed, 22 Aug 2007 19:50:30 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l7N2lqdg014468 for <@sunmail2sca.sfbay.sun.com:sac-review@sun.com>; Thu, 23 Aug 2007 10:47:56 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JN700503H3VLC00@nwk-avmta-2.sfbay.sun.com> for sac-review@sun.com (ORCPT sac-review@Sun.COM); Wed, 22 Aug 2007 19:47:55 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JN7004RIH3TA510@nwk-avmta-2.sfbay.sun.com> for sac-review@sun.com (ORCPT sac-review@Sun.COM); Wed, 22 Aug 2007 19:47:54 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7N2lrNW027131 for ; Thu, 23 Aug 2007 02:47:53 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JN700201GYZGV00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for sac-review@Sun.COM (ORCPT sac-review@Sun.COM); Thu, 23 Aug 2007 10:47:53 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JN7000PEH3SEJ89@mail-apac.sun.com> for sac-review@Sun.COM (ORCPT sac-review@Sun.COM); Thu, 23 Aug 2007 10:47:53 +0800 (SGT) Date: Wed, 22 Aug 2007 19:47:51 -0700 From: Darren.Reed@sun.com Subject: Opinion for SAC review: PSARC/2005/695 Sender: Darren.Reed@sun.com To: sac-review@sun.com Cc: P.Kumar@sun.com Message-id: <46CCF557.703@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_VqSocQaQoc+eqzvH1dY+XQ)" X-Accept-Language: en-au, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 11367 This is a multi-part message in MIME format. --Boundary_(ID_VqSocQaQoc+eqzvH1dY+XQ) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Attached is the opinion for the commitment review held on the 30th of May, 2007. Please respond with comments by Wednesday the 29th of August, 2007. A copy of the opinion can be found in the case directory in PDF format. Darren --Boundary_(ID_VqSocQaQoc+eqzvH1dY+XQ) Content-type: text/plain; name=psarc-2005-695-sac-review.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=psarc-2005-695-sac-review.txt sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: CIFS Client on Solaris Submitted by: Pavan Kumar Mettu File: PSARC/2005/695/opinion.ms Date: May 30, 2007 Committee: Gary Winiger (opinion written by Darren Reed), Kais Belgaied, James D Carlson, Glenn Skinner. Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary CIFS Client for Solaris is a virtual file system on Solaris providing access to the servers which support the CIFS protocol(Windows, Samba on Unix/Linux). The CIFS protocol allows sharing of files, printers and other resources across a network. Using the CIFS client, users can mount remote CIFS server shares (directories) on their system. The CIFS client uses TCP naming and supports authentication and caching, Unicode resource names. Authorization will be given to all users to mount and unmount CIFS filesystems. The team hopes to deliver packet level signing to improve the integrity of the data but is unable to guarantee this at present. The delivery of oplocks, DFS and Extended Attributes is not included in this deliverable. 2. Decision & Precedence Information The project is approved as specified in reference [1-10], but as modified by the required technical changes listed in Appendix A below. The project may be delivered in a patch release of Solaris. The project depends on the following other project and may PSARC/2005/695 Copyright 2007 Sun Microsystems - 2 - not be delivered before it. PSARC/2007/303 pam_smb_login 3. Interfaces The project exports the following interfaces. ________________________________________________________________________ | Interfaces Exported | |____________|_______________________|_________________________________| |Interface | Classification | Comments | |____________|_______________________|_________________________________| |smbutil | Committed | | |nsmbrc(4) | Committed | | |mount_smbfs | Committed | | |umount_smbfs| Committed | | |libsmbfs.so | Project Private | Will contract with Nautilus | |smbfs module| Consolidation Private| | |nsmb module | Project Private | | |SMF service | Committed | svc:/network/smb/client:default| |SUNWsmbfsr | Committed | Package name | |SUNWsmbfsu | Committed | Package name | |____________|_______________________|_________________________________| The project imports the following interfaces. __________________________________________________________________ | Interfaces Imported | |______________|_______________________|_________________________| |Interface | Classification | Comments | |______________|_______________________|_________________________| |libkrb5 | Contracted | PSARC/2006/027 | |uconv routines| Consolidation Private| PSARC/2005/446 | |md4 routines | Consolidation Private| PSARC/2007/139 | |sockfs calls | Project Private | See design [5], 8.5.2.3| |______________|_______________________|_________________________| 4. Opinion 4.1. NetBIOS name resolution The CIFS client will make use of NetBIOS for name resolution if it is enabled and if nornmal hostname resolution has already failed to provide an answer for the name. This fol- lows the algorithm used by Microsoft. We need to pay atten- tion to their moves in this so that in the event that they abandon use of NetBIOS, Solaris is similarly adjusted. PSARC/2005/695 Copyright 2007 Sun Microsystems - 3 - 4.2. Patch binding Although this case has sought and had approved a request for patch binding, the case presented is a large project, with the following 6 dependencies identified in during commitment review: PSARC/2004/047 Enabling user mounts in Solaris in S10 PSARC/2005/446 Unicode encoding conversion functions at the kernel in SNV PSARC/2006/027 Open Kerberos APIs (contracted) in SNV PSARC/2006/715 CIFS Service (parts) PSARC/2007/139 Kernel Crypto support for MD4 in SNV PSARC/2005/374 Share management improvements (sharectl(1M)) in SNV In addition to this, contracts will be required for linking with the Kerberos APIs being used and SMF for removal of the SMF service on patch backout using /var/svc/profile/upgrade. 4.3. Kerberos and Single Sign On The ARC spent some time discussion the interaction of CIFS with Kerberos for single sign on, particularly with respect to the ease of use gained from this. In particular, when operational inside a Kerberos (or Active Directory) realm, there should be no need to use smbutil's login functionality in order to access CIFS shares. The project team commented that while it was within scope of their project, it was not considered to be a "must" for them to deliver. At the time of the meeting it was believed that the code worked, with the actual status unclear, which led to the ARC prescribing a TCR for the delivery of it to work and a case depenedency on PSARC/2007/303 (pam_smb_login). 4.4. Storing CIFS share passwords The use of the .nsmbrc file to hold user passwords for CIFS shares was discussed and points made about how this is han- dled elsewhere. At the very least, the file needs to be protected by making it read and write for the owner only. To store the password, a recoverable hash is used, obscuring the plaintext password. Whilst some mechanics such as the need to support a different password per share were also discussed, the end result must be something that is easy for the user to use and should not require direct editing of the file. PSARC/2005/695 Copyright 2007 Sun Microsystems - 4 - 4.5. Unmounting the filesystem At the close of the meeting, the issue of how the project intends to allow users to unmount filesystems was raised. At the time of the meeting, there was no proposal put for- ward on how to do this. Without this part of the architec- ture the case was considered to be incomplete. In lieu of a vote being able to be taken because of this, a straw poll was taken on whether or not it would be approved with all members present approving. The advice to the project was to find a solution to this problem and present it to the ARC which would then hold a vote via email. The team took this advice up and presented a solution to PSARC at the next PSARC meeting, allowing the project to be voted on and formally approved. 4.6. Use of SMF to store properties The architecture of this case includes the use of SMF as the means for persistent storage of various properties for the CIFS client service. Initially it was believed that the SMF service needed to be enabled by default and at the commit- ment meeting, the committee requested that the project ensure that it was enabled in the appropriate generic ser- vice profile when the project delivered. In a followup to this after commitment, it was made clear that the service did not need to be enabled in order for properties to be used, so the aforementioned requirement was later dropped. 5. Minority Opinion(s) None. 6. Advisory Information 6.1. Backport As noted in the 4.2, this project depends on many other pro- jects spread throughout the present development release. Backports of projects with such dependences often introduce a higher level of instability and bugs than fully contained projects. The committee advises the PAC and any project teams to not undertake such a backport without thoroughly understanding the downside consequences. 7. Appendices 7.1. Appendix A: Technical Changes Required PSARC/2005/695 Copyright 2007 Sun Microsystems - 5 - 1. Document the search order relative to NetBIOS and nsswitch.conf. 2. Add password support to nsmbrc(4) in a user friendly way. 3. Provide support for Kerberos credentials when Ker- beros is the login mechanism. If this cannot be accomplished, submit a fast track to amend this case. 4. Provide for appropriate value and action authori- zations for the smb/client service. Ensure that the authorizations are delivered in a Rights Pro- file and documented in the sharectl(1M) man page or on a separate smb/client man page if appropri- ate. 5. CIFS Client support when TX is enabled should mir- ror that of NFS client support. If this cannot be accomplished, submit a fast track to amend this case. 7.2. Appendix B: Technical Changes Advised none 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2005/695. 1 20 Questions file: commitment.materials/20questions.txt 2 nsmbrc(4) file: commitment.materials/nsmbrc.4.txt file: commitment.materials/nsmbrc.4.pdf 3 CIFS Client Diagram file: commitment.materials/CIFS_Client_diagram.jpg 4 Security Questionaire file: commitment.materials/sec_questions.html file: commitment.materials/sec_questions.txt 5 CIFS design document file: commitment.materials/CIFS_Design_Doc.html 6 Changes since inception file: commitment.materials/changes_since_inception.txt 7 sharectl(1m) file: commitment.materials/sharectl.1m.txt PSARC/2005/695 Copyright 2007 Sun Microsystems - 6 - 8 Project requirements specification file: commitment.materials/cifs_client_prd.html 9 mount_smbfs(1m) file: commitment.materials/mount_smbfs.1m.txt file: commitment.materials/mount_smbfs.1m.pdf 10 smbutil(1) file: commitment.materials/smbutil.1.txt file: commitment.materials/smbutil.1.pdf PSARC/2005/695 Copyright 2007 Sun Microsystems --Boundary_(ID_VqSocQaQoc+eqzvH1dY+XQ)-- From sac-owner Thu Aug 23 15:18:32 2007 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 l7NMIV9S026902 for ; Thu, 23 Aug 2007 15:18:32 -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 l7NMFtYu022823; Fri, 24 Aug 2007 06:15:56 +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 <0JN800501Z6IHY00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 23 Aug 2007 15:15:54 -0700 (PDT) Received: from buye.red.iplanet.com ([192.18.65.224]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JN8001E9Z6IB640@nwk-avmta-1.sfbay.Sun.COM>; Thu, 23 Aug 2007 15:15:54 -0700 (PDT) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id l7NMFsj6000474; Thu, 23 Aug 2007 15:15:54 -0700 (PDT) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id l7NMFsDo000473; Thu, 23 Aug 2007 15:15:54 -0700 (PDT) Date: Thu, 23 Aug 2007 15:15:54 -0700 From: Jyri Virkki Subject: Re: Opinion for SAC review: PSARC/2005/695 In-reply-to: <46CCF557.703@Sun.COM> To: Darren.Reed@Sun.COM Cc: sac-review@Sun.COM, P.Kumar@Sun.COM Message-id: <20070823221554.GK318@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <46CCF557.703@Sun.COM> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 295 Darren.Reed@Sun.COM wrote: > > To store the password, a recoverable hash is used, obscuring "recoverable hash"? I'm guessing what's meant was a reversible obfuscation? In which case I suggest documenting it that way, to be clearer. -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From sac-owner Thu Aug 23 16:41:35 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7NNfZQo028406 for ; Thu, 23 Aug 2007 16:41:35 -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 l7NNd1Ic009480 for <@sunmail2sca.sfbay.sun.com:sac-review@sun.com>; Thu, 23 Aug 2007 16:39:01 -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 <0JN900E0D310C600@nwk-avmta-1.sfbay.Sun.COM> for sac-review@sun.com (ORCPT sac-review@Sun.COM); Thu, 23 Aug 2007 16:39:00 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JN9001N230ZB3A0@nwk-avmta-1.sfbay.Sun.COM> for sac-review@sun.com (ORCPT sac-review@Sun.COM); Thu, 23 Aug 2007 16:38:59 -0700 (PDT) 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 l7NNcxm5029024 for ; Thu, 23 Aug 2007 16:38:59 -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 <0JN9004012WVGE00@fe-sfbay-10.sun.com> (original mail from James.Hughes@Sun.COM) for sac-review@Sun.COM (ORCPT sac-review@Sun.COM); Thu, 23 Aug 2007 16:38:59 -0700 (PDT) Received: from [10.0.231.148] ([192.18.37.228]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JN900IZ130Z7690@fe-sfbay-10.sun.com> for sac-review@Sun.COM (ORCPT sac-review@Sun.COM); Thu, 23 Aug 2007 16:38:59 -0700 (PDT) Date: Thu, 23 Aug 2007 16:38:58 -0700 From: james hughes Subject: Re: Opinion for SAC review: PSARC/2005/695 In-reply-to: <20070823221554.GK318@sun.com> Sender: James.Hughes@Sun.COM To: Jyri Virkki Cc: james hughes , Darren.Reed@Sun.COM, sac-review@Sun.COM, P.Kumar@Sun.COM Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.896) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46CCF557.703@Sun.COM> <20070823221554.GK318@sun.com> Status: RO Content-Length: 459 Someone please send me either a pointer or a copy of this algorithm definition or the code. On Aug 23, 2007, at 3:15 PM, Jyri Virkki wrote: > Darren.Reed@Sun.COM wrote: >> >> To store the password, a recoverable hash is used, obscuring > > "recoverable hash"? I'm guessing what's meant was a reversible > obfuscation? In which case I suggest documenting it that way, to be > clearer. > > > -- > Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From sac-owner Mon Aug 27 13:10:07 2007 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 l7RKA6JM022072 for ; Mon, 27 Aug 2007 13:10:07 -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 l7RK72s9027936; Mon, 27 Aug 2007 14:07:03 -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 <0JNG003017WD8W00@nwk-avmta-2.sfbay.sun.com>; Mon, 27 Aug 2007 13:07:25 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNG00KG47WDE880@nwk-avmta-2.sfbay.sun.com>; Mon, 27 Aug 2007 13:07:25 -0700 (PDT) Received: from [129.150.12.124] (vpn-129-150-12-124.SFBay.Sun.COM [129.150.12.124]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l7RK7NSU785975; Mon, 27 Aug 2007 13:07:24 -0700 (PDT) Date: Mon, 27 Aug 2007 10:04:10 -1000 From: Joseph Kowalski Subject: Re: Opinion for SAC review: PSARC/2005/695 In-reply-to: <46CCF557.703@Sun.COM> To: Darren.Reed@Sun.COM Cc: sac-review@Sun.COM, P.Kumar@Sun.COM Message-id: <46D32E3A.3040002@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46CCF557.703@Sun.COM> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 12110 Opps, I should have caught this in PSARC review. My bad. It seems that the information in 4.2 should also be in section 2. If all the cases listed in 4.2 have been delivered, then its not absolutely required, but it would probably be a good idea anyway. Since I'm lazy, I'd just put the dependencies in section 2, and save the time if they are already delivered. (Of course, with the "Express Releases", one might wonder what actually constitutes "delivered", but that's for another (painful) discussion. :-) ) - jek3 Darren.Reed@sun.com wrote: > Attached is the opinion for the commitment review held on the 30th of > May, 2007. > > Please respond with comments by Wednesday the 29th of August, 2007. > > A copy of the opinion can be found in the case directory in PDF format. > > Darren > > ------------------------------------------------------------------------ > > > sun > microsystems Systems Architecture Committee > > _________________________________________________________________ > > Subject: CIFS Client on Solaris > > Submitted by: Pavan Kumar Mettu > > File: PSARC/2005/695/opinion.ms > > Date: May 30, 2007 > > Committee: Gary Winiger (opinion written by Darren > Reed), Kais Belgaied, James D Carlson, Glenn > Skinner. > > Product Approval Committee: > > Solaris PAC > solaris-pac-opinion@sun.com > > 1. Summary > > CIFS Client for Solaris is a virtual file system on Solaris > providing access to the servers which support the CIFS > protocol(Windows, Samba on Unix/Linux). The CIFS protocol > allows sharing of files, printers and other resources across > a network. > > Using the CIFS client, users can mount remote CIFS server > shares (directories) on their system. The CIFS client uses > TCP naming and supports authentication and caching, Unicode > resource names. Authorization will be given to all users to > mount and unmount CIFS filesystems. > > The team hopes to deliver packet level signing to improve > the integrity of the data but is unable to guarantee this at > present. > > The delivery of oplocks, DFS and Extended Attributes is not > included in this deliverable. > > 2. Decision & Precedence Information > > The project is approved as specified in reference [1-10], > but as modified by the required technical changes listed in > Appendix A below. > > The project may be delivered in a patch release of Solaris. > > The project depends on the following other project and may > > PSARC/2005/695 Copyright 2007 Sun Microsystems > > - 2 - > > not be delivered before it. > > PSARC/2007/303 pam_smb_login > > 3. Interfaces > > The project exports the following interfaces. > > ________________________________________________________________________ > | Interfaces Exported | > |____________|_______________________|_________________________________| > |Interface | Classification | Comments | > |____________|_______________________|_________________________________| > |smbutil | Committed | | > |nsmbrc(4) | Committed | | > |mount_smbfs | Committed | | > |umount_smbfs| Committed | | > |libsmbfs.so | Project Private | Will contract with Nautilus | > |smbfs module| Consolidation Private| | > |nsmb module | Project Private | | > |SMF service | Committed | svc:/network/smb/client:default| > |SUNWsmbfsr | Committed | Package name | > |SUNWsmbfsu | Committed | Package name | > |____________|_______________________|_________________________________| > > The project imports the following interfaces. > > __________________________________________________________________ > | Interfaces Imported | > |______________|_______________________|_________________________| > |Interface | Classification | Comments | > |______________|_______________________|_________________________| > |libkrb5 | Contracted | PSARC/2006/027 | > |uconv routines| Consolidation Private| PSARC/2005/446 | > |md4 routines | Consolidation Private| PSARC/2007/139 | > |sockfs calls | Project Private | See design [5], 8.5.2.3| > |______________|_______________________|_________________________| > > 4. Opinion > > 4.1. NetBIOS name resolution > > The CIFS client will make use of NetBIOS for name resolution > if it is enabled and if nornmal hostname resolution has > already failed to provide an answer for the name. This fol- > lows the algorithm used by Microsoft. We need to pay atten- > tion to their moves in this so that in the event that they > abandon use of NetBIOS, Solaris is similarly adjusted. > > PSARC/2005/695 Copyright 2007 Sun Microsystems > > - 3 - > > 4.2. Patch binding > > Although this case has sought and had approved a request for > patch binding, the case presented is a large project, with > the following 6 dependencies identified in during commitment > review: > > PSARC/2004/047 Enabling user mounts in Solaris in S10 > > PSARC/2005/446 Unicode encoding conversion functions > at the kernel in SNV > > PSARC/2006/027 Open Kerberos APIs (contracted) in SNV > > PSARC/2006/715 CIFS Service (parts) > > PSARC/2007/139 Kernel Crypto support for MD4 in SNV > > PSARC/2005/374 Share management improvements > (sharectl(1M)) in SNV > > In addition to this, contracts will be required for linking > with the Kerberos APIs being used and SMF for removal of the > SMF service on patch backout using /var/svc/profile/upgrade. > > 4.3. Kerberos and Single Sign On > > The ARC spent some time discussion the interaction of CIFS > with Kerberos for single sign on, particularly with respect > to the ease of use gained from this. In particular, when > operational inside a Kerberos (or Active Directory) realm, > there should be no need to use smbutil's login functionality > in order to access CIFS shares. The project team commented > that while it was within scope of their project, it was not > considered to be a "must" for them to deliver. At the time > of the meeting it was believed that the code worked, with > the actual status unclear, which led to the ARC prescribing > a TCR for the delivery of it to work and a case depenedency > on PSARC/2007/303 (pam_smb_login). > > 4.4. Storing CIFS share passwords > > The use of the .nsmbrc file to hold user passwords for CIFS > shares was discussed and points made about how this is han- > dled elsewhere. At the very least, the file needs to be > protected by making it read and write for the owner only. > To store the password, a recoverable hash is used, obscuring > the plaintext password. Whilst some mechanics such as the > need to support a different password per share were also > discussed, the end result must be something that is easy for > the user to use and should not require direct editing of the > file. > > PSARC/2005/695 Copyright 2007 Sun Microsystems > > - 4 - > > 4.5. Unmounting the filesystem > > At the close of the meeting, the issue of how the project > intends to allow users to unmount filesystems was raised. > At the time of the meeting, there was no proposal put for- > ward on how to do this. Without this part of the architec- > ture the case was considered to be incomplete. In lieu of a > vote being able to be taken because of this, a straw poll > was taken on whether or not it would be approved with all > members present approving. The advice to the project was > to find a solution to this problem and present it to the ARC > which would then hold a vote via email. > > The team took this advice up and presented a solution to > PSARC at the next PSARC meeting, allowing the project to be > voted on and formally approved. > > 4.6. Use of SMF to store properties > > The architecture of this case includes the use of SMF as the > means for persistent storage of various properties for the > CIFS client service. Initially it was believed that the SMF > service needed to be enabled by default and at the commit- > ment meeting, the committee requested that the project > ensure that it was enabled in the appropriate generic ser- > vice profile when the project delivered. > > In a followup to this after commitment, it was made clear > that the service did not need to be enabled in order for > properties to be used, so the aforementioned requirement was > later dropped. > > 5. Minority Opinion(s) > > None. > > 6. Advisory Information > > 6.1. Backport > > As noted in the 4.2, this project depends on many other pro- > jects spread throughout the present development release. > Backports of projects with such dependences often introduce > a higher level of instability and bugs than fully contained > projects. The committee advises the PAC and any project > teams to not undertake such a backport without thoroughly > understanding the downside consequences. > > 7. Appendices > > 7.1. Appendix A: Technical Changes Required > > PSARC/2005/695 Copyright 2007 Sun Microsystems > > - 5 - > > 1. Document the search order relative to NetBIOS and > nsswitch.conf. > > 2. Add password support to nsmbrc(4) in a user > friendly way. > > 3. Provide support for Kerberos credentials when Ker- > beros is the login mechanism. If this cannot be > accomplished, submit a fast track to amend this > case. > > 4. Provide for appropriate value and action authori- > zations for the smb/client service. Ensure that > the authorizations are delivered in a Rights Pro- > file and documented in the sharectl(1M) man page > or on a separate smb/client man page if appropri- > ate. > > 5. CIFS Client support when TX is enabled should mir- > ror that of NFS client support. If this cannot be > accomplished, submit a fast track to amend this > case. > > 7.2. Appendix B: Technical Changes Advised > > none > > 7.3. Appendix C: Reference Material > > Unless stated otherwise, path names are relative to the case > directory PSARC/2005/695. > > 1 20 Questions > file: commitment.materials/20questions.txt > > 2 nsmbrc(4) > file: commitment.materials/nsmbrc.4.txt > file: commitment.materials/nsmbrc.4.pdf > > 3 CIFS Client Diagram > file: commitment.materials/CIFS_Client_diagram.jpg > > 4 Security Questionaire > file: commitment.materials/sec_questions.html > file: commitment.materials/sec_questions.txt > > 5 CIFS design document > file: commitment.materials/CIFS_Design_Doc.html > > 6 Changes since inception > file: commitment.materials/changes_since_inception.txt > > 7 sharectl(1m) > file: commitment.materials/sharectl.1m.txt > > PSARC/2005/695 Copyright 2007 Sun Microsystems > > - 6 - > > 8 Project requirements specification > file: commitment.materials/cifs_client_prd.html > > 9 mount_smbfs(1m) > file: commitment.materials/mount_smbfs.1m.txt > file: commitment.materials/mount_smbfs.1m.pdf > > 10 smbutil(1) > file: commitment.materials/smbutil.1.txt > file: commitment.materials/smbutil.1.pdf > > PSARC/2005/695 Copyright 2007 Sun Microsystems > > From sac-owner Mon Aug 27 13:35:17 2007 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 l7RKZHEw022536 for ; Mon, 27 Aug 2007 13:35:17 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7RKWT2R028086; Mon, 27 Aug 2007 21:32:37 +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 <0JNG0040L92BGS00@nwk-avmta-2.sfbay.sun.com>; Mon, 27 Aug 2007 13:32:35 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNG00KP092AE4A0@nwk-avmta-2.sfbay.sun.com>; Mon, 27 Aug 2007 13:32:34 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l7RKWXrY018558; Mon, 27 Aug 2007 13:32:33 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l7RKXN5p000762; Mon, 27 Aug 2007 13:33:23 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l7RKXNMH000761; Mon, 27 Aug 2007 13:33:23 -0700 (PDT) Date: Mon, 27 Aug 2007 13:33:23 -0700 (PDT) From: Gary Winiger Subject: Re: Opinion for SAC review: PSARC/2005/695 To: Darren.Reed@sun.com, jek3@sun.com Cc: sac-review@sun.com, P.Kumar@sun.com Message-id: <200708272033.l7RKXNMH000761@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 613 > Opps, I should have caught this in PSARC review. My bad. > > It seems that the information in 4.2 should also be in section 2. If > all the cases listed in 4.2 have been delivered, then its not absolutely > required, but it would probably be a good idea anyway. Since I'm lazy, > I'd just put the dependencies in section 2, and save the time if they > are already delivered. No. The point of 4.2 is the discussion relative to the advice to NOT backport. These were all identifiec during the discussion on the Patch binding. PSARC/2007/303 pam_smb_login is the relevant case depencency. Gary..