2008/640 iSCSI With DHCP
Hi Darren, Comments inline. Darren J Moffat wrote: > James Carlson wrote: >> I'm sponsoring this fast-track request for Jack Meng. The timer is >> set to 10/24/2008. >> >> Background >> >> By default, dhcpagent "canonizes" interfaces under its control on >> receipt of SIGTERM. This means that it will reset the IP address >> back to 0.0.0.0 during shutdown. This happens regardless of whether >> dhcpagent is configured to release or drop leases. > > I'm sure this was considered but why bother with the reset to 0.0.0.0 > on shutdown at all ? What does it achieve ? dhcpagent canonizes all interfaces upon receiving SIGTERM, which usually happends during shutdown/reboot/halt (kill(-1, SIGTERM)) to stop all processes. It makes sense in the view of DHCP protocol and harmless for most (if not all) userland processes as they usually have SMF dependencies. But this behavior hurts kernel elements (iSCSI, NFS..) which are based on TCP/IP stack and supposed to still work after 'kill(-1, SIGTERM)', e.g., to synchronize file system. > If that wasn't done would there be any need for this special knowlege > of iSCSI (and NFS) both of which seem very "icky" but if needs must. I think NO, no special knowledge needed if the configuration of the if doesn't change at all during shutdown. > What breaks if dhcpagent does not reset back to 0.0.0.0 on shutdown > ? Could it still send the DHCP release to the DHCP server but not > reset the interface ? It is a solution, but violating the protocol more severely. > > > When is dhcpagent going to call the new ioctl ? What are the > responses it gets back and what circumstances ? The proposal is to let dhcpagent to call the ioctl in its handler of SIGTERM. The response is either True or False indicating if there're active iSCSI sessions configured. > What if we have a "mixed" boot environment where one size of the > mirror in the ZFS root pool is local disk and the other is iSCSI ? > Does that count as being ISCSI_IS_ACTIVE? > What if there are no "boot" pools/filesystems under iSCSI but there > are other active iSCSI devices ? Yes, these circumstances stand for 'iSCSI active' as there're active iSCSI session and the system may have iSCSI disks in use (root partition or zpool or..). > > Is this only if there is an an iSCSI initiator active, what about > targets ? [ Though I wouldn't expect those machines to be iSCSI boot ]. > Current iSCSI target on Solaris in a service in userland, it addressed this issue well with SMF dependency, and also it is not supposed to still work after 'kill(-1, SIGTERM)'. Best regards, Jack
LARC meeting summary, Tue, 7 Oct
Aniruddh, Please change the interface classification based on your suggestion in the case directory. Thanks, __Nasser Aniruddh Dikhit wrote: > Nasser Nouri wrote: >> Hi Aniruddh, >> >> The revised version of 1-pager for NetBeans DTrace GUI Plug-in is >> attached. I created a table for "Imported" and "Exported" interfaces >> based on your instructions. > > I just have one comment around the old classification level used. > Please refer > to the current taxonomy defined here > http://sac.sfbay/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp, you may want > to say uncommitted based on the stability level of the component. If > you are fine > with that then I can make that change in the case directory. > > Rest looks fine to me. > > -Aniruddh >> >> Thanks, >> __Nasser >> >> Aniruddh Dikhit wrote: >>> Hello Nasser >>> >>> I was thinking you were discussing this with Tom, the issue around >>> Chime is a separate >>> one which I thought was not concluded. I have copied the 1-pager >>> updated sent by you >>> in the case materials directory. Will announce the fast track and >>> set the expiry timer >>> accordingly. Here is the 1-pager you had sent out >>> >>> http://sac.sfbay/arc/LSARC/2008/620/materials/dtracegui_onepager.txt >>> >>> Tom do you want a separate fasttrack filed for chime which appears >>> to be an imported >>> interface for this project. >>> >>> Nasser also a slight nit on the interfaces section if you can >>> separate out, for the benefit >>> of the rest of the committee the imported (consumed and as mentioned >>> /usr/share/lib/java/dreate.jar) and exported interfaces (files etc. >>> installed and as mentioned >>> the NBM file). I think in addition you may want to document the >>> usage of chime >>> as an imported interfaces. If Tom is fine we can use the same >>> project to cover >>> both. >>> >>> If you can clarify then we can move forward on this case. >>> >>> thanks >>> Aniruddh >>> >>> >>> Aarti Pai wrote: Hi Nasser, These questions are to be directed to your case owner. - Aniruddh? (I'm the PM that coordinates meetings, agendas etc for the ARCs.) Your case owner works directly with the case material and the project team on architectural issues. Aarti Nasser Nouri wrote: > Hi Aarti, > > Based on James Carlson's email (below), the status of DTrace Java > API is "Committed" not "Evolving". The one-pager document is > updated based on that information. Additionally, the one-pager > document specifies that the DTrace GUI utilizes the DTrace Java API. > > What is the next step? Please advise. > > Thanks, > __Nasser > > Tom Childers writes: >> As we mentioned in the LSARC meeting this morning, the DTrace >> Java API was established by PSARC case 2006/054, >> http://sac.sfbay/PSARC/ 2006/054. It looks like the interfaces >> and stability are only described in the mail contents, and >> dtrace.jar is described as "Evolving". Can you please update >> the case materials to show you import this interface (or >> whichever one you use)? > > Nit: it's in the OS/Net consolidation and reviewed by PSARC, so the > old "Evolving" used here maps into the current "Committed." > >>> >> >> >> >> >> Template Version: @(#)onepager.txt 1.35 07/11/07 SMI >> Copyright 2007 Sun Microsystems >> >> // If this is to be exposed outside of Sun, DELETE the line below >> Sun Proprietary/Confidential: Internal Use Only: Engineering >> Need-to-Know >> >> 1. Introduction >>1.1. Project/Component Working Name: >> NetBeans DTrace GUI Plug-in >> >>1.2. Name of Document Author/Supplier: >> Nasser Nouri (nasser.nouri at sun.com) >> >>1.3. Date of This Document: >> 09/19/08 >> >>1.4. Name of Major Document Customer(s)/Consumer(s): >> 1.4.1. The PAC or CPT you expect to review your project: >>Tools PAC >> 1.4.2. The ARC(s) you expect to review your project: >>LSARC >> 1.4.3. The Director/VP who is "Sponsoring" this project: >>Don Kretsch >> 1.4.4. The name of your business unit: >>Software Tools >> >>1.5. Email Aliases: >> 1.5.1. Responsible Manager: >>vijay.tatkar at sun.com >> 1.5.2. Responsible Engineer: >>nasser.nouri at sun.com >> 1.5.3. Marketing Manager: >> 1.5.4. Interest List: >>ivan.vlasyuk at sun.com >>alexandre.iline at sun.com >> >> 2. Project Summary >>2.1. Project Description: >> The NetBeans DTrace GUI Plug-in is a graphical user interface >> (GUI) >> for SolarisTM Dynamic Tracing (DTrace). It works with both >> Sun Studio IDE and NetBeans IDE. >> For more information please see: >> >> http://www.netbeans.org/kb
LARC meeting summary, Tue, 7 Oct
Nasser Nouri wrote: > Hi Aniruddh, > > The revised version of 1-pager for NetBeans DTrace GUI Plug-in is > attached. I created a table for "Imported" and "Exported" interfaces > based on your instructions. I just have one comment around the old classification level used. Please refer to the current taxonomy defined here http://sac.sfbay/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp, you may want to say uncommitted based on the stability level of the component. If you are fine with that then I can make that change in the case directory. Rest looks fine to me. -Aniruddh > > Thanks, > __Nasser > > Aniruddh Dikhit wrote: >> Hello Nasser >> >> I was thinking you were discussing this with Tom, the issue around >> Chime is a separate >> one which I thought was not concluded. I have copied the 1-pager >> updated sent by you >> in the case materials directory. Will announce the fast track and set >> the expiry timer >> accordingly. Here is the 1-pager you had sent out >> >> http://sac.sfbay/arc/LSARC/2008/620/materials/dtracegui_onepager.txt >> >> Tom do you want a separate fasttrack filed for chime which appears to >> be an imported >> interface for this project. >> >> Nasser also a slight nit on the interfaces section if you can >> separate out, for the benefit >> of the rest of the committee the imported (consumed and as mentioned >> /usr/share/lib/java/dreate.jar) and exported interfaces (files etc. >> installed and as mentioned >> the NBM file). I think in addition you may want to document the usage >> of chime >> as an imported interfaces. If Tom is fine we can use the same project >> to cover >> both. >> >> If you can clarify then we can move forward on this case. >> >> thanks >> Aniruddh >> >> >> Aarti Pai wrote: >>> Hi Nasser, >>> >>> These questions are to be directed to your case owner. - Aniruddh? >>> (I'm the PM that coordinates meetings, agendas etc for the ARCs.) >>> Your case owner works directly with the case material and the >>> project team on architectural issues. >>> >>> Aarti >>> >>> Nasser Nouri wrote: Hi Aarti, Based on James Carlson's email (below), the status of DTrace Java API is "Committed" not "Evolving". The one-pager document is updated based on that information. Additionally, the one-pager document specifies that the DTrace GUI utilizes the DTrace Java API. What is the next step? Please advise. Thanks, __Nasser Tom Childers writes: > As we mentioned in the LSARC meeting this morning, the DTrace Java > API was established by PSARC case 2006/054, > http://sac.sfbay/PSARC/ 2006/054. It looks like the interfaces and > stability are only described in the mail contents, and dtrace.jar > is described as "Evolving". Can you please update the case > materials to show you import this interface (or whichever one you > use)? Nit: it's in the OS/Net consolidation and reviewed by PSARC, so the old "Evolving" used here maps into the current "Committed." >>> >>> >> > > > > > Template Version: @(#)onepager.txt 1.35 07/11/07 SMI > Copyright 2007 Sun Microsystems > > // If this is to be exposed outside of Sun, DELETE the line below > Sun Proprietary/Confidential: Internal Use Only: Engineering Need-to-Know > > 1. Introduction >1.1. Project/Component Working Name: > NetBeans DTrace GUI Plug-in > >1.2. Name of Document Author/Supplier: > Nasser Nouri (nasser.nouri at sun.com) > >1.3. Date of This Document: > 09/19/08 > >1.4. Name of Major Document Customer(s)/Consumer(s): > 1.4.1. The PAC or CPT you expect to review your project: >Tools PAC > 1.4.2. The ARC(s) you expect to review your project: >LSARC > 1.4.3. The Director/VP who is "Sponsoring" this project: >Don Kretsch > 1.4.4. The name of your business unit: >Software Tools > >1.5. Email Aliases: > 1.5.1. Responsible Manager: >vijay.tatkar at sun.com > 1.5.2. Responsible Engineer: >nasser.nouri at sun.com > 1.5.3. Marketing Manager: > 1.5.4. Interest List: >ivan.vlasyuk at sun.com >alexandre.iline at sun.com > > 2. Project Summary >2.1. Project Description: > The NetBeans DTrace GUI Plug-in is a graphical user interface (GUI) > for SolarisTM Dynamic Tracing (DTrace). It works with both > Sun Studio IDE and NetBeans IDE. > > For more information please see: > > http://www.netbeans.org/kb/docs/ide/NetBeans_DTrace_GUI_Plugin_0_4.html > >2.2. Risks and Assumptions: > Risk Schedule - assuming review and approval time will be 2 weeks, > i.e. > subission to the LARC on 22-Sep-08, Mon and approval obtained due 3 > Oct, > Fri. > > Risk Schedule -
IBTF IO Memory [PSARC/2008/630 FastTrack timeout 10/17/2008]
We will modify the case to say: IBTI_V3 is incompatible with other IBTI versions. IBCI_V3 is incompatible with other IBCI versions. When IBTI changes, you have to recompile all the in-kernel ULPs and the IBTF framework. When IBCI changes, you have to recompile the IBTF framework and all the HCA drivers. -ted Kais Belgaied wrote: > On 10/20/08 15:01, Ted H. Kim wrote: >> >> I am also not sure where this is leading. >> Are you suggesting some specific change to the case? > > I'm not clear on the future compatibility expectations around the > interface introduced by this case: > > I asked whether versions are incremental all the time and you answered yes > ((capabs of V(n+1) includes all capabs of V(n)) > I asked if some capabs can be used independently, you also said yes, > which suggests > (capabs of V(n+1)) don't necessarily have to include all capabs of V(n). > Capabs are independent. > > The former means that an IBT client module written to V(n) is guaranteed > to work unmodified on a framework+HCAs > that evolved to V(n+1) or later. > > The latter means modules may break or may continue to work. No backward > compatibility is guaranteed. > > Choose one semantic for the interface and clearly document it in the case. > >Kais. -- Ted H. Kim Sun Microsystems, Inc. ted.kim at sun.com 222 North Sepulveda Blvd., 10th Floor (310) 341-1116 El Segundo, CA 90245 (310) 341-1120 FAX
IBTF IO Memory [PSARC/2008/630 FastTrack timeout 10/17/2008]
On 10/20/08 15:01, Ted H. Kim wrote: > > I am also not sure where this is leading. > Are you suggesting some specific change to the case? I'm not clear on the future compatibility expectations around the interface introduced by this case: I asked whether versions are incremental all the time and you answered yes ((capabs of V(n+1) includes all capabs of V(n)) I asked if some capabs can be used independently, you also said yes, which suggests (capabs of V(n+1)) don't necessarily have to include all capabs of V(n). Capabs are independent. The former means that an IBT client module written to V(n) is guaranteed to work unmodified on a framework+HCAs that evolved to V(n+1) or later. The latter means modules may break or may continue to work. No backward compatibility is guaranteed. Choose one semantic for the interface and clearly document it in the case. Kais. > > -ted >
IBTF IO Memory [PSARC/2008/630 FastTrack timeout 10/17/2008]
Ted H. Kim wrote: > > > Kais Belgaied wrote: - Case boundary question: since this marks a flag day for both TI and CI, can you list the components that are affected by this flag day? >>> >>> Most of the IB modules in ON - >>> framework: IBTL >>> IB ULPs (TI): IPonIB, SDP, NFS/RDMA, uDAPL >>> HCA Drivers (CI): Tavor, Hermon >> >> at the risk of re-stating the obvious, all changes in the above 3 >> sets of components are in-scope of this case, >> right? > > Yes Actually, I think I made a mistake to say this. It's true to the extent that the three sets of components will use the interfaces here. But I think saying an unqualified yes means we have to deliver all modified components at once. And so I am going to say the right answer is YES to only the framework and HCA drivers. This allows us to deliver the changes to the framework and HCA drivers first. And then phase the delivery of the ULP mods. That way if there are customer priorities, we can deliver the ones they want first without having to wait to have all of the ULPs modified. -ted -- Ted H. Kim Sun Microsystems, Inc. ted.kim at sun.com 222 North Sepulveda Blvd., 10th Floor (310) 341-1116 El Segundo, CA 90245 (310) 341-1120 FAX
2008/640 iSCSI With DHCP
>That's not legal, for the reason given above. DHCP servers check for >address in use (by ARP and ICMP) before assigning them to clients. > And what is the rest doing? What happens if you don't give up the address? (My systems have a a "pkill -9 dhcpagent" when it sees a "drop/release" message). The system then works. Casper
IBTF IO Memory [PSARC/2008/630 FastTrack timeout 10/17/2008]
Kais Belgaied wrote:
>>> - Case boundary question: since this marks a flag day for both TI and
>>> CI, can you list the components
>>> that are affected by this flag day?
>>
>> Most of the IB modules in ON -
>> framework: IBTL
>> IB ULPs (TI): IPonIB, SDP, NFS/RDMA, uDAPL
>> HCA Drivers (CI): Tavor, Hermon
>
> at the risk of re-stating the obvious, all changes in the above 3 sets
> of components are in-scope of this case,
> right?
Yes
>>> - mi_ibt_version seems to be an enumeration of apparently mutually
>>> exclusive values IBTI_V{1,2,3}
>>> yet the definition suggests a combination of independent (discrete)
>>> capabilities
>>> (FMR support, DMA wrapper support, etc.)
>>
>> The features are examples of what was included at each version change.
>> More discussion of the relationship between ABI and features below ...
>>
>>> . Is there any consumer of this interface that uses DMA wapper
>>> but not FMR?
>>
>> Well to be honest FMR in the current form turned out to be a failure.
>> So no one uses FMR in ON right now.
>>
>> But I think more generally what is going to happen is that
>> the features will be used independently of each other,
>> since they are generally not related to each other.
>>
>>
>>> . For future evolution, is the mi_ibt_version always intended to
>>> express a monotonically increasing set
>>>of capabilities (capabs of V(n+1) includes all capabs of N(n)) ?
>>
>> Yes, that is the intent, but it is not guaranteed. However,
>> as you might imagine, it would involve a great deal of
>> discussion/agreement to remove anything and the ARC would be
>> in the loop.
>>
>>
>>> Basically I'm trying to see if information of different nature if
>>> being encoded in the same field. Without slipping
>>> in a design discussion you should consider if two fileds are more
>>> appropriate: 1 version (number or enum) and one capabs (bitmask).
>>
>> There are in fact capability bitmasks elsewhere.
>> In IB there are a number of optional features. So the bitmasks
>> generally are for saying you have these optional features.
>>
>> But the version number is more an ABI thing, and it is mistake
>> to conflate the too, though the reason we have to change ABI
>> is that new features demand more fields in the structs, etc.
>
> so are you fixing the mistake of conflating the capabs + version ? I
> still see the updated material unchanged
> on that.
I think it's a mistake in *understanding* to not distinguish API
from ABI. I am trying to clarify that.
I don't think it is a mistake in the design.
I am also not sure where this is leading.
Are you suggesting some specific change to the case?
-ted
--
Ted H. Kim
Sun Microsystems, Inc. ted.kim at sun.com
222 North Sepulveda Blvd., 10th Floor (310) 341-1116
El Segundo, CA 90245 (310) 341-1120 FAX
LARC meeting summary, Tue, 7 Oct
Hi Aniruddh, The revised version of 1-pager for NetBeans DTrace GUI Plug-in is attached. I created a table for "Imported" and "Exported" interfaces based on your instructions. Thanks, __Nasser Aniruddh Dikhit wrote: > Hello Nasser > > I was thinking you were discussing this with Tom, the issue around > Chime is a separate > one which I thought was not concluded. I have copied the 1-pager > updated sent by you > in the case materials directory. Will announce the fast track and set > the expiry timer > accordingly. Here is the 1-pager you had sent out > > http://sac.sfbay/arc/LSARC/2008/620/materials/dtracegui_onepager.txt > > Tom do you want a separate fasttrack filed for chime which appears to > be an imported > interface for this project. > > Nasser also a slight nit on the interfaces section if you can separate > out, for the benefit > of the rest of the committee the imported (consumed and as mentioned > /usr/share/lib/java/dreate.jar) and exported interfaces (files etc. > installed and as mentioned > the NBM file). I think in addition you may want to document the usage > of chime > as an imported interfaces. If Tom is fine we can use the same project > to cover > both. > > If you can clarify then we can move forward on this case. > > thanks > Aniruddh > > > Aarti Pai wrote: >> Hi Nasser, >> >> These questions are to be directed to your case owner. - Aniruddh? >> (I'm the PM that coordinates meetings, agendas etc for the ARCs.) >> Your case owner works directly with the case material and the project >> team on architectural issues. >> >> Aarti >> >> Nasser Nouri wrote: >>> Hi Aarti, >>> >>> Based on James Carlson's email (below), the status of DTrace Java >>> API is "Committed" not "Evolving". The one-pager document is updated >>> based on that information. Additionally, the one-pager document >>> specifies that the DTrace GUI utilizes the DTrace Java API. >>> >>> What is the next step? Please advise. >>> >>> Thanks, >>> __Nasser >>> >>> Tom Childers writes: >>>> As we mentioned in the LSARC meeting this morning, the DTrace Java >>>> API was established by PSARC case 2006/054, >>>> http://sac.sfbay/PSARC/ 2006/054. It looks like the interfaces and >>>> stability are only described in the mail contents, and dtrace.jar >>>> is described as "Evolving". Can you please update the case >>>> materials to show you import this interface (or whichever one you >>>> use)? >>> >>> Nit: it's in the OS/Net consolidation and reviewed by PSARC, so the >>> old "Evolving" used here maps into the current "Committed." >>> >> >> > -- next part -- An embedded and charset-unspecified text was scrubbed... Name: dtracegui_onepager.txt URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20081020/c8727c41/attachment.txt>
IBTF IO Memory [PSARC/2008/630 FastTrack timeout 10/17/2008]
On 10/15/08 12:07, Ted H. Kim wrote:
> Kais,
>
>
> Kais Belgaied wrote:
>> - Case boundary question: since this marks a flag day for both TI and
>> CI, can you list the components
>> that are affected by this flag day?
>
> Most of the IB modules in ON -
> framework: IBTL
> IB ULPs (TI): IPonIB, SDP, NFS/RDMA, uDAPL
> HCA Drivers (CI): Tavor, Hermon
at the risk of re-stating the obvious, all changes in the above 3 sets
of components are in-scope of this case,
right?
>
>
>> - I am not clear on the consumer side of this new interface: What
>> prompts a ULP to start using this interface?
>> Is it expected to attempt ibt_alloc_io_mem() until it exhausts all
>> resources?
>> It would be easier to assess the completeness and the usefulness of
>> the TI if you either extended the case's scope
>> to include at least the changes on one transport consumer or gave a
>> real example thereof.
>
> We are in the process of fixing bugs in certain IB ULPs to
> be good citizens in big SPARC platforms with memory DR where
> we have to be careful about what is in/out of the cage.
> The current plan for ULP usage (i.e. TI usage) is related
> to this motivation.
>
>
>> - mi_ibt_version seems to be an enumeration of apparently mutually
>> exclusive values IBTI_V{1,2,3}
>> yet the definition suggests a combination of independent (discrete)
>> capabilities
>> (FMR support, DMA wrapper support, etc.)
>
> The features are examples of what was included at each version change.
> More discussion of the relationship between ABI and features below ...
>
>
>> . Is there any consumer of this interface that uses DMA wapper
>> but not FMR?
>
> Well to be honest FMR in the current form turned out to be a failure.
> So no one uses FMR in ON right now.
>
> But I think more generally what is going to happen is that
> the features will be used independently of each other,
> since they are generally not related to each other.
>
>
>> . For future evolution, is the mi_ibt_version always intended to
>> express a monotonically increasing set
>>of capabilities (capabs of V(n+1) includes all capabs of N(n)) ?
>
> Yes, that is the intent, but it is not guaranteed. However,
> as you might imagine, it would involve a great deal of
> discussion/agreement to remove anything and the ARC would be
> in the loop.
>
>
>> Basically I'm trying to see if information of different nature if
>> being encoded in the same field. Without slipping
>> in a design discussion you should consider if two fileds are more
>> appropriate: 1 version (number or enum) and one capabs (bitmask).
>
> There are in fact capability bitmasks elsewhere.
> In IB there are a number of optional features. So the bitmasks
> generally are for saying you have these optional features.
>
> But the version number is more an ABI thing, and it is mistake
> to conflate the too, though the reason we have to change ABI
> is that new features demand more fields in the structs, etc.
so are you fixing the mistake of conflating the capabs + version ? I
still see the updated material unchanged
on that.
>
>
Kais.
PSARC 2008/625 - Streamline ARC 20Q
John Plocher writes: > James Carlson wrote: > > John Plocher writes: > >> they need help > > > > It sounds to me like you might be expecting at least some teams > > (perhaps "many") to be fully conversant in all of the Best Practices. > > I'm not sure that's realistic. > > We already expect project teams to be conversant in cstyle, compiler > usage, webrev, hg, ddi/dki, posix, etc etc etc. What is special about > the things enumerated in the BP/P archives that makes them topics that > teams aren't expected to be conversant in? One of the big (and obvious) differences is that we have automated tools in place to check for common mistakes in some of the things in the first list, and we generally don't have tools in place for much (if any) of the BP issues. Another important issue is that being able to use the tool set (compiler, hg, and so forth) is a basic requirement to do anything at all. It's in the developer's face every single day, and thus gets practiced often. The nuances of patch delivery, security practices, internationalization and other "best practice" topics simply are *not* part of the ordinary development experience. Heck, many developers aren't even experts with the tool set. Many don't quite the details of working with lint, or how the makefiles go together, or what the build tools themselves are doing. They _often_ don't need to know this and are instead more deeply involved in the particular technology that they're developing. That might be lamentable, but I don't think it's actually avoidable. These extraneous things are details that a project team typically ignores until the end (if they're examined at all), and only then does someone seek out an expert to help them out (or they just stumble ahead through integration, possibly with bugs). I've certainly been there myself. I'd be surprised if anyone's done a non-trivial project and not bumped against "you want me to do a what with who?" sort of issue. Also, the list that you gave is not really all that homogeneous. Among those things, not so many are really experts in DDI/DKI or in POSIX -- or really need to be in order to get their work done. > What can we do to make > them more relevant? That's a good question, but I don't think I have any good answers. Many things are in the BP list because there's no other clear way to handle them; they're design level issues that you really can't "enforce" through any simple tool set. > I don't want to imply that it is all on the project team's plate - if > there is ignorance or confusion, those of us who are more ARC-aware > need to be accessible and willing to step in and help. Unfortunately, it's more than just ARC awareness. Many of those BPs contain information that's rather detailed and related to one particular domain: in other words, it may be too much to expect that even ARC members are experts in every single one of those areas. (Quick and without looking: what chemicals are on the 'lead-free hardware policy' list?) > The failure mode that I fear is that nobody bothers to answer the "do > you know what the ARC BPs and Policies are and how they apply to your > project?" question, the integration-quality of our OS goes to hell and > the ARC job becomes one of trying to reverse engineer and remediate > every project. Uugh. That's exactly why I think a single "do you follow all the rules?" question is pretty close to worthless. The way I actually envision this to work is that non-trivial projects should show up for an inception review. During inception, the ARC members can say things like, "it looks like you're making security- related decisions, so do make sure that you review this list of best- practice documents, and be ready to explain how you comply with those practices during your commitment review." Yes, that's annoyingly repetitive, and, yes, it'd be great if project teams could just automatically determine what things they need to do even when those things are far outside of their domain of expertise, but I do think that *expecting* and depending on them to do that is too much. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
ACLs for CIFS/SMB shares [PSARC/2008/641 FastTrack timeout 10/27/2008]
On Mon, Oct 20, 2008 at 11:25:28AM -0600, Doug McCallum wrote: > >NFS supports share ACLs of a sort now in the form of host/negroup lists. > > > >Shouldn't CIFS also support such an ACL mechanism? > > > The NFS host based access control will be putback into Nevada in build 102. Er, NFS has had it forever. Do you mean that CIFS will also have it in build 102? If so, that's really cool. > >I pointed out that NFS has a notion of shares and share ACLs, but I see > >that the notion of share ACLs for CIFS is based on Windows file ACLs, as > >opposed to the NFS share-ACL-as-host/netgroup-list that we have now. > > > >In NFS there's no TreeConnect-type operation, but a share-level ACL can > >still be applied in operations that deal with paths. > > Correct. Can we expect to see a future case adding share-level ACLs (beyond host-based ACLs) to the NFS server?
ACLs for CIFS/SMB shares [PSARC/2008/641 FastTrack timeout 10/27/2008]
On Mon, Oct 20, 2008 at 11:19:34AM -0600, Doug McCallum wrote: > Nicolas Williams wrote: > >On Mon, Oct 20, 2008 at 10:43:31AM -0600, Tim Haley wrote: > > > >>CIFS is the only protocol we currently support that has the > >>concept of shares (resources in sharemgr/share terms) so this > >>implementation will initially only provide support for CIFS. > >> > > > >That can't possibly be right. NFS has long had a concept of shares, and > >share ACLs too. > > The NFS host access control (which is being added to SMB as well) is > not ACL based. I was specifically responding to the claim about the notion of shares. > They are strictly based off of the client IP address and not based on > the user's ID. That's true, but many people call these ACLs. An ACL need not have a particular form in order to be deserving of the term "ACL." Nico --
ACLs for CIFS/SMB shares [PSARC/2008/641 FastTrack timeout 10/27/2008]
Nicolas Williams wrote: > On Mon, Oct 20, 2008 at 11:25:28AM -0600, Doug McCallum wrote: > >>> NFS supports share ACLs of a sort now in the form of host/negroup lists. >>> >>> Shouldn't CIFS also support such an ACL mechanism? >>> >>> >> The NFS host based access control will be putback into Nevada in build 102. >> > > Er, NFS has had it forever. Do you mean that CIFS will also have it in > build 102? If so, that's really cool. > Sorry. I did mean NFS style host based access control on CIFS. > >>> I pointed out that NFS has a notion of shares and share ACLs, but I see >>> that the notion of share ACLs for CIFS is based on Windows file ACLs, as >>> opposed to the NFS share-ACL-as-host/netgroup-list that we have now. >>> >>> In NFS there's no TreeConnect-type operation, but a share-level ACL can >>> still be applied in operations that deal with paths. >>> >> Correct. >> > > Can we expect to see a future case adding share-level ACLs (beyond > host-based ACLs) to the NFS server? > There aren't any current plans. The CIFS share-level ACLs are part of the Microsoft specification so we need to get those added. It seems like a reasonable RFE for NFS to provide an alternative namespace using resource names.
ACLs for CIFS/SMB shares [PSARC/2008/641 FastTrack timeout 10/27/2008]
Nicolas Williams wrote: > On Mon, Oct 20, 2008 at 11:19:34AM -0600, Doug McCallum wrote: > >> Nicolas Williams wrote: >> >>> On Mon, Oct 20, 2008 at 10:43:31AM -0600, Tim Haley wrote: >>> >>> CIFS is the only protocol we currently support that has the concept of shares (resources in sharemgr/share terms) so this implementation will initially only provide support for CIFS. >>> That can't possibly be right. NFS has long had a concept of shares, and >>> share ACLs too. >>> >> The NFS host access control (which is being added to SMB as well) is >> not ACL based. >> > > I was specifically responding to the claim about the notion of shares. > NFS has shares, but not the same concept. The parenthetical addition of the "resources" terminology was intended to clarify the difference. NFS doesn't really have the same definition. The terminology can be confusing between protocols that have similar, but slightly different, semantics. > >> They are strictly based off of the client IP address and not based on >> the user's ID. >> > > That's true, but many people call these ACLs. An ACL need not have a > particular form in order to be deserving of the term "ACL." > NFS hasn't documented them exactly as ACLs, but I see where you are coming from. Access lists and access control lists are similar. We tend to refer to the NFS style as host based access and the SMB ACLs as share level ACLs.
ACLs for CIFS/SMB shares [PSARC/2008/641 FastTrack timeout 10/27/2008]
On Mon, Oct 20, 2008 at 10:43:31AM -0600, Tim Haley wrote: > During SMB "tree connect" is will be necessary to get the ACL > that is set on a share and use it to setup the initial access. > The ACLs are expected to be stored in objects within a new > directory under .zfs. /dataset/.zfs/shares/ will contain > objects with names that match the shares defined on that > dataset. Just before the tree connect, the sharename will be > looked up in the .zfs/shares directory, the ACLs obtained and > then processed relative to the user making the tree > connect. The result of processing the ACL will be used to > determine access. > > The ZFS changes will include a means to create/remove the > share objects within the new .zfs/shares directory. Once > created, it will also be possible to use the standard ACL > interfaces to get/set ACLs on these new objects. That is, > chmod and ls will be used. NFS supports share ACLs of a sort now in the form of host/negroup lists. Shouldn't CIFS also support such an ACL mechanism? > Note that there can be multiple shares (resources) for any > given path that is shared. This mechanism allows setting > different ACLs for the same path depending on the name it is > associated with. Interesting. I believe there's nothing in the NFSv4 protocol precluding the same feature, but that our NFS server doesn't have this. Out of curiosity: is there a need for this (multiple shares for a given path/dataset) in NFS? > CIFS is the only protocol we currently support that has the > concept of shares (resources in sharemgr/share terms) so this > implementation will initially only provide support for CIFS. I pointed out that NFS has a notion of shares and share ACLs, but I see that the notion of share ACLs for CIFS is based on Windows file ACLs, as opposed to the NFS share-ACL-as-host/netgroup-list that we have now. In NFS there's no TreeConnect-type operation, but a share-level ACL can still be applied in operations that deal with paths. Nico --
ACLs for CIFS/SMB shares [PSARC/2008/641 FastTrack timeout 10/27/2008]
On Mon, Oct 20, 2008 at 10:43:31AM -0600, Tim Haley wrote: > CIFS is the only protocol we currently support that has the > concept of shares (resources in sharemgr/share terms) so this > implementation will initially only provide support for CIFS. That can't possibly be right. NFS has long had a concept of shares, and share ACLs too. Nico --
ACLs for CIFS/SMB shares [PSARC/2008/641 FastTrack timeout 10/27/2008]
Nicolas Williams wrote: > On Mon, Oct 20, 2008 at 10:43:31AM -0600, Tim Haley wrote: > >> During SMB "tree connect" is will be necessary to get the ACL >> that is set on a share and use it to setup the initial access. >> The ACLs are expected to be stored in objects within a new >> directory under .zfs. /dataset/.zfs/shares/ will contain >> objects with names that match the shares defined on that >> dataset. Just before the tree connect, the sharename will be >> looked up in the .zfs/shares directory, the ACLs obtained and >> then processed relative to the user making the tree >> connect. The result of processing the ACL will be used to >> determine access. >> >> The ZFS changes will include a means to create/remove the >> share objects within the new .zfs/shares directory. Once >> created, it will also be possible to use the standard ACL >> interfaces to get/set ACLs on these new objects. That is, >> chmod and ls will be used. >> > > NFS supports share ACLs of a sort now in the form of host/negroup lists. > > Shouldn't CIFS also support such an ACL mechanism? > The NFS host based access control will be putback into Nevada in build 102. It has been a long standing case for adding Montana equivalent support to NFS and CIFS. > >> Note that there can be multiple shares (resources) for any >> given path that is shared. This mechanism allows setting >> different ACLs for the same path depending on the name it is >> associated with. >> > > Interesting. I believe there's nothing in the NFSv4 protocol precluding > the same feature, but that our NFS server doesn't have this. > > Out of curiosity: is there a need for this (multiple shares for a given > path/dataset) in NFS? > There may not be anything that precludes it, but tI don't know of any implementations that provide for it. NFS essentially uses the "path" as the share name while SMB doesn't advertise the underlying path. If NFS implements an equivalent mechanism, this implementation would allow for it to be added. > >> CIFS is the only protocol we currently support that has the >> concept of shares (resources in sharemgr/share terms) so this >> implementation will initially only provide support for CIFS. >> > > I pointed out that NFS has a notion of shares and share ACLs, but I see > that the notion of share ACLs for CIFS is based on Windows file ACLs, as > opposed to the NFS share-ACL-as-host/netgroup-list that we have now. > > In NFS there's no TreeConnect-type operation, but a share-level ACL can > still be applied in operations that deal with paths. > Correct. Doug
ACLs for CIFS/SMB shares [PSARC/2008/641 FastTrack timeout 10/27/2008]
Nicolas Williams wrote: > On Mon, Oct 20, 2008 at 10:43:31AM -0600, Tim Haley wrote: > >> CIFS is the only protocol we currently support that has the >> concept of shares (resources in sharemgr/share terms) so this >> implementation will initially only provide support for CIFS. >> > > That can't possibly be right. NFS has long had a concept of shares, and > share ACLs too. > The NFS host access control (which is being added to SMB as well) is not ACL based. They are strictly based off of the client IP address and not based on the user's ID. SMB share ACLs are just like file ACLs except that they are based on the share name. Each SMB share name for the same path can have its own set of ACLs. Doug
PSARC 2008/631 - Kerberos PKINIT
The timer has expired and there haven't been any further comments, so I'm marking the Kerberos PKINT case as approved. -Wyllys Ingersoll
[kerberos-discuss] Kerberos PKINIT [PSARC/2008/631 FastTrack timeout 10/17/2008]
On Wed, Oct 15, 2008 at 03:48:21PM +0200, Mark Phalan wrote: > > Does OpenSolaris have any latitude in changing the attributes or do they > > need to be kept verbatim as > > they come from MIT code drops? > > We have latitude but generally we like to remain as compatible with > upstream as possible. Right. Differing from MIT -> more merge/sync work down the line (and/or more work to do to get Solaris' differences integrated into MIT krb5). > > If we do, then the choice of boolean flag_RSA_PROTOCOL[=yes] excluded other > > key exchange algorithms, such as ECC. > > As PKINIT (RFC 4556) doesn't support ECC key exchange I don't see an > immediate need for this and is not worth (in my opinion) breaking MIT > compatibility for it now. I should note that this config file option is > "Volatile". FYI, RFC5349 adds ECDH support for PKINIT. Note though that flag_RSA_PROTOCOL does not preclude any ECC enhancements. It merely enables one key exchange method (RSA key transport) for PKINIT. One supposes that that means that we can expect more boolean flag__PROTOCOL parameters. The "flag_" prefix is annoying (read: redundant), but I'll live. IOW, this parameter is not a problem. Nico --
ACLs for CIFS/SMB shares [PSARC/2008/641 FastTrack timeout 10/27/2008]
I am sponsoring the following fasttrack for Doug McCallum. The case introduces ACLs to control access to SMB shares. Requested binding is minor. Timeout is 10/27/2008. Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: ACLs for CIFS/SMB shares 1.2. Name of Document Author/Supplier: Author: Doug McCallum 1.3 Date of This Document: 20 October, 2008 2. Project Summary 2.1. Project Description: Project is to provide ACLs at the CIFS/SMB "share" level. This is a standard feature in Microsoft implementations and is needed for completeness. ACLs on shares will only be supported on ZFS file systems. 2.2. Risks and Assumptions: Assumes changes to ZFS to provide a place to store the share ACLs. 4. Technical Description: 4.1. Details: During SMB "tree connect" is will be necessary to get the ACL that is set on a share and use it to setup the initial access. The ACLs are expected to be stored in objects within a new directory under .zfs. /dataset/.zfs/shares/ will contain objects with names that match the shares defined on that dataset. Just before the tree connect, the sharename will be looked up in the .zfs/shares directory, the ACLs obtained and then processed relative to the user making the tree connect. The result of processing the ACL will be used to determine access. The ZFS changes will include a means to create/remove the share objects within the new .zfs/shares directory. Once created, it will also be possible to use the standard ACL interfaces to get/set ACLs on these new objects. That is, chmod and ls will be used. Note that there can be multiple shares (resources) for any given path that is shared. This mechanism allows setting different ACLs for the same path depending on the name it is associated with. CIFS is the only protocol we currently support that has the concept of shares (resources in sharemgr/share terms) so this implementation will initially only provide support for CIFS. 4.2. Bug/RFE Number(s): 6582163 Access Control List (ACL) for Shares 4.3. In Scope: Only ZFS file systems will be supported. 4.4. Out of Scope: 4.5. Interfaces: Standard ACL interfaces will be used (ls, chmod). 4.6. Doc Impact: CIFS Administration Guide Modification to the zfs(1M) man page: -- When the "sharesmb" property is changed for a dataset, the dataset and any children inheriting the property are re-shared with the new options, only if the property was previously set to "off", or if they were shared before the property was changed. If the new property is set to "off", the file systems are unshared. +When SMB shares are created, the SMB share name appears as an +entry in the .zfs/shares directory. You can use the ls or +chmod command to display the share-level ACLs on the entries +in this directory. -- 4.7. Admin/Config Impact: N/A 4.8. HA Impact: N/A 4.9. I18N/L10N Impact: N/A 4.10. Packaging & Delivery: N/A (existing packages will be used) 4.11. Security Impact: Doesn't change any existing security APIs or features. It does add an additional security mechanism. 4.12. Dependencies: N/A 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
2008/640 iSCSI With DHCP
Casper.Dik at Sun.COM writes: > > > >That's not legal, for the reason given above. DHCP servers check for > >address in use (by ARP and ICMP) before assigning them to clients. > > > > And what is the rest doing? What happens if you don't give up the > address? By "the rest," I assume you're referring to DHCP servers that somehow manage to ignore the text in section 3.1(2) of RFC 2131, and thus fail to check whether the address is in use before handing it out again. In that case, the server thinks that (since the lease expired), the address is free to be reused. When the address is eventually reused, the other client that gets your still-in-use address is _required_ to check whether that address is errantly in use (section 3.1(5)), and send DHCPDECLINE if it is. When it gets your address, it'll see that you're still using it, and refuse to configure it. That DHCPDECLINE message generally causes the server to mark the address as "unusable" so that it's taken out of the address pool. As in the previous case (where the server detects the duplicate), the results are the same: addresses leak out of the pool, because nobody knows who is supposed to be using them. > (My systems have a a "pkill -9 dhcpagent" when it sees a "drop/release" > message). The system then works. Yes; it's possible to damage the daemon in order to obtain the behavior you need for some special situation, but I think it'd be far better if we redesigned the interaction to eliminate the "special" cases. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
2008/640 iSCSI With DHCP
James Carlson wrote: > I'm sponsoring this fast-track request for Jack Meng. The timer is > set to 10/24/2008. > > Background > > By default, dhcpagent "canonizes" interfaces under its control on > receipt of SIGTERM. This means that it will reset the IP address > back to 0.0.0.0 during shutdown. This happens regardless of whether > dhcpagent is configured to release or drop leases. I'm sure this was considered but why bother with the reset to 0.0.0.0 on shutdown at all ? What does it achieve ? If that wasn't done would there be any need for this special knowlege of iSCSI (and NFS) both of which seem very "icky" but if needs must. What breaks if dhcpagent does not reset back to 0.0.0.0 on shutdown ? Could it still send the DHCP release to the DHCP server but not reset the interface ? When is dhcpagent going to call the new ioctl ? What are the responses it gets back and what circumstances ? What if we have a "mixed" boot environment where one size of the mirror in the ZFS root pool is local disk and the other is iSCSI ? Does that count as being ISCSI_IS_ACTIVE? What if there are no "boot" pools/filesystems under iSCSI but there are other active iSCSI devices ? Is this only if there is an an iSCSI initiator active, what about targets ? [ Though I wouldn't expect those machines to be iSCSI boot ]. -- Darren J Moffat
2008/640 iSCSI With DHCP
Darren J Moffat writes: > > By default, dhcpagent "canonizes" interfaces under its control on > > receipt of SIGTERM. This means that it will reset the IP address > > back to 0.0.0.0 during shutdown. This happens regardless of whether > > dhcpagent is configured to release or drop leases. > > I'm sure this was considered but why bother with the reset to 0.0.0.0 on > shutdown at all ? What does it achieve ? [For what it's worth, someone noted by private email that the word "canonize" is used quite incorrectly here. I know. The code has been like that for a long time.] Once we lose the lease, we're required to stop using the address right away, because it may be assigned to someone else. When the dhcpagent daemon exits, though, we lose the ability to take down the address when required. We thus tear it down when we can. Part of the problem is that we have no way of knowing why dhcpagent is being sent SIGTERM. It could be that the user just wants that one service to stop and will wait hours or months before doing anything else, and we can't leave our address in place. It could also be that the system is being shut down, and we can safely just exit, leaving the address working until the OS halts. This is what the text refers to in the final section. This project is just a short-term fix for the operation of iSCSI with DHCP, and slightly cleaner and simpler than the one already in place for NFS. As a separate project, and possibly not a fast-track, someone needs to look into how DHCP, networking, and SMF all interact. I think a better answer in that direction is to make dhcpagent hang around as long as the lease is in place. That'll take a fair bit of rework, though, as we wouldn't want this one service "failing" to exit to block the shutdown of others on which the service claims dependency for start-up purposes. > If that wasn't done would > there be any need for this special knowlege of iSCSI (and NFS) both of > which seem very "icky" but if needs must. What breaks if dhcpagent does > not reset back to 0.0.0.0 on shutdown ? DHCP itself breaks. The server may reallocate the address, discover that it's still in use, and end up marking it as permanently "unusable" due to a conflict. > Could it still send the DHCP > release to the DHCP server but not reset the interface ? That's not legal, for the reason given above. DHCP servers check for address in use (by ARP and ICMP) before assigning them to clients. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
